implement-slice-complement
SolidExecute a bounded micro-delta (adjustments, fixes, polish, missed checklist items) that stays inside the same slice intent and DECISIONS.md, then record evidence in slice notes and/or TASK_STATE.md without churning unrelated artifacts. Use when a slice was already implemented or is ready-to-close-with-follow-ups and you discovered a narrow gap (bug, typo, test, log line, copy, small refactor under the same acceptance story), you can state the work as a numbered micro-delta list, and the file touch set is small with named primary paths. Do not use when work belongs to net-new scope (use implementation-plan plus a new slice), correctness-critical ambiguity is open (route upstream to targeted-questions or decision-interview), the change would materially alter signed-off decisions (use post-review-pivot), only state memory needs updating (use sync-task-state), only closure judgment is needed (use slice-closure), or the micro-delta list is empty or vague.
Install
Quality Score: 81/100
Skill Content
Details
- Author
- Mozurok
- Repository
- Mozurok/fhorja.dev
- Created
- 1 months ago
- Last Updated
- 5 days ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
implement-approved-slice
Implement only the approved slice with minimal, explicit, review-friendly changes, then persist execution evidence in slice notes and TASK_STATE.md. The single official execution path of the workflow. Supports an opt-in test-first (TDD) mode, enabled per slice or via --tdd, that writes the failing test before the code (ADR-0063). Use when the task has a valid IMPLEMENTATION_PLAN.md, the current slice is explicitly defined and approved, correctness-critical ambiguity is already resolved, and the files in scope are known well enough to edit safely. Do not use when the task is still in discovery or contract refinement or planning, when unresolved ambiguity still affects correctness, when the slice boundary is still unclear, when the next step is only to sync task memory or close the slice (use sync-task-state or slice-closure), or when the remaining work is a narrow micro-delta anchored to an already-executed slice with the same intent (use implement-slice-complement).
implement-slice
Use when a delivery run dispatches any code-executing action: implementing an approved backend slice, implementing an approved frontend slice, or applying a minimal fix to an isolated defect. One shared procedure — execute a bounded change per an approved target, produce the change plus targeted validation, never expand scope — parameterized by the action id passed as the first skill argument (backend_implementation, frontend_implementation, or apply_minimal_fix) and the persona dispatched (backend-developer or frontend-developer, who carries the domain lens). Replaces the retired backend-implementation, frontend-implementation, and apply-minimal-fix skills.
implementation-plan
Define an incremental, reviewable, production-safe implementation plan for the active task and persist it as IMPLEMENTATION_PLAN.md plus a TASK_STATE.md update. Breaks work into the smallest safe slices with objective, exact scope, ordering rationale, key risks, validation approach, exit criteria, and work complexity (LOW/MEDIUM/HIGH) per slice. No code is written. Also runs an annotate-only retrofit mode that backfills per-slice Scope and Depends-on plus an Execution waves section onto an existing in-progress plan so it can adopt implement-fleet, without re-planning. A --spec mode derives slices from a spec or PRD, checking every spec item is covered (ADR-0061). Use when impact is understood enough to plan safely, key boundaries are known, and major factual or decision ambiguity is already resolved. Do not use when the task is still too unclear, when key facts or decisions remain open, or when the current need is to implement an already-approved slice (use implement-approved-slice).