Execute

Execute

Receive a task, classify its difficulty, think proportionally, and start working immediately.

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.

• 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.

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

• Bug reports with error messages or failing symptoms. Route to bug-fix.
• Repository-wide build, CI, or deployment failures. Route to deploy-fix.
• Pre-release validation or build readiness checks. Route to pre-deploy.
• Strategic planning or architecture decisions. Route to a dedicated planning or architecture skill when available; in this repo prefer prd-maker for requirements and framework-specific architecture skills for implementation architecture.
• Client or customer feedback that needs repository-grounded interpretation before implementation. Route to client-feedback.
• Security analysis. Route to a dedicated security skill when available; in this repo use framework-specific security skills such as tanstack-start-security when applicable.
• Explicit workflow invocations such as $autoresearch-skill, $ralph, or another $skill request. 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.

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.

Classify before thinking. Use these signals:

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.

Adaptive Structured Reasoning

Before implementation, perform an internal structured reasoning pass. The number of steps scales with difficulty:

Easy (1-3 steps):

1. What exactly needs to change
2. Where to change it
3. How to verify

Medium (4-6 steps):

1. Scope and deliverable clarity
2. Relevant code exploration plan
3. Implementation approach
4. Edge cases or risks
5. Verification strategy
6. (Optional) Alternative approach comparison

Hard (7+ steps):

1. Scope and deliverable clarity
2. Codebase context and dependencies
3. Design approach
4. Implementation breakdown
5. Edge cases and failure modes
6. Cross-cutting impact
7. Verification strategy 8+ (as needed) Revision, branching, deeper analysis

Announce the classification briefly before starting:

Difficulty: [easy/medium/hard] — [one-line reason]

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.

Steps 4-6 may repeat as needed. The goal is a working deliverable, not a single pass.

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.

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