HeyvhuangHeyvhuang/ship-faster/skills/workflow-feature-shipper/SKILL.md

workflow-feature-shipper

Skill337 starsChanged 10 months agoMITView on GitHub

Use when you need to ship a single PR-sized feature end-to-end (plan -> implement -> verify) with artifacts. Ship core product features quickly in a Next.js codebase: turn a feature idea into an executable plan, implement in PR-sized slices, and keep artifacts under runs/ (or OpenSpec changes/ when available). Supports plan-only mode for early scoping. For prototype UI work, include a demo-ready wow moment (animation/micro-interaction) by default unless user opts out.

In this repository40 other files it gives its agents.
- review-clean-codeSkill
- review-doc-consistencySkill
- review-merge-readinessSkill
- workflow-execute-plansSkill
- workflow-template-extractorSkill
- workflow-template-seederSkill
- cloudflareSkill
- deep-researchSkill
- mcp-cloudflareSkill
- mcp-stripeSkill
- mcp-supabaseSkill
- publish-x-articleSkill
- review-clean-codeSkill
- review-doc-consistencySkill
- review-merge-readinessSkill
- review-qualitySkill
- review-react-best-practicesSkill
- review-seo-auditSkill
- skill-creatorSkill
- skill-evolutionSkill
- skill-improverSkill
- stripeSkill
- supabaseSkill
- tool-ast-grep-rulesSkill
- tool-better-authSkill
- tool-design-style-selectorSkill
- tool-hooks-doctorSkill
- tool-openclawSkill
- tool-programmatic-seoSkill
- tool-schema-markupSkill
- tool-systematic-debuggingSkill
- tool-ui-ux-pro-maxSkill
- tool-x-article-publisherSkill
- workflow-brainstormSkill
- workflow-creatorSkill
- workflow-execute-plansSkill
- workflow-project-intakeSkill
- workflow-ship-fasterSkill
- workflow-template-extractorSkill
- workflow-template-seederSkill

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 1 is distinctive, and 8 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Read feature.md, normalize into: acceptance criteria, boundaries, risks, rollback.
line 31
Very specific:
Prototype UI rule (default): if this feature affects user-facing UI and quality_bar isn’t functional-only, propose 1 “demo moment” …
line 32
Very specific:
Write plan to evidence/features/<feature_slug>-plan.md.
line 35
Very specific:
If mode: plan-only, stop here and ask for confirmation before implementing.
line 36
Very specific:
After each batch (or before merge), recommend using review-quality for a conclusive review + verdict.
line 41
Very specific:
If the user explicitly wants *only* a React/Next.js perf audit, run review-react-best-practices directly.
line 43
Very specific:
If verification fails (tests/build/runtime error): run tool-systematic-debugging before attempting more fixes.
line 45
Very specific:
Write evidence/features/<feature_slug>-summary.md: what was done, how verified, next steps.
line 48
Distinctive:
Don't introduce new complexity (unless it significantly reduces future cost, and user confirms)
line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Feature Shipper

Turn "I want to build a feature" into a fast execution chain.

Input (Pass Paths Only)

feature.md: Requirements description (acceptance criteria + non-goals)
repo_root
run_dir

Optional flags (recommended inside `feature.md`)

mode: plan-only | execute (default: execute)
feature_slug: short slug for artifact naming (default: derived from title + timestamp)
quality_bar: demo-ready | functional-only (default: demo-ready for user-facing UI features)

Output (Persisted)

evidence/features/<feature_slug>-plan.md (checklist plan: tasks + verification)
evidence/parallel/features/<feature_slug>/ (if implementation is split)
evidence/features/<feature_slug>-summary.md

Process

Hooks doctor (required check; non-blocking): Run tool-hooks-doctor once at the start of the session to verify skill-evolution hooks are enabled. If missing, offer to install project-level hooks; continue either way.
Read feature.md, normalize into: acceptance criteria, boundaries, risks, rollback.
Prototype UI rule (default): if this feature affects user-facing UI and quality_bar isn’t functional-only, propose 1 “demo moment” (animation/micro-interaction) and add it to acceptance criteria. Must respect prefers-reduced-motion.
Produce 2 options (A: minimal; B: cleaner but slower), default to A. If user cares about “demo feel”, offer A-demo-ready vs A-functional-only as explicit sub-options.
Split into PR-sized small steps (each independently runnable + rollback-able).
Write plan to evidence/features/<feature_slug>-plan.md.
If mode: plan-only, stop here and ask for confirmation before implementing.
Implement (batch execution + checkpoints):
- UI visual/layout/animation changes → First call tool-design-style-selector to load the project’s design-system.md, then strictly follow it. If tool-ui-ux-pro-max is installed, use it to ground motion/UX constraints (search “animation” + “accessibility”). For complex visual/animation/responsive design, delegate to /gemini frontend UI/UX senior design agent.
- Business logic/data flow/integration → Implement directly.
- Default batch rhythm: 3 small tasks per batch → run verification → report and wait for feedback; stop immediately for help when blocked/verification fails.
- After each batch (or before merge), recommend using review-quality for a conclusive review + verdict.
  - review-quality is the single entry point and will auto-triage: if React/Next.js performance risk is detected, it will also run review-react-best-practices.
  - If the user explicitly wants only a React/Next.js perf audit, run review-react-best-practices directly.
Verification: can run, can build (and existing tests pass).
- If verification fails (tests/build/runtime error): run tool-systematic-debugging before attempting more fixes.
- Persist debugging artifacts to:
  - evidence/features/<feature_slug>-debug.md (repro steps, hypotheses, root cause, fix + re-verify)
Write evidence/features/<feature_slug>-summary.md: what was done, how verified, next steps.
Wrap up: Do a skill-evolution Evolution checkpoint (3 questions); if user chooses "want to optimize", run skill-improver based on this run_dir to produce minimal patch suggestions

Delivery Requirements

No "big bang" refactoring
Don't introduce new complexity (unless it significantly reduces future cost, and user confirms)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free