./<skill-folder>/tools/memory.sh add <category> "<content>" [--tags a,b,c]

./<skill-folder>/tools/memory.sh session add todo "Task" --status pending
./<skill-folder>/tools/memory.sh session show                    # View current
./<skill-folder>/tools/memory.sh session update <id> --status completed
./<skill-folder>/tools/memory.sh session delete <id>
./<skill-folder>/tools/memory.sh session clear                   # Current only
./<skill-folder>/tools/memory.sh session clear --all             # ALL sessions

./<skill-folder>/tools/memory.sh session use feature-auth        # Switch session
./<skill-folder>/tools/memory.sh -S other session add todo "..." # One-off
./<skill-folder>/tools/memory.sh session sessions                # List all

<skill-folder>/tools/spawn-glm.sh -n NAME -f PROMPT_FILE [-m MODEL] [--pi]

<skill-folder>/tools/wait-glm.sh name1:$PID1 name2:$PID2 name3:$PID3

undefined

The planner selects from the following bricks. Skipped bricks are noted as `SKIPPED: [reason]`. **Do NOT wait for user approval — output the plan and proceed immediately.**

PLAN            Always FULL (2 agents: planner + organizer, both default model).
                No variants. Never skipped. Bad plan poisons everything downstream.
                Planner (agentic-planner) researches and produces the plan. Organizer (agent-organizer) reviews and fixes in-place — the organizer's output IS the final plan.

DISCOVER        Pre-change analysis — review/audit existing code before making changes.
├── NONE        Required for size=tiny — nothing to discover on changes this small.
│               Required for size=small when the planner traced the complete code
│               path and identified the exact fix location with file:line citations
│               — no open questions remain. Justify with specific research findings.
│               If the planner cannot state "Root cause at [file:line], fix is
│               [approach]" with concrete evidence, the NONE bar is not met.
├── SINGLE      1 agent per domain. Use for medium+ tasks, or small tasks
│               where open questions remain after planning research.
│               At MEDIUM+ severity: +1 second opinion agent per domain (parallel).
│               Default pair: domain specialist (primary) + code-reviewer (second opinion) — planner may override based on task context.
└── MULTI       N agents, one per domain. Split by specialist → volume.
                At MEDIUM+: each domain gets a second opinion agent.

                When the task spans 2+ domains with non-trivial coupling (see
                Boundary Selection Criteria below), the planner adds intersection
                discovery agents to the DISCOVER batch. An intersection agent
                audits the integration boundary between two adjacent domains —
                tracing the full data/error/call flow across the divide,
                verifying contracts hold at the boundary, and identifying
                mismatches in data format, error semantics, or transactional
                consistency. This is distinct from second opinions: second
                opinions apply a different analytical lens to the SAME domain;
                intersection agents trace the boundary BETWEEN different domains
                where coupling creates defect-prone blind spots invisible to
                either domain specialist alone. Intersection findings are tagged
                "boundary-found" in extraction — signaling issues no within-domain
                specialist could have detected. CRITICAL/HIGH findings from
                intersection discovery are routed through cross-domain adversarial
                verification (1:1 per finding, verifying from both sides of the
                boundary). Intersection agents MUST be placed in the first DISCOVER
                stage — never deferred to CONVERGE iterations. CONVERGE inherits
                the intersection requirement but adds ADDITIONAL agents with
                different specialists, not replacements for the first-stage ones.
                Intersection agents run in parallel with domain primaries and
                second opinions within the same stage. At MEDIUM+ severity: each
                intersection agent gets its own second opinion (a different
                specialist from the INDEX, not the same type as the intersection
                agent). Intersection agents audit gaps between domains — second
                opinions audit the intersection audit itself for missed concerns.

                The planner selects the best agent for each boundary based on
                domain context. Suggested defaults (planner's selection is
                authoritative — these are starting points, not mandates):
                `backend-architect` for data flow and contract tracing;
                `security-reviewer` for crypto/auth boundaries. The planner
                may choose any agent from the INDEX that fits the boundary.

IMPLEMENT       Write or modify code.
├── NONE        No code change (analysis-only, cosmetic-only).
├── SINGLE      1 agent per domain. Writes code directly to original files.
│               Standard for all code changes.
└── MULTI       N agents, one per domain. Split by specialist → volume.

                SINGLE for narrow single-domain changes; MULTI for changes
                spanning multiple specialists. Line count is not the measure —
                split by domain diversity, not file count.

REVIEW          Review code changes.
├── NONE        Skip: change type=cosmetic AND severity=none.
│               Or: IMPLEMENT=NONE.
├── SINGLE      1 agent per domain. Standard.
│               At MEDIUM+ severity: +1 second opinion agent per domain (parallel).
│               Default pair: code-reviewer (primary) + language specialist (second opinion) — planner may override based on task context.
│               When the task spans 2+ domains using DIFFERENT specialists,
│               the planner adds cross-domain integration reviewers to the
│               REVIEW batch (see Boundary Selection Criteria for triage —
│               same ALWAYS/DEFAULT/SKIP tiers apply). These agents focus
│               ONLY on integration points: API contracts, shared types,
│               data flow between domains, and regressions at boundaries from
│               implementation changes. Do NOT re-review domain-internal logic.
│               Post-implementation intersection review is critical: domain
│               reviewers see new methods as correct within their context;
│               only tracing the full boundary reveals regressions where error
│               contracts, data formats, or transactional ordering differ from
│               what the caller expects. Findings from cross-domain integration
│               review are routed through adversarial cross-verification (1:1
│               per CRITICAL/HIGH finding, verifying from both sides).
└── MULTI       N agents, one per domain.

VERIFY          Verify findings from DISCOVER, REVIEW, or post-fix review.
                Always includes extraction (1 agent, default model). Tags findings
                "both-found"/"single-found" when originating stage had second opinion,
                and "boundary-found"/"domain-only" when intersection agents were present.
                Routes findings by severity:
                
                CRITICAL/HIGH → ADVERSARIAL AGENT (1 agent per finding — 1:1)
                  Adversarial agent tries to FALSIFY every finding: reads cited code
                  with full surrounding context (minimum 30 lines), exhaustively
                  searches for counter-evidence at every level (same function guards,
                  caller-level validation, framework-level protections — middleware,
                  decorators, interceptors, global error handlers — type system
                  invariants, test coverage). Labels each CONFIRMED / REJECTED /
                  WEAKENED with evidence. For CONFIRMED: describe what patterns
                  were searched, which grep commands were run, why nothing was found.
                  For REJECTED: paste exact counter-evidence code with file:line.
                  For WEAKENED: paste partial counter-evidence AND explain what
                  portion of the original claim still stands.
                  Default position: assume the claimed issue is a misunderstanding and search exhaustively before confirming. For "missing X" findings, searching for X and finding it in no reachable code path IS valid evidence — document all searched locations. Findings that survive
                  exhaustive falsification become ADVERSARIALLY VERIFIED.
                
                CRITICAL/HIGH from intersection or cross-domain integration review
                  (any finding spanning domain boundaries, regardless of whether
                  it originated in DISCOVER or REVIEW) → ADVERSARIAL CROSS AGENT
                  (1 agent per finding — 1:1). Same exhaustive falsification but verifies
                  from BOTH sides of the integration boundary (Domain A producer +
                  Domain B consumer + bridge between them). Finding only survives
                  if no counter-evidence on either side or in the bridge.
                
                MEDIUM → ADVERSARIAL AGENT (1 agent per batch of 5 findings)
                  Same exhaustive falsification methodology as CRITICAL/HIGH —
                  reads cited code with full surrounding context (minimum 30
                  lines), exhaustively searches for counter-evidence at every
                  level (same function guards, caller-level validation,
                  framework-level protections, type system invariants, test
                  coverage). Labels each CONFIRMED / REJECTED / WEAKENED with
                  evidence. Default position: assume the claimed issue is a
                  misunderstanding and search exhaustively before confirming.
                  Every CONFIRMED label must be hard-won with grep evidence.
                
                LOW → NOTED. Recorded in report. No further agent spend.
                
                After routing: SYNTHESIS (1 agent, default model) compiles all
                verdicts into unified grid. Surfaces "both-found" confidence signals.
                Unified vocabulary: CONFIRMED / REJECTED / WEAKENED.
                Also sanity-checks severity assignments against the severity
                classification criteria — if a finding's severity appears mismatched
                (e.g., "SQL injection" labeled MEDIUM), flag it as CHALLENGED.
                Challenged findings are re-routed through adversarial verification.
                Exception: documentation-domain challenged findings skip
                adversarial — documentation severity is inherently subjective
                (is "10 missing API docs" HIGH or MEDIUM?) and adversarial
                review of severity ratings adds no meaningful verification.
                Documentation-domain challenged findings stay at their
                challenged severity; the lead accepts the downgrade directly.
                Early-exit: 0 findings after extraction → skip synthesis.
                Always runs when DISCOVER, REVIEW, or post-fix review produced findings with code-level references.
                When CONFIRMED findings exist at MEDIUM+, FIX=DOMAINS must follow.

CONVERGE        Repeat DISCOVER or REVIEW for additional passes. Planner decides variant.
                Factors: ambiguity, codebase complexity, finding volume, production impact,
                change type, time sensitivity.
                NONE: One pass. For well-understood, narrow work. Also appropriate
                      for codebases with comprehensive test coverage (>80%) and
                      clean module boundaries — first pass is unlikely to miss
                      meaningful issues.
                ONCE: One extra iteration if first pass found anything ("found
                      anything" means any iter 1 agent reported at least one
                      finding — regardless of whether it survived adversarial
                      verification; the point is different iter 2 specialists
                      re-examine what iter 1 noticed). Use when
                      the planner's Phase 1 research reveals interconnected modules,
                      dense coupling, non-uniform code patterns, or >15K LOC per
                      domain — characteristics suggesting a first pass may miss
                      issues. Also used when severity is HIGH/CRITICAL regardless
                      of codebase quality (missed findings are expensive). ONCE is
                      NOT the universal default — well-tested, cleanly-structured
                      codebases should use NONE.
                LOOP: Up to 3 iterations, stop on empty report. For highly ambiguous
                      or production-critical work where missed findings would be
                      unacceptable.
                Iterations inherit ALL mandatory rules from the parent stage type
                (second opinions at MEDIUM+, intersection agents at triaged boundaries,
                DISCOVER/REVIEW → VERIFY pipeline, etc.). Intersection agents inherited
                by CONVERGE are ADDITIONAL agents, not replacements — the first DISCOVER
                stage must have its own intersection agents for ALWAYS/DEFAULT boundaries;
                CONVERGE iter 2 adds fresh intersection agents with different specialists.
                
                Each iteration gets its own VERIFY stage. Iter 1's VERIFY runs BEFORE
                iter 2 spawns — the synthesis grid from iter 1's VERIFY determines
                whether iter 2 spawns (any finding = spawn) AND provides PRIOR CONTEXT
                for iter 2 agents. Do NOT merge both iterations' verification into a
                single stage after both iterations complete. The plan structure must be:
                  Stage N:   DISCOVER iter 1
                  Stage N+1: VERIFY iter 1
                  Stage N+2: DISCOVER iter 2 (conditional, PRIOR CONTEXT from N+1)
                  Stage N+3: VERIFY iter 2
                
                The planner must list all agents per iteration with different
                specialists from the previous iteration — the lead spawns
                whatever the plan lists. Before writing iter 2, the planner MUST
                list every agent `.md` file used in iter 1 and exclude them all
                from iter 2 — no agent may appear in any role in both iterations.
                Swapping primary and second opinion roles between iterations does
                NOT count as different specialists. Using the same pair of agent
                `.md` files in opposite roles is still the same analytical
                framework. The exclusion list must be explicit in the plan.

FIX             Apply verified findings. Always 2-3 sequential stages — includes post-fix review.
                When DOMAINS: 1 fix agent per domain → post-fix REVIEW
                (same variant/domain split as the REVIEW stage), then VERIFY
                if any post-fix review report contains at least one finding at
                MEDIUM severity or above. A finding is any numbered item with a
                severity label and code reference (file:line, function, or block)
                in a reviewer's report. The lead does NOT re-classify, downgrade,
                or exclude findings — the reviewer's filed severity is authoritative.
                VERIFY is skipped ONLY when ALL post-fix review reports contain
                zero MEDIUM+ findings. Mechanical trigger, no judgment.

                CONVERGENCE: If post-fix VERIFY produces CONFIRMED MEDIUM+
                findings in the synthesis grid, the fix is incomplete. Spawn a new
                fix pass (fix agents → post-fix review → conditional verify) for
                the confirmed findings. This repeats until post-fix review
                produces zero MEDIUM+ findings and VERIFY is skipped. The FIX
                brick is a convergence loop — one pass is never final when
                MEDIUM+ findings survive verification. Documented findings marked
                "for follow-up action" are still unfixed MEDIUM+ findings — fix
                them now, not later.
├── NONE        No verified findings.
└── DOMAINS     1 fix agent per domain → post-fix REVIEW → conditional VERIFY.

TEST            Run build + test suite. Always single agent, default model (mechanical).
├── NONE        IMPLEMENT=NONE. Or planner skips with justification (no test infra).
└── FULL        1 agent. Runs build + tests, fixes failures.

  Stage N: Implementation — 1 agent per domain
    Agent writes code directly to original files.
  Stage N+1: Review — 1 agent per domain
    Reviews the implementation for bugs, quality, correctness.
  Stage N+2: Verification — severity-routed (extraction → adversarial [CRITICAL/HIGH 1:1, MEDIUM 1 per 5] → synthesis)

  Stage N: Fixes — N agents split by domain
  Stage N+1: Post-fix review — N agents (1 per domain)
  Stage N+2: Verification — severity-routed (only if fix review found MEDIUM+ findings)

  Stage N agents:
    Batch 1 (parallel): agent-a (writes X.swift), agent-b (writes Y.swift)
    Batch 2 (after batch 1): agent-c (tests X.swift, depends on agent-a)

undefined

**Prompt assembly:** Assemble ONE prompt per agent via `assemble-prompt.sh`:
```bash
<skill-folder>/tools/assemble-prompt.sh -a AGENT -t TYPE -n NAME --task tmp/task.txt

undefined

**Naming convention overview:**
- Plan: `s0-planner`, `s0-organize`
- Discovery: `sN-discover-{domain}`, `sN-discover-2-{domain}` (second opinion),
  `sN-discover-{domainA}-{domainB}` (intersection, e.g., `s1-discover-crypto-services`)
- Implementation: `sN-impl-{domain}`, `sN-review-{domain}`, `sN-review-2-{domain}` (second opinion),
  `sN-review-{domainA}-{domainB}` (intersection, e.g., `s6-review-crypto-services`)
- Verification: `sN-extract`, `sN-adv-{domain}` (adversarial — 1:1 for CRITICAL/HIGH, 1 per 5 for MEDIUM), `sN-adv-cross` (cross-domain adversarial), `sN-synth`
- Fix: `sN-fix-{domain}`
- Test: `sN-test`
- Iterations: `s{N}i{K}-name` (e.g., `s2i1-researcher`, `s2i2-researcher`)
- Respawns: add `-r2`, `-r3` suffix when re-spawning a failed agent with corrected configuration (e.g., `s2i1-reviewer-r2` = stage 2 iteration 1 reviewer, respawn attempt 2). Maximum 3 respawn attempts per agent.

You are a single agent working solo. Do all the work yourself — do not spawn sub-agents, do not delegate to other agents, do not run agentic workflows. Agentic workflows are not allowed in this session.

Before claiming something is missing or broken — grep for existing guards, handlers, or implementations first.

{cat <skill-folder>/templates/coordination-review.txt OR coordination-code.txt — replace {NAME}}

{cat <skill-folder>/templates/severity-guide.txt — REVIEW/audit tasks only}

{cat <skill-folder>/templates/quality-rules-review.txt OR quality-rules-code.txt}

{Full <skill-folder>/agents/{agent}.md — see Rules → Prompts}

You are an AI agent named {NAME}.

--- TASK ASSIGNMENT ---

PROJECT: {working directory and project description}

ENVIRONMENT (code tasks only):
{Runtime, test command, lint command}

PRIOR CONTEXT (stage 2+ or iteration 2+):
{Contents of tmp/stage-N-synthesis.md OR cumulative tmp/stage-N-iter-*-synthesis.md for iterations}

YOUR TASK: {KEY FILES, CONTEXT, SCOPE, MUST ANSWER questions}

WRITABLE FILES: {code agents only — list source files agent may edit. Review/research/audit agents: omit this section}

./<skill-folder>/tools/memory.sh session add context "CHECKPOINT: [task] | DONE: [steps] | NEXT: [remaining] | SKIP: [do not redo — completed agents, failed approaches, skipped stages, pending approvals] | FILES: [key files] | BUILD/TEST: [commands]"

undefined

undefined