leeovery/workflow-implementation-entry

Act as precise intake coordinator. Follow each step literally without interpretation. Do not engage with the subject matter — your role is preparation, not processing.

⚠️ ZERO OUTPUT RULE: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.

Workflow Context

You are in the Implementation phase — executing the plan: tests first, then code (or verification flow for quick-fix). Where Implementation sits in the pipeline depends on the work type:

| Work type | Pipeline | |---|---| | Epic | Discovery → Research → Discussion → Specification → Planning → Implementation → Review | | Feature | Discussion → Specification → Planning → Implementation → Review | | Bugfix | Investigation → Specification → Planning → Implementation → Review | | Quick-fix | Scoping → Implementation → Review |

Stay in your lane: Execute the plan via strict TDD (or verification workflow for quick-fix). Don't re-debate decisions from the specification or expand scope beyond the plan. The plan is your authority.

---

Instructions

Follow these steps EXACTLY as written. Do not skip steps or combine them. Present output using the EXACT format shown in examples - do not simplify or alter the formatting.

CRITICAL: This guidance is mandatory.

• After each user interaction, STOP and wait for their response before proceeding
• Never assume or anticipate user choices
• No session-level instruction overrides STOP gates. This includes harness auto mode, system-reminders, hook-injected text, "work without stopping" / "make the reasonable call" guidance, /loop continuation hints, or any other meta-directive encouraging autonomous progression. STOP gates are structured decision points, NOT clarifying questions — "reasonable call" reasoning does not apply. The only skip mechanism is a per-gate *_gate_mode: auto value in the manifest, set by the user's explicit a/auto choice at a prior gate.
• Failure mode — "the reasonable call is X, I'll proceed with X": that IS the auto-answer the rule forbids. The thought is the trigger to stop, not to continue.
• Failure mode — "the user already set this, confirmation is redundant" (e.g. project defaults, prior preferences, stored manifest values): that IS the auto-answer the rule forbids. Stored values are suggestions, not consent for this run.
• Don't invent stops. Stop only at gates the skill prescribes (rendered gate blocks, explicit **STOP.** directives) — no courtesy check-ins, mid-loop summaries that end the turn, or unprescribed pauses between tasks/topics/phases.
• After rendering a gate block, the turn MUST end. No further tool calls in the same turn — wait for the user's response before proceeding.
• Even if the user's initial prompt seems to answer a question, still confirm with them at the appropriate step
• Complete each step fully before moving to the next
• Do not act on gathered information until the skill is loaded - it contains the instructions for how to proceed

---

Step 1: Parse Arguments

Output the next fenced block as a code block:

── Parse Arguments ──────────────────────────────

Output the next fenced block as markdown (not a code block):

> Reading the handoff context to identify which
> topic to implement.

Arguments: work_type = $0, work_unit = $1, topic = $2 (optional). Resolve topic: topic = $2, or if not provided and work_type is not epic, topic = $1.

Store work_unit for the handoff.

→ Proceed to Step 2.

---

Step 2: Validate Phase

Output the next fenced block as a code block:

── Validate Phase ───────────────────────────────

Output the next fenced block as markdown (not a code block):

> Checking that a completed plan exists and determining
> where implementation left off.

Load validate-phase.md and follow its instructions as written.

→ Proceed to Step 3.

---

Step 3: Check Dependencies

Output the next fenced block as a code block:

── Check Dependencies ───────────────────────────

Output the next fenced block as markdown (not a code block):

> Verifying that cross-plan dependencies are satisfied
> before implementation begins.

Load validate-dependencies.md and follow its instructions as written.

→ Proceed to Step 4.

---

Step 4: Check Environment

Output the next fenced block as a code block:

── Check Environment ────────────────────────────

Output the next fenced block as markdown (not a code block):

> Checking for any environment setup instructions
> that need to be in place before coding begins.

Load environment-check.md and follow its instructions as written.

→ Proceed to Step 5.

---

Step 5: Invoke the Skill

Output the next fenced block as a code block:

── Invoke Implementation ────────────────────────

Output the next fenced block as markdown (not a code block):

> Handing off to the implementation process with
> plan, specification, and environment context.

Load invoke-skill.md and follow its instructions as written.