How do I install the Ship A Feature skill?

Run npx skillmds@latest add vodouai/ship-a-feature in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Ship A Feature safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Ship A Feature?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Ship A Feature free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Ship A Feature?

VodouAI (@vodouai) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Ship A Feature by vodouai — Agent Skill

Name: Ship A Feature
Author: VodouAI

File contents

ship-a-feature

A 4-stage pipeline for shipping a feature end-to-end: spec → implement → review → deploy. The dispatcher auto-advances tasks through these stages when each stage's required_artifacts validate.

Phase 1 status: pre-installed but inactive. The kernel migration's tasks.workflow_template_id + current_step_key columns hold the binding; Phase 2 lands the loader that reads this file's AGENT_ACTIONS_N blocks into board.db::board_templates.

Stages

Stage 1 — Specify

The PM (or PM-equivalent subagent) writes the spec: goal, approach, acceptance criteria, success metrics. Output is a markdown file. The dispatcher checks the file path matches .md$ and the acceptance_criteria_count is ≥1 before advancing.

Stage 2 — Implement

The engineer (or engineer-equivalent subagent) writes the code in a git worktree, runs tests, opens a PR. Required artifacts: metadata.pr_url matching GitHub, tests_run ≥ 1, changed_files_count ≥ 1. On failure, retries once (back to implement); on second failure, falls to block for human review.

Stage 3 — Review

The reviewer (or reviewer-equivalent subagent) does the editorial + security pass. Must explicitly set metadata.approved=true AND metadata.security_audit_passed=true. Approval gate fires before done so a human signs off. On rejection, kicks back to implement (engineer iterates).

Stage 4 — Deploy

The deployer ships it. Requires deploy_status=success AND a deploy_url. On failure, blocks for human investigation.

Pipeline total budget cap (recommendation)

Sum of stage caps: ~$12.50 per feature run. The board enforces per-stage caps; cumulative spend across stages rolls up via SUM(task_runs.usd_spent) for the parent task.

When to use this template vs not

✓ Use it when the work follows the standard ship-a-feature shape: discrete spec, code change, review, deploy.

✗ Skip it when:

It's research-only (no code change → use daily-research-brief instead)
It's a documentation-only change (no review needed → just create a task with assignee=writer)
It's a hotfix (the pipeline is too slow for incidents → create direct + auto-approve)

---name: ship-a-featuredescription: workflow template — PM specs, engineer implements, reviewer approves, deployer ships; pre-installed with the board, activates in Phase 2 when the workflow_template kind enum lands---# ship-a-featureA 4-stage pipeline for shipping a feature end-to-end: spec → implement → review → deploy. The dispatcher auto-advances tasks through these stages when each stage's `required_artifacts` validate.**Phase 1 status:** pre-installed but inactive. The kernel migration's `tasks.workflow_template_id` + `current_step_key` columns hold the binding; Phase 2 lands the loader that reads this file's `AGENT_ACTIONS_N` blocks into `board.db::board_templates`.## Stages### Stage 1 — SpecifyThe PM (or PM-equivalent subagent) writes the spec: goal, approach, acceptance criteria, success metrics. Output is a markdown file. The dispatcher checks the file path matches `.md$` and the acceptance_criteria_count is ≥1 before advancing.### Stage 2 — ImplementThe engineer (or engineer-equivalent subagent) writes the code in a git worktree, runs tests, opens a PR. Required artifacts: `metadata.pr_url` matching GitHub, `tests_run ≥ 1`, `changed_files_count ≥ 1`. On failure, retries once (back to implement); on second failure, falls to `block` for human review.### Stage 3 — ReviewThe reviewer (or reviewer-equivalent subagent) does the editorial + security pass. Must explicitly set `metadata.approved=true` AND `metadata.security_audit_passed=true`. Approval gate fires before `done` so a human signs off. On rejection, kicks back to `implement` (engineer iterates).### Stage 4 — DeployThe deployer ships it. Requires `deploy_status=success` AND a `deploy_url`. On failure, blocks for human investigation.## Pipeline total budget cap (recommendation)Sum of stage caps: ~$12.50 per feature run. The board enforces per-stage caps; cumulative spend across stages rolls up via `SUM(task_runs.usd_spent)` for the parent task.## When to use this template vs not✓ **Use it when** the work follows the standard ship-a-feature shape: discrete spec, code change, review, deploy.✗ **Skip it when**:- It's research-only (no code change → use `daily-research-brief` instead)- It's a documentation-only change (no review needed → just create a task with assignee=writer)- It's a hotfix (the pipeline is too slow for incidents → create direct + auto-approve)

Frequently asked questions

Ship A Feature