# Execute

> [Hyper] Immediately start working on a given task with adaptive thinking depth — light thinking for easy tasks, deep thinking for hard ones. Use when the user wants immediate execution, not diagnosis, planning, or review.

- Skill: `alpoxdev/execute` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add alpoxdev/execute`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alpoxdev/execute/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: alpoxdev (https://skillmd.com/u/alpoxdev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alpoxdev/execute

---


# Execute

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

<purpose>

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

</purpose>

<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

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

</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. |
| 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:

```text
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)**:
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]
```

</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>

<workflow>

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

</workflow>

<completion_report>

After execution, report briefly:

```markdown
## 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>

<validation>

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

</validation>