|
| 1 | +# CLAUDE.md: Instructions for Claude Code - Agent Roles |
| 2 | + |
| 3 | +## Purpose |
| 4 | +This directory contains agent role definitions for the Conductor-Score orchestration system. Each `.md` file defines a specific agent type (dev, devops, security, etc.) with responsibilities, skills, and workflows. Claude Code should use these definitions to understand agent capabilities and generate compatible extensions without disrupting the orchestration system. |
| 5 | + |
| 6 | +## Guidelines |
| 7 | +- **Do**: Always reference `_core.md` for the base agentic workflow (ReAct pattern) |
| 8 | +- **Do**: Inherit patterns from existing roles when creating new ones |
| 9 | +- **Do**: Respect the contracts defined in `../contracts.md` for inter-role communication |
| 10 | +- **Don't**: Modify original role files directly - create new files for custom roles |
| 11 | +- **Don't**: Break the hybrid model (generalist `dev` + specialists) without clear justification |
| 12 | +- **Don't**: Generate roles that bypass security or quality checks |
| 13 | + |
| 14 | +## Autonomous Decision Tree for Role Operations |
| 15 | + |
| 16 | +### When to Use Existing Roles vs. Create New Ones |
| 17 | + |
| 18 | +``` |
| 19 | +Task requires role assignment? |
| 20 | +├─ YES: Check required_skills in task |
| 21 | +│ ├─ Empty [] → Use 'dev' role (generalist) |
| 22 | +│ ├─ Contains ["frontend"] → Use 'frontend' role |
| 23 | +│ ├─ Contains ["devops"] → Use 'devops' role |
| 24 | +│ ├─ Contains ["security"] → Use 'security' role |
| 25 | +│ └─ Contains unknown skill → Check if partial match exists |
| 26 | +│ ├─ 70%+ match → Use closest role |
| 27 | +│ └─ <70% match → Create new role following patterns |
| 28 | +└─ NO: Default to 'dev' role |
| 29 | +``` |
| 30 | + |
| 31 | +### When to Create a New Role |
| 32 | + |
| 33 | +``` |
| 34 | +New skill requirement detected? |
| 35 | +├─ Check overlap with existing roles |
| 36 | +│ ├─ >50% overlap → Extend existing role instead |
| 37 | +│ └─ <50% overlap → Create new role |
| 38 | +├─ Validate need |
| 39 | +│ ├─ Used in 3+ tasks → Definitely create |
| 40 | +│ ├─ Used in 1-2 tasks → Consider if 'dev' can handle |
| 41 | +│ └─ Highly specialized → Create if clear domain boundary |
| 42 | +└─ Create following _core.md patterns |
| 43 | +``` |
| 44 | + |
| 45 | +## Step-by-Step Usage |
| 46 | + |
| 47 | +### 1. Observe - Understanding Existing Roles |
| 48 | +Automatically read and analyze: |
| 49 | +- **Structure**: Each role has sections for Overview, Responsibilities, Skills, Task Selection, etc. |
| 50 | +- **Patterns**: Notice how specialized roles build on the `_core.md` foundation |
| 51 | +- **Contracts**: Check `../contracts.md` for how roles interact |
| 52 | + |
| 53 | +### 2. Plan - Think Through Extensions |
| 54 | +Automated checks: |
| 55 | +- Gap analysis against current task requirements |
| 56 | +- Role overlap calculation |
| 57 | +- Contract compatibility verification |
| 58 | +- Boundary definition based on existing patterns |
| 59 | + |
| 60 | +### 3. Act - Generate Role Definitions |
| 61 | +When creating new roles: |
| 62 | +```markdown |
| 63 | +# custom-roles/[role-name].md |
| 64 | + |
| 65 | +# [Role Name] Agent |
| 66 | + |
| 67 | +## Overview |
| 68 | +[Clear purpose statement inheriting from _core.md patterns] |
| 69 | + |
| 70 | +## Core Responsibilities |
| 71 | +[Specific tasks this role handles that others don't] |
| 72 | + |
| 73 | +## Required Skills |
| 74 | +[Technical competencies needed] |
| 75 | + |
| 76 | +## Task Selection Criteria |
| 77 | +[How this agent decides which tasks to claim] |
| 78 | + |
| 79 | +## Workflow Patterns |
| 80 | +[Specific ReAct adaptations for this domain] |
| 81 | + |
| 82 | +## Quality Standards |
| 83 | +[Acceptance criteria specific to this role] |
| 84 | + |
| 85 | +## Collaboration Contracts |
| 86 | +[Reference to ../contracts.md entries or new contracts] |
| 87 | +``` |
| 88 | + |
| 89 | +### 4. Evaluate - Test Role Compatibility |
| 90 | +Verify new roles by: |
| 91 | +- Checking they don't duplicate existing capabilities |
| 92 | +- Ensuring they follow the ReAct pattern from `_core.md` |
| 93 | +- Validating contract interfaces if adding new interactions |
| 94 | +- Testing with sample task assignments |
| 95 | + |
| 96 | +## Examples |
| 97 | + |
| 98 | +### Example 1: Extending for a New Domain |
| 99 | +**Scenario**: Task requires database optimization skills not in existing roles |
| 100 | + |
| 101 | +**Autonomous approach**: |
| 102 | +```python |
| 103 | +# Decision logic |
| 104 | +if "database-optimization" in task.required_skills: |
| 105 | + existing_match = find_best_role_match("database-optimization") |
| 106 | + if existing_match.score < 0.7: |
| 107 | + # Auto-generate new role |
| 108 | + create_role_from_template("db-optimizer", { |
| 109 | + "base": "dev.md", |
| 110 | + "additions": ["query optimization", "indexing", "migrations"], |
| 111 | + "evaluation": ["query performance tests", "index usage analysis"] |
| 112 | + }) |
| 113 | +``` |
| 114 | + |
| 115 | +### Example 2: Creating Domain-Specific Variant |
| 116 | +**Prompt**: "Create a frontend-react specialist variant of frontend.md for React-specific projects" |
| 117 | + |
| 118 | +**Expected approach**: |
| 119 | +1. Read frontend.md for base UI/UX patterns |
| 120 | +2. Add React-specific skills (hooks, state management, component patterns) |
| 121 | +3. Include React-specific quality checks (prop-types, React Testing Library) |
| 122 | +4. Maintain compatibility with existing contracts |
| 123 | + |
| 124 | +### Example 3: Role for New Stack |
| 125 | +**Prompt**: "Generate a role for Rust backend development based on dev.md patterns" |
| 126 | + |
| 127 | +**Expected approach**: |
| 128 | +1. Inherit general development workflow from dev.md |
| 129 | +2. Add Rust-specific sections: |
| 130 | + - Memory safety considerations |
| 131 | + - Cargo-specific commands |
| 132 | + - Performance benchmarking steps |
| 133 | +3. Keep contract interfaces compatible |
| 134 | + |
| 135 | +## Warnings |
| 136 | +- **State Conflicts**: Never generate roles that directly modify `workflow-state.json` outside of proper task claiming |
| 137 | +- **Security**: Avoid roles that bypass code review or security scanning steps |
| 138 | +- **Isolation**: Ensure roles respect worktree isolation (one agent per worktree) |
| 139 | +- **Performance**: Consider token budget management (see _core.md section on this) |
| 140 | +- **Contracts**: Breaking existing contracts in `../contracts.md` will disrupt multi-agent collaboration |
| 141 | + |
| 142 | +## Best Practices |
| 143 | +1. **Modularity**: Create roles that do one thing well rather than everything poorly |
| 144 | +2. **Inheritance**: Always build on `_core.md` patterns rather than starting from scratch |
| 145 | +3. **Documentation**: Include clear examples in your generated roles |
| 146 | +4. **Testing**: Provide sample tasks that demonstrate when to use the new role |
| 147 | +5. **Compatibility**: Ensure new roles work with existing GitHub Actions workflows |
| 148 | + |
| 149 | +## References |
| 150 | +- `_core.md` - Base agentic workflow all roles must follow |
| 151 | +- `../contracts.md` - Inter-role communication contracts |
| 152 | +- `../config.yaml` - Project configuration including active roles |
| 153 | +- `dev.md` - Default generalist role (good starting template) |
| 154 | +- `code-reviewer.md` - Example of specialized automated role |
| 155 | + |
| 156 | +Last Updated: 2025-07-23 |
| 157 | +Version: 1.0 |
0 commit comments