ship-feature
Ship a feature end-to-end: understand the ask, research the codebase, plan, build test-first with small commits, verify via scripts, and deliver. Use this skill when starting any non-trivial feature, bug fix, or refactor that needs the full understand → plan → build → verify → deliver cycle.
- License 许可
- MIT
- 最近更新
- 2026-04-30
- Stars
- ★ 1
- Forks
- 2
01 前言 Front Matter
- name
- ship-feature
- license
- MIT
- metadata
- { "harness-tags": "methodology,development,shipping", "harness-author": "human", "harness-status": "active", "harness-related": "read-before-edit,search-before-create" }
- description
- Ship a feature end-to-end: understand the ask, research the codebase, plan, build test-first with small commits, verify via scripts, and deliver. Use this skill when starting any non-trivial feature, bug fix, or refactor that needs the full understand → plan → build → verify → deliver cycle.
02 资源文件 6
- 参考文档evals/evals.json1.1 KB
- 参考文档evals/files/branch-state.txt586 B
- 参考文档evals/triggers.json3.1 KB
- 脚本scripts/pre-pr-checklist.sh12.3 KB
- 脚本scripts/verify-build.sh6.1 KB
- 脚本scripts/verify-tests.sh8.3 KB
03 SKILL.md 正文
ship-feature
When to use
Use this skill when the user asks to implement a feature, fix a bug, or perform a refactor that requires more than a trivial one-liner. It covers the full lifecycle from understanding the ask through verified delivery.
Available scripts
scripts/verify-tests.sh— Run the project's test suite and return pass/fail counts as JSON. Call this after each significant change to confirm nothing regressed.scripts/verify-build.sh— Run the project's build and return success/failure as JSON. Call this before opening a PR.scripts/pre-pr-checklist.sh— Run typecheck + lint + tests + build all-or-nothing. Call this once when the feature is complete and all commits are staged.
Workflow
- Understand — Read the full ask. Ask clarifying questions if ambiguous.
- Research — Search the codebase for existing patterns, types, and utilities that the change will touch. Read every related file completely — never speculate.
- Plan — Outline the approach. Identify risks. Share the plan with the user if the change is non-trivial.
- Build — One file at a time. Write or update tests alongside each change. Read before edit; reuse before create.
- Verify — Run
scripts/verify-tests.shafter each significant change. Address failures before moving to the next file. - Pre-PR check — Run
scripts/pre-pr-checklist.shonce all commits are ready. Fix every error before opening the PR. - Deliver — Push with a clear commit message. Summarize what changed and why.
Gotchas
- Scope creep: if the work reveals adjacent issues, flag them to the user rather than expanding the change silently.
- Missing dependencies: propose adding any missing library with a rationale before installing it.
- Pre-PR checklist is blocking: if
scripts/pre-pr-checklist.shreturnsstatus: error, fix the reported step before proceeding. - No test runner detected: if
scripts/verify-tests.shreturnsstatus: blockedwithcode: NO_TEST_COMMAND, inform the user and agree on a manual verification step.
Failure modes
If scripts/pre-pr-checklist.sh returns status: error, read error.code:
TYPECHECK_FAILED— TypeScript errors present. Fix them before continuing.LINT_FAILED— Lint violations present. Fix or suppress with justification.TESTS_FAILED— Test suite is red. Fix failing tests before opening the PR.BUILD_FAILED— Build command failed. Fix compilation/bundling errors.NO_TEST_COMMAND— Project has no detectable test script. Discuss with user.NO_BUILD_COMMAND— Project has no detectable build script. Typecheck and lint are still enforced.
04 同仓库更多 Skills
research
Conduct research.
{{NAME=null}=null}
Briefly describe what this skill does AND when to use it. Use imperative phrasing ("Use this skill when..."). Aim for 80-500 chars. Include keywords the model can pattern-match against the user's prompt.
working-in-a-git-repo
Operating manual for dev work: worktree discipline, build/test/lint commands, file ownership zones, commit style, and a verification checklist before reporting done. Use when starting any feature/fix work in this repo.
test-runner
Runs the project's test suite (or a targeted subset), parses the output, and reports pass/fail with failing-test details. Use when you need to know test status; call with the test command to run, or leave blank for the project default.
reviewer
Reviews a diff or change set for bugs, security issues, test gaps, and style. Use when evaluating a code change, reviewing a pull request, or running a structured review pass before merge.
fix-failing-tests
Seven-step flow for diagnosing and fixing failing tests. Use when the user asks to fix failing tests, green the suite, or says 'tests are red' — works through reproduce → read → root-cause → propose → apply → verify → commit.