Cm Fleet Review

CM Fleet Review

Orchestrates a multi-perspective parallel code review using diverse AI models, each with a specific role and mandatory checklist. This is THE core quality gate for the Config Manager project.

Fleet Sizes

The global instruction says "at minimum 4–5 parallel review agents." Running 11 agents on every small fix is expensive and slow. Default to minimum fleet unless the change is significant. Ask the user if unsure.

Every agent reviews the full changed files (not just diffs) to catch inconsistencies, stale comments, and cross-file issues. Model diversity across 4 Claude + 6 GPT + 1 Gemini variants maximizes perspective coverage.

Agent Roster

Group A — General Perspectives

Group B — Specialized Checklists

Group C — Platform Reviewer Simulation

Mandatory Checklists

These checklists are mandatory — each agent MUST work through every checkbox in its assigned checklist. Do not skip items.

Agent 2 — Correctness/Edge Cases

□ Boundary values: min, max, min-1, max+1 for every numeric input
□ Alias/normalization values: inputs that map to other values — tested before AND after normalization
□ Normalization ordering: does validation happen before or after input transformation
□ Boundary combinations: boundary/alias values combined with other parameters
□ Off-by-one in loops: <= vs <, starting index, step arithmetic, fence-post errors
□ Empty/zero/nil: every code path handles these explicitly
□ Error paths: every error return tested, unreachable error branches
□ Integer overflow/underflow: can arithmetic on user inputs wrap
□ State mutation ordering: does the order of field updates matter

Agent 6 — Deep Security

□ Every URL/path reaching a template or browser: can browser normalize /../ to hit unintended routes
□ Every API field displayed in UI: sanitized before rendering (trace data flow)
□ Every user-controlled path segment: validated against traversal
□ POST endpoint paths: validated before embedding in template URLs
□ Double-encoding: can %252e%252e bypass single-decode checks
□ Control characters in API responses: stripped before display
□ Error messages: do they leak internal paths, stack traces, secrets
□ HTTP headers: user-controlled values reflected without sanitization

Agent 7 — Unicode/Encoding

□ Every rune/character filter: handles Unicode C1 control chars (U+0080–U+009F)
□ Every string truncation: rune-aware (not byte-aware)
□ Every titleCase/uppercase: uses unicode.ToUpper + utf8.DecodeRuneInString
□ Multi-byte characters at truncation boundaries: no partial runes
□ String vs []byte conversions: any unnecessary allocations
□ URL encoding/decoding: handles non-ASCII paths correctly
□ JSON marshaling: preserves Unicode characters

Agent 8 — Test Quality

□ Error path tests: use closed httptest.Server (not hardcoded ports)
□ Flaky patterns: timing-dependent assertions, race conditions in parallel tests
□ Test isolation: each test creates own server/client
□ Assertion strength: error messages checked (not just err != nil)
□ Edge case coverage: empty input, nil, max-length, Unicode, concurrent access
□ Mock fidelity: mocks match real API behavior
□ Cleanup: httptest servers closed in defer
□ Table-driven tests: could similar test cases be consolidated

Agent 9 — Lint/Consistency

□ errcheck: every error return checked or nolint with justification
□ Param naming: matches usage
□ DRY: logic duplicated across 2+ functions
□ Import consistency: same packages imported same way
□ File ordering: generic/shared FIRST, then specific
□ Exported vs unexported: correct visibility
□ nolint directives: each has justification
□ Comment accuracy: describes what code actually does
□ Consistent error wrapping: fmt.Errorf with %w

Agent 10 — Template/Contract

□ Every URL in templates: correct prefix, no double slashes
□ Type safety: specific types not any/interface{}
□ Error propagation: errors from API surfaced to user
□ Display consistency: same data formatted same way
□ API field naming: matches backend json tags
□ Content-Type handling: JSON parsed as JSON
□ HTTP method correctness: GET for reads, POST for mutations
□ Status code handling: non-2xx produces user-visible errors
□ PR description: matches actual implementation

Agent 11 — GitHub Copilot Perspective

□ Fix propagation: for every pattern changed in the diff, check if the OLD
  pattern exists UNFIXED in any other file. Copilot reviews full files and
  cross-references what was fixed against what remains — this is its #1 source
  of comments.
□ Regex consistency: same input type must use same regex across all scripts
  (e.g., repo names validated identically in load-project.sh, init-project.sh,
  repo-status.sh)
□ Path traversal: every input used as a path segment rejects literal "." and
  ".." (dot-prefixed names like `.github` are valid)
□ Error output: every error-path echo uses "Error:" prefix + >&2
□ UUOC: no cat file | command — use $(<file) or direct argument
□ Manifest snippets: identical 5-line cascade (header + 4 checks with inline comments) in every skill/agent
□ Comment/wording: same pattern = same words across all files
□ Stale docs: counts, descriptions, examples match actual implementation
□ Unquoted $() assignments: must be VAR="$(...)" for space safety
□ Hardcoded values: status names, repo names, owner names should be
  manifest-driven or use placeholders
□ Else branches: error messages to stderr, consistent wording, exit on required
  paths
□ Script paths in skills: repo-root-relative, not cwd-relative
□ Usage/help text: hardcoded examples must match dynamic behavior. If a script
  reads statuses from manifest, usage text must not list fixed statuses.
□ Overly restrictive guards: validation must not block legitimate input. E.g.,
  a ".." check must not reject repo paths like "../sibling-repo". Test guards
  against real-world values.
□ CI workflow safety: every cd in CI must be in a subshell or use || exit 1 to
  propagate failures. Grep exit code 2 must not be silently swallowed.
□ Action versions: actions/checkout@v6, actions/setup-go@v6,
  markdownlint-cli2-action@v22, golangci-lint-action@v9 — must be consistent
  across ci.yml, release.yml, skills, and scaffold templates.
□ Untrimmed user input: EVERY read -rp value must be trimmed before validation.
  Whitespace-only input must be treated as empty.
□ Error message vs regex mismatch: if validation uses ^[A-Za-z0-9]..., the
  error message must describe that exact pattern, not a different one.
□ Mutually exclusive args: if --url and --item-id cannot coexist, the script
  must reject both being set — not silently prefer one.
□ Tilde expansion: ~ does not expand inside quotes or variable assignment. If
  user input may contain ~/path, handle expansion explicitly (e.g., substring
  check for ~/ prefix and replace with $HOME).
□ Manifest-missing exit: if a code path requires manifest data and the manifest
  is absent, it must exit 1 or return error — never silently fall through or
  continue with empty values.

Each agent receives this prompt with its role, checklist, and file contents injected. The template MUST be used verbatim — do not paraphrase or abbreviate.

You are reviewing a Go codebase change for [{REPO}].
Branch: {BRANCH} (PR #{PR_NUMBER})

ROLE: {ROLE_NAME}
PERSPECTIVE: {ROLE_DESCRIPTION}

REVIEW THE FULL FILES (not just diffs) — catch inconsistencies, stale comments, cross-file issues.

{CHECKLIST}

RULES:
- Only flag issues in code MODIFIED by this PR (not pre-existing)
- Score each finding 0-100 confidence
- Only report findings with confidence >= 75
- Be specific: file, line number, what's wrong, how to fix
- Do NOT flag: formatting, style preferences, things linters catch
- Do NOT suggest: over-engineering, premature abstraction, YAGNI changes

FILES TO REVIEW:
{FILE_CONTENTS}

Report findings as:
### [{SEVERITY}] {Title} (Confidence: {score})
- **File**: `{file}:{line}`
- **Issue**: {description}
- **Fix**: {concrete suggestion}

If no issues found, report: "✅ Clean — no issues found from {ROLE_NAME} perspective."

Execution Protocol

Step 1 — Auto-detect context

Determine the repo name, path, and branch automatically from the working directory. Then collect the set of changed files.

1. Repo name and path: infer from cwd
2. Current branch: git branch --show-current
3. Changed files (pick the first that returns results):
   a. git diff --name-only main...HEAD        (branch vs main)
   b. git diff --name-only --staged           (staged changes)
   c. git diff --name-only                    (unstaged changes)
4. Read full content of every changed file

Step 2 — Determine iteration mode

• First iteration (default, or explicitly requested): review FULL changed files. All 11 agents run.
• Targeted iteration (after fixing findings from a previous run): review only the diff since the last commit. Only launch agents whose roles are relevant to the files/findings that changed.

Ask the user which mode to use if unclear. Default to first iteration.

Step 3 — Launch agents

Launch ALL agents in parallel using the task tool with mode: "background". For minimum fleet, launch agents 1–5 only. For full fleet, launch all 11.

Each agent uses its assigned model via the model parameter.

## Group A — General Perspectives (always launched)
Agent  1: task(agent_type="code-review", model="claude-opus-4.6",      prompt=<template with Architect role>)
Agent  2: task(agent_type="code-review", model="gpt-5.1-codex",        prompt=<template with Correctness role>)
Agent  3: task(agent_type="code-review", model="gpt-5.3-codex",        prompt=<template with Security Overview role>)
Agent  4: task(agent_type="code-review", model="claude-sonnet-4.5",    prompt=<template with Test Coverage role>)
Agent  5: task(agent_type="code-review", model="gemini-3-pro-preview", prompt=<template with Operational role>)

## Group B+C — Specialized (full fleet only)
Agent  6: task(agent_type="code-review", model="claude-sonnet-4.6",    prompt=<template with Deep Security role>)
Agent  7: task(agent_type="code-review", model="gpt-5.2-codex",        prompt=<template with Unicode role>)
Agent  8: task(agent_type="code-review", model="gpt-5.1-codex-max",    prompt=<template with Test Quality role>)
Agent  9: task(agent_type="code-review", model="claude-sonnet-4",      prompt=<template with Lint role>)
Agent 10: task(agent_type="code-review", model="gpt-5.1",              prompt=<template with Template/Contract role>)
Agent 11: task(agent_type="code-review", model="gpt-5.4",              prompt=<template with GitHub Copilot Perspective role>)

Step 4 — Collect and triage

As agents complete, read their results with read_agent. Then:

1. Group findings by severity: CRITICAL > HIGH > MEDIUM > LOW
2. Deduplicate — same file+line flagged by multiple agents counts once (list all agents that flagged it)
3. Filter — only surface findings with confidence >= 80
4. Cross-reference — if two or more agents flag the same area, escalate severity by one level

Step 5 — Report

Output findings grouped by file, then by severity within each file.

## Fleet Review Results — {REPO} ({BRANCH})

### Summary
- Agents reporting clean: X/11
- Total findings: Y (Z critical, W high, ...)
- Files reviewed: N

### Findings

#### `path/to/file.go`

##### [CRITICAL] Title (Confidence: 95)
- **Agents**: #2 Correctness, #6 Deep Security
- **Line**: 42
- **Issue**: description
- **Fix**: concrete suggestion

...

### Verdict
✅ Fleet review clean — ready to commit
   — or —
❌ N findings require attention before commit

Agent Configuration Reference

Quick-reference table for programmatic agent launch.

Model Diversity

The fleet uses 11 distinct models across 3 providers to maximize perspective diversity and minimize shared blind spots:

• Claude (4 agents): opus-4.6, sonnet-4.6, sonnet-4.5, sonnet-4
• GPT (6 agents): 5.1-codex, 5.3-codex, 5.2-codex, 5.1-codex-max, 5.1, 5.4
• Gemini (1 agent): 3-pro-preview

No two agents in Group B share the same model.

Iteration Workflow

┌─────────────────────────────────────────┐
│  1. Run fleet review (all 11 agents)    │
│  2. Fix findings                        │
│  3. PROPAGATE fixes repo-wide           │
│  4. Build + test                        │
│  5. Run targeted fleet review           │
│     (only relevant agents, diff only)   │
│  6. If findings remain → go to 2        │
│  7. If clean → commit + push            │
└─────────────────────────────────────────┘

Repeat until the fleet reports clean. Only then proceed to commit.

Step 3 — Fix Propagation (MANDATORY)

After fixing ANY finding, you MUST sweep the entire repo for the same pattern class before moving on. Never fix one instance and leave others.

Pattern sweep rules:

1. Regex fix → grep ALL regex validations in ALL scripts. Same input type = same regex. All path-segment inputs must reject literal . and .. (dot-prefixed names like .github are valid).
2. Error message fix → grep ALL echo calls on error paths. Ensure: Error: prefix, >&2, consistent wording.
3. Code snippet fix → grep ALL files containing that snippet. If a snippet appears in 8 files, fix all 8 — not just the one flagged.
4. UUOC fix (cat file | X) → grep ALL $(cat and cat.*| patterns repo-wide. Replace with $(<file) or direct arg.
5. Path/traversal fix → grep ALL inputs used as path segments. Validate every one.
6. Stderr fix → grep ALL error-path echo calls. Every one must use >&2.
7. Comment/wording fix → grep for the old wording repo-wide. Update every instance.

Scope: scripts, skills, agents, docs, CI — not just the file type flagged.

Verification: After propagation, run a consistency audit:

• Manifest discovery snippets identical everywhere
• Regex patterns consistent for same input types
• Error message format standardized
• Placeholder syntax consistent ({X} not $X or <X>)
• Script paths repo-root-relative in skills

Trigger Phrases

This skill activates for any of the following phrases:

• "fleet review"
• "run fleet"
• "multi-model review"
• "11 agent review"
• "cm review"
• "code review fleet"
• "review changes"
• "run code review"
• "multi-perspective review"
• "launch fleet"

Important Notes

• The checklists are MANDATORY — agents MUST work through every checkbox. Skipping checklist items defeats the purpose of the fleet.
• First iteration always reviews full files, not just diffs. This catches stale comments, doc/code mismatches, and cross-file inconsistencies.
• Subsequent iterations: ask the user whether to do full-file or diff-only review. Let the user decide the review depth.
• Model diversity is critical. Do not substitute models unless the specified model is unavailable.
• Only surface findings with confidence >= 80. Lower-confidence findings create noise and slow down the review cycle.
• Deduplicate across agents — if multiple agents flag the same line, report it once and list all flagging agents.
• This skill is the pre-push quality gate. Never push without a clean fleet review unless the user explicitly approves skipping.

Severity Definitions

Use these severity levels consistently across all agents:

Cross-Agent Escalation Rules

When multiple agents independently flag the same area of code, escalate:

• 2 agents flag same file+line → escalate severity by one level
• 3+ agents flag same file+line → escalate to CRITICAL regardless
• Security + Correctness overlap → always treat as CRITICAL
• Unicode + Security overlap → always treat as CRITICAL (encoding attacks)

Error Handling

If an agent fails to complete (model timeout, rate limit, etc.):

1. Log which agent failed and the error reason
2. Do NOT block the review — report results from the agents that completed
3. Note in the summary which agents did not finish
4. Offer to re-run only the failed agents

If fewer than 7 agents complete successfully, warn the user that coverage is degraded and recommend a re-run before committing.

File Scope Rules

Not every file type needs all 11 agents. Use these rules to skip irrelevant agents and save tokens:

When a skip rule applies, note it in the summary so the user knows why an agent was not launched for a particular file.

Windows / PowerShell Notes

When running on Windows (Git Bash via PowerShell):

• Parallel golangci-lint conflicts: golangci-lint uses a file lock. If two repos are linted simultaneously (e.g., during Phase 1 pre-flight across multiple repos), one may fail with "parallel golangci-lint is running." Serialize lint runs or use separate GOLANGCI_LINT_CACHE directories.

• --body escaping: Complex markdown with backticks, quotes, and newlines breaks in PowerShell. Always use --body-file /tmp/review-body.md instead of inline --body when creating issues or PRs from fleet results.