ship-feature

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

1) Read project `AGENTS.md`, `codex.toml`, the current code diff/status, and target work item folder `spec/features/<work-id>-<slug>/`.
   - `<work-id>` must use `S-<stream>-<nnn>` (example: `S-core-001`) for new work.
   - For legacy single-file specs, read the matching file under `spec/features/`.
2) Verify spec completeness before execution:
   - `feature.md` has stable AC IDs and every AC is marked satisfied with test/evidence mapping
   - `test-plan.md` exists and maps planned coverage to AC IDs
   - Smoke applicability is `required` or `not_applicable`; required smoke has scenario + fixture + pass/fail mode + artifact expectation, while `not_applicable` has a non-runnable rationale
   - API-facing work has Google-style docstring expectations documented or a clear no-change rationale
   - `status.md` has owner/status/next action and no unresolved blocker or deferred AC
3) Run `test-runner` in full mode.
   - `test-runner` full mode owns the smoke execution for this flow.
   - Do not run `smoke-test` a second time unless the full-mode smoke artifact is missing, stale, or explicitly invalid.
4) Stop the readiness flow if any full-check stage fails.
   - Update only `test-results.md` and `status.md` with the failure; do not run docs/changelog/index readiness updates.
5) Validate smoke according to applicability.
   - For `required`, fail if artifacts are missing: `summary.json`, `cases/<case_id>.json`, `stdout.txt`, `stderr.txt`, `timing.json`.
   - Require `summary.json` evidence identity for the current source state: Git commit, dirty-state flag and diff hash when dirty, command, registry hash, fixture hashes, and generation time.
   - Treat evidence from a different source state as stale and rerun smoke once through `test-runner`; never accept stale evidence.
   - For `not_applicable`, validate and record the rationale instead of creating smoke artifacts.
   - Record the artifact path and summary in `test-results.md` and `evidence/README.md`.
6) Run `adr-review` when architecture/design decisions changed or the spec indicates ADR is required.
7) Run `architecture-updater` when components, data flow, external dependencies, or public interfaces changed.
8) Run `docs-update` when user-facing behavior changed.
9) Run `docs-index-refresh` to keep spec navigation current.
10) Update the work item docs:
   - `test-results.md`: full checks, smoke outcome, failures/fixes
   - `implementation.md`: commands run and implementation summary
   - `status.md`: `Ready to ship`, no blockers, and the next merge/release action
   - `evidence/README.md`: smoke evidence or not-applicable rationale plus other readiness evidence
11) Ensure evidence is recorded:
   - `Smoke artifacts: <path>`
   - `Smoke summary: <brief>`
   - optional `Key metrics: latency/error buckets`
12) End with a concise readiness summary:
   - work item ID
   - pass/fail of full checks
   - pass/fail of docstring checks when configured
   - pass/fail/not-applicable of the full-mode smoke stage
   - evidence paths
   - ADR/architecture/docs/index update status
   - final line: `Ready to ship` only when ACs, required checks, evidence, and documentation gates passed.

From rafaie/codex_home, Apache-2.0.

More from rafaie/codex_home