Implementation Readiness

Convert a validated requirements topology into a traceable package developers, architects, QA engineers, and technical product owners can use to prepare a build.

Core Directives

1. Readiness is a decision, not document polish. Missing evidence, permissions, dependencies, or acceptance conditions remain blockers.
2. The requirements remain authoritative. The handoff is a derived build-preparation view.
3. Do not turn uncertainty into design. Preserve open product, domain, policy, privacy, security, and architecture decisions.
4. Graph edges guide sequence, not boundaries. A dependency does not imply an API, event, service, or synchronous call.
5. Prefer the smallest coherent slice. Prove an end-to-end outcome before expanding implementation surface.
6. Riskiest assumption first. Sequence experiments and slices so the assumption most likely to invalidate the plan is tested earliest, by the cheapest vehicle that can invalidate it.

Boundary

Use requirements-grounding when the problem, source basis, actor, scope, priority, or complete-when conditions are unclear. Use requirements-topology when stable IDs, typed edges, duplicate/conflict checks, or dependency order are missing.

Read project instructions, architecture constraints, domain glossaries, source catalogs, and policy files when present. Treat them as inputs; do not generalize their domain rules into this skill.

After this skill admits a slice into implementation, use requirements-traceability to maintain implementation anchors, executed test or operational evidence, reverse traceability, and stale-reference checks. Readiness defines the evidence obligation; traceability records whether later work fulfills it.

Minimum Inputs

Require enough information to make readiness falsifiable:

• stable requirement IDs and atomic statements;
• source lineage and validation status;
• usable complete-when conditions;
• owning problem scope or foundation capability;
• typed dependencies and dependency order;
• actors, permissions, and relevant constraints;
• external prerequisites and known decision/watch items.

If the user supplies raw requirements, do not pretend they are implementation ready. Run a light grounding/topology pass and label the result incomplete, or route to the missing stage.

Workflow

1. Verify topology stability: no blocking cycles, unresolved ID transformations, likely duplicates, must-have verification gaps, or ownerless prerequisites.
2. Group requirements into cohesive capabilities and workstreams without changing meaning.
3. Pull foundation capabilities, cross-cutting constraints, data ownership, and evidence primitives early in the sequence.
4. Check every external prerequisite for an existing artifact or an explicit minimal contract. Mark dependent work partial or blocked when neither exists.
5. Convert prerequisite edges into implementation order while keeping architecture choices open. Within that order, place first the slice or experiment that tests the riskiest unvalidated assumption: the one most likely to be wrong, weighted by the cost of learning that late. Choose the cheapest vehicle that can invalidate it (see Assumption Vehicles).
6. Derive only supported domain-model seeds, contract candidates, integration points, data boundaries, and non-functional constraints.
7. Identify ADR candidates where multiple viable designs or unresolved forces remain.
8. Define the smallest coherent vertical slice that demonstrates the core outcome. Mark a slice parallel-ready only on criteria readable from the artifacts: it is isolated (needs little context beyond its own scope), shares no unmerged prerequisite, carries no unresolved contract, is mergeable on its own, and is independent of every other slice in its group. Record parallel-ready groups in the implementation order. Who will pick a slice up is a scheduling fact, not a property of the slice; it cannot be read from any artifact and is not a criterion.
9. Reference grounding's complete-when conditions as acceptance tests; add only concrete fixtures, expected values, and edge cases still needed.
10. Separate ready work, blockers, risks, and technical questions.
11. Seed stable requirement and acceptance-criterion references for downstream traceability without claiming implementation or verification evidence yet.

Assumption Vehicles

Match the vehicle to the assumption it must be able to invalidate. Each is a bounded experiment, not the product:

Vehicle	Invalidates	Constraint
Proof of concept	One named feasibility or technical assumption	Any technology, disposable; throwaway code never crosses the merge boundary without the enforcement architecture-as-code requires
Prototype	A functional or interaction assumption, with stakeholders	One-off, without the non-functional obligations; demonstrates, never ships
Minimum viable product	The linked outcome hypothesis, through real use	Complete enough for one full build-measure-learn turn, and the first end-to-end exercise of the delivery path

Record the vehicle, the assumption, and the invalidation criterion. For a need or outcome assumption, carry the criterion from the grounding experiment it serves or from the hypothesis's Decision threshold; do not author a new one. For a feasibility or technical assumption, state the criterion in the technical question or ADR seed that raised it; that is derived build preparation, not requirement meaning. A vehicle without an invalidation criterion is speculative build, not an experiment.

An assumption invalidatable by inspection is resolved, not scheduled. If reading the code, schema, configuration, or contract answers the question, answer it now and record the fact. Carrying a lookup as an open assumption inflates the risk list, and — because ordering is riskiest-first — displaces the assumption that actually needed the first slice. Only questions no available artifact can settle earn a vehicle and a position in the order.

Readiness Gate

Mark a requirement or slice ready only when it has:

• stable, traceable requirement IDs;
• usable complete-when conditions;
• a clear owner and actor;
• known prerequisites with existing artifacts or named minimal contracts;
• identified data ownership and lifecycle;
• relevant security, privacy, accessibility, compliance, audit, and operational constraints;
• no unresolved decision that changes the required outcome;
• the retirement of every criterion the slice's mechanism replaces, admitted as part of the slice;
• an accepted validation decision, or an explicitly reversible experiment.

Mark it partly ready when a bounded implementation can proceed behind an explicit assumption, adapter, configuration point, or reversible decision.

Mark it not ready when source meaning, actor permission, data availability, acceptance conditions, external ownership, or dependency order prevents a responsible implementation decision.

Readiness, implementation, and verification are independent states. A READY decision permits work to start; it does not mean an artifact exists or evidence has passed.

Do not use architecture uncertainty alone as a blocker when the requirement is clear and the design decision can be captured as an ADR. Do treat product or policy uncertainty as a blocker when different answers change the required outcome.

Derived Artifacts

Produce only what the current audience needs:

Capability:
- Purpose:
- Requirement IDs:
- Owner:
- Inputs and outputs:
- Constraints:
- Evidence:
- Prerequisites:
- Ready state:

Implementation slice:
- Outcome:
- Requirement IDs:
- Actor workflow:
- Prerequisites:
- In scope / out of scope:
- Acceptance-test references:
- Data touched and ownership:
- Roles and permissions:
- Evidence and operations:
- Parallel-ready: yes | no + missing criterion
- Risks and watch items:
- Developer / architect questions:

Contract candidate:
- Kind: command | query | event | import | export | API
- Purpose:
- Producer / consumer:
- Domain terms:
- Validation:
- Security and privacy:
- Evidence and operations:
- Requirement traceability:

ADR seed:
- Decision needed:
- Requirement traceability:
- Forces and constraints:
- Viable options:
- Recommendation, if supported:
- Consequences:
- Enforcement candidate:
- Revisit trigger:

These are design inputs, not automatic commitments. Use architecture-guidelines when turning them into module or service designs, and use functionality-complexity-tradeoff when a proposed capability still needs a worth decision.

Output Contract

Every application emits a decision record before any longer readiness package:

Subject:          <requirement scope, capability, or slice>
Decision:         READY | PARTLY-READY | NOT-READY
Requirement IDs:  <stable IDs covered by the decision>
Prerequisites:    <ready, assumed, or missing>
Blocking gaps:    <source, outcome, owner, data, permission, verification, or contract>
Smallest slice:   <smallest coherent outcome supported now, or none>
Open decisions:   <product / policy blockers versus architecture ADRs>
Next action:      <build, decide, source, contract, split, or return upstream>
Verification:     <readiness checks run, or Not run + reason>
Revisit when:     <required for PARTLY-READY or NOT-READY>

A complete readiness package additionally contains:

Implementation readiness:
- Meta-context:                 # standalone artifacts only
- Canonical grounding/topology:
- Readiness decision:           # ready | partly ready | not ready
- Blocking gaps and owners:
- Capability map:
- Workstreams or epics:
- Implementation order:         # riskiest assumption first; parallel-ready groups marked
- Smallest coherent slice:
- Cross-cutting constraints:
- Data ownership and lifecycle:
- Evidence and operational needs:
- Contract candidates:
- Domain-model seeds:
- ADR seeds:
- Acceptance-test references:
- Technical questions:
- Traceability:

For a standalone artifact, state audience, purpose, completion date, source artifacts, source currency, and caveats once near the top. Keep every derived item traceable to requirement IDs and keep blockers visible beside the readiness decision.

Guardrails

• Do not rewrite source requirements to fit a preferred architecture.
• Do not invent payloads, entities, integrations, or non-functional targets that the requirements do not support.
• Do not restate complete-when conditions as a competing acceptance-criteria set.
• Do not admit a replacement without the retirement it implies. A slice that removes or replaces a mechanism carries the lapsing criteria and closes them.
• Do not turn every graph edge into a contract or runtime dependency.
• Do not mark a slice parallel-ready while it shares an unmerged prerequisite or an unresolved contract with another slice in its group.
• Do not schedule an assumption that reading an existing artifact would settle; resolve it and record the answer.
• Do not bury product, domain, security, privacy, compliance, or source-currency decisions inside developer notes.
• Do not mark a requirement implemented or verified in a readiness package; hand the admitted IDs and evidence obligations to requirements-traceability.
• If grounding or topology changes materially, refresh the readiness package or state exactly what is stale.

See also

• requirements-grounding — problem, source, evidence, and canonical meaning.
• requirements-topology — stable IDs, typed graph, repository validation, and order.
• requirements-traceability — implementation and executed verification after readiness.