Receive a task, classify its difficulty, think proportionally, and start working immediately.
<output_language>
Default all user-facing deliverables, saved artifacts, reports, plans, generated docs, summaries, handoff notes, commit/message drafts, and validation notes to Korean, even when this canonical skill file is written in English.
Preserve source code identifiers, CLI commands, file paths, schema keys, JSON/YAML field names, API names, package names, proper nouns, and quoted source excerpts in their required or original language.
Use a different language only when the user explicitly requests it, an existing target artifact must stay in another language for consistency, or a machine-readable contract requires exact English tokens. If a localized template or reference exists (for example *.ko.md or *.ko.json), prefer it for user-facing artifacts.
</output_language>
- Start clear implementation tasks immediately with proportional reasoning depth.
- Classify task difficulty before editing so easy work stays light and hard work gets enough context.
- Route diagnosis, planning, review, deployment, security, or explicit workflow requests to more specific skills.
<routing_rule>
Positive triggers
- A direct task instruction with a clear deliverable: "add pagination to the user list", "implement dark mode toggle".
- An explicit execution request: "do this", "build this", "make this work".
- A scoped feature or change request that does not require extended planning: "refactor this", "add tests", "clean up this component".
Out-of-scope
Route neighboring work elsewhere by the shape of its output:
- A bug report whose deliverable is a root cause and a repair for the reported symptom, not the new work requested here.
- A repository-wide build, CI, or deployment failure whose deliverable is a restored pipeline.
- A pre-release readiness verdict whose deliverable is a go/no-go assessment instead of an implemented change.
- A strategic plan or architecture decision whose deliverable is a requirements document or an architecture document.
- Raw client or customer feedback whose deliverable is an interpreted, repository-grounded feedback report.
- A security assessment whose deliverable is a vulnerability finding instead of the requested change.
- An explicitly named multi-step workflow whose deliverable is that workflow's own artifact. Preserve the explicitly requested workflow instead of treating the prompt as a generic execute task.
Boundary cases
- If the request mixes a bug fix with new work, execute owns it when the primary intent is the new work.
- If the task scope is genuinely unclear (no deliverable identifiable), ask one clarifying question — then execute.
- If the user asks for a persistent guaranteed-completion loop ("keep going until done", "until max score", or Ralph-style repetition), route to Ralph when available rather than silently downgrading it to one-shot execute.
- If the task turns out to require architectural decisions mid-flight, pause and consult the user rather than guessing.
</routing_rule>
<instruction_contract>
| Field | Contract |
|---|---|
| Intent | Execute a clear task directly while scaling reasoning and verification to task difficulty. |
| Trigger | Direct implementation, refactor, test, cleanup, or "do/build/make this work" requests with an identifiable deliverable. |
| Scope | Own context gathering, code edits, validation, and final Korean execution report for the requested deliverable. |
| Authority | User and project instructions outrank this skill; repository files and validation output are evidence. |
| Evidence | Use local file reads, search results, diffs, test/build/lint output, and runtime checks when relevant. |
| Tools | Use local read/edit/search/shell tools; gate destructive, credentialed, production, and external side effects. |
| Loop | No optimization loop. One pass per request: validate input, classify difficulty, think proportionally, implement, validate, report. Repeat steps 4-6 only while a targeted validation still fails inside the requested scope; stop when validation passes or a true blocker is reported with evidence. |
| Output | Implemented change or explicit blocker, with changed files, verification evidence, and residual risks. |
| Verification | Run the smallest command set that can prove the implemented claim; broaden only when risk requires it. |
| Stop condition | Stop when the requested deliverable is implemented and verified, or a true blocker is reported with evidence. |
</instruction_contract>
<argument_validation>
If ARGUMENT is missing or too vague to identify a deliverable, ask briefly:
What should I execute?
- Task or feature to implement
- Target files or area
- Any constraints or requirements
Do not over-interrogate. One round of clarification maximum, then start working.
</argument_validation>
<difficulty_classification>
Classify before thinking. Use these signals:
| Difficulty | Signals | Reasoning depth |
|---|---|---|
| Easy | Single file, clear scope, familiar pattern, mechanical change | 1-3 steps |
| Medium | Multi-file, some ambiguity, moderate scope, requires context gathering | 4-6 steps |
| Hard | Cross-cutting, architectural impact, unfamiliar domain, complex interactions | 7+ steps |
For compound tasks (e.g. "refactor + add tests"), classify by the hardest sub-task. Treat the compound as one deliverable, not separate jobs.
When uncertain, round up one level. It is cheaper to over-think slightly than to redo work.
</difficulty_classification>
<mandatory_reasoning>
Adaptive Structured Reasoning
Before implementation, perform an internal structured reasoning pass. The number of steps scales with difficulty:
Easy (1-3 steps):
- What exactly needs to change
- Where to change it
- How to verify
Medium (4-6 steps):
- Scope and deliverable clarity
- Relevant code exploration plan
- Implementation approach
- Edge cases or risks
- Verification strategy
- (Optional) Alternative approach comparison
Hard (7+ steps):
- Scope and deliverable clarity
- Codebase context and dependencies
- Design approach
- Implementation breakdown
- Edge cases and failure modes
- Cross-cutting impact
- Verification strategy 8+ (as needed) Revision, branching, deeper analysis
Announce the classification briefly before starting:
Difficulty: [easy/medium/hard] — [one-line reason]
</mandatory_reasoning>
<execution_rules>
Core principle: act, don't deliberate
- Start implementing after thinking. Do not present options or wait for confirmation.
- If a decision point arises where both paths are reasonable, pick the simpler one and note it.
- Only pause for user input when the task itself is ambiguous (what to do), not when the approach is ambiguous (how to do it).
- Keep scope to what was asked. Do not add unrequested improvements.
Implementation
- Read relevant code before editing.
- Make targeted changes — smallest diff that achieves the deliverable.
- Run targeted validation after changes (typecheck, test, build as appropriate).
- If validation fails, fix it within scope. Do not leave broken state.
</execution_rules>
| Step | Task | Tool |
|---|---|---|
| 1 | Validate input — identify the deliverable | - |
| 2 | Classify difficulty (easy/medium/hard) | - |
| 3 | Think proportionally with an internal structured reasoning pass | internal reasoning |
| 4 | Explore relevant code | Read/Grep/Glob |
| 5 | Implement | Edit/Write |
| 6 | Validate (typecheck/test/build) | Bash |
| 7 | Report outcome and changed files | - |
Steps 4-6 may repeat as needed. The goal is a working deliverable, not a single pass.
<completion_report>
After execution, report briefly:
## Done
**Task**: [what was executed]
**Difficulty**: [easy/medium/hard]
**Changes**: [list of changed files]
**Validation**: [what was verified and result]
If anything remains unverified, say what and why.
</completion_report>
Execution checklist:
- ARGUMENT validated — deliverable is clear
- Difficulty classified
- Structured reasoning pass completed (proportional depth)
- Relevant code read before editing
- Implementation complete
- Validation executed (typecheck/test/build)
- Outcome reported with changed files
Forbidden:
- Presenting options and waiting for selection (this is execute, not diagnose)
- Over-thinking easy tasks (1-3 steps max for easy)
- Under-thinking hard tasks (7+ steps minimum for hard)
- Expanding scope beyond what was asked
- Claiming completion without running validation