groundwork-specflow

Skills

18 in the Claude listing

• bootstrapCreate or complete the foundation documents (PROJECT.md, ARCHITECTURE.md, CONSTITUTION.md, AGENTS.md, CONTRACTS/, DECISIONS/) for the current workspace or repo.
• Code layoutDecide and follow where code lives in a repo — the GroundWork standard layout (core / connectors / entrypoints / config / wiring) or the repo's own existing structure.
• Code qualityRecord and follow the repo's code quality toolchain (GroundWork's standard formatter, linter, type checker and test runner, or the repo's own tools) and the coding rules every agent follows.
• Fix bugThe lifecycle for fixing a defect — reproduce, find the root cause, tie it to the requirement(s) or RFC it violates (possibly across several specs), classify it (code-bug / spec-gap / design-flaw), wr
• handoverWrite the handover for a finished or paused feature so the next engineer or agent can continue without reverse-engineering decisions.
• implementImplement the active feature task by task, keeping docs in sync and giving the user a manual test.
• interviewInterview the user about what they want built until the picture is complete and unambiguous, before any RFC, spec or code.
• ownershipRecord and look up who is responsible for what — who requested a feature, who owns it, who implemented it, who deployed it, who supports it — and whom to contact about any feature, including ones a ch
• Plain writingHow to write replies and documents that a busy person actually reads and can decide from — short, plain, decision-first.
• refreshBring the foundation documents (PROJECT.md, ARCHITECTURE.md, AGENTS.md, CONSTITUTION.md — in the repo and in the workspace above it) back in line with reality after things changed, then confirm them.
• resumePick up unfinished work in a new session — an RFC mid-interview, an approved RFC with no spec, a spec without a plan, a half-built feature, an open bug, or work blocked by another feature.
• workflowThe groundwork operating model — workspace vs repo levels, the document pipeline (interview → RFC → approval → spec → plan → tasks → evals → implement → handover) and who may do what.
• Write contractWrite or update a cross-repo contract in the workspace's CONTRACTS/ folder (shapes, examples, failure semantics, version).
• Write evalsWrite evals.md — the scenarios, edge cases and unplanned cases that prove the feature is right — before any code.
• Write planWrite plan.md (how) for the active feature, citing the spec's requirement ids.
• Write rfcTurn a completed interview into an RFC document in DECISIONS/ and request human review.
• Write specCreate and fill the spec (what and why, numbered FR/NFR/AC, manual test) for a feature in a repo from an approved RFC.
• Write tasksBreak the plan into small, verifiable tasks in tasks.md.