// 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.
| name | brainstorming |
| description | 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. |
Turn ideas into approved designs through structured dialogue. Surface assumptions, propose alternatives, write the spec. No code until the spec is approved.
Do NOT invoke any implementation skill, edit any source file, or create any wrapper/CLI binding until you have presented a design and the user has explicitly approved it. "Simple" changes are where unexamined assumptions cause the most rework — every task gets a design, even if the design is three sentences.Complete in order. Use the todo tool to track each step.
project-layout rule)docs/dev/specs/YYYY-MM-DD-<topic>-design.md and commitwriting-plans — that is the ONLY next skillBeyond the generic design sections, an amd-smi spec must address:
| Section | Why It Matters |
|---|---|
| API cascade impact | Which layers change: header → amd_smi.cc → wrapper → interface → CLI → docs |
| Backward compatibility | Public C API is contract — additions safe, signature changes are breaking |
| Error path | New amdsmi_status_t values? Mapping to AmdSmiException? |
| Test plan | C++ GTest, Python unit, Python integration, CLI — which suites need new tests |
| Hardware dependency | Requires GPU? Specific ASIC? Document the test environment |
| Build/packaging impact | New CMake option? New file in install set? RPM + DEB both? |
| Changelog entry | What goes in CHANGELOG.md under the next version |
If the request touches multiple independent subsystems (e.g., new metric + new CLI subcommand + new logging mode), flag this immediately. Decompose into independent sub-projects, each with its own spec → plan → implementation cycle. Don't refine details of a feature that needs splitting first.
Before asking the user to review, look at the spec with fresh eyes:
TBD, TODO, vague requirements? Fix them.Fix inline. Move on.
After self-review:
"Spec written and committed to
<path>. Please review it and let me know if you want changes before I write the implementation plan."
Wait for explicit approval. If changes requested, fix and re-run self-review. Only proceed once approved.
All of these mean: stop, return to the checklist.
Invoke the writing-plans skill. Do NOT invoke any other skill from here.
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 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 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.