Implementation

Manual delivery is the skill-by-skill implementation path.

The operator asks the agent to invoke each skill explicitly, then reviews the artifact that skill produces. The point is to use the Harness skills directly instead of recreating their contracts by hand.

• Use this when: the operator wants to inspect spec, plan, implementation, validation, review, or docs ingest before the next step.
• It gives you: an artifact trail with human checkpoints at each skill boundary.
• It ends with: implemented, validated, reviewed, and documented scope, or a clear blocker.
• Wrapped phase/skills: $create-spec, $create-plan, $implement-spec, $review-phase, optional $debugging-phase, $docs-ingest-phase.

Runtime Graph

Manual delivery is artifact-by-artifact control. The graph shows where the operator accepts the current artifact before the next skill is allowed to create the next one.

Reading The Checkpoints

• Operator arrows are the checkpoints. Pause there; the next artifact depends on the previous one being accepted.
• Spec and plan are different gates. Spec asks “is this the right work?” Plan asks “can this be executed and verified?”
• Implementation does not go straight to trust. It goes through matched checks and manual evidence when behavior needs eyes on it.
• Debugging is not a normal detour. It starts only when validation or review has runtime evidence.
• Docs ingest closes changed durable knowledge. If nothing changed, say why.

Entrypoints

Use this flow after Brainstorming Requirements And Backlog when the operator wants human review between lifecycle artifacts.

• $create-spec: create or update the scoped SPEC.md for the target EPIC and all of its child stories or sub-issues.
• $create-plan: plan after the spec is reviewed enough to trust, with tasks mapped back to the owning EPIC and relevant child stories or sub-issues.
• $implement-spec: execute the approved plan while preserving every story requirement from the EPIC's child stories or sub-issues.
• $review-phase: review after implementation.
• $debugging-phase: enter when validation or review produces runtime evidence.
• $docs-ingest-phase: ingest when behavior, architecture, setup, contracts, operator workflow, or durable source knowledge changed.

When the target EPIC depends on backlog work from an open parent PR, the stack decision starts in $create-spec through Dependency Readiness and Branch/Base Intent. Manual delivery should not wait for the parent PR to merge when the dependency can be represented by a recorded parent PR base; $implement-spec enforces the branch/base intent before coding, and delivery uses stack sync --dry-run before any stack mutation.

Backlog Targeting Contract

Delivery targets EPICS and their child stories or sub-issues.

• $create-spec uses the parent EPIC as the spec anchor. It must read every child story or sub-issue under that EPIC and incorporate each story's product requirement, constraint, acceptance signal, and blocker into the unified SPEC.md.
• $create-plan plans from that reviewed spec. Each implementation task should reference the owning EPIC and the specific child stories or sub-issues it satisfies when backlog ids or URLs exist.
• $implement-spec implements the approved plan without dropping, weakening, or silently merging child-story or sub-issue requirements.
• $delivery-phase must preserve this same EPIC plus child stories or sub-issues relationship while orchestrating $create-spec -> $create-plan -> $implement-spec -> $review-phase -> optional $debugging-phase -> $docs-ingest-phase.

Do not target a standalone story as if it were the whole capability when its parent EPIC has sibling child stories or sub-issues. Do not target an EPIC summary while treating child stories or sub-issues as mere links.

Flow

Run the checkpoints in this order:

1. Invoke $create-spec against the target EPIC and its child stories or sub-issues.
2. Review the generated or updated SPEC.md. Return to $requirements-grill if scope is still underdefined.
3. Invoke $create-plan against the reviewed spec and its EPIC/story links.
4. Review PLAN.md for dependency order, write scopes, validation gates, and review mode.
5. Invoke $implement-spec with the approved plan and story-preservation contract.
6. Run the validation gates matched to the touched surface. See Validation Gates.
7. Use the manual E2E checklist produced by implementation when behavior requires human inspection.
8. Invoke $review-phase and fix blocking in-scope findings.
9. Invoke $debugging-phase when runtime evidence exists. See Debugging.
10. Invoke $docs-ingest-phase or record an explicit docs no-op. See Docs Update.

Checkpoint Shape

Manual HITL checkpoints come from the individual skills being called separately. A phase wrapper can compose the same skills, but manual delivery is where the operator sees and steers each artifact before the next skill runs.

Spec review answers whether the work is the right work. Plan review answers whether the implementation path is safe. Post-implementation validation answers whether the changed surface has proof. Manual E2E answers whether a human-observable behavior should be trusted.

Decision Points

• If spec review exposes unclear requirements, stop implementation and grill again.
• If validation fails, patch within scope and rerun the failing gate.
• If review finds unrelated issues, report them without expanding scope unless they block correctness.

Terminal Outcome

The requested implementation is complete, validated, reviewed, and documented or explicitly marked as docs-no-op.

Validation

Report exact commands, browser scenarios, manual checklist items, review status, docs ingest output, and remaining blockers.