원클릭으로
fix-issue
Guidelines for deeply exploring the problem space first and designing the best solution before implementing.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Guidelines for deeply exploring the problem space first and designing the best solution before implementing.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.