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 existing roadmap if present and steps/step-03-plan.md. Preserve its schema and finished phases. Research only unresolved external questions through websearch when available. Render scripts/render.py only for --html or an explicit request. Mark ready when approved; a roadmap request alone does not authorize implementation.

-a permits explicit assumptions, not new permissions; --no-agents stays solo. Any delegation requires consent, references/agent-contracts.md and the matching adapter; at most three independent read-only units, no nested delegation. Explicit --install-omp-agents, --install-codex-agents and matching --uninstall-* actions use scripts/install_agents.py with backups, then stop. Never install agents as a side effect of routing.