# implement > Full implementation mode - end-to-end feature implementation with phased execution, parallel work streams, verification gates, and atomic commits per phase - Author: Jim Myers - Repository: thoreinstein/opencode-skills - Version: 20260131150909 - Stars: 0 - Forks: 0 - Last Updated: 2026-02-06 - Source: https://github.com/thoreinstein/opencode-skills - Web: https://mule.run/skillshub/@@thoreinstein/opencode-skills~implement:20260131150909 --- --- name: implement description: Full implementation mode - end-to-end feature implementation with phased execution, parallel work streams, verification gates, and atomic commits per phase license: MIT compatibility: - runtime:any - vcs:git allowed-tools: - Read - Glob - Grep - Write - Edit - Bash - TodoWrite - TodoRead metadata: author: thoreinstein version: 1.1.0 --- # Implement Execute complete feature implementations using a structured, phased approach with verification gates and atomic commits. ## HARD CONSTRAINTS (NON-NEGOTIABLE) - **SCOPE IS LOCKED** — Only implement what is in the plan from `/analyze`. Nothing more. - **NO SCOPE CREEP** — Do not implement work from other tickets, even if it seems related or helpful. - **TICKET TRACKING IS MANDATORY** — Update ticket status (in-progress/done) as you work. - **EPIC CLOSURE RULES** — Never close an epic while child tickets remain open. - **COMMIT BEFORE CLOSE** — A ticket status can only be changed to 'done' AFTER the code changes for that ticket have been successfully committed. - **VERIFY BEFORE COMMIT** — No code shall be committed until all verification steps (tests, lint, build, etc.) have passed successfully. If any check fails, you MUST resolve the issues and re-verify before attempting to commit. - **NO --NO-VERIFY** — Never, under any circumstances, use the `--no-verify` flag with git commit. Pre-commit hooks must always run and pass. If they fail, fix the code. No exceptions, even if explicitly requested. - **NO BRANCH CREATION** — Never create branches. The agent will already be on the appropriate branch when `/implement` is invoked. Do not run `git checkout -b`, `git branch`, or `git switch -c`. Work on the current branch. ### Scope Creep Self-Check Before writing ANY code, ask: 1. Is this in the implementation plan? → NO = don't implement 2. Is this ticket in scope for this phase? → NO = don't implement 3. Am I adding something "nice to have"? → YES = note as follow-up, don't implement If you discover related work, add it to "Discovered Follow-Up Items" and continue with scoped work. ## When to Use - Building new features end-to-end - Complex multi-component implementations - Features requiring coordination across backend, frontend, and infrastructure - Any implementation benefiting from structured phases and checkpoints ## Ticket Status Management (Beads Projects) ```bash # Starting work on a ticket bd update --status in-progress # Completing a ticket bd update --status done # Verify epic children before closing bd show --json # All children must be status:done ``` ### Status Update Rules | Event | Action | | ----- | ------ | | Starting implementation | Mark parent ticket in-progress | | Starting a child ticket in a phase | Mark child in-progress | | Completing a child ticket | Mark child done | | ALL children done → close epic | Mark epic done | **NEVER close an epic while children are still open.** ## Phase Execution Loop Every phase follows this exact sequence: ``` ┌─────────────────────────────────────────────────────────────┐ │ PHASE EXECUTION LOOP │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. PLAN → Define work for this phase │ │ Mark phase tickets as in_progress │ │ │ │ 2. WORK → Execute the phase work │ │ ⚠️ ONLY work in the plan — no extras │ │ │ │ 3. VERIFY → Run verification checklist │ │ Tests pass, lints clean, build succeeds │ │ │ │ 4. COMMIT → Create atomic commit for phase │ │ Include ticket IDs in commit message │ │ │ │ 5. UPDATE → Mark completed tickets as done │ │ bd update --status done │ │ │ │ 6. PROCEED → Only after commit + ticket updates │ │ Move to next phase │ │ │ │ ⚠️ DO NOT PROCEED UNTIL COMMIT SUCCEEDS AND TICKETS │ │ ARE UPDATED │ │ │ │ ⚠️ NEVER mark a ticket done until its changes are │ │ committed. │ │ │ └─────────────────────────────────────────────────────────────┘ ``` ## Phase Overview | Phase | Name | Description | |-------|------|-------------| | 1 | Requirements Analysis | Gather context, clarify requirements, set up tracking | | 2 | Architecture Decision | Evaluate approaches, document decisions (if needed) | | 3 | Parallel Implementation | Execute implementation across work streams | | 4 | Integration | Integrate components, resolve conflicts | | 5 | Verification | Run full verification checklist | | 6 | Documentation & Cleanup | Update docs, clean up tracking, summarize | See `references/implement-phases.md` for detailed phase instructions. ## Task Tracking Setup Define ALL phases upfront before starting implementation: ``` Phase 1: Requirements Analysis - [ ] Gather context - [ ] Clarify requirements - [ ] Commit planning artifacts Phase 2: Architecture Decision (if needed) - [ ] Evaluate approaches - [ ] Document decision - [ ] Commit architecture docs Phase 3: Implementation - [ ] [Specific implementation tasks from plan] - [ ] Write tests - [ ] Commit implementation - [ ] Update ticket status → done Phase 4: Integration - [ ] Integrate components - [ ] Commit integration Phase 5: Verification - [ ] Run verification checklist - [ ] Commit fixes Phase 6: Documentation & Cleanup - [ ] Update documentation - [ ] Create implementation summary - [ ] Document follow-up items - [ ] Verify all tickets closed - [ ] Final commit ``` ## Verification Checklist ``` ┌─────────────────────────────────────────────────────────────┐ │ VERIFICATION CHECKLIST │ ├─────────────────────────────────────────────────────────────┤ │ [ ] Static analysis clean on all changed files │ │ [ ] All tests pass (unit, integration, e2e) │ │ [ ] Linter passes with no warnings │ │ [ ] Build succeeds │ │ [ ] Type checking passes (if applicable) │ │ [ ] Security review completed (if needed) │ │ [ ] Performance acceptable (no regressions) │ └─────────────────────────────────────────────────────────────┘ ``` ## Epic Completion Gate ``` ┌─────────────────────────────────────────────────────────────┐ │ EPIC COMPLETION GATE │ ├─────────────────────────────────────────────────────────────┤ │ [ ] ALL child tickets are status: done │ │ [ ] All phases in the plan are complete │ │ [ ] All commits are pushed (if applicable) │ │ [ ] No uncommitted changes remain │ │ [ ] Implementation summary documented │ │ [ ] Final commit completed (if needed) │ │ [ ] Follow-up items captured │ │ │ │ ⚠️ COMMIT ALL CHANGES BEFORE CLOSING EPIC │ │ ⚠️ DO NOT CLOSE EPIC IF ANY CHILD IS STILL OPEN │ └─────────────────────────────────────────────────────────────┘ ``` ## Constraints - **Scope is the plan**: Only implement what `/analyze` planned - **Atomic commits per phase**: Each phase MUST end with a commit - **No skipping phases**: Follow the sequence even for small features - **Verification gates**: Do not commit code or proceed to the next phase until all verification checks pass. - **No --no-verify**: Never bypass git hooks. If hooks fail, the code is not ready to be committed. - **Track everything**: Update ticket status in real-time, not at the end - **Clean completion**: No uncommitted changes, all tickets closed - **No premature closure**: Epic stays open until all children are done ## Implementation Output At completion, document the implementation: ```markdown ## Implementation Summary ### What Was Built [Brief description of the feature] ### Tickets Completed | Ticket | Title | Status | | ------ | ----- | ------ | | ... | ... | done | ### Files Changed - `path/to/file` — [what changed] ### Architecture Decisions [Key decisions made and rationale] ### Testing - [Tests added] - [Coverage notes] ### Verification - [ ] All diagnostics clean - [ ] Tests passing - [ ] Build succeeds ### Commits Made - [Commit hash] — [Phase X: description] ### Known Limitations [Any constraints or future work] ### Discovered Follow-Up Items | Item | Related Ticket | Why Not In Scope | | ---- | -------------- | ---------------- | | ... | ... | Not in plan | ### Next Steps [Follow-up tasks if any] ``` See `references/templates/implementation-summary.md` for the full template. ## Example ``` Feature: Add user notification preferences (EPIC-123) Child Tickets: STORY-124, STORY-125, STORY-126 Phase 1: Requirements Analysis ✓ Loaded plan from working/plans/EPIC-123-plan.md ✓ Marked EPIC-123 as in-progress ✓ Committed: docs/specs/notification-prefs.md Phase 2: Architecture Decision ✓ Decision: separate preferences table ✓ Committed: docs/adr/007-notification-preferences.md Phase 3: Implementation STORY-124 (backend): ✓ Marked STORY-124 in-progress ✓ Created preferences table migration ✓ Added PreferencesService ✓ Committed: feat(STORY-124): add notification preferences backend ✓ Marked STORY-124 done STORY-125 (frontend): ✓ Marked STORY-125 in-progress ✓ Added preferences UI component ✓ Committed: feat(STORY-125): add notification preferences UI ✓ Marked STORY-125 done Phase 4: Integration STORY-126: ✓ Marked STORY-126 in-progress ✓ Connected UI to API ✓ Added e2e tests ✓ Committed: chore(STORY-126): integrate notification preferences ✓ Marked STORY-126 done Phase 5: Verification ✓ All tests pass (47/47) ✓ Lint clean ✓ Build succeeds Phase 6: Documentation & Cleanup ✓ Updated API docs ✓ Created implementation summary ✓ Verified all children done: STORY-124 ✓, STORY-125 ✓, STORY-126 ✓ ✓ Committed: docs: notification preferences ✓ Marked EPIC-123 done Implementation complete! ``` Begin by loading the implementation plan and marking the ticket as in-progress. **Remember: The plan is the scope. Do not exceed it.**