@dotobokuri/fleet-cli 1.3.1 → 1.5.0

package/README.md

@@ -27,7 +27,7 @@ After installation, run `fleet` from any directory.
 ## Session Plugins
 
 Dedicated Claude and Codex sessions receive Fleet context through generated plugin assets rendered under `~/.fleet/marketplace/plugins/fleet`.
-The Fleet system prompt is injected at CLI launch time via temporary prompt files for Claude and a dedicated Codex profile, while provider-shared skill files and Claude subagent definitions are generated inside the plugin bundle from packaged assets. Built-in skills include Fleet Wiki usage plus the four protocol-mode skills used by the Admiral protocol gate: `fleet-protocol-trivial`, `fleet-protocol-standard`, `fleet-protocol-high-risk`, and `fleet-protocol-multi-agent`.
+The Fleet system prompt is injected at CLI launch time via temporary prompt files for Claude and a dedicated Codex profile, while provider-shared skill files and Claude subagent definitions are generated inside the plugin bundle from packaged assets. Built-in skills include Fleet Wiki usage plus the four protocol-mode skills used by the Admiral protocol gate: `protocol-baseline`, `protocol-midline`, `protocol-redline`, and `protocol-frontline`.
 The carrier and wiki MCP servers are not rendered into the plugin bundle; they are injected at spawn time as launch arguments (`--mcp-config` for Claude and `-c mcp_servers.*` for Codex).
 
 Claude launches with `--plugin-dir ~/.fleet/marketplace/plugins/fleet` and discovers enabled carrier agents from plugin `agents/*.md`.

package/assets/skills/{fleet-assumption-audit → assumption-audit}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: fleet-assumption-audit
+name: assumption-audit
 description: Resolve decision-shaped Context Confidence gate failures one blocking gap at a time before the active protocol re-applies its planning boundary.
 ---
 

package/assets/skills/protocol-baseline/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: protocol-baseline
+description: Use the compact Fleet protocol mode for simple, reversible, single-surface work.
+---
+
+# Fleet Protocol: Baseline
+
+Use this mode only for simple, reversible, single-surface operational work.
+
+At any point during the work, if a Downward Guard trigger appears, stop and re-classify.
+
+## Checkpoints
+
+None. Selecting baseline implies Mission Anchor Compact Mode.
+
+## Reporting Cadence
+
+As you move through this protocol, report progress to the Admiral of the Navy in order.
+
+1. Brief in one line how the Workflow will proceed. → report `brief: <…>`
+2. State that execution is beginning and run the Workflow. → report `status: executing`
+
+## General Quarters
+
+Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to the Objective anchor. These checks prepare the work; they do not gate entry.
+
+- [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
+- [ ] **Single surface** — the exact file, command, or fact is identified. → report `surface: <x>`
+- [ ] **Reversibility** — the change is trivially reversible. → report `reversible: yes`
+
+## Workflow
+
+1. Objective statement: state the Mission Anchor objective in one line.
+2. Exact fact/file verification: verify the exact file, command, or fact needed for the request.
+3. Execution: make the smallest reversible change or run the exact requested command.
+4. Result verification: check the touched surface or command result.
+5. One-line report: report what changed, verification, and any skipped escalation trigger.

package/assets/skills/{fleet-protocol-multi-agent → protocol-frontline}/SKILL.md

@@ -1,32 +1,31 @@
 ---
-name: fleet-protocol-multi-agent
+name: protocol-frontline
 description: Use the coordinated Fleet protocol mode for multi-carrier or parallel ownership work.
 ---
 
-# Fleet Protocol: Multi-Agent
+# Fleet Protocol: Frontline
 
-Use this mode when operational work requires multiple Carriers, independent parallel workstreams, cross-carrier review loops, or file ownership coordination. If the work is high risk but single-owner, use `fleet-protocol-high-risk` instead.
+Use this mode when operational work requires multiple Carriers, independent parallel workstreams, cross-carrier review loops, or file ownership coordination. If the work is high risk but single-owner, use `protocol-redline` instead.
 
-The always-on Standing Orders remain binding: Mission Anchor, Context Confidence, Carrier Operations Policy, Deep Dive, and Result Integrity.
+## Checkpoints
 
-## Reporting Cadence
+Decomposition, Dispatch, Integration, Verification.
 
-As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token. Do not merge steps together or fold them into the General Quarters checks below.
+## Reporting Cadence
 
-1. State that you are drawing up the plan for this work. → report `plan: drafting`
-2. State that you are running the readiness checks below. → report `checks: running`
-3. Confirm the readiness checks are complete. → report `checks: complete`
-4. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) each carrier's file or responsibility ownership, and (c) the dispatch wave sequencing. → report `brief: <…>`
-5. Confirm all five steps were reported, then state that execution is beginning and run the Workflow. → report `executing`
+As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token.
 
-Steps 2–3 wrap the General Quarters section: step 2 opens the readiness checks, they run in full, and step 3 closes them once every check has reported its token.
+1. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) each carrier's file or responsibility ownership, and (c) the dispatch wave sequencing. → report `brief: <…>`
+2. State that execution is beginning and run the Workflow. → report `status: executing`
 
 ## General Quarters
 
 Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to reconnaissance and decomposition. These checks prepare the work; they do not gate entry.
 
 - [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
-- [ ] **Impact & isolation** — carry the high-risk checks (public-surface impact, rollback checkpoint, branch or worktree isolation) wherever the work is also high risk. → report `impact/isolation: <…>`
+- [ ] **Impact radius** — flag public-surface or API impact, irreversibility, and any security-sensitive surface. → report `impact: <…>`
+- [ ] **Rollback** — identify a rollback-safe checkpoint and any Admiral of the Navy approval point before execution begins. → report `rollback: <…>`
+- [ ] **Isolation** — confirm a working branch or worktree isolates the change; no direct work on the default branch. → report `isolation: <branch>`
 - [ ] **Carrier availability** — confirm the intended carriers are actually exposed and available this session. → report `carriers: <…>`
 - [ ] **Ownership** — pre-sketch each carrier's file or responsibility boundary. → report `ownership: <…>`
 - [ ] **Shared resources** — flag shared mutable resources (same files, lock files, or a singleton test environment). → report `shared: <…|none>`

package/assets/skills/protocol-midline/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: protocol-midline
+description: Use the normal Fleet protocol mode for bounded operational work without downward-guard triggers.
+---
+
+# Fleet Protocol: Midline
+
+Use this mode for ordinary bounded operational work.
+
+At any point during the work, if a Downward Guard trigger appears, stop and re-classify.
+
+## Checkpoints
+
+Reconnaissance, Plan, Execution, Verification.
+
+## Reporting Cadence
+
+As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token.
+
+1. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) the target surfaces, and (c) the verification command. → report `brief: <…>`
+2. State that execution is beginning and run the Workflow. → report `status: executing`
+
+## General Quarters
+
+Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to focused reconnaissance. These checks prepare the work; they do not gate entry.
+
+- [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
+- [ ] **Target surfaces** — provisionally name the minimal modules or files reconnaissance will touch; confirm or revise in the brief after reconnaissance. → report `surfaces: <…>`
+- [ ] **Verification** — provisionally pre-load the test, build, or check command that will prove the work done; confirm or revise in the brief after reconnaissance. → report `verify: <cmd>`
+- [ ] **Carrier** — declare whether a carrier sortie is needed. → report `carrier: <none|…>`
+
+## Workflow
+
+1. Focused reconnaissance: audit known facts, identify blocking and confirmatory gaps, and inspect the minimal relevant surfaces.
+2. Planning boundary: `Apply the Context Confidence Standing Order — entry requires sufficient`. Resolve all blocking gaps before planning.
+3. Inline plan: state objective, targets, execution steps, and done criteria.
+4. Execution: implement the plan in narrow batches, using Carrier Operations Policy when delegation is appropriate.
+5. Verification and review: run targeted checks, apply Deep Dive to speculative results, and fix actionable issues.
+6. Documentation and final report: update directly affected docs only when behavior or operator guidance changed, then summarize changes and QA.

package/assets/skills/{fleet-protocol-high-risk → protocol-redline}/SKILL.md

@@ -1,25 +1,22 @@
 ---
-name: fleet-protocol-high-risk
+name: protocol-redline
 description: Use the risk-controlled Fleet protocol mode for irreversible, structural, multi-module, or prompt-policy work.
 ---
 
-# Fleet Protocol: High Risk
+# Fleet Protocol: Redline
 
-Use this mode for irreversible operations, structural/API changes, cross-module edits, doctrine or prompt-policy edits, security-sensitive work, or any operational request needing explicit risk controls. Escalate to `fleet-protocol-multi-agent` when multiple Carriers or parallel ownership boundaries are required.
+Use this mode for irreversible operations, structural/API changes, cross-module edits, doctrine or prompt-policy edits, security-sensitive work, or any operational request needing explicit risk controls. Escalate to `protocol-frontline` when multiple Carriers or parallel ownership boundaries are required.
 
-The always-on Standing Orders remain binding: Mission Anchor, Context Confidence, Carrier Operations Policy, Deep Dive, and Result Integrity.
+## Checkpoints
 
-## Reporting Cadence
+Reconnaissance, Risk review, Plan, Execution, Verification.
 
-As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token. Do not merge steps together or fold them into the General Quarters checks below.
+## Reporting Cadence
 
-1. State that you are drawing up the plan for this work. → report `plan: drafting`
-2. State that you are running the readiness checks below. → report `checks: running`
-3. Confirm the readiness checks are complete. → report `checks: complete`
-4. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) file ownership and the rollback-safe checkpoint, and (c) the risk controls in force. → report `brief: <…>`
-5. Confirm all five steps were reported, then state that execution is beginning and run the Workflow. → report `executing`
+As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token.
 
-Steps 2–3 wrap the General Quarters section: step 2 opens the readiness checks, they run in full, and step 3 closes them once every check has reported its token.
+1. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) file ownership and the rollback-safe checkpoint, and (c) the risk controls in force. → report `brief: <…>`
+2. State that execution is beginning and run the Workflow. → report `status: executing`
 
 ## General Quarters
 
@@ -28,17 +25,17 @@ Confirm each readiness check below before the Workflow. Work through them in ord
 - [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
 - [ ] **Doctrine** — enumerate the applicable AGENTS.md files to load for the affected scope. → report `doctrine: <…>`
 - [ ] **Impact radius** — flag public-surface or API impact, irreversibility, and any security-sensitive surface. → report `impact: <…>`
-- [ ] **Rollback** — identify a rollback-safe checkpoint and any Admiral approval point before execution begins. → report `rollback: <…>`
+- [ ] **Rollback** — identify a rollback-safe checkpoint and any Admiral of the Navy approval point before execution begins. → report `rollback: <…>`
 - [ ] **Isolation** — confirm a working branch or worktree isolates the change; no direct work on the default branch. → report `isolation: <branch>`
-- [ ] **Escalation** — if multiple carriers or parallel ownership boundaries are required, re-classify under multi-agent. → report `escalation: clear`
+- [ ] **Escalation** — if multiple carriers or parallel ownership boundaries are required, re-classify under frontline. → report `escalation: clear`
 
 ## Workflow
 
 1. Full reconnaissance: audit known facts, enumerate blocking and confirmatory gaps, read applicable AGENTS.md files, map affected code, tests, docs, and boundaries.
-2. Architecture and risk review: identify public-surface impact, dependency constraints, rollback risk, security risk, and approval needs.
+2. Architecture and risk review: identify public-surface impact, dependency constraints, rollback risk, security risk, and Admiral of the Navy approval requirements.
 3. Structured planning boundary: `Apply the Context Confidence Standing Order — entry requires complete`. Do not plan with unresolved blocking or confirmatory gaps.
 4. Risk-controlled plan: define file ownership, small execution batches, verification commands, rollback-safe checkpoints, and any approval point.
 5. Small-batch execution: edit narrowly, re-read before modifying shared files, and pause on unexpected diffs or scope expansion.
-6. Refactor gate: refactor only touched code when duplication, complexity, or convention drift appears.
-7. Parallel correctness and security review: review changed behavior and risk controls; apply Deep Dive to speculative findings and repeat after fixes.
+6. Refactor gate: refactor only touched code when duplication, complexity, or convention drift appears, only with Admiral of the Navy approval or when pre-declared in the brief.
+7. Correctness and security review (may run as a single combined review dispatch): review changed behavior and risk controls; apply Deep Dive to speculative findings and repeat after fixes.
 8. Documentation and completion report: update directly affected operator docs and report changes, QA, risk controls, and residual uncertainty.