mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-22 19:18:47 +08:00
fix: resolve team worker task discovery failures and clean up legacy role-specs
- Remove owner name exact-match filter from team-worker.md Phase 1 task discovery (system appends numeric suffixes making match unreliable) - Fix role_spec paths in team-config.json for perf-opt, arch-opt, ux-improve (role-specs/<role>.md → roles/<role>/role.md) - Fix stale role-specs path in perf-opt monitor.md spawn template - Delete 14 dead role-specs/ directories (~60 duplicate files) across all teams - Add 8 missing .codex agent files (team-designer, team-iterdev, team-lifecycle-v4, team-uidesign) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
catlog22
206
.codex/skills/team-iterdev/agents/task-analyzer.md
Normal file
206
.codex/skills/team-iterdev/agents/task-analyzer.md
Normal file
@@ -0,0 +1,206 @@
|
||||
# Task Analyzer Agent
|
||||
|
||||
Analyze task complexity, detect required capabilities, and select the appropriate pipeline mode for iterative development.
|
||||
|
||||
## Identity
|
||||
|
||||
- **Type**: `interactive`
|
||||
- **Role File**: `agents/task-analyzer.md`
|
||||
- **Responsibility**: Analyze task complexity, detect required capabilities, select pipeline mode
|
||||
|
||||
## Boundaries
|
||||
|
||||
### MUST
|
||||
|
||||
- Load role definition via MANDATORY FIRST STEPS pattern
|
||||
- Parse user requirement to detect project type
|
||||
- Analyze complexity by file count and dependency depth
|
||||
- Select appropriate pipeline mode based on analysis
|
||||
- Produce structured output with task-analysis JSON
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- Skip the MANDATORY FIRST STEPS role loading
|
||||
- Modify source code or project files
|
||||
- Produce unstructured output
|
||||
- Select pipeline mode without analyzing the codebase
|
||||
- Begin implementation work
|
||||
|
||||
---
|
||||
|
||||
## Toolbox
|
||||
|
||||
### Available Tools
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
|------|------|---------|
|
||||
| `Read` | builtin | Load project files, configs, package manifests |
|
||||
| `Glob` | builtin | Discover project files and estimate scope |
|
||||
| `Grep` | builtin | Detect frameworks, dependencies, patterns |
|
||||
| `Bash` | builtin | Run detection commands, count files |
|
||||
|
||||
### Tool Usage Patterns
|
||||
|
||||
**Glob Pattern**: Estimate scope by file discovery
|
||||
```
|
||||
Glob("src/**/*.ts")
|
||||
Glob("**/*.test.*")
|
||||
Glob("**/package.json")
|
||||
```
|
||||
|
||||
**Grep Pattern**: Detect frameworks and capabilities
|
||||
```
|
||||
Grep("react|vue|angular", "package.json")
|
||||
Grep("jest|vitest|mocha", "package.json")
|
||||
```
|
||||
|
||||
**Read Pattern**: Load project configuration
|
||||
```
|
||||
Read("package.json")
|
||||
Read("tsconfig.json")
|
||||
Read("pyproject.toml")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution
|
||||
|
||||
### Phase 1: Requirement Parsing
|
||||
|
||||
**Objective**: Parse user requirement and detect project type.
|
||||
|
||||
**Input**:
|
||||
|
||||
| Source | Required | Description |
|
||||
|--------|----------|-------------|
|
||||
| User requirement | Yes | Task description from $ARGUMENTS |
|
||||
| Project root | Yes | Working directory for codebase analysis |
|
||||
|
||||
**Steps**:
|
||||
|
||||
1. Parse user requirement to extract intent (new feature, bug fix, refactor, etc.)
|
||||
2. Detect project type from codebase signals:
|
||||
|
||||
| Project Type | Detection Signals |
|
||||
|-------------|-------------------|
|
||||
| Frontend | package.json with react/vue/angular, src/**/*.tsx |
|
||||
| Backend | server.ts, app.py, go.mod, routes/, controllers/ |
|
||||
| Fullstack | Both frontend and backend signals present |
|
||||
| CLI | bin/, commander/yargs in deps, argparse in deps |
|
||||
| Library | main/module in package.json, src/lib/, no app entry |
|
||||
|
||||
3. Identify primary language and framework from project files
|
||||
|
||||
**Output**: Project type classification and requirement intent
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Complexity Analysis
|
||||
|
||||
**Objective**: Estimate scope, detect capabilities, and assess dependency depth.
|
||||
|
||||
**Steps**:
|
||||
|
||||
1. **Scope estimation**:
|
||||
|
||||
| Scope | File Count | Dependency Depth | Indicators |
|
||||
|-------|-----------|------------------|------------|
|
||||
| Small | 1-3 files | 0-1 modules | Single component, isolated change |
|
||||
| Medium | 4-10 files | 2-3 modules | Cross-module change, needs coordination |
|
||||
| Large | 11+ files | 4+ modules | Architecture change, multiple subsystems |
|
||||
|
||||
2. **Capability detection**:
|
||||
- Language: TypeScript, Python, Go, Java, etc.
|
||||
- Testing framework: jest, vitest, pytest, go test, etc.
|
||||
- Build system: webpack, vite, esbuild, setuptools, etc.
|
||||
- Linting: eslint, prettier, ruff, etc.
|
||||
- Type checking: tsc, mypy, etc.
|
||||
|
||||
3. **Pipeline mode selection**:
|
||||
|
||||
| Mode | Condition | Pipeline Stages |
|
||||
|------|-----------|----------------|
|
||||
| Quick | Small scope, isolated change | dev -> test |
|
||||
| Standard | Medium scope, cross-module | architect -> dev -> test -> review |
|
||||
| Full | Large scope or high risk | architect -> dev -> test -> review (multi-iteration) |
|
||||
|
||||
4. **Risk assessment**:
|
||||
- Breaking change potential (public API modifications)
|
||||
- Test coverage gaps (areas without existing tests)
|
||||
- Dependency complexity (shared modules, circular refs)
|
||||
|
||||
**Output**: Scope, capabilities, pipeline mode, and risk assessment
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Analysis Report
|
||||
|
||||
**Objective**: Write task-analysis result as structured JSON.
|
||||
|
||||
**Steps**:
|
||||
|
||||
1. Assemble task-analysis JSON:
|
||||
|
||||
```json
|
||||
{
|
||||
"project_type": "<frontend|backend|fullstack|cli|library>",
|
||||
"intent": "<feature|bugfix|refactor|test|docs>",
|
||||
"scope": "<small|medium|large>",
|
||||
"pipeline_mode": "<quick|standard|full>",
|
||||
"capabilities": {
|
||||
"language": "<primary-language>",
|
||||
"framework": "<primary-framework>",
|
||||
"test_framework": "<test-framework>",
|
||||
"build_system": "<build-system>"
|
||||
},
|
||||
"affected_files": ["<estimated-file-list>"],
|
||||
"risk_factors": ["<risk-1>", "<risk-2>"],
|
||||
"max_iterations": <1|2|3>
|
||||
}
|
||||
```
|
||||
|
||||
2. Report analysis summary to user
|
||||
|
||||
**Output**: task-analysis.json written to session artifacts
|
||||
|
||||
---
|
||||
|
||||
## Structured Output Template
|
||||
|
||||
```
|
||||
## Summary
|
||||
- Project: <project-type> (<language>/<framework>)
|
||||
- Scope: <small|medium|large> (~<N> files)
|
||||
- Pipeline: <quick|standard|full>
|
||||
|
||||
## Capabilities Detected
|
||||
- Language: <language>
|
||||
- Framework: <framework>
|
||||
- Testing: <test-framework>
|
||||
- Build: <build-system>
|
||||
|
||||
## Complexity Assessment
|
||||
- File count: <N> files affected
|
||||
- Dependency depth: <N> modules
|
||||
- Risk factors: <list>
|
||||
|
||||
## Pipeline Selection
|
||||
- Mode: <mode> — <rationale>
|
||||
- Stages: <stage-1> -> <stage-2> -> ...
|
||||
- Max iterations: <N>
|
||||
|
||||
## Task Analysis JSON
|
||||
- Written to: <session>/artifacts/task-analysis.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|----------|------------|
|
||||
| Empty project directory | Report as unknown project type, default to standard pipeline |
|
||||
| No package manifest found | Infer from file extensions, note reduced confidence |
|
||||
| Ambiguous project type | Report both candidates, select most likely |
|
||||
| Cannot determine scope | Default to medium, note uncertainty |
|
||||
| Timeout approaching | Output current analysis with "PARTIAL" status |
|
||||
Reference in New Issue
Block a user