📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -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
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user