best-workflow

Temporary Files

tmp/

Agents

<skill-folder>/agents/

<skill-folder>/agents/INDEX.md

Agent Categories

Agent Selection

Memory System

knowledge.md

session.md

memory.sh

knowledge.md

session.md

Knowledge

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

architecture

gotcha

pattern

config

entity

decision

discovery

todo

reference

context

--tags redis,production,auth

search "<query>"

list [--category CAT]

delete <id>

stats

Session

plan

todo

progress

note

context

decision

blocker

pending

in_progress

completed

blocked

./<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

Checkpoints

Multi-Session

-S

MEMORY_SESSION

<skill-folder>/current_session

"default"

./<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

Web Research

1. ALL internet research must go through

   web_search.sh

   — no exceptions. This means: no built-in websearch tool, no WebFetch tool, no

   curl

   against APIs, no manual GitHub API calls, no

   wget

   , nothing else. Every time you need information from the internet, use

   ./<skill-folder>/tools/web_search.sh "query"

   (or

   <skill-folder>/tools/web_search.bat

   on Windows)
   • One query per call — run each query as a separate

     web_search.sh

     invocation. Never combine multiple queries into a single call. Run calls sequentially (one after another, not in parallel) to avoid hitting API rate limits
   • Always use default options — never add

     -s

     ,

     --max-results

     , or any result-limiting flags. Let the tool use its built-in defaults
   • Scientific queries: add

     --sci

     for CS, physics, math, engineering (arXiv + OpenAlex)
   • Medical queries: add

     --med

     for medicine, clinical trials, biomedical (PubMed + Europe PMC + OpenAlex)
   • Tech queries: add

     --tech

     for software dev, DevOps, IT, startups (Hacker News + Stack Overflow + Dev.to + GitHub)
2. Synthesize results into a report

/

Orchestration Workflow

assemble-prompt.sh

spawn-glm.sh

wait-glm.sh

Task

subagent_type

Agent Loading Rules

<skill-folder>/agents/

• Before any subtask: select the best agent and read its

  .md

  file (always fresh re-read)
• Load ONE agent at a time (Exception: Orchestration Workflow may read multiple for prompt building)
• All agent delegation goes through

  spawn-glm.sh

  — see Rules → Task tool prohibition
• Agent instructions are TEMPORARY — apply to current subtask only, discard after

<skill-folder>/agents/*.md

assemble-prompt.sh

.md

.md

.md

.md

assemble-prompt.sh

spawn-glm.sh

Request Workflow

1. Continuation:

   ./<skill-folder>/tools/memory.sh search "GLM-CONTINUATION"

   — resume if exists
   • If found: Read

     tmp/glm-continuation.md

     , read prior synthesis, and continue from where the previous session left off. The plan is already finalized and partially executed — pick up at the next uncompleted stage.
   • If not found: Proceed to step 2.
2. Re-read Verification and Iterative Convergence sections: Before spawning ANY stage agents, re-read the Verification section AND Iterative Convergence section in full. Verification defines the severity-routed pipeline (extraction → route findings by severity → synthesis). Iterative Convergence defines planner-decided repeat logic (NONE/ONCE/LOOP). Skipping these re-reads is the #1 cause of plans missing appropriate verification and convergence. MANDATORY.
   Do NOT read source files, skim the project, or try to understand scope before spawning. The planner is your research — spawn it immediately. Fill in the project path, spawn, and let the planner do everything else. Any attempt to "understand the codebase first" IS the research we forbid. Go directly to step 3.
3. Planning phase (2 batches, 2 agents) — ALWAYS run, never skipped: a. Initial planner: Copy

   <skill-folder>/templates/planner-task-template.txt

   , fill in the project path (just the working directory — the planner researches the codebase itself), assemble with

   assemble-prompt.sh -a agentic-planner -t research -n s0-planner

   , spawn (no

   -m

   , uses default model). Researches the project, classifies the task on 5 axes (size, domains, ambiguity, severity, type), selects bricks from the palette, and produces a custom workflow manifest to

   tmp/glm-plan.md

   . b. Mandatory plan review (ALL plans): Create a review task targeting

   tmp/glm-plan.md

   with MUST ANSWER questions covering brick selection, severity classification, agent assignment, verification placement, convergence decisions, volume splitting, and dependency analysis. Include

   WRITABLE FILES: tmp/glm-plan.md

   in the task file. Assemble with

   assemble-prompt.sh -a agent-organizer -t review -n s0-organize

   , spawn (no

   -m

   , default model). The agent-organizer reviews the plan using its dual analytical framework:
   Workflow quality (native anti-patterns): Check for over-staffing, wrong agent assignments, redundant agents, vague delegations, ignored dependencies, and stale agent references. Its anti-patterns list is a ready-made plan review checklist.
   Structural validation (embedded rules in task): Verify every DISCOVER/REVIEW stage has a corresponding VERIFY. Verify IMPLEMENT stages have a corresponding REVIEW. Verify MEDIUM+ severity tasks have second opinions in ALL DISCOVER and REVIEW stages, including CONVERGE iterations. Verify FIX stages include post-fix REVIEW. Verify CONVERGE variant matches the codebase characteristics documented in the plan's research — if coverage >80% and clean boundaries but CONVERGE=ONCE, correct to NONE (ONCE requires interconnected modules, dense coupling, non-uniform code patterns, >15K LOC per domain, or HIGH+ severity). Verify no agent is reused across CONVERGE iterations (different iterations deploy genuinely different specialists). If the plan specifies an exclusion list, mechanically cross-check EVERY iter 2 agent against it — do NOT trust the plan's claim without verifying each slot. When the task spans 2+ domains: verify the Boundary Analysis section exists, each boundary is triaged (ALWAYS/DEFAULT/SKIP), ALWAYS/DEFAULT boundaries have intersection agents in DISCOVER and cross-domain reviewers in REVIEW, and SKIP boundaries have one-line justification. Verify cross-domain integration review only runs when genuinely different specialists are at integration boundaries. Verify domain breadth counts specialists, not packages. Volume splitting and close-call flagging are handled by the organizer's scope resolution step before structural validation — do NOT duplicate them here. Verify sequential stages are genuinely dependent — if stage N+1 does not consume stage N's verified output, flag for merge into a single parallel stage. Flag miscounts or over-large single-agent scopes.
   After review, the organizer applies all fixes directly to

   tmp/glm-plan.md

   . Its report documents what was changed and why. The organizer's output IS the final plan — no separate merge agent is needed. This runs on EVERY plan — a bad plan poisons everything downstream regardless of severity.
4. Review final plan: Read

   tmp/glm-plan.md

   , confirm classification, brick selection, and stage structure are sound. Verify CONVERGE variant matches codebase characteristics from the planner's own Phase 1 research — if research shows >80% coverage and clean boundaries but CONVERGE=ONCE, flag for correction (ONCE is for interconnected modules, dense coupling, non-uniform code patterns, >15K LOC per domain, or HIGH+ severity, not a default). If gaps remain, spawn a quick-fix agent to correct the plan.
5. Decompose: List subtasks from the plan, map each to best agent, report to user

tmp/glm-plan.md

Subtask Workflow

1. Select the best agent, read its

   .md

   , prepare the task file using the planner's KEY FILES and MUST ANSWER questions from the manifest
2. Assemble the prompt via

   assemble-prompt.sh

   , spawn the agent via

   spawn-glm.sh

3. Wait for completion, check operational status (was the report produced? no STALLED/EMPTY/MISSING?)
4. Delegate ALL substantive verification to the verification pipeline — the lead never evaluates output quality, judges findings, or assesses results
5. Save non-trivial discoveries to knowledge
6. Discard agent instructions, move to next subtask

debugger

research-analyst

spawn-glm.sh

When to Delegate

• Multiple distinct topics/domains/areas involved
• Task requires synthesizing information from different sources
• Involves any kind of audit, review, or comprehensive analysis
• Combines research with any follow-up action
• Task has natural subtask boundaries that could run in parallel
• Independent parallelizable subtasks
• Production checks, security audits, code reviews

Lead Role

• Success: Decomposable subtasks went to specialists. Your context stayed clean for coordination. Findings were verified.
• Failure: You did any implementation work an agent should have done (writing, editing, or modifying code). You read raw domain data that would have been better isolated in a specialist's context. You produced analysis without verification.

• The lead NEVER writes, edits, or modifies any project source file. The Edit and Write tools are for task files, prompts, and synthesis reports in tmp/ only. Any code change — even a single-line fix, a config tweak, or a build script adjustment — must go through a spawned agent.
• Heavy Read/Grep usage for verification coordination is expected and allowed (reading agent reports, building task files from synthesis output). For anything resembling planning or codebase research — never. Delegate to the planner pipeline immediately. Reading source files to understand the codebase is planner-agent work, not lead work.
• If a specialized agent in

  <skill-folder>/agents/INDEX.md

  matches the subtask domain → SPAWN it. Don't reproduce its work yourself
• If the subtask requires writing code, running test suites, or deep analysis across many files → that's agent work. Delegate it via

  spawn-glm.sh

  (see Rules → Task tool prohibition for the absolute rule)

• Reclassifies or downgrades an agent's severity finding to avoid running a mandatory verification stage. The reviewer's filed severity is authoritative.
• Substitutes judgment for a mechanical trigger. "When X, do Y" means exactly that — the lead does not override with "X is true but Y seems unnecessary."
• Resolves ambiguity in workflow rules by choosing the interpretation that avoids work. When a term has multiple readings, the lead applies the reading that preserves verification and quality gates, not the one that saves agents.

• Verification (lead delegates): After stage agents complete, spawn the verification pipeline:

1. Extraction agent (single, default model): Reads all reports from the stage, deduplicates findings (same file:line + same issue → merge, note source), classifies each finding by severity, splits into batches grouped by domain and severity. When the originating stage (DISCOVERY or REVIEW) used a second opinion agent, tag each finding as "both-found" (both agents reported independently) or "single-found" (one agent only). When intersection agents were present, also tag findings as "boundary-found" (reported by an intersection agent auditing a domain boundary — inherently invisible to within-domain specialists) or "domain-only" (reported only by domain primaries/second opinions). Both-found and boundary-found carry elevated confidence for different reasons: both-found signals cross-agent agreement within a domain; boundary-found signals issues spanning domains that no within-domain specialist could have detected. A finding that is both "both-found" AND "boundary-found" carries the highest confidence. Surface all tags in synthesis. Findings from documentation specialist agents (documentation-pro) are domain-verified — route them directly to synthesis at the agent's rated severity, skipping adversarial verification. If extraction finds 0 findings, VERIFY early-exits — nothing to verify, skip all subsequent batches.
   Mechanical trigger — MANDATORY: If extraction finds any finding at MEDIUM severity or above, the lead MUST spawn ALL verification batches the extraction report prescribes — every adversarial batch, at the exact finding IDs listed in the extraction's batch assignment table. Spawning an adversarial agent against different findings than prescribed does NOT satisfy this trigger. The lead does NOT pre-judge findings, skip verification steps, substitute finding targets, or decide which findings "don't matter." Only the synthesis grid determines FIX=SKIPPED. The synthesis agent is part of the pipeline — it MUST run after all routing agents complete, even if every routed finding was REJECTED or WEAKENED. The lead does NOT evaluate routing agent outputs to decide whether synthesis is needed. Proceeding to the next stage without completing all verification steps is a protocol violation.
2. Findings routed by severity (single-source routing):
   • CRITICAL/HIGH findings → Adversarial agent (single agent per finding (1:1), default model; use

     adversarial-reviewer

     agent

     .md

     ). The adversarial agent tries to FALSIFY every finding in its batch: 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), and labels each finding with evidence:
     • CONFIRMED — exhaustive search found NO counter-evidence. Describe what patterns were searched, which grep commands were run, why nothing was found.
     • REJECTED — found CLEAR counter-evidence that disproves the claim. Paste exact code with file:line.
     • WEAKENED — partial counter-evidence reduces severity or scope but doesn't fully disprove. State the correct severity.
     The adversarial agent assumes the claimed issue is a misunderstanding and searches 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. Every CONFIRMED label must be hard-won — superficial grep is not exhaustive. Surviving findings become ADVERSARIALLY VERIFIED.

• CRITICAL/HIGH findings from intersection or cross-domain integration review (any finding spanning domain boundaries, from DISCOVER or REVIEW) → Adversarial cross-domain agent (single agent per finding (1:1), default model). 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 findings → Adversarial agent (single agent per batch of 5 findings, default model; use

    adversarial-reviewer

    agent

    .md

    ). Same exhaustive falsification methodology as CRITICAL/HIGH findings — 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), and 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 — superficial grep is not exhaustive. For "missing X" findings, searching for X and finding it in no reachable code path IS valid evidence — document all searched locations.
  • LOW findings → NOTED. Recorded in the report. No further agent spend.

1. Synthesis agent (single, default model): Reads all adjudication verdicts. Builds a unified verification grid:

   CONFIRMED	REJECTED	WEAKENED
   → fix list	→ dropped	severity downgraded → fix list at lower priority

   Surfaces "both-found" confidence signals from extraction — findings reported by both primary and second opinion agents carry higher initial confidence.
   If the synthesis grid shows zero CONFIRMED findings at MEDIUM or above (all MEDIUM+ findings were REJECTED, or only LOW-severity survivors remain), FIX is SKIPPED — there is nothing significant to fix. LOW verified findings are acknowledged in the synthesis as non-blocking. The lead writes the synthesis with

   FIX SKIPPED: Zero MEDIUM+ verified findings — nothing to fix.

   This is mechanical — no lead judgment.

• Implementation (agent does): Writing/editing code, running test suites, fixing bugs, adding tests, refactoring
• After the verified checklist is produced, if many fixes are needed across many files: collect them into a fix-agent prompt and spawn

Tools

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

-m

-m MODEL

--pi

SPAWNED|name|pid|log_file

tmp/{NAME}-report.md

tmp/{NAME}-log.txt

tmp/{NAME}-status.txt

.cmd

-m

-m

.md

.md

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

wait

sleep

name:pid

Workflow

Planning

tmp/glm-plan.md

1. Pass the user's request as-is and the current working directory to the planner — no summarization or research, the planner reads the codebase itself
2. Review the planner-generated manifest for classification accuracy, brick selection, severity justification, and agent assignments
3. If the manifest has discovered scope ambiguity, add discovery/research stages — these are agent work, not lead work. Never open source files to fill gaps yourself
4. Write well-scoped prompts using the manifest's context, KEY FILES, and MUST ANSWER questions (provided by the planner per stage). The lead may add 1-2 supplementary questions about workflow concerns (e.g., "Was the linter run?") but does not write code-level technical questions.
5. If the plan is insufficiently informed, re-run the planner with more specific questions or add a discovery stage. Under no circumstances does the lead read source files to research gaps directly

# DYNAMIC BRICK MANIFEST — planner selects bricks per task.
# No fixed skeleton. Each task gets a custom workflow.

Plan: [N stages, M total agents]

  Stage 0: Plan — 2 agents (planner + organizer)
    Classification: size=[], domains=[], ambiguity=[], severity=[], type=[]

  Stage 1: [Brick name] — [Variant] — N agents
    Justification: [why this brick, why this variant]
    Agent: [specialist name]
    Second Opinion: [agent name if MEDIUM+; "N/A (severity < MEDIUM)" otherwise]
    KEY FILES: [list]
    MUST ANSWER:
      1. [technical question from planner's codebase research]
      2. [...]
    ...

  Total agents: M

SKIPPED: [reason]

Brick Catalog

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.

Severity Classification

validatePassword

Domain Splitting

swift-pro

1. Split by specialist — map each file/concern to the best specialist agent from

   <skill-folder>/agents/INDEX.md

2. Split by volume — keep each discovery agent to ~20 files and ~5K LOC. A narrow overage (up to 25 files / 6K LOC, in a single cohesive module — not unrelated files packed together) is acceptable; above that, split is mandatory. Discovery agents must read every file — a 20-line header costs the same context as a 200-line implementation file because the agent must understand the API and cross-reference every caller. After splitting, re-count each resulting sub-group to verify none still exceeds the limits.
   Post-split re-evaluation. After mandatory splits, verify the resulting agents are not fragmented. If any sub-agent has fewer than 15 files AND fewer than 3K LOC, the split produced an under-utilized agent — standalone agents this small add coordination overhead without proportional audit depth. Consider merging adjacent sub-agents: a single 40f/4K-LOC agent with "many thin boilerplate files" justification is better than two 20f/2K-LOC agents that have almost nothing to audit. When file count exceeds the 25f cap but total LOC is under 3K, the files are likely thin code-behind or utility stubs — prefer accepting as close call over splitting into fragments. The caps prevent agent overload, not create stand-alone agents that have too little to examine.
   The planner provides FILE SCOPES (module-level descriptions, e.g. "GPG core: core/GPGHandler.py, core/gpg_utils/*.py") with rough LOC estimates from Phase 1 research. The organizer resolves every scope to exact individual file paths (using glob + find + test -f), runs wc -l for exact counts, produces a systematic volume audit table comparing each domain against the ~20f / ~5K LOC baseline and the 25f / 6K LOC narrow cap, splits domains exceeding the cap, and writes the resolved KEY FILES + exact LOC counts into the plan file, preserving the planner's MUST ANSWER questions, domain descriptions, and agent assignments for each domain.
3. Split implementation agents by edit density — different from discovery volume splitting. Sequential edits on the same file accumulate context pressure linearly (agent re-reads, re-edits, re-tests the same code) causing edit amnesia: the agent forgets it already applied a change and tries to re-apply it. Two mechanical caps, counted from the synthesis grid's confirmed MEDIUM+ findings:
   • Per-file cap: no single file may carry more than 8 confirmed MEDIUM+ findings to one implementation agent. If a file exceeds 8, split that file's fixes across 2 agents by finding index.
   • Per-agent cap: no implementation agent may receive more than 12 confirmed MEDIUM+ findings across all files. If a domain exceeds 12 total, split into 2 agents by file/module.

Boundary Selection for Intersection Agents

Size Classification

size=tiny

size=small

medium

large

Mid-Execution Amendment

  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)

1. What subtasks exist? (list each one)
2. Which agent handles each subtask? (map agent name to subtask — consult

   <skill-folder>/agents/INDEX.md

   )
3. Where is verification in this plan? Confirm verification runs after every DISCOVER and REVIEW stage that produces findings, or mark it explicitly as SKIPPED with justification.

PRIOR CONTEXT:

tmp/glm-plan.md

-m

spawn-glm.sh

1. For each agent, list files it will READ and files it will WRITE/CREATE
2. If Agent B reads or tests a file that Agent A writes → B depends on A → they CANNOT run in parallel
3. Split into batches: independent agents run together, dependent agents run sequentially
4. Document in

   tmp/glm-plan.md

   per stage:

  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)

find

1. rm -f tmp/glm-plan.md

2. find tmp/ -maxdepth 1 \( -name 'stage-*-synthesis.md' -o -name 'stage-*-iter-*-synthesis.md' -o -name 's[0-9]*-task.txt' -o -name 's[0-9]*-prompt.txt' -o -name 's[0-9]*-status.txt' -o -name 's[0-9]*-report.md' -o -name 'plan-review-*' \) -delete

3. Verify:

   ls tmp/

   — confirm no stale workflow artifacts remain. If any survived, remove them manually before proceeding.

echo "# Session Memory" > session.md

tmp/*-report.md

tmp/*-log.txt

log-analysis-report.md

tmp/loop-runs/

s{digit}...

s1-researcher

s2i1-reviewer-r2

tmp/s[0-9]*

Agent Preparation

<skill-folder>/agents/INDEX.md

1. Define task with KEY FILES, CONTEXT, SCOPE,

   WRITABLE FILES

   (code agents only — list source files agent may edit), and

   MUST ANSWER:

   questions (provided by the planner in the manifest — mandatory, prompts without these are invalid). The lead may add 1-2 supplementary workflow-level questions (e.g., "Was the linter run?") but does not write code-level technical questions.
2. Write the TASK ASSIGNMENT block (PROJECT, ENVIRONMENT if code, PRIOR CONTEXT if stage 2+, YOUR TASK, WRITABLE FILES) to

   tmp/{name}-task.txt

   . NOTE: Do NOT include the report file path in WRITABLE FILES — the script auto-injects

   tmp/{NAME}-report.md

   automatically.
3. Assemble the full prompt:
   bash

   <skill-folder>/tools/assemble-prompt.sh -a AGENT -t TYPE -n NAME --task tmp/{name}-task.txt

   Types:

   review

   (coordination-review + severity + quality-rules-review),

   code

   (coordination-code + quality-rules-code),

   research

   (coordination-review + quality-rules-review). The script reads the agent .md, selects templates, substitutes

   {NAME}

   in the task file content, and writes

   tmp/{name}-prompt.txt

   . Output:

   ASSEMBLED|name|path|bytes

4. Validate prompt contains ALL: full agent .md, TASK ASSIGNMENT with MUST ANSWER questions, quality rules, severity guide (review only), environment (code only), coordination, report format. The script handles all boilerplate automatically — you only own the task file. Missing ANY = do not spawn
5. Match agent type to task: REVIEW → code-reviewer, security-reviewer, backend-architect. CODE → language-pro, debugger. Git/history analysis (blame, log, diff, tracing fixes through commits) →

   debugger

   or

   research-analyst

6. WRITABLE FILES: Code agents: task file MUST list the exact source files/directories the agent may modify. Review/audit/research agents: omit WRITABLE FILES entirely — the script auto-injects the correct report path and marks all source files as read-only.
   • Implementation agents: WRITABLE FILES must list the exact source files the agent may modify directly. The task must instruct them to produce their implementation and run any available lint/test commands to verify correctness. The task MUST also instruct them to write an Intent section in their report before coding: a description of their understanding of the task and their intended approach, in their own words, at whatever level of detail they think is useful for the reviewer. The agent decides what to communicate — architectural reasoning, assumptions about the codebase, trade-offs considered, alternatives rejected, or anything else that helps someone else understand why they built what they built. This is the first thing they write, before any code.
   • Review/audit/research agents: omit WRITABLE FILES entirely — the script auto-injects the correct report path and marks all source files as read-only. Describe problems and desired behavior — do NOT paste exact fix code unless precision is critical (regex, API signatures, security logic). Name agents with stage prefix:

     s1-researcher

     ,

     s2-impl-auth

     .

Agent Spawning

-m

1. A single agent gets the agent

   .md

   and the task assignment — it works independently
2. When a stage has independent subtasks (different files, modules, concerns), spawn one agent per subtask in parallel — as many as the task naturally decomposes into, maximum 10 agents
3. Each agent's report feeds into the verification pipeline (see Verification section)
4. Naming convention:

   sN-name

   , e.g.

   s1-reviewer

   ,

   s2i1-researcher

   (stage 2, iteration 1)

1. Write step: A single agent writes the implementation directly to the original files. The agent reads the full task, understands the requirements, and produces a complete implementation.
2. Review step: A single review agent reviews the implementation — same task description, independent assessment.
3. Fix and iterate: The review report is processed by the verification pipeline to produce a verified checklist. ALL verified findings are fixed via fix-agents split by domain. The lead does NOT fix findings directly, regardless of how few or how trivial. Every fix MUST be followed by a post-fix review agent. Every review MUST be followed by verification — review findings are not deliverable until they've been verified. The review → fix → re-review loop iterates until the review agent produces no new findings (empty report) — this convergence is the final gate.

# Single agent (uses default model)
<skill-folder>/tools/spawn-glm.sh -n s1-reviewer -f tmp/s1-reviewer-prompt.txt
# Override model
<skill-folder>/tools/spawn-glm.sh -n s1-reviewer -f tmp/s1-reviewer-prompt.txt -m zai/glm-5.1

assemble-prompt.sh

<skill-folder>/tools/assemble-prompt.sh -a AGENT -t TYPE -n NAME --task tmp/task.txt

review

code

research

# Write step
<skill-folder>/tools/spawn-glm.sh -n sN-impl  -f tmp/sN-impl-prompt.txt
# Review step (spawn AFTER write completes)
<skill-folder>/tools/spawn-glm.sh -n sN-review -f tmp/sN-review-prompt.txt

• 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.

Second Opinion Guidelines

.md

DISCOVER pairings (defaults — planner may override)

python-pro

swift-pro

code-reviewer

security-reviewer

code-reviewer

devops-engineer

code-reviewer

REVIEW pairings (defaults — planner may override)

code-reviewer

python-pro

swift-pro

code-reviewer

security-reviewer

code-reviewer

devops-engineer

code-reviewer

backend-architect

code-reviewer

backend-architect

.md

.md

python-pro

Execution

1. Spawn current batch of agents via

   spawn-glm.sh

   , respecting the per-batch limit from Tools and the dependency analysis above. If stdout is empty (Windows

   .cmd

   issue), read

   tmp/{NAME}-status.txt

   to get PID. Checkpoint with PIDs and names. If stage has multiple batches, wait for current batch to finish before spawning next

2. wait-glm.sh name1:$PID1 name2:$PID2 ...

   — first progress at 30s, then every 60s, STALLED warnings, health check on finish
3. Do verification prep (for VERIFY stages): read the extraction agent's output, create verification task files per batch, assemble prompts. Batch cross-check (MANDATORY): Before spawning, verify that every batch the extraction report prescribes has a corresponding task file, and each task file targets the exact finding IDs from the extraction's batch assignment table (e.g., ADV-1 → B1-B4). A task file for different findings than prescribed does not satisfy the batch assignment. The extraction report is authoritative — the lead does NOT substitute finding targets.
4. Review output. Check operational status only — was the report produced? Is the log non-empty? Any STALLED markers? This is NOT quality review (do NOT evaluate findings, accuracy, or correctness). If ANY agent shows STALLED / EMPTY LOG / MISSING REPORT / EMPTY REPORT:
   • Diagnose root cause. Fix the issue (environment, prompt, task file, dependencies).
   • Re-spawn the agent with corrected configuration.
   • Do NOT proceed to the next stage with incomplete stage output.
   • Accept a gap and proceed ONLY for trivial gaps in discovery stages (e.g. a single agent in a 10-agent discovery stage failed after 3 respawn attempts with different approaches, AND its domain is partially covered by other agents). Every such decision must be explicitly justified in

     tmp/glm-plan.md

     with

     STAGE GAP ACCEPTED: [domain] [reason] [coverage from other agents]

     . Do NOT accept gaps in implementation or fix stages — those stages must produce complete, correct output. Do NOT silently skip failed agents.

Verification

research-analyst

.md

• CRITICAL/HIGH findings → Adversarial agent (single agent per finding (1:1), default model). Tries to FALSIFY every finding: reads cited code with full surrounding context, exhaustively searches for counter-evidence (guards, validation, framework protections, type system invariants, test coverage), labels each CONFIRMED / REJECTED / WEAKENED with evidence. Adversarial methodology: assume the claimed issue is a misunderstanding and search exhaustively before confirming. Every CONFIRMED label must be hard-won with grep evidence.
• CRITICAL/HIGH findings from intersection or cross-domain integration review (any finding spanning domain boundaries, from DISCOVER or REVIEW) → Adversarial cross-domain agent (single agent per finding (1:1), default model). 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 findings → Adversarial agent (single agent per batch of 5 findings, default model). Same exhaustive falsification methodology as CRITICAL/HIGH — reads cited code with full surrounding context, exhaustively searches for counter-evidence (guards, validation, framework protections, type system invariants, test coverage), labels each CONFIRMED / REJECTED / WEAKENED with evidence. Adversarial methodology: assume the claimed issue is a misunderstanding and search exhaustively before confirming. Every CONFIRMED label must be hard-won with grep evidence.
• LOW findings → NOTED. Recorded in the report. No further agent spend.

research-analyst

.md

FIX SKIPPED: Zero MEDIUM+ verified findings — nothing to fix.

1. Extraction agent spawned and report produced
2. If extraction found 0 findings → stage complete (early-exit)
3. If extraction found MEDIUM+ findings: a. ALL adversarial batches from extraction's batch assignment table spawned — cross-check each ADV task file's finding IDs against the prescribed batch:finding mapping b. Synthesis agent spawned — compiles grid, sanity-checks severity c. Synthesis grid determines FIX=SKIPPED or FIX follows Skipping any step when MEDIUM+ findings exist is a protocol violation.

• Extraction:

  sN-extract

• Adversarial pairs:

  sN-adv-{domain}

  (single agent per finding for CRITICAL/HIGH — 1:1; single agent per batch of 5 for MEDIUM)
• Adversarial cross:

  sN-adv-cross

  (single agent per finding — 1:1)
• Synthesis:

  sN-synth

Between Stages

1. Write

   tmp/stage-N-synthesis.md

   — verified results from the synthesis grid, decisions, context for next stage
2. Mid-execution amendment (new findings): If VERIFY produces confirmed findings at MEDIUM severity or above and IMPLEMENT is NOT in the manifest, the lead auto-adds IMPLEMENT followed by FIX (always 2-3 sequential stages: fix + post-fix review + conditional VERIFY). This is unconditional — all confirmed MEDIUM+ findings are fixed regardless of task intent. LOW findings are reported but not auto-fixed. This is mechanical — verify the condition, add the stages. FIX convergence (incomplete fixes): After a FIX stage's post-fix VERIFY produces CONFIRMED MEDIUM+ findings in the synthesis grid, auto-add another FIX pass regardless of whether IMPLEMENT is already in the manifest. IMPLEMENT presence does not block FIX convergence — surviving MEDIUM+ findings mean the fix was incomplete. Repeat until post-fix review produces zero MEDIUM+ findings and VERIFY is skipped.
3. If scope changed from original plan, update

   tmp/glm-plan.md

   with actual stages and revised goals
4. Checkpoint. Clean up:

   rm -f tmp/sN-*-prompt.txt tmp/sN-*-task.txt

5. Next stage prompts include synthesis as

   PRIOR CONTEXT:

   section. PRIOR CONTEXT should contain only factual project context the next stage needs: what was discovered, what was decided, what constraints exist, what was already fixed. Do NOT include verification process details, rejected findings, or behavioral instructions — these compete with the agent .md. Target under 50 lines
6. Never re-do verified work unless evidence shows it was wrong
7. Never skip a planned stage without explicitly marking it in

   tmp/glm-plan.md

   as

   SKIPPED

   with a reason. A stage is only complete when its agents have been spawned, waited, their reports processed by the verification pipeline, and findings verified — incomplete stages cannot be proceeded past, outside the narrow gap-acceptance rules in Execution step 4. PLAN stages cannot be SKIPPED for speed or token savings — only for genuine blockers (environment failure, missing files, corrupted state).
8. After writing synthesis, read

   tmp/glm-plan.md

   to confirm the next stage. If the plan has remaining stages, execute them — do not deliver early unless remaining stages are explicitly marked SKIPPED.

Iterative Convergence

• 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.

1. Each iteration = full prepare → spawn → verify cycle
2. After verification: check reports mechanically — any non-empty finding list in any agent report?
   • Yes (any finding produced) → write iteration synthesis to

     tmp/stage-N-iter-K-synthesis.md

     , prepare next iteration with cumulative context from all prior iterations
   • No (all reports empty, zero findings) → convergence reached; write final stage synthesis and move on
3. Lead SHOULD vary approach between iterations — different agents, focus areas, or angles — to avoid blind spots. Running identical agents repeatedly is wasteful.
4. Lead can adjust agent count and type between iterations based on what prior iterations revealed
5. If iteration cap hit without convergence → synthesize what's known, note "convergence not reached" in delivery, proceed
6. Naming: iteration agents follow

   s{N}i{K}-name

   — e.g.

   s2i1-reviewer

   ,

   s2i2-researcher

   (stage 2, iteration 1/2). Respawn within iteration:

   s2i1-reviewer-r2

   .

Delivery

tmp/glm-plan.md

• If any conditional VERIFY was skipped: read the stage's review reports. If any report contains a MEDIUM+ finding with a code reference, the VERIFY stage must be run now.
• If any finding was marked as dropped or noted by the lead without routing through the verification pipeline: the finding must be routed through the verification pipeline now.

• Reviews/audits: write report to

  tmp/

  with verified findings, rejected items, gaps
• Code changes: spawn a single agent (default model) to run build + tests, fix all failures, and deliver production-ready result. Lead chooses the exact agent for the job (e.g. debugger, build-error-resolver, cpp-pro). This is the final production gate.
• Research/analysis: synthesize into clear summary
• Write

  tmp/session-summary.md

  : task goal, stages executed, total agents, agent aborts/failures, iterations per iterative stage, verification stats, key decisions, phase durations (planning, preparation, execution/wait, verification, synthesis)
• Cleanup:

  rm -f tmp/s[0-9]*-prompt.txt tmp/s[0-9]*-task.txt

  . Keep logs, reports, summary
• Save workflow lessons to knowledge if applicable

Agent Prompt Template

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>/templates/

cat

Checkpoints & Recovery

./<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]"

SKIP:

• Already-completed agents whose reports exist (e.g.

  s2-reviewer done

  )
• Failed approaches tried 3× (do not retry same thing)
• Stages explicitly skipped with reason (e.g.

  verify skipped — 0 findings

  )
• Pending approval decisions (

  awaiting user approval for push

  )

1. Run

   <skill-folder>/tools/glm-recover.sh

   — prints memory session, plan, continuation (if any), newest synthesis (iter or stage, by mtime), and latest checklist in one stream. Replaces steps 1, 2, 3 below with a single command
2. Re-read AGENTS.md in full and STRICTLY follow its instructions — ALWAYS, no exceptions, no partial reads.

   glm-recover.sh

   does NOT do this for you
3. Only then resume work

glm-recover.sh

1. ./<skill-folder>/tools/memory.sh session show

   — restore session state
2. Read

   tmp/glm-plan.md

   — restore current plan
3. Read the latest

   tmp/sN-synth-report.md

   ,

   tmp/stage-N-iter-K-synthesis.md

   , or

   tmp/stage-N-synthesis.md

   — restore verification/iteration/stage state

tmp/glm-plan.md

tmp/stage-N-synthesis.md

tmp/stage-N-iter-K-synthesis.md

## Compaction Handoff
- **Current objective:** [what this stage is doing]
- **User constraints:** [explicit instructions that must survive compaction]
- **Active plan / workflow:** [reference to plan artifact or current step]
- **Approval state:** [what's approved, what's pending, what was denied]
- **Key facts and decisions:** [exact values, resolved ambiguities, why choices were made]
- **Actions already taken:** [agents spawned, commands run, files changed]
- **Errors, blockers, attempted fixes:** [what failed and what was tried — do not retry same approach]
- **Pending tasks:** [remaining subtasks in this stage]
- **Next recommended step:** [single concrete action to resume with]
- **Do not redo:** [completed agents, failed approaches, skipped steps]

Session Continuation

1. Complete current stage fully
2. Write

   tmp/glm-continuation.md

   : original task, plan, completed stages, next stage, decisions, modified files, blockers

3. ./<skill-folder>/tools/memory.sh add context "GLM-CONTINUATION: [summary]" --tags glm-opencode,continuation

4. Tell user what's done and what continues

./<skill-folder>/tools/memory.sh search "GLM-CONTINUATION"

Error Handling

Rules

-r2

-r3

spawn-glm.sh

Task

subagent_type

subagent_type

.md

<skill-folder>/agents/

code-reviewer

ios-pro

swift-pro

spawn-glm.sh

.md

-a AGENT_NAME

assemble-prompt.sh

spawn-glm.sh

Task(subagent_type=...)

spawn-glm.sh

.md

<skill-folder>/templates/

opencode

pi

--pi

Skills (Workflows)

<skill-folder>/skills/

/skill-name