# Cm Fleet Review > Multi-perspective code review fleet for the Config Manager project. Launches parallel review agents with diverse AI models, each with a specific role and mandatory checklist. Supports minimum fleet (5 agents) for routine reviews and full fleet (11 agents) for major changes. This is the core quality gate for cm. USE FOR: 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. - Skill: `msutara/cm-fleet-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add msutara/cm-fleet-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/msutara/cm-fleet-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: msutara (https://skillmd.com/u/msutara) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/msutara/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 | Mode | Agents | When to Use | | --- | --- | --- | | **Minimum fleet** | 5 (Group A) | Routine PRs, small fixes, docs changes | | **Full fleet** | 11 (Groups A + B + C) | Major features, security work, pre-release, structural changes | 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 | # | Role | Model | Focus | | --- | --- | --- | --- | | 1 | Architect/Designer | claude-opus-4.6 | SOLID, layering, coupling, abstraction, API shape | | 2 | Correctness/Edge Cases | gpt-5.1-codex | Logic bugs, off-by-one, nil/empty, error handling, boundary analysis | | 3 | Security Overview | gpt-5.3-codex | Auth, injection, access control, data exposure | | 4 | Test Coverage | claude-sonnet-4.5 | Missing tests, assertion quality, coverage gaps | | 5 | Operational/Deploy | gemini-3-pro-preview | Config, logging, graceful degradation, observability | ### Group B — Specialized Checklists | # | Role | Model | Focus | | --- | --- | --- | --- | | 6 | Deep Security | claude-sonnet-4.6 | Path traversal, URL normalization, sanitization trace, template injection | | 7 | Unicode/Encoding | gpt-5.2-codex | C0/C1 control chars, multi-byte rune handling, UTF-8 edge cases | | 8 | Test Quality | gpt-5.1-codex-max | Flaky patterns, httptest usage, error path testing, test isolation | | 9 | Lint/Consistency | claude-sonnet-4 | errcheck, nolint justifications, DRY violations, import consistency | | 10 | Template/Contract | gpt-5.1 | URL generation, type mismatches, error propagation, display consistency | ### Group C — Platform Reviewer Simulation | # | Role | Model | Focus | | --- | --- | --- | --- | | 11 | GitHub Copilot Perspective | gpt-5.4 | Simulates GitHub's Copilot auto-reviewer. **Key behavior: Copilot checks if patterns fixed in the diff exist unfixed in other files** — this is its primary comment source. Also checks: unvalidated external inputs, missing existence guards, defensive coding gaps (unchecked return values, empty vars in paths, unquoted vars), inconsistent patterns across files, stale docs/comments/counts, regex consistency, UUOC, error output to stderr, path traversal via `.`/`..`. Every value from JSON/env/user input must be validated. Every file/dir access must be guarded. | --- ## 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 ```text □ 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 ```text □ 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 ```text □ 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 ```text □ 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 ```text □ 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 ```text □ 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 ```text □ 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 $(= 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. ```text 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. ```text ## Group A — General Perspectives (always launched) Agent 1: task(agent_type="code-review", model="claude-opus-4.6", prompt=