# Feature Delivery

> Deliver every user story in a revised design document through GitHub issue synchronization, single-story implementation and independent review, merge, and an overall feature audit. Use when asked to deliver, ship, resume, finish, or fully implement a complete design doc or multi-story feature.

- Skill: `eho/feature-delivery` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add eho/feature-delivery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eho/feature-delivery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: eho (https://skillmd.com/u/eho)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/eho/feature-delivery

---


# Feature Delivery

Deliver the feature described by one design document. The design document defines scope. GitHub Issues track story progress, and Pull Requests track implementation, review, verification, and merge history.

Use these specialists:

- `design-to-issues` to synchronize stories with GitHub;
- `user-story-delivery` to deliver one issue at a time;
- `post-implementation-reviewer` for the final feature audit.

If a required specialist is unavailable, report that prerequisite instead of silently combining implementation and independent review in one context.

## Workflow

1. Read repository instructions and the complete design document.
2. Require `Status: Revised` and run the `design-to-issues` story validator in
   delivery mode. This proves the mechanical status, story, and dependency
   contract; semantic readiness comes from the independent review that promoted
   the design. The user may explicitly override a semantic review risk, but
   mechanical delivery validation must still pass.
3. Before mutation, inventory delivery gates that require credentials,
   permissions, deployment, physical hardware, human observation, or elapsed
   time. Report each gate, its responsible actor, evidence, and earliest
   dependency point. Continue repository-local work that does not depend on
   it; the inventory is not permission to defer scope or invent verification
   requirements.
4. Run `design-to-issues` to create or update one canonical GitHub Issue for every current story. Use the issue state, body, comments, linked PRs, and dependencies as the durable progress record.
5. Inspect all canonical story issues:
   - a closed issue with a merged, reviewed PR is complete;
   - an open issue is remaining work;
   - resume an existing branch or PR rather than creating a duplicate;
   - work only on stories whose dependencies are complete.
6. Invoke `user-story-delivery` for one dependency-ready open issue. Require it to implement every acceptance criterion, obtain independent review, address blocking findings, merge according to repository policy, and verify issue closure.
7. While a specialist is making progress, wait for its handoff rather than
   polling or replacing it. Communicate state changes, completed milestones,
   blockers, and decisions; do not repeat unchanged status.
8. Re-read the issue and PR after the handoff. Continue until every in-scope story issue is complete. If one story is blocked, continue unrelated dependency-ready stories.
9. Invoke `post-implementation-reviewer` with the original design document. The auditor must inspect the assembled implementation, story completion, cross-story behavior, documentation, and relevant verification.
10. Handle audit results:
   - attach a story-specific blocking finding to its canonical issue, reopen it if necessary, and deliver it again through `user-story-delivery`;
   - create one ordinary GitHub Issue for a blocking integration or documentation gap that does not belong to an existing story, give it concrete acceptance criteria, and deliver it through `user-story-delivery`;
   - request the user's decision when remediation would expand the approved design scope;
   - rerun the overall audit after blocking remediation.
11. Finish only when every in-scope story is complete and the latest overall audit reports no blocking findings.

## Completion rules

A story is complete only when:

- its canonical issue reflects the current story requirements;
- every acceptance criterion has implementation and verification evidence;
- an independent reviewer found no unresolved blocking issue;
- required checks and repository merge policy passed;
- the reviewed PR head was merged; and
- the canonical issue is closed.

The feature is complete only when all current stories satisfy those rules and the overall audit has no blocking findings. Issue creation, an open or approved PR, a review checkpoint, or a newly filed follow-up issue is not completion.

## Safety and authorization

- Current repository and GitHub state outrank conversation handoffs.
- Resolve ambiguous duplicate issues or PRs before proceeding.
- Preserve unrelated and dirty worktree changes.
- Never replace active work merely because a worker is slow or interrupted.
- Do not remove or defer a design story without explicit user authority.
- Do not treat unperformed manual verification as passed.
- When only an external, human, or time-dependent gate remains, record the
  exact continuation condition and return control instead of repeatedly
  retrying unchanged state.
- Follow repository-specific branch, review, check, merge, and branch-retention policy.
- Never create or complete a runtime goal unless the user authorized that goal and this feature satisfies it.

## Final report

```markdown
## Feature Delivery Status
- Design:
- Final audit: Ready | Not ready

| Story | Issue | PR | Status | Verification |
| --- | --- | --- | --- | --- |

## Audit
- Blocking findings remediated:
- Remaining non-blocking follow-ups:

## Remaining Work
- None | exact blocker and required action
```