Spec-driven development with existing task packets

Keep one authority for the task

Spec-driven development starts by describing the intended behavior and how a reviewer will recognize it. In this foundation, GitHub Spec Kit is the selected method to bring that discipline into existing task packets. OpenSpec is an optional small-change authoring pilot. Neither becomes a second scheduler, permission system, or mandatory approval chain. A generated plan does not widen the authorized paths or turn a deferred integration into an active one.

The local packet contract already records an identifier, task class, level, skills, dated inputs, outcome, acceptance, stop conditions, budget, allowed paths, and forbidden work. Retain that record as the authority. Use specification documents to explain behavior and implementation choices in enough detail to make the packet reviewable. This guide proposes a mapping, not a report that either CLI was installed or run.

Map artifacts to questions a reviewer asks

Keep the packet identifier on every supporting document. If an authoring tool creates additional files, give those files an approved location before generation. In a shared worktree, file existence is not ownership: preserve other writers' modifications, capture a status baseline, and use non-overlapping edit paths. Review discrepancies between the specification and packet before work proceeds.

Worked example: a catalog search change

Suppose a fictional local catalog viewer should distinguish a missing schema from an empty one. The behavior specification says: when a source card supplies only a field count, display “schema not supplied.” Do not generate parameter names, and do not expose a Run button. When a real schema is present in a later authorized fixture, preserve its provenance and validate it under a separately defined rule. These are proposed behaviors for an exercise, not claims about the present product.

The packet outcome becomes “a reviewer can see that numeric field counts do not establish callable parameters.” Inputs name a small synthetic fixture and its revision. Allowed work is limited to that fixture and an isolated renderer draft. Forbidden work includes credentials, live connectors, package installation, and existing catalog records. A stop condition names unexpected changes by another writer. Acceptance includes one card with a count, one with no count, and one malformed count. Each must produce an explicit, understandable result without suggesting executable readiness.

Plan evidence before implementation

Write expected results beside the cases before changing the draft. Record the exact command or manual procedure needed to inspect them. Save an observed result, timestamp, and artifact reference after running a check. “Tests planned,” “tests run,” and “tests passed” describe different states. A screenshot can show presentation; it cannot by itself prove database integrity, account permissions, or absence of side effects.

If a check fails, preserve the result and identify the violated criterion. If a needed permission is missing, continue only with independent authorized work. Do not broaden scope merely to make a demonstration look complete. At handoff, explain which behavior is implemented, which is documented, and which remains untested.

Choose the authoring method conservatively

Use Spec Kit's specification, planning, and task decomposition approach where it improves the existing packet. Treat concrete commands and generated layouts as version-dependent details to verify before adoption. Use OpenSpec optionally for a small change description and review its telemetry policy before any pilot. The supplied review establishes CLI/file workflows for these projects; transcript assertions of REST or official MCP interfaces are unsupported. Do not publish those assertions as integrations.

Exercise and acceptance

Take the fictional catalog change and create one packet plus a short behavior specification. Include the three cases, a phase boundary, source dates, an exact file allowlist, and an unresolved-question list. Ask a peer to introduce a contradictory requirement: “generate missing parameter names automatically.” Acceptance: you can show why that request conflicts with the outcome and evidence limits, preserve the original packet, and record the proposed change for review. You should finish with one authoritative contract and traceable supporting artifacts, not competing task queues.

Continue with the platform architecture guide for infrastructure boundaries and the integration directory for readiness terms. The learning roadmap provides prerequisite exercises. Existing knowledge practice and adoption paths pages offer native navigation; their current rendering was not verified here.

Sources and limits

This lane made no live documentation requests or CLI trials. An authenticated client connection is not verified. The mapping and exercise are original recommendations, not vendor compatibility certification. Generated files, actual command behavior, telemetry, and fit with a particular team's review process still require bounded evaluation.