story-implementation-planner

Story Implementation Planner

Own the Implementation Plan artifact. Turn an implementation-ready story and repo evidence into an executable plan for a named or described executor without clarifying the story, scouting the repository, assembling a packet, or editing code.

Activation Contract

Use this skill only when all of these are true:

• the requested output is an implementation plan;
• the input is one materialized active Story Card, not a Split Story Set, with Artifact Type: Story Card, Status: Ready, observable acceptance criteria, and a settled implementation boundary;
• Repo Context contains enough evidence to locate the existing implementation, validation surface, and any convention needed for proposed files;
• every planning-critical external claim, when present, has current and applicable primary-source support in Repo Context External Evidence; and
• executor constraints are known or can be stated conservatively without changing the required behavior or safety policy.

Use story-to-plan-orchestrator when the request spans clarification, scouting, planning, packet assembly, readiness validation, or resumption. Use story-clarifier for unresolved product behavior and story-repo-scout for missing, weak, or stale repository evidence. Do not perform those stages here. A ready Split Story Set still requires slice selection and materialization by the orchestrator before it becomes valid planning input.

If this skill is invoked with inadequate inputs, return the supported portions of the artifact with a non-ready status and route the missing work to its owner. Do not fill gaps by guessing.

Status Contract

Every output starts with:

## Implementation Plan

Artifact Type: Implementation Plan
Status: Ready | Needs Input | Blocked
Reason: None | <concise readiness reason>

Use the statuses operationally:

• Ready: the plan is executable as written and has no unresolved blocking input; write Reason: None.
• Needs Input: a specific answer, upstream revision, or re-scout can make the plan executable. Name each missing input, its owner, and the next action; do not write unsupported downstream steps.
• Blocked: a hard dependency or constraint prevents an honest plan and the required input cannot currently be obtained through the preparation workflow. Name the evidence, unblock condition, and safe stopping point.