Execute

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

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.
• Code review or quality audit. Route to a dedicated review or QA skill when available; in this repo prefer

  qa

  for systematic QA work.
• 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.

What should I execute?
- Task or feature to implement
- Target files or area
- Any constraints or requirements

Adaptive Sequential Thinking

sequential-thinking

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

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

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

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.

## Done

**Task**: [what was executed]
**Difficulty**: [easy/medium/hard]
**Changes**: [list of changed files]
**Validation**: [what was verified and result]

• ARGUMENT validated — deliverable is clear
• Difficulty classified
• sequential-thinking completed (proportional depth)
• Relevant code read before editing
• Implementation complete
• Validation executed (typecheck/test/build)
• Outcome reported with changed files

• Presenting options and waiting for selection (this is execute, not diagnose)
• Over-thinking easy tasks (1-3 thoughts max for easy)
• Under-thinking hard tasks (7+ thoughts minimum for hard)
• Expanding scope beyond what was asked
• Claiming completion without running validation