Zero to shipped.

The on-ramp. Follow it once, end to end, and you will have driven the full cycle — from a blank operation to a closed one with a reviewed after-action. Two surfaces are in play: the web app, where you capture intel and review what your agent did, and your coding agent — today Claude Code; Codex on the way. The naholo CLI sits underneath them; you install it once and your agent drives it from there.

Prerequisites

One-time gear (detail in Readiness):

• Node.js LTS for the naholo CLI.
• Claude Code as your coding agent.
• VS Code + the Claude Code extension — strongly recommended; the cycle's review windows hinge on hand-editing OPERATION.md.

1. Open a new operation

Sign in to naholo, create a project, and open a new operation. Give it a title that names the problem, not the solution. Drop logs as you think — every requirement, link, or constraint goes in as a log. The agent reads every log when you infil, so don't squeeze the idea; let it land in pieces.

When you're done dropping for the moment, hit the Copy /infil button on the operation page. It puts the /infil <n> slash command on your clipboard, ready to paste into your agent.

Alternative on-ramp: /recon → /fob

Once the CLI is installed (Section 2), you can skip creating the op in the web app — you still need to sign in and create a project there — and drop the idea straight into your agent. /recon lets the agent explore the codebase from a vague prompt and talk the shape out with you; when the direction lands, ask it to fire /fob and it spins up the operation server-side and chains /infil in one gesture.

User: /recon We're keeping tfstate locally. We'd like to share tfstate
      more easily but securely so we can modify cloud assets from other
      devices.

Agent: You can use a versioned S3 bucket as the tfstate backend — locked
       down with bucket policies and a DynamoDB lock table for safety.

User: Sounds good. Run /fob for me.

Agent: [runs /fob, creates the OP server-side, chains /infil]

Same destination as the web-app path — CLI-first instead of browser-first. Reach for it when you'd rather think out loud against the codebase before committing to a title.

2. Install the CLI

npm install -g @naholo/cli
naholo login
naholo init

naholo init writes .naholo/config.yml (commit it) and .mcp.json (gitignored), then drops /infil, /warno, /opord, /splash, /exfil into .claude/skills/ for your Claude Code session. Don't want naholo's footprint in the repo? Swap naholo init for naholo covert init — same outcome, project wiring lives under ~/.naholo/ instead.

Covert vs team setup, worktree caveats, and re-installing skills after a CLI upgrade live in Readiness.

3. Run the operation

Open Claude Code in your repo and run the chain. Each skill mutates exactly one document on disk and stops, so you review before the next step. The happy path is the chain run straight through:

/infil → /warno → /opord → /splash → /splash … → /exfil

Every step lands a review window. If you like what you see, run the next skill. If you don't — the WARNO needs revising, a TASK needs rewriting, a shipped After-Action Report (AAR) needs a follow-up — re-run the same skill with feedback (/warno "use the existing queue", /opord "split TASK 3"). Quick Start walks the happy path; Workflow covers every branch.

/infil <n>

/infil 42

Pulls operation <n> from the server into a local working directory and seeds OPERATION.md with the SITUATION — the pain, the suggested solution, the notes that fell out of your logs. Open OPERATION.md and review SITUATION; add anything that surfaces while you read, either by hand-editing or telling the agent in chat.

Branches and side flows: Workflow → /infil.

/warno

/warno

Writes the WARNING ORDER: the Concept of Operations (the approach), the Constraints (one architectural decision per bullet), and the Target Reference Points (a map of the files the next skill will need). This is your direction review. Read the WARNO and ask: can I picture, at the architecture level, how this gets tackled? Not the implementation — the shape. Which layer it lives in, which patterns it leans on, what gets traded off.

Branches and side flows: Workflow → /warno.

/opord + /splash — the per-task cycle

/opord

/opord cuts the WARNO into tasks. It writes ## OPERATION ORDER to OPERATION.md (one task per section) and mirrors the list into TASKS.md. Each task carries an Intent (the success criterion) and a Scheme of Maneuver — an action list of atomic steps, optionally preceded by an ASCII artifact that names the shape of the change. Tasks get reviewed one at a time, right before they ship — not as a whole list.

Branches and side flows: Workflow → /opord.

Then the per-task loop:

1. Review the next TASK. Read Intent and Scheme of Maneuver. If it's not one cohesive change you'd happily review as one diff, ask the agent to fix it: "split this task", "use the existing util", "add a backfill step".
2. Ship it. /splash
3. Review the AAR and the diff. Happy with both — loop to step 1 for the next TASK. Off-target on something small — chat the fix and let the agent rewrite the code and the AAR. Off-target on something bigger — re-run /opord to insert a new TASK and ship it in its own splash.

Loop until every box in TASKS.md is [x].

Branches and side flows: Workflow → /splash.

/exfil

/exfil

Pushes everything back to the server, posts a summary log, optionally closes the operation, and deletes the local working directory.

Branches and side flows: Workflow → /exfil.

4. Review the after-action

Return to the web app and open the closed operation. You get:

• The timeline — every step the cycle went through.
• The logs — your original intel, plus the summary log /exfil just posted.
• The agent stats — token usage by skill, model, session count. So you can see what the operation actually cost.