@winspan/claude-forge 9.2.0 → 9.12.0

package/dist/skills/distilled/distilled-brand-guidelines.md

@@ -0,0 +1,86 @@
+---
+name: distilled-brand-guidelines
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: brand-guidelines (score 3/5)'
+keywords:
+  - brand
+  - guidelines
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - brand-guidelines/SKILL.md
+distilled_at: '2026-06-15T01:02:32.005Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3
+it_universal_dims:
+  d1: 0.5
+  d2: 0.5
+  d3: 1
+  d4: 0.5
+  d5: 0.5
+it_universal_rationale: >-
+  Color tokens and type-scale rules are language/tool-agnostic; only the original python-pptx
+  implementation detail is language-specific and was stripped in distillation.
+---
+
+# Anthropic Brand Guidelines — Visual Reference
+
+## When to use
+- You need to produce any visual artifact (slides, reports, web pages, diagrams, data-viz) that should match Anthropic's official look-and-feel.
+- A user asks for brand colors, corporate color palette, or Anthropic typography.
+- You are post-processing or styling an existing artifact to bring it on-brand.
+- You are picking accent colors for charts, icons, or decorative shapes in an Anthropic context.
+
+## Core idea
+
+Anthropic's visual identity revolves around a warm neutral base (near-black / off-white / grays) with three accent colors (orange, blue, green) that cycle through non-text shapes. Typography is split into two roles: **Poppins** (or Arial fallback) for headings, **Lora** (or Georgia fallback) for body. The key principle is to keep backgrounds and text in the neutral palette and reserve accents for interactive or decorative elements, maintaining legibility at all times.
+
+## Color Tokens
+
+### Neutral Base
+
+| Role | Hex | Usage |
+|---|---|---|
+| Dark | `#141413` | Primary text; dark backgrounds |
+| Light | `#faf9f5` | Light backgrounds; text on dark |
+| Mid Gray | `#b0aea5` | Secondary / supporting elements |
+| Light Gray | `#e8e6dc` | Subtle background tints, dividers |
+
+### Accent Palette (cycle in order)
+
+| Name | Hex | Role |
+|---|---|---|
+| Orange | `#d97757` | Primary accent (CTA, highlights) |
+| Blue | `#6a9bcc` | Secondary accent |
+| Green | `#788c5d` | Tertiary accent |
+
+## Typography
+
+| Text Role | Font | Fallback |
+|---|---|---|
+| Headings (large / ≥ 24 pt) | Poppins | Arial |
+| Body text | Lora | Georgia |
+
+> Fonts should be pre-installed in the target environment for best results. The fallbacks (Arial / Georgia) are safe on all platforms.
+
+## Steps
+
+1. **Establish the background** — choose `#faf9f5` (light) or `#141413` (dark) as the canvas; avoid mixing both on the same surface.
+2. **Apply text colors** — use Dark `#141413` on light backgrounds, Light `#faf9f5` on dark backgrounds; use Mid Gray `#b0aea5` for secondary/caption text.
+3. **Assign fonts** — headings at ≥ 24 pt → Poppins/Arial; all body copy → Lora/Georgia.
+4. **Color decorative shapes** — cycle accent colors: first shape orange `#d97757`, second blue `#6a9bcc`, third green `#788c5d`, then repeat. Do not apply accents to large background areas.
+5. **Validate contrast** — confirm text-on-background meets WCAG AA (≥ 4.5:1 for body, ≥ 3:1 for large text). The defined neutral pairs all pass at normal usage sizes.
+6. **Trim non-brand colors** — remove any bright reds, purples, or generic blues that are not in the palette above.
+
+## Anti-patterns
+- **Using accents as backgrounds** — large orange/blue/green fills look off-brand; keep them to shapes, icons, and callout borders.
+- **Mixing font stacks arbitrarily** — using Poppins for body or Lora for headings breaks the typographic hierarchy.
+- **Pure black / pure white** — `#000000` / `#ffffff` are not in the palette; use `#141413` / `#faf9f5` instead.
+- **Skipping fallbacks** — always specify Arial after Poppins and Georgia after Lora so artifacts render correctly on systems without the custom fonts.
+- **More than three accent colors on a single page** — cycling works, but introducing additional off-palette colors dilutes the brand identity.
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-canvas-design.md

@@ -0,0 +1,128 @@
+---
+name: distilled-canvas-design
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: canvas-design (score 3.5/5)'
+keywords:
+  - canvas
+  - design
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - canvas-design/SKILL.md
+distilled_at: '2026-06-15T01:03:48.379Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3.5
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral visual design methodology (two-phase philosophy→canvas) transferable to any
+  creative/design output workflow regardless of toolchain or codebase
+---
+
+# Two-Phase Visual Design: Philosophy-First Canvas Creation
+
+## When to use
+- When asked to create a poster, piece of art, visual identity, or any static visual artifact
+- When the goal is expressive/artistic output (PNG, PDF, or similar) rather than functional UI
+- When an AI agent or designer needs a structured framework to avoid "decorated document" pitfalls
+- When quality bar is museum/magazine-grade, not clipart/template-grade
+
+## Core idea
+
+Great visual output requires separating the *thinking* phase from the *making* phase. First, articulate a named aesthetic movement (design philosophy) in 4–6 paragraphs covering space, color, material, rhythm, and composition. Only then execute the canvas, treating the philosophy as a scientific bible. Text on the canvas must be treated as a rare visual element—never explanatory paragraphs, only essential words integrated into the architecture. Expert craftsmanship is the non-negotiable standard: every alignment, color choice, and spacing decision should feel like it was labored over by someone at the top of their field.
+
+## Steps
+
+### Phase 1 — Design Philosophy Creation (output: `.md`)
+
+1. **Name the movement** (1–2 words): e.g., "Brutalist Joy", "Chromatic Silence", "Metabolist Dreams"
+
+2. **Write the philosophy** (4–6 paragraphs), covering each dimension exactly once:
+   - *Space and form*: How does the aesthetic treat negative space, volume, structure?
+   - *Color and material*: What palette logic or material sensibility governs the work?
+   - *Scale and rhythm*: How do elements grow, repeat, pulse, or breathe?
+   - *Composition and balance*: What governs arrangement—grid, organic, axial?
+   - *Visual hierarchy*: How does the eye move? What dominates, what recedes?
+
+3. **Repeat the craftsmanship imperative** multiple times within the philosophy:
+   > "meticulously crafted", "painstaking attention", "the product of deep expertise", "countless hours"
+
+4. **Keep it generic** (no mention of the specific output subject)—the philosophy should feel like it could apply to any artifact in that aesthetic tradition.
+
+5. **Leave interpretive room**: be specific about *direction*, not prescriptive about *every element*.
+
+### Phase 2 — Deduce the Subtle Reference
+
+Before drawing, identify the conceptual thread from the request:
+- This is the **soul** of the piece—the quiet DNA woven into composition, color, and form
+- It should be recognizable to those who know, invisible to those who don't
+- Think: *jazz musician quoting another song*—only insiders catch it, everyone else just hears great music
+
+### Phase 3 — Canvas Execution (output: `.pdf` or `.png`)
+
+6. **Ratio**: ~90% visual / 10% text (essential words only, never explanatory blocks)
+
+7. **Visual language of systematic observation**:
+   - Dense accumulation of marks, repeated elements, layered patterns
+   - Sparse clinical typography + systematic reference markers
+   - Treat the subject as if it were being documented by an imaginary discipline
+
+8. **Typography rules**:
+   - Use diverse, design-forward fonts (thin weight preferred)
+   - Type is *part of the art*, not typeset copy
+   - Nothing overlaps, nothing falls off canvas; every element has breathing room
+
+9. **Color**: Limited palette, intentional and cohesive; anchor with 1–2 subtle phrases or detail markers
+
+10. **Single page default** (unless multi-page is explicitly requested); treat it as one page of a coffee-table book
+
+### Phase 4 — Refinement Pass
+
+11. **Do not add more elements**; instead *refine* what exists:
+    - Make spacing more precise
+    - Make colors more cohesive
+    - Make composition more internally consistent with the philosophy
+    - Ask: *"How do I make what's already here more of a piece of art?"* before adding anything new
+
+12. **Final checklist**:
+    - All elements inside canvas boundaries with proper margins
+    - No overlaps anywhere
+    - Typography flawless
+    - Composition coherent with the stated philosophy
+
+### Multi-page Option (when requested)
+
+13. Bundle additional pages in the same PDF (or multiple PNGs)
+14. Each page: unique twist on the philosophy, not a repeat—like chapters in a visual story
+15. Pages should feel connected yet individually distinct
+
+## Anti-patterns
+
+- **Decorated document trap**: Adding text blocks with design "decoration" around them is not visual art—information must live in design, not paragraphs
+- **Literal interpretation**: The subtle reference should be *felt*, not *announced*; avoid illustrating the subject literally
+- **Adding to fix**: Refinement means subtraction and precision, not accumulation of new elements
+- **Font monotony**: One font throughout kills design sophistication; vary with intention
+- **Redundant philosophy**: Each design dimension (color, space, etc.) should appear once in the philosophy—repetition dilutes authority
+- **Amateur energy**: Cartoony shapes, clip-art icons, gradient noise—none of these belong; everything must justify its presence
+
+## Philosophy Examples (condensed)
+
+| Name | Core Visual Language |
+|---|---|
+| "Concrete Poetry" | Massive color blocks, sculptural typography, Brutalist spatial divisions, Polish poster meets Le Corbusier |
+| "Chromatic Language" | Color as information system; geometric precision; Josef Albers meets data viz; words only to anchor what color already shows |
+| "Analog Meditation" | Paper grain, ink bleeds, vast negative space; Japanese photobook aesthetic; text whispered in small restrained type |
+| "Organic Systems" | Rounded forms, natural clustering, color from nature through architecture; info through spatial diagrams, not text |
+| "Geometric Silence" | Grid-based precision, bold photography, dramatic negative space; Swiss formalism meets Brutalist material honesty |
+
+*Full philosophies are 4–6 substantial paragraphs each.*
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-claude-api.md

@@ -0,0 +1,185 @@
+---
+name: distilled-claude-api
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: claude-api (score 4/5)'
+keywords:
+  - claude
+  - api
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - claude-api/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-connector-builder/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - x-api/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-connector-builder/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - x-api/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-connector-builder/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - x-api/SKILL.md
+distilled_at: '2026-06-15T01:04:51.971Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 1
+  d5: 1
+it_universal_rationale: >-
+  Multi-language surface-selection methodology and agent-viability criteria are fully portable to
+  any codebase integrating the Anthropic Claude API, regardless of language, framework, or project
+  structure.
+---
+
+# Building Applications with the Anthropic Claude API
+
+## When to use
+- You are adding or modifying Claude/Anthropic SDK integration in any project
+- You need to choose between single API calls, tool-use workflows, or Managed Agents
+- You are migrating Claude model versions or tuning caching / streaming / thinking settings
+- You have questions about prompt caching, batch processing, tool use, or streaming in an Anthropic SDK project
+
+## Core idea
+
+All Claude API requests go through a single endpoint (`POST /v1/messages`). Tool use, output constraints, streaming, and caching are all features of this one endpoint — not separate APIs. The main architectural decision is **which surface** to use: a plain API call, a code-orchestrated tool-use workflow, or Anthropic-managed stateful agents (Managed Agents). Default to the simplest tier that meets your needs; only escalate to agents when the task genuinely requires open-ended, model-driven exploration. Always use the official Anthropic SDK for your language — never mix raw HTTP calls into an SDK project, and never fall back to OpenAI-compatible shims.
+
+## Steps
+
+### 1. Detect the project language
+
+Match project files to the correct SDK:
+
+| Signals | Language / SDK |
+|---|---|
+| `*.py`, `pyproject.toml`, `requirements.txt` | Python (`anthropic`) |
+| `*.ts`, `*.tsx`, `package.json`, `tsconfig.json` | TypeScript (`@anthropic-ai/sdk`) |
+| `*.js`/`*.jsx` with no `.ts` files | TypeScript SDK (JS-compatible) |
+| `*.java`, `pom.xml`, `build.gradle` | Java (`com.anthropic.*`) |
+| `*.kt`, `*.scala`, `build.sbt` | Java SDK (Kotlin/Scala-compatible) |
+| `*.go`, `go.mod` | Go (`github.com/anthropics/anthropic-sdk-go`) |
+| `*.rb`, `Gemfile` | Ruby |
+| `*.cs`, `*.csproj` | C# |
+| `*.php`, `composer.json` | PHP |
+| Shell scripts, explicit cURL request | Raw HTTP only |
+
+If multiple languages are detected, ask which one the Claude integration lives in. If no language is inferable, ask before writing code.
+
+### 2. Choose the right surface
+
+```
+0. Deploying via Amazon Bedrock, Google Vertex AI, or Microsoft Foundry?
+   └── Yes → Claude API + tool use for all tiers (Managed Agents is 1P-only)
+   No → continue
+
+1. Single task (classify, summarize, extract, Q&A, batch)?
+   └── Claude API — one request, one response
+
+2. Want Anthropic to run the agent loop AND host a per-session
+   container (bash, file ops, code execution)?
+   └── Managed Agents — persisted agent configs, SSE stream,
+       Skills + MCP, file mounts, per-session workspaces
+
+3. Multi-step pipeline with code-controlled logic, your own tools?
+   └── Claude API + tool use — you orchestrate the loop
+
+4. Open-ended agent, your own tools, you host the compute?
+   └── Claude API agentic loop
+```
+
+### 3. Gate on agent viability (before choosing the agent tier)
+
+Check all four criteria. If **any** answer is "no", stay at a simpler tier:
+
+- **Complexity** — Is the task multi-step and hard to fully specify upfront?
+- **Value** — Does the outcome justify higher cost and latency?
+- **Viability** — Is Claude reliably capable at this task type?
+- **Cost of error** — Can errors be caught and recovered from? (tests, review, rollback)
+
+### 4. Apply code defaults
+
+Unless the user explicitly requests otherwise:
+
+| Setting | Default |
+|---|---|
+| Model | `claude-opus-4-7` |
+| Thinking | `thinking: { type: "adaptive" }` for anything non-trivial |
+| Streaming | Enable for long input, long output, or high `max_tokens` |
+| Streaming helper | `.get_final_message()` / `.finalMessage()` to get complete response |
+| Prompt caching | Always include — reduces cost on repeated large contexts |
+
+### 5. Verify SDK usage before writing code
+
+- Function names, class names, method signatures, and import paths **must** come from official documentation or the SDK repository — never infer from another language's SDK or from cURL shapes.
+- If a binding is not documented in the reference you have at hand, fetch the official SDK repository or API docs before writing code.
+- Never reach for raw HTTP (`requests`, `fetch`, `httpx`) in a project that has an official SDK.
+- Check for non-Anthropic provider markers (`import openai`, `langchain_openai`, `gpt-4`, `*-openai.py`) before editing any file — do not inject Anthropic SDK calls into a file written for another provider.
+
+### 6. Managed Agents: create once, reference by ID
+
+- Call `agents.create` once at setup time; store the returned agent ID.
+- Every subsequent `sessions.create` references that ID — do **not** call `agents.create` in the request path.
+- Agents are persistent versioned objects; sessions pin to a specific version.
+
+## Anti-patterns
+
+- **Mixing raw HTTP with SDK** — pick one and stick to it per project
+- **Inferring SDK API shapes** from cURL examples or from a different language's SDK
+- **Calling `agents.create` per request** — agents are persistent; create once, reuse by ID
+- **Skipping streaming** for requests with large inputs or high `max_tokens` — risks timeouts
+- **Omitting prompt caching** — it should be the default, not an afterthought
+- **Reaching for the agent tier reflexively** — single API calls and code-orchestrated workflows handle most real use cases; agents add cost and complexity
+- **Using Managed Agents on third-party providers** (Bedrock/Vertex/Foundry) — they are Anthropic 1P only; use Claude API + tool use instead
+
+## References
+
+- Upstream: https://github.com/anthropics/skills.git
+- Anthropic API docs: https://docs.anthropic.com
+- Python SDK: https://github.com/anthropics/anthropic-sdk-python
+- TypeScript SDK: https://github.com/anthropics/anthropic-sdk-typescript
+- Go SDK: https://github.com/anthropics/anthropic-sdk-go

package/dist/skills/distilled/distilled-creator.md

@@ -3,8 +3,11 @@ name: distilled-creator
 version: 0.2.0-distilled
 description: 'Distilled IT-universal skill: skill-creator (score 3.5/5)'
 keywords:
-  - creator
-  - skill
+  - skill creation
+  - create skill
+  - 创建技能
+  - skill development
+  - distill skill
 rubric_version: 2
 distilled_from:
   - upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-dispatching-parallel-agents.md

@@ -0,0 +1,136 @@
+---
+name: distilled-dispatching-parallel-agents
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: dispatching-parallel-agents (score 3.5/5)'
+keywords:
+  - dispatching
+  - parallel
+  - agents
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - dispatching-parallel-agents/SKILL.md
+distilled_at: '2026-06-15T00:49:21.259Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3.5
+it_universal_dims:
+  d1: 0.5
+  d2: 0.5
+  d3: 0.5
+  d4: 1
+  d5: 1
+it_universal_rationale: >-
+  Four-step parallel dispatch pattern (identify → task → dispatch → integrate) applies to any
+  codebase and any agent framework; examples are illustrative, not framework-locked
+---
+
+# Dispatching Parallel Agents for Independent Problems
+
+## When to use
+
+- Two or more failures / tasks span **different problem domains** with no shared state
+- Each sub-problem can be understood without context from the others
+- Agents would not edit the same files or race on the same resources
+- You want wall-clock time equal to the slowest agent, not the sum of all agents
+
+**Do NOT use when:**
+- Failures are related — fixing one might fix others (investigate together first)
+- You are still in exploratory mode and don't yet know what's broken
+- Agents would interfere (editing the same file, locking the same resource)
+- All failures share a single root cause
+
+## Core idea
+
+When multiple independent problems exist simultaneously, serialising their
+investigation wastes time proportional to `N - 1` agent turns. The insight is
+simple: **dispatch one agent per independent problem domain and let them run
+concurrently**. Each agent gets a narrow scope, isolated context, and a concrete
+deliverable. The orchestrator's job is to identify the domain boundaries, craft
+tight prompts, and integrate results — not to investigate itself.
+
+Good parallel dispatch rests on three guarantees: agents receive *exactly* the
+context they need (no more, no less), their scopes do not overlap, and the
+orchestrator verifies integration after all agents return.
+
+## Steps
+
+1. **Identify independent domains**
+   Group the work by what is broken or needs doing. Ask: "Could I hand these
+   to two different engineers who never talk to each other?" If yes, they are
+   independent domains.
+
+2. **Write a focused prompt per agent**
+   Each prompt must contain:
+   - **Scope**: one clearly bounded area (one test file, one subsystem, one bug)
+   - **Goal**: what "done" looks like (tests pass / feature works / analysis returned)
+   - **Constraints**: what NOT to touch ("do not change unrelated code")
+   - **Expected output**: what the agent should return ("summary of root cause and changes made")
+
+   Template:
+   ```
+   Fix the N failing cases in <file or subsystem>:
+
+   1. "<test/case name>" — <symptom observed>
+   2. "<test/case name>" — <symptom observed>
+
+   Your task:
+   1. Read <relevant file(s)> and understand what each case verifies
+   2. Identify the root cause
+   3. Fix it — do NOT just increase timeouts or skip assertions
+
+   Constraints: do not touch <out-of-scope areas>.
+
+   Return: brief summary of root cause + list of changes made.
+   ```
+
+3. **Dispatch all agents in a single message** (parallel, not sequential)
+   Emit all `Task` / agent-spawn calls at once. Do not wait for one to finish
+   before dispatching the next — that defeats the purpose.
+
+4. **Review and integrate**
+   When all agents return:
+   - Read each summary; verify scope was respected
+   - Check for conflicts (did two agents edit the same file?)
+   - Run the full test suite / verification step
+   - Spot-check agent reasoning — agents can make systematic errors
+
+## Anti-patterns
+
+- **Too broad a scope per agent**: "Fix all the broken tests" → agent gets lost
+  and thrashes. Give each agent one file or one subsystem.
+- **Missing context in prompt**: "Fix the race condition" with no details →
+  agent hallucinates the problem. Paste actual error messages and failing case
+  names.
+- **No output constraint**: agent may refactor production code unasked.
+  Add "do NOT change X" explicitly.
+- **Vague deliverable**: "Fix it" → you cannot tell what changed or whether it
+  is correct. Ask for a structured summary.
+- **Dispatching sequentially**: spawning agent 2 only after agent 1 returns
+  eliminates the parallelism benefit. Batch all dispatches in one message.
+- **Dispatching when domains overlap**: if agents share mutable state (same
+  file, same DB, same resource), they will conflict silently. Serialise those.
+
+## Example domain split
+
+| Agent | Scope | Why independent |
+|---|---|---|
+| Agent 1 | Abort/interrupt logic tests | Abort flow has no overlap with batch scheduling |
+| Agent 2 | Batch completion behavior tests | Batch scheduling unrelated to race-condition guards |
+| Agent 3 | Approval race-condition tests | Race guard is a thin wrapper layer, isolated |
+
+Each agent investigates in parallel → wall-clock cost = max(agent times), not sum.
+
+## Verification checklist
+
+After all agents return:
+- [ ] Each agent's changes are within its declared scope
+- [ ] No two agents edited the same file/function
+- [ ] Full suite (or end-to-end check) is green
+- [ ] Any systematic misunderstanding caught and corrected before merge
+
+## References
+
+- Upstream: https://github.com/obra/superpowers.git