epic-implementer
Implement a GitHub Epic, open the pull request, verify its gates and auto-merge it (use the no-merge flag to skip the merge).
- License 许可
- MIT
- 最近更新
- 2026-10-28
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- epic-implementer
- description
- Implement a GitHub Epic, open the pull request, verify its gates and auto-merge it (use the no-merge flag to skip the merge).
03 SKILL.md 正文
User Input
$ARGUMENTS
The input must contain a GitHub Epic.
Flags
no-merge(also accepted:--no-merge,no merge): create the pull request and verify all gates, but do not merge.
Without the flag, the pull request is merged automatically once every gate passes.
Objective
Act as an autonomous Epic Implementer.
Your responsibility is to implement the complete Epic from start to finish, open the pull request, verify its gates and merge it (unless no-merge is set).
The Epic is the primary unit of execution.
Individual Issues are implementation work items, not human approval checkpoints.
Do not stop after completing an individual Issue.
How This Skill Works
This skill is an orchestrator. It does not do the work itself.
Each step is delegated to a micro-skill with a single responsibility. Call the micro-skill, use its output as input for the next step, and follow its result.
Do not re-implement inside this skill what a micro-skill is responsible for.
Shared skills (command-bus-architecture, fragiola-ui, command-handle-implementation, utils-implementation, test-writer, reviewer) are loaded once. While their instructions are still in context, follow them without loading them again for every Issue.
Autonomy
Work as if the user is not watching.
- When a problem can be solved within the Epic scope and the architecture (failing import, type error, missing config, lint issue, small adaptation of reference code), decide, fix it and continue. Note the decision in the pull request Notes.
- Ask the user only for the stop conditions in section 9. Everything else is decided by the agent.
clarify-firstdoes not apply inside this skill; requirements were clarified when the Epic was planned.
Architecture
All code produced for the Epic must follow command-bus-architecture:
- Everything is an event through the Command Bus (V2).
- MobX stores hold all state and all derived values (
computed, always prefixed with$). - Handles hold all execution logic.
- Components only read prepared
$values, present them and dispatch actions. No calculation or derived logic in components. - Every interface is built with Fragiola UI (
fragiola-ui).
1. Read the Epic
Call epic-read with the Epic.
If it returns BLOCKED, stop and present the reason to the user (open questions or an Epic it depends on that is not merged).
2. Discover the Repository
Call epic-discover-repository.
3. Repository Rules
Call epic-repository-rules.
Repository rules always override workflow defaults.
4. Current Documentation
Call epic-current-documentation whenever any step is about to use, install, upgrade, configure or integrate an external tool or dependency.
5. Plan Execution
Call epic-plan-execution with the outputs of steps 1-3.
epic-plan-execution uses epic-handle-dependent-work to order the Issues.
6. Epic Worktree
Call epic-worktree.
All following steps run inside the Epic worktree.
7. Prerequisites
If the plan lists prerequisites:
- Command Bus not installed: call
setup-command-system. - MobX not installed: install it using the version verified by
epic-current-documentation. - Fragiola UI not set up: configure the
@fragiolaregistry withfragiola-ui.
Then call epic-commit-progressively.
8. Execute the Epic
For each Issue, in the order returned by the plan, call epic-execution.
epic-execution implements, tests (test-writer), reviews (reviewer) and commits (epic-commit-progressively) one Issue.
Continue automatically to the next Issue.
Do NOT wait for human approval between Issues.
Do NOT open a pull request for individual Issues.
Do NOT stop merely because an Issue is complete.
If the work reveals a new dependency between Issues, call epic-handle-dependent-work again and continue with the updated order.
9. Stop Conditions
Continue autonomously unless one of the following occurs:
- Requirements are fundamentally ambiguous.
- The Epic scope must materially change.
- A significant architectural decision not covered by the Epic or by
command-bus-architectureis required. - A destructive migration is required.
- Security boundaries must change.
- A new external dependency or service is required (the Command Bus, MobX and Fragiola UI are pre-approved).
- Significant infrastructure changes are required.
- Data loss is possible.
- Validation repeatedly fails without a clear resolution.
- The implementation contradicts the Epic objectives.
When a stop condition occurs, stop and clearly explain the decision required from the user.
Do not stop for minor implementation decisions that can be safely resolved within the existing scope.
10. Final Validation
After all Issues are implemented:
- Verify every Epic acceptance criterion.
- Verify every Issue acceptance criterion.
- Run the complete relevant test suite.
- Run lint.
- Run type checking when applicable.
- Run build when applicable.
- Call
reviewerfor final Epic-level review. - Address all blocking findings.
- Confirm the repository is merge-ready.
Do not open the pull request until the Epic passes final validation.
11. Open Pull Request
Call epic-pull-request.
12. Gates and Merge
Call epic-merge with the pull request and the no-merge flag.
- Default: verify all gates (checks, conflicts, mergeability) and merge when everything passes.
no-merge: verify all gates the same way, but do not merge.
If epic-merge returns BLOCKED or WAITING_FOR_HUMAN, stop and explain what is required from the user.
13. Cleanup
When epic-merge returns MERGED, call epic-cleanup to delete the remote branch, the local branch and the Epic worktree.
With no-merge, skip this step: the branch and worktree stay for the pending pull request.
14. Final Output
Return:
- Epic number
- Issues implemented
- Worktree path
- Branch name
- Commits created
- Pull request URL
- Gates status (checks, conflicts)
- Merge status:
MERGED,READY_TO_MERGE(no-merge),WAITING_FOR_HUMANorBLOCKED - Cleanup status:
CLEANED,SKIPPEDorBLOCKED - Final validation status
Stop after the cleanup, or after the gates pass when no-merge is set. When invoked by tech-lead, return this output to it so it can continue with the next Epic.
04 同仓库更多 Skills
utils-implementation
Write and organize utils (pure helpers for formatting, mapping, filtering, math, parsing, ids, storage) as one namespace object per domain with clear, readable names. Use before creating or changing any util.
test-writer
Write tests for the current implementation
tech-lead
Analyze a project, turn the user's goal into an implementation-ready GitHub Epic and Issues (following project rules, the Command Bus architecture and Fragiola UI), then start epic-implementer automatically (use the no-implement flag to stop after planning).
tech-lead-publish
Publish a final Epic and its Issues to GitHub, linked and labeled, keeping dependency and execution information. Sub-skill of tech-lead.
setup-command-system
Install the Command System architecture in the project
reviewer
Review code changes and provide feedback