build-epic
Skill288 starsChanged 7 days agoMITView on GitHub
Eight-step epic build cycle — reads state.yaml, execution-status.yaml, and one epic capsule; updates status via bp-yaml-set or direct edit. Resume mode runs one step per invocation. Use instead of ad-hoc execute-plan for release work.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Beakpoint-Insights/roosttheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Beakpoint-Insights/roost★ 32same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository162 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- website/AGENTS.mdAGENTS.md
- .cursor/rules/align-grid.mdcCursor rule
- .cursor/rules/assess-impact.mdcCursor rule
- .cursor/rules/audit-code.mdcCursor rule
- .cursor/rules/audit-plan.mdcCursor rule
- .cursor/rules/build-epic.mdcCursor rule
- .cursor/rules/change-request.mdcCursor rule
- .cursor/rules/commit-message.mdcCursor rule
- .cursor/rules/compose-workflow.mdcCursor rule
- .cursor/rules/craft-skill.mdcCursor rule
- .cursor/rules/deepen-architecture.mdcCursor rule
- .cursor/rules/define-language.mdcCursor rule
- .cursor/rules/define-success.mdcCursor rule
- .cursor/rules/delegate-task.mdcCursor rule
- .cursor/rules/deploy.mdcCursor rule
- .cursor/rules/design-interface.mdcCursor rule
- .cursor/rules/develop-tdd.mdcCursor rule
- .cursor/rules/diagnose-root.mdcCursor rule
- .cursor/rules/diagnose-stall.mdcCursor rule
- .cursor/rules/dispatch-agents.mdcCursor rule
- .cursor/rules/edit-document.mdcCursor rule
- .cursor/rules/elaborate-spec.mdcCursor rule
- .cursor/rules/enforce-first.mdcCursor rule
- .cursor/rules/evolve-skill.mdcCursor rule
- .cursor/rules/execute-plan.mdcCursor rule
- .cursor/rules/extract-design.mdcCursor rule
- .cursor/rules/find-way.mdcCursor rule
- .cursor/rules/fix-bug.mdcCursor rule
- .cursor/rules/gate-trace.mdcCursor rule
- .cursor/rules/generate-allure-report.mdcCursor rule
- .cursor/rules/grill-me.mdcCursor rule
- .cursor/rules/grill-with-docs.mdcCursor rule
- .cursor/rules/guard-git.mdcCursor rule
- .cursor/rules/harden-vps.mdcCursor rule
- .cursor/rules/hook-commits.mdcCursor rule
- .cursor/rules/inspect-quality.mdcCursor rule
- .cursor/rules/investigate-bug.mdcCursor rule
- .cursor/rules/kickoff-branch.mdcCursor rule
- .cursor/rules/maintain-wiki.mdcCursor rule
- .cursor/rules/map-codebase.mdcCursor rule
- .cursor/rules/migrate-spec.mdcCursor rule
- .cursor/rules/model-domain.mdcCursor rule
- .cursor/rules/orchestrate-project.mdcCursor rule
- .cursor/rules/organize-workspace.mdcCursor rule
- .cursor/rules/plan-refactor.mdcCursor rule
- .cursor/rules/plan-release.mdcCursor rule
- .cursor/rules/plan-tests.mdcCursor rule
- .cursor/rules/plan-work.mdcCursor rule
- .cursor/rules/publish-package.mdcCursor rule
- .cursor/rules/quick-fix.mdcCursor rule
- .cursor/rules/release-branch.mdcCursor rule
- .cursor/rules/request-review.mdcCursor rule
- .cursor/rules/research-first.mdcCursor rule
- .cursor/rules/reset-baseline.mdcCursor rule
- .cursor/rules/respond-review.mdcCursor rule
- .cursor/rules/run-benchmark.mdcCursor rule
- .cursor/rules/run-evals.mdcCursor rule
- .cursor/rules/run-planning.mdcCursor rule
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 2 are distinctive, and 13 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 37
Read specs/state.yaml, specs/execution-status.yaml, specs/release-plan.yaml, active specs/epics/eNN-slug/epic.yaml.
- Very specific: line 38
On story start (step 1): Write started_at ISO 8601 timestamp to execution-status.yaml under the story's key in the stories: section.
- Very specific: line 39
Step 0 — Threat Model: Run security-review against the epic's scope (read from the epic capsule).
- Very specific: line 40
Assess Impact (Step 2): Before writing tasks, run assess-impact --lightweight on the proposed change.
- Very specific: line 41
BCP Tracking (Step 2): After plan-work completes, read the bcps: count (Business Complexity Points story size) from the epic capsule and …
- Very specific: line 42
BCP Plus (Step 2, optional): When the epic capsule carries a bcp_plus_breakdown (13-dimension sizing), also carry it into state.yaml as …
- Very specific: line 43
If epic_cycle.step missing, set to 1.
- Distinctive: line 44
Run only the current step (resume mode) unless user asked for full auto-run.
- Very specific: line 45
After step verify passes, increment epic_cycle.step in state.yaml (or bash scripts/bp-yaml-set.sh if available).
- Very specific: line 47
On story complete (step 8): Write completed_at ISO 8601 timestamp to execution-status.yaml under the same story key.
- Distinctive: line 63
If any script is missing or fails, note "OKF wiki refresh skipped" and continue.
- Very specific: line 68
After step 5 (verify-work) completes successfully, step 6 runs audit-code automatically in --gate mode:
- Very specific: line 71
Pass (exit 0): All checklist sections pass → run bash scripts/lib/assert-epic-gate.sh advance to mechanically confirm the audit pass, then …
- Very specific: line 74
Enforce F.I.R.S.T: After audit-code passes, run enforce-first --quick on new/modified tests.
- Very specific: line 100
Write handoff.next_skill and handoff.context in state.yaml when pausing mid-epic.
≈ “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.
Files
<!-- story: e20s05 -->Build Epic
Scope: one story. Called by orchestrate-project Phase 4. Not a replacement for orchestrate-project.
Orchestrates the build flow for a single epic: survey → plan tasks → kickoff → TDD → verify → audit → commit → release.
HARD GATE — Set
specs/state.yamlactive_flow: build_epicandactive_epic: eNNbefore starting.HARD GATE — Not on
main/masterbefore step 3 (kickoff-branch).
Nine steps (epic_cycle in state.yaml)
| Step | Skill / action | |
| 0 | security-review — threat-model epic scope → specs/security/epics/<id>/THREAT_MODEL.md | |
| 1 | survey-context — confirm epic + story | |
| 2 | plan-work — flesh out story tasks[] in specs/epics/eNN-slug/epic.yaml | |
| 3 | kickoff-branch — feature branch + clean baseline | |
| 4 | develop-tdd — red-green per task | |
| 5 | verify-work — UAT + mechanical gates | |
| 6 | audit-code — non-optional gate (pass/fail; fail → loop back to step 4) | |
| 7 | commit-message — Conventional Commits draft | |
| 8 | release-branch — PR or solo land (supports --squash-state) |
Process
- Read
specs/state.yaml,specs/execution-status.yaml,specs/release-plan.yaml, activespecs/epics/eNN-slug/epic.yaml.- On story start (step 1): Write
started_atISO 8601 timestamp toexecution-status.yamlunder the story's key in thestories:section. Thebp-timing.shscript already tracks skill-level timings — this is story-level.
- On story start (step 1): Write
- Step 0 — Threat Model: Run
security-reviewagainst the epic's scope (read from the epic capsule). Outputspecs/security/epics/<epic-id>/THREAT_MODEL.mdwith surface area, vulnerability categories, risk level, and mitigation guidance. - Assess Impact (Step 2): Before writing tasks, run
assess-impact --lightweighton the proposed change. If the risk score exceeds 7, gate — require agrill-mesession. Write the impact report tospecs/IMPACT-<epic>-<story>.md. For net-new code with no existing dependents, skip. - BCP Tracking (Step 2): After
plan-workcompletes, read thebcps:count (Business Complexity Points story size) from the epic capsule and carry it intostate.yamlasepic_cycle.story_bcps = N. - BCP Plus (Step 2, optional): When the epic capsule carries a
bcp_plus_breakdown(13-dimension sizing), also carry it intostate.yamlasepic_cycle.bcp_plus. The breakdown maps each of the 13 dimensions to an integer count. NFR dimensions (11–13) that are N/A per the NFR Gate may be set to 0. - If
epic_cycle.stepmissing, set to1. - Run only the current step (resume mode) unless user asked for full auto-run.
- After step verify passes, increment
epic_cycle.stepinstate.yaml(orbash scripts/bp-yaml-set.shif available). - On story complete, set
execution-status.yamlstory key todone; runbash scripts/sync-status-from-epics.sh.On story complete (step 8): Write
completed_atISO 8601 timestamp toexecution-status.yamlunder the same story key. Format:stories: e01s01: status: done started_at: "2026-07-12T16:00:00-03:00" completed_at: "2026-07-12T18:45:00-03:00"
- Traceability refresh: Before step 8 (release-branch), run
bash scripts/trace-stories.shto regeneratespecs/traceability-matrix.json,specs/TRACEABILITY_LATEST.md, and thespecs/codebase-wiki/OKF bundle. Surface dark/orphan/stale findings for the just-built epic in your verify summary. Ifscripts/trace-stories.shis missing or fails, note "trace skipped" and continue — trace failure must be visible, not silent (blocking is gate-trace's job, e38s06).
9b. OKF wiki refresh (e39s08): Before step 8, run maintain-wiki INGEST to refresh the OKF wiki bundle:
bash scripts/decompose-conventions.sh
bash scripts/generate-agent-guide.shIf any script is missing or fails, note "OKF wiki refresh skipped" and continue. This is non-blocking — stale concepts are caught by LINT in verify-work Phase 3.
Step 6 — audit-code gate (non-optional)
After step 5 (verify-work) completes successfully, step 6 runs audit-code automatically in --gate mode:
- Run audit: Invoke
audit-code --gateon the complete diff for this story. - Pass (exit 0): All checklist sections pass → run
bash scripts/lib/assert-epic-gate.sh advanceto mechanically confirm the audit pass, then advance to step 7 (commit-message). Recordepic_cycle.audit_result: passinstate.yaml. - Fail (exit 1): One or more checklist sections fail → reset
epic_cycle.current_stepto4(develop-tdd) and add the failing section IDs tocompleted_stepsas"1,2,3,4,5,6(fail: ...)". Recordepic_cycle.audit_result: failinstate.yaml. Do NOT advance past step 6 until audit passes. - Audit artifact: Full audit report saved to
specs/verifications/AUDIT-<epic>-<story>.mdregardless of pass/fail, for reviewer traceability. - Enforce F.I.R.S.T: After audit-code passes, run
enforce-first --quickon new/modified tests. Append F.I.R.S.T violations (if any) to the audit report. Failing F.I.R.S.T criteria trigger the same loop-back to step 4.
--fast mode
Coalesces read-and-report steps to reduce token overhead. Activate with build-epic --fast.
| Normal | --fast | Change |
| Step 1 (survey-context) | 1+2 together | survey + plan in one invocation |
| Step 2 (plan-work) | (absorbed into 1) | — |
| Step 3 (kickoff-branch) | Step 2 | unchanged, sequential |
| Step 4 (develop-tdd) | Step 3 | unchanged, sequential |
| Step 5 (verify-work) | Step 4 | unchanged, sequential |
| Step 6 (audit-code) | 5+6 together | audit + commit-message in one invocation |
| Step 7 (commit-message) | (absorbed into 6) | — |
| Step 8 (release-branch) | Step 7 | unchanged, sequential |
Total invocations: 8 → 6 per story.
Rules:
- Steps 3/4/5/8 (kickoff, develop, verify, release) still run sequentially — they require user interaction or branch state.
--fastdoes NOT skip any checklist items; it only coalesces steps that are pure read-and-report.- Record
epic_cycle.fast_mode: trueinstate.yamlwhen this flag is active.
Handoff
Write handoff.next_skill and handoff.context in state.yaml when pausing mid-epic.
Verify
→ verify: test -f specs/state.yaml && test -f specs/execution-status.yaml && test -f specs/release-plan.yaml && test -d skills/assess-impact && test -d skills/audit-code && test -d skills/security-review
<!-- story: e38s02 -->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
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.

