Menu
Guidelines for deeply exploring the problem space first and designing the best solution before implementing.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Run comprehensive Rust code quality checks including compilation, linting, documentation, and tests. Use after completing code changes and before creating commits.
Enforce the "Clean Imports over Inline Absolute Paths" rule by removing inline crate:: prefixes and adding proper use statements.
Rules and guidelines for creating well-formatted commit messages, including 72-char limits, scope prefixes, and trailer blocks for tasks, PR closing, and attribution.
Zero-allocation string building strategies. Use when formatting strings, generating ANSI codes, or writing hot loops to avoid heap allocations and Formatter state machine overhead.
Run clippy linting, enforce comment punctuation rules, format code with cargo fmt, and verify module organization patterns. Use after code changes and before creating commits.
Standard for writing structured tracing logs behind debug flags.
| name | fix-issue |
| description | Guidelines for deeply exploring the problem space first and designing the best solution before implementing. |
This skill codifies the "slow and steady" approach to solving non-trivial issues or adding features. It enforces exploring the problem space, considering alternative designs, and formalizing the design before writing any implementation code.
Use this skill whenever you are:
The workflow consists of four distinct steps:
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ 1. Deep Research │ ───► │ 2. Design Doc │ ───► │ 3. User Review │ ───► │ 4. Implementation │
│ (No Code Written) │ │ (Task MD File) │ │ & Approval │ │ (Iterative Step) │
└───────────────────┘ └───────────────────┘ └───────────────────┘ └───────────────────┘
Before proposing any changes or writing a task file, gather context on the problem space:
gh issue view <id>).Create the task file under task/issue-<id>-fix.md or task/<name>.md.
Create a new git branch for this task, push it, and open a Draft PR using gh pr create --draft --fill to track the work.
Instead of a simple todo list, format this task file as a Design Document with the following sections:
Present at least two (ideally three) alternative approaches. For each alternative, detail:
The very last section containing flat checklists grouped under phase headers.
Present the newly created task file to the user.
Only after the design doc is approved, load the task and begin implementation step-by-step.
./check.fish) and pause for manual reviews frequently.Once the implementation is fully tested and manually reviewed:
/merge-pr slash command to push the final code and merge the existing Pull Request into main.