Навык Claude Code для разработки на основе спецификаций. specs/ говорит, что программное обеспечение должно делать и остается авторитетным для жизни системы. plans/ отслеживает работу в полете, которая приводит код в соответствие со спецификациями, один ограниченный кусок за раз и зависает как запись того, что было построено. Отслеживание проблем остается нерешенным.

Специфики написаны в первую очередь для агентов, выполняющих работу: они представляют собой то, как реализатор сообщает о предполагаемом поведении от случайного, и как решение, принятое за один сеанс, выживает в следующий. Люди читают их, когда им нужно знать, что было согласовано; им не нужно читать их, чтобы использовать проект.

Как работа переходит от проблемы к слиянию

Каждый кусок работы едет ** одна ветка и один PR, обрамленный вокруг функции, которая будет поставлять **. PR открывается рано только со спецификацией и планом на борту, подбирает реализацию на той же ветке и сливается после завершения плана.

Здесь дело не только в пиаре. Два случая, когда незавершенный план находится на главной ветке, - это партия планов, которые должны быть выполнены, и предложение, строительство которого ждет стороннюю сторону. Все остальное, что «спланировано, но не начато», является проблемой.

SpecOps

A Claude Code skill for spec-driven development. specs/ says what the software should do and stays authoritative for the life of the system. plans/ tracks the work in flight that brings the code into line with the specs, one bounded chunk at a time, and freezes as the record of what got built. Your issue tracker stays the backlog.

Specs are written primarily for the agents doing the work: they are how an implementer tells an intended behavior from an accidental one, and how a decision made in one session survives into the next. People read them when they need to know what was agreed; they do not need to read them to use the project.

How work flows from issue to merge

Every chunk of work rides one branch and one PR, framed around the feature that will ship. The PR opens early with only the spec and plan aboard, picks up the implementation on the same branch, and merges once the plan is complete.

flowchart LR
    I[Issue in the trackerwhat's wanted, how urgent]
    subgraph PR["One feature branch → one PR (opened as a draft at step 1)"]
        direction LR
        S["1 · docs(specs): commitwhat should be true"] --> P["2 · plan filescope · validation"] --> C["3 · implementationbrought to the spec"] --> D["4 · closeout commitplan → done"]
    end
    I --> S
    D --> R["Reviewspec diff → code → evidence"] --> M((merge))

Spec-only PRs are not a thing here. The two cases where an unfinished plan sits on the main branch are a bootstrap batch of plans about to be executed, and a proposal whose build waits on an outside party. Everything else that is “planned but not started” is an issue.

What issues, specs, and plans are each for

A spec carries its own why: decisive principles, written down in specs/principles.md and referenced into the specs they govern, so the cases no rule enumerated get resolved the way the author would have. And spec↔code drift is a bug, not debt: when the two diverge the spec is the authority until a review says otherwise, and a drift auditor keeps them honest.