@dotobokuri/fleet-cli 1.3.1 → 1.4.0

package/assets/skills/fleet-protocol-high-risk/SKILL.md

@@ -7,19 +7,16 @@ description: Use the risk-controlled Fleet protocol mode for irreversible, struc
 
 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.
 
-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`
 
 ## 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.

package/assets/skills/fleet-protocol-multi-agent/SKILL.md

@@ -7,26 +7,25 @@ description: Use the coordinated Fleet protocol mode for multi-carrier or parall
 
 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.
 
-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/fleet-protocol-standard/SKILL.md

@@ -5,36 +5,34 @@ description: Use the normal Fleet protocol mode for bounded operational work wit
 
 # Fleet Protocol: Standard
 
-Use this mode for ordinary bounded operational work that does not involve irreversible operations, structural/API changes, multi-module edits, doctrine or prompt-policy edits, or required multi-carrier coordination. If any downward-guard trigger appears, self-escalate before planning.
+Use this mode for ordinary bounded operational work.
 
-The always-on Standing Orders remain binding: Mission Anchor, Context Confidence, Carrier Operations Policy, Deep Dive, and Result Integrity.
+At any point during the work, if a Downward Guard trigger appears, stop and re-classify.
 
-## Reporting Cadence
+## Checkpoints
+
+Reconnaissance, 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) the target surfaces, and (c) the verification command. → 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) 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** — name the minimal modules or files reconnaissance will touch. → report `surfaces: <…>`
-- [ ] **Verification** — pre-load the test, build, or check command that will prove the work done. → report `verify: <cmd>`
+- [ ] **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|…>`
-- [ ] **Downward-guard** — affirm bounded single-owner scope; if a full boundary map, risk review, or parallel ownership emerges, re-classify under high-risk or multi-agent. → report `downward-guard: clear`
 
 ## 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 complete`. Resolve all blocking and confirmatory gaps before planning.
+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.

package/assets/skills/fleet-protocol-trivial/SKILL.md

@@ -5,35 +5,33 @@ description: Use the compact Fleet protocol mode for simple, reversible, single-
 
 # Fleet Protocol: Trivial
 
-Use this mode only for simple, reversible, single-surface operational work. If irreversible operations, structural/API changes, multi-module edits, doctrine or prompt-policy edits, or multi-carrier coordination appear, self-escalate to `fleet-protocol-high-risk` or `fleet-protocol-multi-agent` before planning.
+Use this mode only for simple, reversible, single-surface operational work.
 
-The always-on Standing Orders remain binding: Mission Anchor, Context Confidence, Carrier Operations Policy, Deep Dive, and Result Integrity.
+At any point during the work, if a Downward Guard trigger appears, stop and re-classify.
 
-## Reporting Cadence
+## Checkpoints
+
+None. Selecting trivial implies Mission Anchor Compact Mode.
 
-As you move through this protocol, report progress to the Admiral of the Navy in order, each step with its report token. For trivial work you may compress this into one or two lines, but all five steps must still appear — do not drop a step even when compressing.
+## 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 in one line how the Workflow will proceed. → 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.
 
-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 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 and the change is trivially reversible. → report `surface: <x> | reversible: yes`
-- [ ] **Downward-guard** — no structural, API, doctrine, multi-module, or multi-carrier signal is present; if one appears, re-classify under a higher mode before anchoring. → report `downward-guard: clear`
+- [ ] **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 anchor: state the Mission Anchor objective once.
-2. Minimal knowledge audit: verify the exact file, command, or fact needed for the request.
-3. Planning micro-check: when a planning decision exists, state `Apply the Context Confidence Standing Order — entry requires complete` before choosing the direct action.
-4. Direct execution: make the smallest reversible change or run the exact requested command.
-5. Exact verification: check the touched surface or command result.
-6. Compact final: report what changed, verification, and any skipped escalation trigger.
+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.