Feature spec delivery pipeline

Skill mo-hawary/hawary-workflow-skills/skills/feature-spec-delivery-pipeline

Reusable Agent Skills for Codex, Claude, and AI coding agents

Install

npx -y skills add mo-hawary/hawary-workflow-skills --skill feature-spec-delivery-pipeline

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn a feature request or bug cluster into a source-backed spec, impact map, acceptance criteria, and delivery plan before coding.

SKILL.md

2.6 KB, as published. Nobody here has run it

Feature Spec Delivery Pipeline

Convert an idea into a buildable, reviewable plan before implementation.

When To Use

Use this before multi-file implementation, cross-layer changes, migrations, or user-flow changes.

Do not use this for a read-only health snapshot; use project-status-dashboard. Do not use it for a narrow contract mismatch review; use cross-layer-contract-audit.

Workflow

Clarify the request:
- Goal.
- In-scope and out-of-scope behavior.
- Product decisions that need user approval.
Map existing contracts:
- Relevant UI, API, database, jobs, integrations, tests, and docs.
Identify risk:
- Auth, payments, sessions, migrations, data loss, compatibility, and user-facing workflow changes.
Write the spec:
- Problem.
- Current behavior.
- Proposed behavior.
- Affected files/components.
- Contract changes.
- Implementation phases.
- Acceptance criteria.
- Verification plan.
- Rollout and rollback notes when relevant.
Ask for approval before implementation when behavior, layout, copy, or data contracts are not settled.

For sample prompts and spec shape, see references/examples.md. For a reusable spec skeleton, see references/spec-template.md.

Input Signals

Use source evidence before proposing a plan: changed files, current behavior, failing tests, issue text, screenshots, logs, schemas, route handlers, migrations, and prior specs. If the request is vague, ask for the missing product decision only after mapping what the repo already proves.

Output

Use this structure:

Summary
Current Evidence
Decisions Needed
Proposed Contract
Implementation Plan
Acceptance Criteria
Verification
Risks and Rollback

Guardrails

Do not invent requirements when evidence is ambiguous.
Do not make product, UI, or layout decisions without approval.
Do not edit implementation code unless the user explicitly asks you to proceed.
Keep the plan narrow enough to review.

Avoid

Do not turn the spec into a broad roadmap unless the user asked for one.
Do not hide unresolved decisions inside acceptance criteria.
Do not propose implementation phases that cannot be verified independently.

Final Checks

The spec separates evidence from assumptions.
Every decision that needs user approval is explicit.
Acceptance criteria are testable.
Verification covers the highest-risk changed contracts.