epic-dev

Name: epic-dev
Author: neuromechanist

37stars7forks

How to install epic-dev?

neuromechanist/research-skills/epic-dev

$npx -y skills add neuromechanist/research-skills --skill epic-dev

Installs into the current project.

Summary

Execute the project epic development workflow for Codex. Use when the user asks for "epic dev", "epic-dev", "/epic-dev", "run the epic workflow", "create an epic", "resume the epic", "--resume", "--next-phase", "--finalize", phased feature delivery, sprint phases, GitHub sub-issu

Files · 1

View on GitHub

SKILL.md

1	# Epic Development Workflow
2
3	Codex entrypoint for the same phased epic workflow exposed to Claude Code as
4	`/epic-dev`. Use `workflow-reference` for command snippets, state shape, and
5	variation details, then follow this procedure as the execution contract.
6
7	## Operating Rules
8
9	- Execute repository detection, GitHub lookups, worktree setup, tests, commits, PR creation, and cleanup directly when prerequisites are valid.
10	- Ask before strategic points only: epic plan approval, per-phase implementation plan approval, critical review decisions, and final epic merge.
11	- Use absolute paths in shell commands. Do not rely on a previous `cd`.
12	- Track progress with the active planning tool when available.
13	- Do not use `codex/` branch prefixes. Prefer `feature/issue-{N}-...`, `patch/...`, or `chore/...` per project rules.
14	- Do not use emojis in issues, PRs, commits, or generated state.
15	- Keep the lead on Sol (or the strongest available model) for epic design,
16	observation, approvals, supervision, load-bearing verification, and final
17	synthesis. Use Terra only to elaborate an approved phase architecture, and
18	Luna for detailed implementation, focused review, and validation. Escalate
19	unresolved design or high-risk invariants per `agent-fanout`.
20	- Semantic line breaks remain the default for prose source, except GitHub issue
21	and pull-request bodies. In GitHub bodies, keep each paragraph on one source
22	line, separate paragraphs with blank lines, and do not insert sentence- or
23	clause-level newlines inside a paragraph.
24
25	## Phase 0: Repository Detection
26
27	1. Run `project-detect-repo-config` from the target repository.
28	2. Validate required values before continuing:
29	- `INTEGRATION_BRANCH`
30	- `REPO_ROOT`
31	- `CURRENT_BRANCH`
32	3. Stop and report the exact error if `ERROR` is set or required values are empty.
33	4. Validate GitHub CLI access. If `HAS_GH=false` or `GH_ERROR` is set, tell the user what to fix and stop.
34	5. If `HAS_GH_SUBISSUE=false`, install `gh-sub-issue` with `gh extension install agbiotech/gh-sub-issue` after normal approval rules for networked commands.
35	6. Read existing state from `.claude/epic.local.md` if present. New Codex runs may continue using that file for compatibility with the Claude command.
36
37	## Mode Parsing
38
39	Interpret the user request:
40
41	\| Input \| Mode \| Action \|
42	\| --- \| --- \| --- \|
43	\| `--resume` \| Resume \| Read state, find the current incomplete phase, and continue. \|
44	\| `--next-phase` \| Next phase \| Read state, find the next pending phase, and start it. \|
45	\| `--finalize` \| Finalize \| Skip to the final epic PR and cleanup. \|
46	\| Any other text \| New epic \| Treat the text as the epic description. \|
47	\| Empty request \| New epic \| Ask for the epic description. \|
48
49	For resume modes, validate state fields before acting: `epic_issue`,
50	`epic_branch`, `integration_branch`, `phases`, and `current_phase`.
51
52	## Phase 1: Epic Setup
53
54	1. Gather the epic description and phase breakdown. Suggest phases when the user has not provided them, using the sizing rule in `workflow-reference` (one phase = one independently reviewable and testable PR, roughly one subsystem or up to ~500 net changed lines; if two candidate phases can only be tested together, they are one phase). If the description contains only one such unit, use the single-phase shortcut.
55	2. Present the plan for confirmation:
56
57	```text
58	Epic: {title}
59	Integration branch: {INTEGRATION_BRANCH}
60	Epic branch: feature/issue-{N}-epic-{slug}
61
62	Phases:
63	1. {phase 1 title}
64	2. {phase 2 title}
65
66	Proceed?
67	```
68
69	3. After confirmation, create the epic issue, phase sub-issues, and links:
70	- `gh issue create --title "Epic: {title}" --label "feature"`
71	- `gh issue create --title "Phase {X}: {title}" --label "feature"`
72	- `gh sub-issue add {epic_issue} --sub-issue-number {phase_issue}`
73	4. Create the epic worktree from the integration branch unless this is a single-phase feature.
74	5. Write `.claude/epic.local.md` using the format in `workflow-reference`.
75	6. Ensure `.claude/*.local.md` is ignored without overwriting existing `.gitignore` customizations.
76
77	For a single-phase feature, skip the epic worktree and sub-issues. Create one
78	feature branch from the integration branch and target the integration branch
79	directly.
80
81	## Phase 2: Sprint Execution
82
83	For each phase, starting from the current state:
84
85	1. Create or reuse the phase worktree from the epic branch.
86	2. Mark the phase `in_progress`.
87	3. Have the lead define the phase architecture and open judgment calls. After
88	approval, a Terra phase planner may expand it into exact files, decisions,
89	tests, and gates. Ask for approval of the worker-execu

People who liked this also viewed

6 picks

Type

epic-dev

37stars7forks

View on GitHub

How to install epic-dev?

neuromechanist/research-skills/epic-dev

$npx -y skills add neuromechanist/research-skills --skill epic-dev

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Epic Development Workflow
2
3	Codex entrypoint for the same phased epic workflow exposed to Claude Code as
4	`/epic-dev`. Use `workflow-reference` for command snippets, state shape, and
5	variation details, then follow this procedure as the execution contract.
6
7	## Operating Rules
8
9	- Execute repository detection, GitHub lookups, worktree setup, tests, commits, PR creation, and cleanup directly when prerequisites are valid.
10	- Ask before strategic points only: epic plan approval, per-phase implementation plan approval, critical review decisions, and final epic merge.
11	- Use absolute paths in shell commands. Do not rely on a previous `cd`.
12	- Track progress with the active planning tool when available.
13	- Do not use `codex/` branch prefixes. Prefer `feature/issue-{N}-...`, `patch/...`, or `chore/...` per project rules.
14	- Do not use emojis in issues, PRs, commits, or generated state.
15	- Keep the lead on Sol (or the strongest available model) for epic design,
16	observation, approvals, supervision, load-bearing verification, and final
17	synthesis. Use Terra only to elaborate an approved phase architecture, and
18	Luna for detailed implementation, focused review, and validation. Escalate
19	unresolved design or high-risk invariants per `agent-fanout`.
20	- Semantic line breaks remain the default for prose source, except GitHub issue
21	and pull-request bodies. In GitHub bodies, keep each paragraph on one source
22	line, separate paragraphs with blank lines, and do not insert sentence- or
23	clause-level newlines inside a paragraph.
24
25	## Phase 0: Repository Detection
26
27	1. Run `project-detect-repo-config` from the target repository.
28	2. Validate required values before continuing:
29	- `INTEGRATION_BRANCH`
30	- `REPO_ROOT`
31	- `CURRENT_BRANCH`
32	3. Stop and report the exact error if `ERROR` is set or required values are empty.
33	4. Validate GitHub CLI access. If `HAS_GH=false` or `GH_ERROR` is set, tell the user what to fix and stop.
34	5. If `HAS_GH_SUBISSUE=false`, install `gh-sub-issue` with `gh extension install agbiotech/gh-sub-issue` after normal approval rules for networked commands.
35	6. Read existing state from `.claude/epic.local.md` if present. New Codex runs may continue using that file for compatibility with the Claude command.
36
37	## Mode Parsing
38
39	Interpret the user request:
40
41	\| Input \| Mode \| Action \|
42	\| --- \| --- \| --- \|
43	\| `--resume` \| Resume \| Read state, find the current incomplete phase, and continue. \|
44	\| `--next-phase` \| Next phase \| Read state, find the next pending phase, and start it. \|
45	\| `--finalize` \| Finalize \| Skip to the final epic PR and cleanup. \|
46	\| Any other text \| New epic \| Treat the text as the epic description. \|
47	\| Empty request \| New epic \| Ask for the epic description. \|
48
49	For resume modes, validate state fields before acting: `epic_issue`,
50	`epic_branch`, `integration_branch`, `phases`, and `current_phase`.
51
52	## Phase 1: Epic Setup
53
54	1. Gather the epic description and phase breakdown. Suggest phases when the user has not provided them, using the sizing rule in `workflow-reference` (one phase = one independently reviewable and testable PR, roughly one subsystem or up to ~500 net changed lines; if two candidate phases can only be tested together, they are one phase). If the description contains only one such unit, use the single-phase shortcut.
55	2. Present the plan for confirmation:
56
57	```text
58	Epic: {title}
59	Integration branch: {INTEGRATION_BRANCH}
60	Epic branch: feature/issue-{N}-epic-{slug}
61
62	Phases:
63	1. {phase 1 title}
64	2. {phase 2 title}
65
66	Proceed?
67	```
68
69	3. After confirmation, create the epic issue, phase sub-issues, and links:
70	- `gh issue create --title "Epic: {title}" --label "feature"`
71	- `gh issue create --title "Phase {X}: {title}" --label "feature"`
72	- `gh sub-issue add {epic_issue} --sub-issue-number {phase_issue}`
73	4. Create the epic worktree from the integration branch unless this is a single-phase feature.
74	5. Write `.claude/epic.local.md` using the format in `workflow-reference`.
75	6. Ensure `.claude/*.local.md` is ignored without overwriting existing `.gitignore` customizations.
76
77	For a single-phase feature, skip the epic worktree and sub-issues. Create one
78	feature branch from the integration branch and target the integration branch
79	directly.
80
81	## Phase 2: Sprint Execution
82
83	For each phase, starting from the current state:
84
85	1. Create or reuse the phase worktree from the epic branch.
86	2. Mark the phase `in_progress`.
87	3. Have the lead define the phase architecture and open judgment calls. After
88	approval, a Terra phase planner may expand it into exact files, decisions,
89	tests, and gates. Ask for approval of the worker-execu

People who liked this also viewed

6 picks

Type