Handoff-driven development (HDD)

Русская версия — ru/.

A specification system for solo developers and small teams working with LLM agents. HDD = Spec-driven development + handoffs: specs describe the existing system and are obliged to stay true; handoffs carry the context of unfinished work across sessions and tasks.

Two problems it solves:

1. Context hygiene. The model's context must contain what the task needs — and nothing else. The right context is the right answer. Handoffs are recipes for assembling context per task, including what NOT to load.
2. Task and session switching. Tasks run in parallel, sessions end. Switching between tasks is choosing a handoff; a new session picks up exactly where the previous one left off.

A long-lived track eventually stops being one piece of work. Then the handoff stops being a document and becomes a thin index: a map of strands, each with a permanent home of its own. Distillation does not wait for the track to close.

Companion article: English (dev.to) · Russian (Habr).

What's inside

• specs/spec-specs.md — the rules of the system in one document: genres, statuses, conventions, tombstone protocol, backlogs, work tracks and their second level (strands, consolidation, work plans), audit
• specs/specs-map.md — starter root specification map
• specs/handoff-template.md — session handoff template, in both shapes: a plain handoff and a consolidated thin index with a strand map
• specs/TRACKS.md / specs/TRACKS-LOG.md — index of live tracks / archive of closed ones
• specs-audit.py — audit script: broken links, orphaned specs, missing status lines
• CLAUDE-block.md — ready-made block for your agent config (CLAUDE.md)
• ru/ — the whole thing in Russian: README, the spec set, the CLAUDE.md block. A translation — the English set is canonical, and on divergence it wins

This repository is itself organized by its own rules: the specs live in specs/, the map reaches them, and python3 specs-audit.py passes clean.

How to apply

Clone it — or simply give your agent the link with this prompt, verbatim:

Look at the repository . Let's apply the same specification system in my project: lay out the maps and the rules across our structure, create TRACKS.md, and propose the first tracks.

It will figure out the rest.

Part of your specs is generated — a brainstorming skill, a design or ADR tool writing into fixed paths? Append one more line:

Any directory a tool writes into on its own — declare it a subproject with its own rules file and index, reach it from the root map with a single link, and don't change its paths; after each generation, update that index and the track in TRACKS.md.