/arsenal

name: arsenal
description: Use when the user invokes Arsenal, needs help choosing an approach, or wants an end-to-end task handled with the installed Arsenal skills.

Arsenal

One entry point, the shortest sufficient workflow. Read and apply selected skills; do not reproduce their procedures here. Work solo by default.

Start

Load steps/step-00-init.md. Keep the objective, scope, constraints, decisions, artifact paths, permissions and remaining questions in conversation. Reuse existing artifacts; no mandatory orchestration file or roadmap.

With no description, ask what outcome the user wants and whether they want advice, a document, or implementation. Use the runtime's native question form when available and permitted in the active mode; otherwise ask in plain text. Wait for the answer: a preselected option is not submitted consent.

With a description, inspect supplied context and relevant project instructions first. Ask only missing questions that could change the route, scope or safety. Use small adaptive batches, not a fixed questionnaire or complexity score. Existing answers and accepted artifacts are not another interview.

Choose the next useful step

Use the live installed skill inventory, including actual names and paths. These routes express intent, not a required sequence or proof of installation:

| Evidence or requested outcome | Next step | |---|---| | Product outcome, audience or scope needs a durable specification | brief | | Consequential technical choice remains unresolved | propose | | Clear implementation request or approved implementation artifact | ship | | External facts are needed to answer the current question | websearch | | Save, update, read or resume a specific GitHub issue | issue | | Start a session, resume what was left, discover unfinished work | next | | End a session and keep the thread for the next one | trace | | Analyze code in depth, find what is wrong or illogical | review | | Read project activity or explicitly record progress | trace | | Explicit phased roadmap or genuine multi-workstream sequencing | Roadmap below |

For another installed Arsenal skill, match its declared purpose to the missing result. Do not route back to Arsenal. A bug does not imply a GitHub issue; a large change does not imply a brief. A short clarification can resolve uncertainty without creating a document. For advice-only requests, recommend the shortest path and stop before execution.

Before routing to ship in a Git repository, check whether another spec is already running there: a checkout under `.worktrees/`, or an unfinished `trace.md` beside a different spec. If there is one, say so in one line and ask whether to run this spec with `-w`, in its own worktree and its own session. Follow the answer; never pick `-w` on your own, and never propose it when nothing else is running.

Apply, then reassess

1. Name the selected skill and the concrete reason in one short update. 2. Resolve it from the live inventory and read its complete SKILL.md before acting. Load only the linked references/scripts required by that skill. Resolve relative resources from that skill's directory, never Arsenal's. Plugins may be installed separately; do not guess sibling cache paths. 3. Pass the current objective, constraints, decisions, artifacts, authorizations and unknowns into the step. Follow its actual instructions, not its summary. 4. When it returns a result, update that context and reassess what remains. Continue only inside the user's original authorized outcome. Child skills do not launch one another; Arsenal owns the transition. When a skill ends by suggesting the next one (issue: a brief; an unclear brief: a proposal; review: the skill per point; next: the picked item), offer that step in one line and run it only on the user's yes, one link at a time. The one inline exception is the shared "Verify external facts" lookup: any skill may read the `websearch` skill and run one search without handing control over.

Missing or unreadable skill: state the gap. Do not claim to have used it or silently install it. Offer installation or a clearly labeled native fallback; stop if the missing capability is essential. No whole-config scan by default.

Standalone stop rules end that skill's step, not an already authorized broader Arsenal task. They never waive approval gates: a proposal remains Draft/Review until explicitly accepted; ship requires a ready brief or Accepted proposal when consuming one. Analysis is not permission to implement. Issue creation, closure, commits, pushes, installs and delegation retain their approval rules. If a selected skill explicitly forbids the required transition, stop and ask.

Stop when the outcome is delivered, approval is needed, the user stops, or a step cannot progress. No repeated unchanged route, redoing completed work, automatic reviewers, model retuning or ceremonial launch confirmations.

Verify external facts

Before stating an external fact (a version, an API, a price, a date, a regulation, the behaviour of a tool or library, a person or company), search first when the runtime offers web search: read the `websearch` skill and run one quick search, then cite the source. One search per fact; `--deep` only on request. Without web search, mark the claim unverified. Facts visible in the repository or the request need no search.

Optional efficiency plugins

With Espresso or another efficiency plugin, Arsenal still owns routing and the selected skill retains its approval gates, specialized agents, model assignments, schemas, artifacts and verification. An automatic delegation setting does not waive these rules or authorize a competing team/reviewer. Use the stricter applicable scope and concurrency limit. No plugin is required; without one, the workflow is unchanged. Never install one as a routing side effect.

Optional roadmap and configuration

For a requested roadmap or `-r <slug>`, read the