csh/playbook
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📦 deps(thirdparty): update snapshots

Browse Source
This commit is contained in:
ci[bot]
2026-05-29 08:33:53 +00:00
parent fdb52f1e96
commit 06e0d13d57
1615 changed files with 232858 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
outfitter-agents/plugins/outfitter/skills/subagents/SKILL.md
+347
View File
@@ -0,0 +1,347 @@
---
name: subagents
description: This skill should be used when coordinating agents, delegating tasks to specialists, or when "dispatch agents", "which agent", or "multi-agent" are mentioned.
metadata:
version: "2.2.0"
related-skills:
- context-management
- pathfinding
---
# Subagent Coordination
Orchestrate outfitter subagents by matching tasks to the right agent + skill combinations.
## Orchestration Planning
For complex multi-agent tasks, **start with the Plan subagent** to research and design the orchestration strategy before execution.
```
Complex task arrives
│
├─► Plan subagent (research stage)
│ └─► Explore codebase, gather context
│ └─► Identify which agents and skills needed
│ └─► Design execution sequence (sequential, parallel, or hybrid)
│ └─► Return orchestration plan
│
└─► Execute plan (dispatch agents per plan)
```
**Plan subagent benefits**:
- Runs in isolated context — doesn't consume main conversation tokens
- Can read many files without bloating orchestrator context
- Returns concise plan for execution
**When to use Plan subagent**:
- Task touches multiple domains (auth + performance + testing)
- Unknown codebase area — needs exploration first
- Sequence of agents matters (dependencies between steps)
- High-stakes changes requiring careful coordination
## Context Management
For long-running orchestration, load the **context-management** skill. It teaches:
- Using Tasks as survivable state (persists across compaction)
- Delegating to subagents to preserve main context
- Pre-compaction checklists to capture progress
- Cross-session patterns for multi-day work
**Key principle**: Main conversation context is precious. Delegate exploration and research to subagents — only their summaries return, keeping main context lean.
## Roles and Agents
Coordination uses **roles** (what function is needed) mapped to **agents** (who fulfills it). This allows substitution when better-suited agents are available.
### Baselayer Agents
| Role | Agent | Purpose |
|------|-------|---------|
| coding | **engineer** | Build, implement, fix, refactor |
| reviewing | **reviewer** | Evaluate code, PRs, architecture, security |
| research | **analyst** | Investigate, research, explore |
| debugging | **debugger** | Diagnose issues, trace problems |
| testing | **tester** | Validate, prove, verify behavior |
| challenging | **skeptic** | Challenge complexity, question assumptions |
| specialist | **specialist** | Domain expertise (CI/CD, design, accessibility, etc.) |
| patterns | **analyst** | Extract reusable patterns from work |
### Other Available Agents
Additional agents may be available in your environment (user-defined, plugin-provided, or built-in). When dispatching:
1. Check available agents for best fit to the role
2. Prefer specialized agents over generalists when they match the task
3. Fall back to outfitter agents when no better option exists
Examples of role substitution:
- **coding** → `senior-engineer`, `developer`, `engineer`
- **reviewing** → `security-auditor`, `code-reviewer`, `reviewer`
- **research** → `research-engineer`, `docs-librarian`, `analyst`
- **specialist** → `cicd-expert`, `design-agent`, `accessibility-auditor`, `bun-expert`
## Task Routing
Route by role, then select the best available agent for that role:
```
User request arrives
│
├─► "build/implement/fix/refactor" ──► coding role
│
├─► "review/critique/audit" ──► reviewing role
│
├─► "investigate/research/explore" ──► research role
│
├─► "debug/diagnose/trace" ──► debugging role
│
├─► "test/validate/prove" ──► testing role
│
├─► "simplify/challenge/is this overkill" ──► challenging role
│
├─► "deploy/configure/CI/design/a11y" ──► specialist role
│
└─► "capture this workflow/make reusable" ──► patterns role
```
## Workflow Patterns
### Sequential Handoff
One agent completes, passes to next:
```
research (investigate) → coding (implement) → reviewing (verify) → testing (validate)
```
**Use when**: Clear stages, each requires different expertise.
### Parallel Execution
Multiple agents work simultaneously using `run_in_background: true`:
```
┌─► reviewing (code quality)
│
task ──┼─► research (impact analysis)
│
└─► testing (regression tests)
```
**Use when**: Independent concerns, time-sensitive, comprehensive coverage needed.
### Challenge Loop
Build → challenge → refine:
```
coding (propose) ←→ challenging (evaluate) → coding (refine)
```
**Use when**: Complex architecture, preventing over-engineering, high-stakes decisions.
### Investigation Chain
Narrow down, then fix:
```
research (scope) → debugging (root cause) → coding (fix) → testing (verify)
```
**Use when**: Bug reports, production issues, unclear symptoms.
## Role + Skill Combinations
### Coding Role
| Task | Skills |
|------|--------|
| New feature | software-craft, tdd |
| Bug fix | debugging → software-craft |
| Refactor | software-craft + simplify |
| API endpoint | hono-dev, software-craft |
| React component | react-dev, software-craft |
| AI feature | ai-sdk, software-craft |
### Reviewing Role
| Task | Skills |
|------|--------|
| PR review | code-review |
| Architecture review | architecture |
| Performance audit | performance |
| Security audit | security |
| Pre-merge check | code-review + scenarios |
### Research Role
| Task | Skills |
|------|--------|
| Codebase exploration | codebase-recon |
| Research question | research |
| Unclear requirements | pathfinding |
| Status report | status, report-findings |
### Testing Role
| Task | Skills |
|------|--------|
| Feature validation | scenarios |
| TDD implementation | tdd |
| Integration testing | scenarios |
## Advanced Execution Patterns
### Background Execution
Run agents asynchronously for parallel work:
```json
{
"description": "Security review",
"prompt": "Review auth module for vulnerabilities",
"subagent_type": "outfitter:reviewer",
"run_in_background": true
}
```
Retrieve results with `TaskOutput`:
```json
{
"task_id": "agent-abc123",
"block": true
}
```
### Chaining Subagents
Sequence agents for complex workflows — each agent's output informs the next:
```
research agent → "Found 3 auth patterns in use"
↓
coding agent → "Implementing refresh token flow using pattern A"
↓
reviewing agent → "Verified implementation, found 1 issue"
↓
coding agent → "Fixed issue, ready for merge"
```
Pass context explicitly between agents via prompt.
### Resumable Sessions
Continue long-running work across invocations:
```json
{
"description": "Continue security analysis",
"prompt": "Now examine session management",
"subagent_type": "outfitter:reviewer",
"resume": "agent-abc123"
}
```
Agent preserves full context from previous execution.
**Use cases**:
- Multi-stage research spanning topics
- Iterative refinement without re-explaining context
- Long debugging sessions with incremental discoveries
### Model Selection
Override model for specific needs:
```json
{
"subagent_type": "outfitter:analyst",
"model": "haiku" // Fast, cheap for exploration
}
```
- **haiku**: Fast exploration, simple queries
- **sonnet**: Balanced reasoning (default)
- **opus**: Complex analysis, nuanced judgment
## Coordination Rules
1. **Single owner**: One role owns each task stage
2. **Clear handoffs**: Explicit deliverables between agents
3. **Skill loading**: Agent loads only needed skills
4. **User prefs first**: Check `CLAUDE.md` before applying defaults
5. **Minimal agents**: Don't parallelize what can be sequential
## Decision Framework
When agents face implementation choices:
1. **Favor existing patterns** — Match what's already in the codebase
2. **Prefer simplicity** — Cleverness is a liability; simple is maintainable
3. **Optimize for maintainability** — Next developer (or agent) must understand it
4. **Consider backward compatibility** — Breaking changes require explicit approval
5. **Document trade-offs** — When choosing between options, record why
These principles apply across all roles. Agents should surface decisions to the orchestrator when trade-offs are significant.
## Communication Style
Orchestrators and agents should:
- **Report progress** at each major step (don't go silent)
- **Flag blockers immediately** — don't spin on unsolvable problems
- **Provide clear summaries** of delegated work (what was done, what remains)
- **Include file paths and line numbers** when referencing code
Progress format:
```
░░░░░░░░░░ [1/5] research: Exploring auth patterns
▓▓▓▓░░░░░░ [2/5] coding: Implementing refresh token flow
```
## When to Escalate
- **Blocked**: Agent can't proceed → route to research role
- **Conflicting findings**: Multiple agents disagree → surface to user
- **Scope creep**: Task expands beyond role's domain → re-route
- **Missing context**: Not enough info → research role with pathfinding skill
## Git Operations Policy
> **CRITICAL**: Subagents MUST NOT perform git operations (commit, push, branch creation) when running in parallel.
>
> Only the **orchestrator** handles git state. Subagents write code to the filesystem and report completion.
For detailed workflows and recovery procedures, see the **source-control** plugin:
- `source-control:multi-agent-vcs` — Full orchestrator-only workflow patterns
- `source-control:graphite-stacks` — Graphite-specific commands and recovery
## Anti-Patterns
- Running all agents on every task (wasteful)
- Skipping reviewing role for "small changes" (risk)
- Coding role debugging without debugging skills (inefficient)
- Parallel agents with dependencies (race conditions)
- Not challenging complex proposals (over-engineering)
- **Parallel agents with git permissions** (stack corruption)
## Quick Reference
**"I need to build X"** → coding role + TDD skills
**"Review this PR"** → reviewing role + code-review
**"Why is this broken?"** → debugging role + debugging
**"Is this approach overkill?"** → challenging role + simplify
**"Prove this works"** → testing role + scenarios
**"What's the codebase doing?"** → research role + codebase-recon
**"Deploy to production"** → specialist role + domain skills
**"Make this workflow reusable"** → patterns role + codify
outfitter-agents/plugins/outfitter/skills/subagents/references/agent-skills.md
+142
View File
@@ -0,0 +1,142 @@
# Agent-Skill Mappings
Detailed breakdown of which skills each agent can load and when. Agents are grouped by their coordination role.
## engineer (coding role)
**Identity**: Builder, implementer, fixer.
| Skill | Load When |
|-------|-----------|
| software-craft | Always (core methodology) |
| tdd | New features, bug fixes requiring tests |
| bun-dev | Bun runtime, package management |
| react-dev | React components, hooks, state |
| hono-dev | API routes, middleware, server |
| ai-sdk | AI features, streaming, tools |
**Typical combos**:
- **software-craft** + **tdd** (standard feature)
- **software-craft** + **react-dev** (frontend work)
- **software-craft** + **hono-dev** + **ai-sdk** (AI API endpoint)
## reviewer (reviewing role)
**Identity**: Evaluator, quality guardian.
| Skill | Load When |
|-------|-----------|
| code-review | PR reviews, code audits |
| performance | Performance concerns, optimization |
| architecture | Architecture decisions, structural changes |
| security | Security audits, auth review |
**Typical combos**:
- **code-review** (standard PR review)
- **code-review** + **architecture** (significant refactor)
- **code-review** + **performance** (performance-critical code)
- **code-review** + **security** (auth or sensitive code)
## analyst (research role)
**Identity**: Investigator, researcher.
| Skill | Load When |
|-------|-----------|
| codebase-recon | Understanding existing code |
| research | External research, comparisons |
| pathfinding | Unclear requirements, many unknowns |
| status | Project status, progress reports |
| report-findings | Structuring analysis output |
| patterns | Analyzing code patterns |
| codify | Extracting reusable workflows |
| session-analysis | Mining conversation for patterns |
**Typical combos**:
- **codebase-recon** + **report-findings** (codebase exploration)
- **research** (technology comparison)
- **pathfinding** (requirements clarification)
- **codify** + **session-analysis** (capture workflow from session)
- **patterns** (analyze codebase patterns)
## debugger (debugging role)
**Identity**: Problem solver, root cause finder.
| Skill | Load When |
|-------|-----------|
| debugging | Always (core methodology) |
| codebase-recon | Understanding surrounding code |
**Typical combos**:
- **debugging** (standard debugging)
- **debugging** + **codebase-recon** (unfamiliar codebase)
## tester (testing role)
**Identity**: Validator, proof provider.
| Skill | Load When |
|-------|-----------|
| scenarios | End-to-end validation, integration tests |
| tdd | TDD workflow, test-first approach |
**Typical combos**:
- **scenarios** (feature validation)
- **tdd** (TDD implementation)
## skeptic (challenging role)
**Identity**: Complexity challenger, assumption questioner.
| Skill | Load When |
|-------|-----------|
| simplify | Always (core methodology) |
**Typical combos**:
- **simplify** (challenge proposals)
## specialist (specialist role)
**Identity**: Domain expert, infrastructure handler.
| Skill | Load When |
|-------|-----------|
| (dynamic) | Based on task domain |
**Examples**:
- CI/CD configuration → loads relevant CI patterns
- Design review → loads design/UX patterns
- Accessibility audit → loads a11y patterns
- Deployment → loads infrastructure patterns
Specialist loads skills dynamically based on detected domain. Other specialist agents (e.g., `cicd-expert`, `design-agent`, `bun-expert`) may be preferred when available.
## Skill Categories
### Core Methodology
Always relevant for the agent's identity:
- engineer: software-craft
- debugger: debugging
- skeptic: simplify
### Domain-Specific
Load based on technology in use:
- bun-dev, react-dev, hono-dev, ai-sdk
### Process-Oriented
Load based on workflow stage:
- tdd, code-review, scenarios
### Analysis-Oriented
Load for investigation and research:
- codebase-recon, research, pathfinding
### Output-Oriented
Load for structuring deliverables:
- report-findings, status
outfitter-agents/plugins/outfitter/skills/subagents/references/workflows.md
+172
View File
@@ -0,0 +1,172 @@
# Coordination Workflows
Detailed patterns for multi-agent coordination. Workflows use **roles** — select the best available agent for each role.
## Feature Development Workflow
Full cycle from requirements to delivery:
```
1. research + pathfinding
└─► Clarify requirements, identify unknowns
2. challenging + simplify
└─► Challenge proposed approach before building
3. coding + tdd
└─► Implement with tests first
4. reviewing + code-review
└─► Verify quality, patterns, security
5. testing + scenarios
└─► Validate end-to-end behavior
6. patterns + codify (optional)
└─► Capture reusable patterns from the work
```
**Handoff artifacts**:
- research → coding: Requirements doc, decision log
- coding → reviewing: PR with tests passing
- reviewing → testing: Approval with caveats noted
- testing → done: Validation report
## Bug Investigation Workflow
From symptom to verified fix:
```
1. research + codebase-recon
└─► Locate relevant code, understand context
2. debugging + debugging
└─► Root cause analysis, hypothesis testing
3. coding + software-craft
└─► Implement fix with regression test
4. testing + scenarios
└─► Verify fix, confirm no regressions
```
**Key principle**: Don't jump to fixing before understanding.
## Architecture Decision Workflow
When making significant structural changes:
```
1. research + research
└─► Gather options, prior art, tradeoffs
2. challenging + simplify
└─► Challenge each option for over-engineering
3. reviewing + architecture
└─► Evaluate against project constraints
4. coding + software-craft
└─► Implement chosen approach
```
**Gate**: Don't proceed past challenging without addressing concerns.
## Code Review Workflow
Comprehensive review before merge:
```
Parallel:
├─► reviewing + code-review (correctness, style)
├─► reviewing + performance (if applicable)
└─► testing + scenarios (behavior validation)
Then:
└─► coding (address feedback)
```
**When to parallelize**: Large PRs, critical paths, time pressure.
## Exploration Workflow
Understanding unfamiliar territory:
```
1. research + codebase-recon
└─► Map structure, identify patterns
2. research + research
└─► Document findings, create reference
3. (optional) patterns + patterns
└─► Extract patterns for future use
```
**Output**: Knowledge artifact for future agents.
## Refactoring Workflow
Safe structural changes:
```
1. testing + scenarios
└─► Establish baseline behavior tests
2. challenging + simplify
└─► Validate refactor is worthwhile
3. coding + software-craft
└─► Execute refactor in small steps
4. testing + scenarios
└─► Verify behavior unchanged
```
**Key principle**: Tests before and after, challenging validates ROI.
## Incident Response Workflow
Production issues:
```
1. research + status
└─► Assess scope, communicate status
2. debugging + debugging
└─► Rapid root cause identification
3. coding + software-craft
└─► Hotfix implementation
4. reviewing + code-review (abbreviated)
└─► Quick sanity check
5. testing + scenarios
└─► Verify fix in staging
```
**Priority**: Speed over perfection, but never skip verification.
## Choosing a Workflow
| Situation | Workflow |
|-----------|----------|
| New feature request | Feature Development |
| Bug report | Bug Investigation |
| "Should we use X?" | Architecture Decision |
| PR ready for merge | Code Review |
| "How does this work?" | Exploration |
| Tech debt cleanup | Refactoring |
| Production is down | Incident Response |
## Workflow Customization
Workflows adapt based on:
- **Project stage**: Early = more analyst, late = more tester
- **Risk level**: High = mandatory skeptic + reviewer
- **Time pressure**: Can skip patterns role, abbreviate reviewer
- **Team context**: Solo = lighter review, team = full workflow
User preferences in `CLAUDE.md` override defaults.