About this skill

Problem It Addresses

Multi-step engineering work can lose its boundary mid-flight: a dependency is missed, a plan is incomplete, or “looks like it works” is mistaken for proof. auto-invoke is for manual /auto execution. It breaks work into small, checkable steps, each with an explicit file, tool, expected output, and verification command.

How It Works and Where It Applies

It is not an automatic trigger. The core loop is: initialize the skill index → generate a plan → batch-approve via ExitPlanMode → execute in batches → verify with command output. Modes are intent-driven: PLAN produces a plan only, BUILD executes an existing plan, FULL plans and executes by default, and AUTO minimizes interruption.
Key steps include:
- On first run, scan and read every full SKILL.md body, then build skill-index.json.
- Match tasks using ops, domain, and prereqs filters, score candidates, and fall back to direct tools when needed.
- Execute in batches of three, report after each batch, and revise later tasks when earlier results change inputs.
- During verification, run the command, read the full output and exit code, then claim completion.
Use it for tasks with two or more steps, multi-file changes, or cross-domain work. Skip it for one-line fixes, pure Q&A, or read-only inspection. Stop and ask for clarification when blocked, after three failed verification attempts, or when an instruction is unclear.

Screenshots

Use Cases

When a refactor touches multiple files, use /auto to split the work, approve the plan, and run tests after each batch.
When executing an existing dev plan, load it from docs/plans, run tasks in threes, and pause for feedback between batches.
When changing front-end and back-end code together, match tasks to skills and fall back to direct tools for simple reads.
When claiming a fix is done, require the full test command, read the exit code and output before marking completion.

Best For

Engineers maintaining multi-repo code: they want cross-file changes split into reviewable, verifiable batches.
Delivery owners: they need existing plans executed with batch status and risk feedback.
Engineers debugging complex builds: they want real commands run and output read before completion claims.
Automation maintainers: they want /auto to maintain the skill index before matching tasks to tools.