// Use when a written implementation plan exists at docs/dev/plans/ and you need to execute it task-by-task in the current session with verification at each step.
Use before any creative work — designing a new amdsmi_* API, adding a CLI command, building a feature, or modifying behavior. Explores intent, requirements, and design before any code is written.
Use when facing 2+ independent problems with no shared state — e.g., unrelated test failures in different subsystems, multiple independent bug investigations, parallel research tasks. Dispatch one focused subagent per domain instead of investigating sequentially.
Use when finishing an amd-smi development branch — consolidating commits into logical groups with clean messages AND deciding how to integrate the work (merge to develop, push and open PR, keep as-is, or discard). Covers commit restructuring plus the merge/PR/cleanup workflow.
Use when encountering any bug, test failure, build failure, or unexpected behavior in amd-smi — before proposing any fix. Enforces root-cause investigation before symptom patching.
Use when implementing any amd-smi feature, bug fix, or behavior change — before writing implementation code. Enforces strict RED-GREEN-REFACTOR: failing test first, watch it fail, minimal code to pass, refactor.
Use when starting amd-smi feature work, executing an implementation plan, or reviewing a PR that needs an isolated workspace away from the main checkout. Sets up a worktree following the rocm-systems-pr<PR#> convention.
| name | executing-plans |
| description | Use when a written implementation plan exists at docs/dev/plans/ and you need to execute it task-by-task in the current session with verification at each step. |
Load the plan, review it critically, execute every task in order, verify at every step, report when done.
Announce at start: "I'm using the executing-plans skill to implement this plan."
If subagent dispatch is available and the plan has 3+ independent tasks, prefer the amdsmi-development agent's subagent-driven mode — it isolates per-task context and gives higher-quality output. Use this skill when subagents aren't available or the plan is small enough to run inline.
Verify you're in an isolated workspace. If not, invoke using-git-worktrees before touching code.
For each task in the plan:
in-progress in the todo listcompletedAfter every task: invoke verification-before-completion before marking the task done. Compilation success is not verification.
After all tasks complete:
amdsmi-test-runner skill)pre-commit run --all-filesproject-layout rule's "Quick Check" grep)Invoke the restructure-commits skill — the "Finishing" section handles merge/PR/discard options.
STOP immediately when:
systematic-debugging Phase 4.5)Ask the user. Don't guess. Don't improvise.
Return to Step 1 (re-review) if:
Do NOT batch-edit later tasks to compensate for an earlier task's gaps — fix the plan, then re-execute.
| Symptom | Action |
|---|---|
| Skipping a verification step "to save time" | Stop. Verification steps are mandatory. |
| Editing files outside the plan's "Files" list | Stop. Ask whether the plan needs updating. |
| Batching multiple tasks into one commit | Stop. Commit per the plan. |
| "The test failure looks unrelated" | Run systematic-debugging. Don't dismiss. |
Starting on develop/main without a feature branch | Stop. Create a branch (or worktree) first. |
using-git-worktrees — set up isolated workspace before Step 3test-driven-development — when the plan says "write failing test", follow strict RED-GREEN-REFACTORverification-before-completion — after every tasksystematic-debugging — when a step fails unexpectedlyrestructure-commits — to finish the branch (Step 5)