sync-specs

Synchronizes specification documents with task progress across kanban workflow stages.

1|1|Updated Jul 6, 2026
One-click install
npx skills add https://github.com/gabesan21/project-of-projects --skill sync-specs-gabesan21
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sync-specs
Source: https://github.com/gabesan21/project-of-projects/tree/main/.agents/skills/sync-specs
Command: npx skills add https://github.com/gabesan21/project-of-projects --skill sync-specs-gabesan21

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Specs that drift away from delivered reality become misleading documentation; this Skill enforces mandatory spec updates as tasks move through stages 002, 004, and 005_closing so specifications always reflect the agreed current state. ## Core Features & Use Cases - Stage-gated spec obligations: Defines what must happen to specs at each kanban stage, from identifying affected contracts in 002 to reflecting delivered reality at close-out in 005_closing. - Canonical spec format enforcement: Requires the SPEC template with fields like id, project, domain, kind, status, implementation, origin, and reciprocal supersession links. - Drift auditing: Audits 005_closing cards and linked specs for implementation drift, broken supersession links, and unreachable current specs. - Use Case: When closing a task card, an agent checks every linked spec, resolves open questions, and sets implementation status to partial, implemented, or not_applicable in the same wrap-up that writes the memory. ## Quick Start Ask the agent to audit the specs linked to the current 005_closing card and update their implementation status to match what was actually delivered.

Frequently Asked Questions about sync-specs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep specs in sync with completed tasks?▼

Update specs at each kanban stage: link affected contracts in 002, record divergence in 004, and at 005_closing reflect delivered reality by setting implementation to partial, implemented, or not_applicable. Checking spec impact at close-out is mandatory, not optional.

What fields does a canonical spec document require?▼

A canonical spec requires id, project, domain, kind, status, implementation, origin, dates, supersedes, and superseded_by in its frontmatter. It follows the SPEC template and stores durable behavior, invariants, interfaces, errors, and criteria.

When should a spec change go back to the planning stage?▼

A material contract change discovered during implementation in stage 004 returns to stage 002 for re-planning. Minor divergences are recorded in Open items and the card without restarting the workflow.

What should a spec never contain?▼

A spec must never contain reasoning, edit sequences, changelogs, or completed-task history. It stores only durable behavior, invariants, interfaces, errors, and acceptance criteria describing the agreed current state.

How do I audit specs for implementation drift?▼

Audit 005_closing cards and their linked specs for implementation drift, broken reciprocal supersession links, and current specs unreachable from the specs/INDEX.md or a domain overview. Every draft or active spec must be reachable directly or through one indexed domain overview.