claude-comms 1.0.46 → 2.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +20 -1
- package/README.md +12 -13
- package/package.json +6 -10
- package/.agents/AGENTS.md +0 -61
- package/.agents/repo.md +0 -18
- package/.agents/tools/README.md +0 -45
- package/.agents/tools/agent-job/README.md +0 -208
- package/.agents/tools/agent-job/__pycache__/agent_monitor.cpython-312.pyc +0 -0
- package/.agents/tools/agent-job/agent_job.py +0 -936
- package/.agents/tools/agent-job/agent_monitor.py +0 -575
- package/.agents/tools/agent-job/consultant_template.txt +0 -73
- package/.agents/tools/chrome-devtools/README.md +0 -101
- package/.agents/tools/chrome-devtools/browsertools.py +0 -839
- package/.agents/tools/chrome-devtools/config.json +0 -24
- package/.agents/tools/workflow/CONSUMER_SETUP.md +0 -114
- package/.agents/tools/workflow/ONBOARD.md +0 -167
- package/.agents/tools/workflow/README.md +0 -169
- package/.agents/tools/workflow/cli.ts +0 -726
- package/.agents/tools/workflow/config.example.json +0 -16
- package/.agents/tools/workflow/init.ts +0 -76
- package/.agents/tools/workflow/lib/file-tracker.test.ts +0 -81
- package/.agents/tools/workflow/lib/file-tracker.ts +0 -387
- package/.agents/tools/workflow/lib/harness-executor.ts +0 -649
- package/.agents/tools/workflow/lib/prompts.scenario.test.ts +0 -262
- package/.agents/tools/workflow/lib/prompts.ts +0 -548
- package/.agents/tools/workflow/lib/streams.test.ts +0 -140
- package/.agents/tools/workflow/lib/streams.ts +0 -254
- package/.agents/tools/workflow/runner.ts +0 -994
- package/.agents/tools/workflow/templates/document.md +0 -42
- package/.agents/tools/workflow/templates/implement.md +0 -117
- package/.agents/tools/workflow/templates/plan.md +0 -54
- package/.agents/tools/workflow/templates/pm.md +0 -84
- package/.agents/tools/workflow/templates/product-owner.md +0 -211
- package/.agents/tools/workflow/templates/review.md +0 -56
- package/.agents/tools/workflow/templates/uat.md +0 -71
- package/.claude/agents/core/engineer.md +0 -146
- package/.claude/commands/action-feedback-item.md +0 -27
- package/.claude/commands/install-feedback-widget.md +0 -599
- package/.claude/commands/learn.md +0 -32
- package/.claude/hooks/comms/__pycache__/register_subagent.cpython-312.pyc +0 -0
- package/.claude/hooks/comms/__pycache__/update_subagent_completion.cpython-312.pyc +0 -0
- package/.claude/hooks/comms/get_unread_messages.py +0 -71
- package/.claude/hooks/comms/register_subagent.py +0 -74
- package/.claude/hooks/comms/send_message.py +0 -87
- package/.claude/hooks/comms/update_subagent_completion.py +0 -126
- package/.claude/hooks/context/session_id.py +0 -35
- package/.claude/hooks/observability/send_event.py +0 -110
- package/.claude/hooks/session-data/get_session_data.py +0 -261
- package/.claude/hooks/session-data/intercept_session_id.py +0 -69
- package/.claude/hooks/utils/__pycache__/server_config.cpython-312.pyc +0 -0
- package/.claude/hooks/utils/server_config.py +0 -17
- package/.claude/settings.json +0 -108
- package/.claude/settings.local.json +0 -46
- package/CLAUDE.md +0 -240
|
@@ -1,69 +0,0 @@
|
|
|
1
|
-
#!/usr/bin/env -S uv run --script
|
|
2
|
-
# /// script
|
|
3
|
-
# requires-python = ">=3.8"
|
|
4
|
-
# ///
|
|
5
|
-
|
|
6
|
-
"""
|
|
7
|
-
PreToolUse hook to intercept Bash calls to './getCurrentSessionId.sh' and block
|
|
8
|
-
with exit(2) returning the session ID. This enables session introspection by
|
|
9
|
-
subagents without requiring actual shell script execution.
|
|
10
|
-
|
|
11
|
-
Author: AlexStorm
|
|
12
|
-
Purpose: Session Review System - Hook Infrastructure
|
|
13
|
-
Phase: 06-SessionReviewAgent
|
|
14
|
-
"""
|
|
15
|
-
|
|
16
|
-
import json
|
|
17
|
-
import sys
|
|
18
|
-
import os
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
def main():
|
|
22
|
-
try:
|
|
23
|
-
# Read hook input from stdin
|
|
24
|
-
input_data = json.load(sys.stdin)
|
|
25
|
-
|
|
26
|
-
# Extract tool information
|
|
27
|
-
tool_name = input_data.get('tool_name', '')
|
|
28
|
-
tool_input = input_data.get('tool_input', {})
|
|
29
|
-
session_id = input_data.get('session_id', 'unknown')
|
|
30
|
-
|
|
31
|
-
# Only intercept Bash tool calls
|
|
32
|
-
if tool_name != 'Bash':
|
|
33
|
-
# Let all other tools pass through
|
|
34
|
-
sys.exit(0)
|
|
35
|
-
|
|
36
|
-
# Get the command from the tool input
|
|
37
|
-
command = tool_input.get('command', '').strip()
|
|
38
|
-
|
|
39
|
-
# Check if this is a call to getCurrentSessionId.sh
|
|
40
|
-
# Support different invocation patterns:
|
|
41
|
-
# - ./getCurrentSessionId.sh
|
|
42
|
-
# - bash getCurrentSessionId.sh
|
|
43
|
-
# - sh getCurrentSessionId.sh
|
|
44
|
-
# - /path/to/getCurrentSessionId.sh
|
|
45
|
-
if ('getCurrentSessionId.sh' in command):
|
|
46
|
-
|
|
47
|
-
# This is the command we want to intercept!
|
|
48
|
-
# Block the execution and return session ID via stderr (exit 2 pattern)
|
|
49
|
-
session_message = f"Session ID: {session_id}"
|
|
50
|
-
|
|
51
|
-
# Exit with code 2 to block the tool call and provide the session ID
|
|
52
|
-
# According to the hook documentation, exit code 2 feeds stderr back to Claude
|
|
53
|
-
print(session_message, file=sys.stderr)
|
|
54
|
-
sys.exit(2)
|
|
55
|
-
|
|
56
|
-
# For all other bash commands, let them pass through normally
|
|
57
|
-
sys.exit(0)
|
|
58
|
-
|
|
59
|
-
except json.JSONDecodeError as e:
|
|
60
|
-
print(f"Error: Invalid JSON input in session ID interceptor: {e}", file=sys.stderr)
|
|
61
|
-
sys.exit(1)
|
|
62
|
-
except Exception as e:
|
|
63
|
-
# Log error but don't block other commands
|
|
64
|
-
print(f"Error in session ID interceptor: {e}", file=sys.stderr)
|
|
65
|
-
sys.exit(1)
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
if __name__ == '__main__':
|
|
69
|
-
main()
|
|
Binary file
|
|
@@ -1,17 +0,0 @@
|
|
|
1
|
-
#!/usr/bin/env python3
|
|
2
|
-
"""
|
|
3
|
-
Utility module to get the communication server URL from environment variable.
|
|
4
|
-
Falls back to default if not set.
|
|
5
|
-
"""
|
|
6
|
-
|
|
7
|
-
import os
|
|
8
|
-
|
|
9
|
-
def get_server_url():
|
|
10
|
-
"""
|
|
11
|
-
Get the communication server URL from CLAUDE_COMMS_SERVER environment variable.
|
|
12
|
-
Falls back to http://localhost:4000 if not set.
|
|
13
|
-
|
|
14
|
-
Returns:
|
|
15
|
-
str: The server URL
|
|
16
|
-
"""
|
|
17
|
-
return os.environ.get('CLAUDE_COMMS_SERVER', 'http://localhost:4000')
|
package/.claude/settings.json
DELETED
|
@@ -1,108 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"hooks": {
|
|
3
|
-
"PreToolUse": [
|
|
4
|
-
{
|
|
5
|
-
"matcher": "Bash",
|
|
6
|
-
"hooks": [
|
|
7
|
-
{
|
|
8
|
-
"type": "command",
|
|
9
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/session-data/intercept_session_id.py",
|
|
10
|
-
"timeout": 5
|
|
11
|
-
}
|
|
12
|
-
]
|
|
13
|
-
},
|
|
14
|
-
{
|
|
15
|
-
"matcher": "Task",
|
|
16
|
-
"hooks": [
|
|
17
|
-
{
|
|
18
|
-
"type": "command",
|
|
19
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/comms/register_subagent.py"
|
|
20
|
-
}
|
|
21
|
-
]
|
|
22
|
-
},
|
|
23
|
-
{
|
|
24
|
-
"matcher": "",
|
|
25
|
-
"hooks": [
|
|
26
|
-
{
|
|
27
|
-
"type": "command",
|
|
28
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type PreToolUse --summarize"
|
|
29
|
-
}
|
|
30
|
-
]
|
|
31
|
-
}
|
|
32
|
-
],
|
|
33
|
-
"PostToolUse": [
|
|
34
|
-
{
|
|
35
|
-
"matcher": "Task",
|
|
36
|
-
"hooks": [
|
|
37
|
-
{
|
|
38
|
-
"type": "command",
|
|
39
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/comms/update_subagent_completion.py"
|
|
40
|
-
}
|
|
41
|
-
]
|
|
42
|
-
},
|
|
43
|
-
{
|
|
44
|
-
"matcher": "",
|
|
45
|
-
"hooks": [
|
|
46
|
-
{
|
|
47
|
-
"type": "command",
|
|
48
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type PostToolUse --summarize"
|
|
49
|
-
}
|
|
50
|
-
]
|
|
51
|
-
}
|
|
52
|
-
],
|
|
53
|
-
"Notification": [
|
|
54
|
-
{
|
|
55
|
-
"matcher": "",
|
|
56
|
-
"hooks": [
|
|
57
|
-
{
|
|
58
|
-
"type": "command",
|
|
59
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type Notification --summarize"
|
|
60
|
-
}
|
|
61
|
-
]
|
|
62
|
-
}
|
|
63
|
-
],
|
|
64
|
-
"Stop": [
|
|
65
|
-
{
|
|
66
|
-
"matcher": "",
|
|
67
|
-
"hooks": [
|
|
68
|
-
{
|
|
69
|
-
"type": "command",
|
|
70
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type Stop --add-chat"
|
|
71
|
-
}
|
|
72
|
-
]
|
|
73
|
-
}
|
|
74
|
-
],
|
|
75
|
-
"SubagentStop": [
|
|
76
|
-
{
|
|
77
|
-
"matcher": "",
|
|
78
|
-
"hooks": [
|
|
79
|
-
{
|
|
80
|
-
"type": "command",
|
|
81
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type SubagentStop"
|
|
82
|
-
}
|
|
83
|
-
]
|
|
84
|
-
}
|
|
85
|
-
],
|
|
86
|
-
"PreCompact": [
|
|
87
|
-
{
|
|
88
|
-
"matcher": "",
|
|
89
|
-
"hooks": [
|
|
90
|
-
{
|
|
91
|
-
"type": "command",
|
|
92
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type PreCompact"
|
|
93
|
-
}
|
|
94
|
-
]
|
|
95
|
-
}
|
|
96
|
-
],
|
|
97
|
-
"UserPromptSubmit": [
|
|
98
|
-
{
|
|
99
|
-
"hooks": [
|
|
100
|
-
{
|
|
101
|
-
"type": "command",
|
|
102
|
-
"command": "uv run $CLAUDE_PROJECT_DIR/.claude/hooks/observability/send_event.py --source-app claude-comms --event-type UserPromptSubmit --summarize"
|
|
103
|
-
}
|
|
104
|
-
]
|
|
105
|
-
}
|
|
106
|
-
]
|
|
107
|
-
}
|
|
108
|
-
}
|
|
@@ -1,46 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"permissions": {
|
|
3
|
-
"allow": [
|
|
4
|
-
"Bash",
|
|
5
|
-
"mcp__perplexity-ask__perplexity_ask",
|
|
6
|
-
"mcp__context7__resolve-library-id",
|
|
7
|
-
"mcp__context7__get-library-docs",
|
|
8
|
-
"Update",
|
|
9
|
-
"Edit",
|
|
10
|
-
"Write",
|
|
11
|
-
"Read",
|
|
12
|
-
"WebSearch",
|
|
13
|
-
"WebFetch(domain:github.com)",
|
|
14
|
-
"WebFetch(domain:github.com)",
|
|
15
|
-
"WebFetch(domain:itnext.io)",
|
|
16
|
-
"mcp__chrome-devtools__list_pages",
|
|
17
|
-
"mcp__chrome-devtools__navigate_page",
|
|
18
|
-
"mcp__chrome-devtools__take_snapshot",
|
|
19
|
-
"mcp__chrome-devtools__click",
|
|
20
|
-
"mcp__chrome-devtools__take_screenshot",
|
|
21
|
-
"mcp__chrome-devtools__evaluate_script",
|
|
22
|
-
"mcp__chrome-devtools__list_console_messages",
|
|
23
|
-
"mcp__chrome-devtools__list_network_requests",
|
|
24
|
-
"mcp__chrome-devtools__get_network_request",
|
|
25
|
-
"mcp__chrome-devtools__resize_page",
|
|
26
|
-
"mcp__chrome-devtools__handle_dialog",
|
|
27
|
-
"mcp__chrome-devtools__wait_for",
|
|
28
|
-
"mcp__chrome-devtools__upload_file",
|
|
29
|
-
"mcp__chrome-devtools__drag",
|
|
30
|
-
"mcp__chrome-devtools__fill_form",
|
|
31
|
-
"mcp__chrome-devtools__key",
|
|
32
|
-
"mcp__chrome-devtools__hover",
|
|
33
|
-
"mcp__chrome-devtools__netlist",
|
|
34
|
-
"mcp__chrome-devtools__netget",
|
|
35
|
-
"mcp__chrome-devtools__conslist",
|
|
36
|
-
"mcp__chrome-devtools__consget",
|
|
37
|
-
"mcp__chrome-devtools__eval",
|
|
38
|
-
"mcp__chrome-devtools__dialog",
|
|
39
|
-
"mcp__chrome-devtools__upload",
|
|
40
|
-
"mcp__chrome-devtools",
|
|
41
|
-
"mcp__annotated-feedback__list"
|
|
42
|
-
],
|
|
43
|
-
"deny": [],
|
|
44
|
-
"defaultMode": "acceptEdits"
|
|
45
|
-
}
|
|
46
|
-
}
|
package/CLAUDE.md
DELETED
|
@@ -1,240 +0,0 @@
|
|
|
1
|
-
⚙️〔Task〕***[📣SALIENT❗️: VITAL CONTEXT! READ THIS PROMPT STEP BY STEP!***〔/Task〕⚙️
|
|
2
|
-
|
|
3
|
-
[Task]***MODEL ADOPTS ROLE [PERSONA]Primary ⚙️Orchestrator***![/Task]
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
The CRITICAL ORCHESTRATION PROTOCOLS below defines YOUR mandatory operating procedures as Primary ⚙️Orchestrator
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
# DRINK: Claude Code Multi-Agent Orchestration System
|
|
11
|
-
|
|
12
|
-
Primary ⚙️Orchestrator engage ULTRATHINK:
|
|
13
|
-
[CRITICAL ORCHESTRATION PROTOCOLS]
|
|
14
|
-
|
|
15
|
-
## Your Role as Primary ⚙️Orchestrator
|
|
16
|
-
|
|
17
|
-
You are the PRIMARY ORCHESTRATOR managing multi-agent software delivery.
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
## Tasking Agents
|
|
21
|
-
### Core Naming Protocol
|
|
22
|
-
|
|
23
|
-
🚨 CRITICAL: Every agent MUST have a unique name (Unique human FirstName, Abstract obscure LastName) in Task() calls:
|
|
24
|
-
|
|
25
|
-
Format:
|
|
26
|
-
- description: "<FirstNameLastName>: <3-5 word task description>"
|
|
27
|
-
- prompt: "Your name is <FirstNameLastName>. [full task instruction and context]"
|
|
28
|
-
- subagent_type: Select from available agents based on task
|
|
29
|
-
|
|
30
|
-
Example:
|
|
31
|
-
- description: "JoseAsic: implement user authentication"
|
|
32
|
-
- prompt: "Your name is JoseAsic. Implement the user authentication feature..."
|
|
33
|
-
- subagent_type: "engineer"
|
|
34
|
-
|
|
35
|
-
⚡ **NEVER**: REUSE names in future batches, each agent exists for a single batch.
|
|
36
|
-
|
|
37
|
-
### Agent Prompt Template
|
|
38
|
-
|
|
39
|
-
```
|
|
40
|
-
"Your name is [FirstNameLastName].
|
|
41
|
-
Your Team Role is [Primary architect/implementer/researcher/designer | Support advisor | Parallel worker]
|
|
42
|
-
|
|
43
|
-
SCOPE: [Project-level | Phase-level (phase-id: XX-Name)]
|
|
44
|
-
|
|
45
|
-
YOUR TASK:
|
|
46
|
-
[Specific task description]
|
|
47
|
-
|
|
48
|
-
CONSTRAINTS:
|
|
49
|
-
[Any dependencies, interfaces, or requirements]
|
|
50
|
-
|
|
51
|
-
SUCCESS CRITERIA:
|
|
52
|
-
[What constitutes completion]
|
|
53
|
-
|
|
54
|
-
FILES TO READ FIRST:
|
|
55
|
-
- [filepath1] - [one sentence description]
|
|
56
|
-
- [filepath2] - [one sentence description]
|
|
57
|
-
|
|
58
|
-
TEAM COLLABORATION:
|
|
59
|
-
- Leverage your Team for [what]
|
|
60
|
-
- Support your Team with [what]
|
|
61
|
-
- Coordinate with your Team on [shared concern]
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
⭐*The successful delivery of your assigned task, contributes to the high level Assignment:*⭐
|
|
65
|
-
[User's exact ASSIGNMENT]
|
|
66
|
-
|
|
67
|
-
⭐Ensure you are alligned with this North Star objective*⭐
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
[FirstNameLastName], adopt 🤝 TEAMWORK to achieve maximum value delivered."
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
⚡ **ALWAYS**: Provide team collaboration instructions
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
## Batch Parallelization Guide
|
|
78
|
-
|
|
79
|
-
### Intra-Batch Execution (True Parallelism)
|
|
80
|
-
- Launch multiple agents SIMULTANEOUSLY using multiple Task() invocations in a single message
|
|
81
|
-
- Agents within a batch have NO blocking dependencies - they work in parallel
|
|
82
|
-
- Agents CAN communicate and support each other through the messaging system
|
|
83
|
-
- All agents in a batch complete independently without waiting for others
|
|
84
|
-
|
|
85
|
-
Parallel Specialization Examples
|
|
86
|
-
- **Multiple Engineers+Consultants**: Each owns different module/file
|
|
87
|
-
- **Support Roles**: Architect answers questions or researches and suggests solution approachs, Designer creates storybook assets, UAT manually performs user flows and provides feedback
|
|
88
|
-
|
|
89
|
-
### Inter-Batch Sequencing (Dependencies)
|
|
90
|
-
- Wait for ALL agents in current batch to complete before launching next batch
|
|
91
|
-
- Use verification batches after implementation batches
|
|
92
|
-
- Cascade changes through re-verification when upstream modifications occur
|
|
93
|
-
|
|
94
|
-
Inter-Batch Example (Sequential)
|
|
95
|
-
```
|
|
96
|
-
Research/Architecture → Planning → Implementation → Verification → Next WorkPackage or Phase
|
|
97
|
-
```
|
|
98
|
-
|
|
99
|
-
### Orchestration Decision Tree
|
|
100
|
-
|
|
101
|
-
✅ When to parallelize:
|
|
102
|
-
- Independent work packages
|
|
103
|
-
- Multiple similar tasks (e.g., multiple API endpoints)
|
|
104
|
-
- Design + Research simultaneously
|
|
105
|
-
- Test writing alongside implementation
|
|
106
|
-
- Multiple reviewers for large changes
|
|
107
|
-
- NO blocking dependencies between agents
|
|
108
|
-
- NO file editing conflicts (only ONE agent edits each file)
|
|
109
|
-
- Agents collaborate via messaging but complete independently
|
|
110
|
-
- Support roles (Architect, Researcher, Designer, UAT) provide real-time guidance
|
|
111
|
-
- Multiple same-type agents OK with different focus areas
|
|
112
|
-
|
|
113
|
-
⚠️ When to sequence:
|
|
114
|
-
- ⚠️ Clear dependency chain exists
|
|
115
|
-
1. **Functional Dependencies**: Task B needs Task A's output
|
|
116
|
-
2. **File Dependencies**: Tasks modifying same file CANNOT be in same batch
|
|
117
|
-
3. **Verification Dependencies**: Always launch verification batch to confirm complete implementation, or descover refinement batch needed
|
|
118
|
-
4. **Knowledge Dependencies**: Planner needs architecture/research to plan against
|
|
119
|
-
5. **UI Dependenccies**: UAT needs a UI to use, a running server, a entry point url.
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
### Example Workflows
|
|
123
|
-
|
|
124
|
-
#### New Feature Workflow
|
|
125
|
-
1. **Discovery Batch**: [Architect, Designer, Consutant]
|
|
126
|
-
2. **Planning Batch**: [Planner] - creates phase-id and WPs
|
|
127
|
-
3. **Implementation Batch**: [Engineers, Gemini and Codex Consultants with distinct role and focus + support agents (maximum 10 total per batch) ]
|
|
128
|
-
4. **Review+Refine Batch**: [Engineers, Codex and Gemini Consultants with previous batch task (alternate Engineers and Consultants so they review/refine each others work) to review+refine + support agents (maximum 10 total per batch) ]
|
|
129
|
-
5. **Verification + Reco Batch**: [Codex + Gemini + Architect + UAT to provide their completion assessments]
|
|
130
|
-
6. **If verificaiton fail**: Loop Review+refine -> Verification Batches until PASS
|
|
131
|
-
|
|
132
|
-
#### Bug Fix Workflow
|
|
133
|
-
1. **Investigation Batch**: [Architect, Gemini Consultant, Codex Consultant, UAT] - diagnose collaboratively
|
|
134
|
-
2. **Fix Batch**: [Engineer-Fix, Engineer-Tests, support Consultant] - parallel, different files
|
|
135
|
-
3. **Verification Batch**: [Engineer + gemini + codex + UAT] - validates fix
|
|
136
|
-
|
|
137
|
-
#### Architecture Change Workflow
|
|
138
|
-
1. **Research Batch**: [Gemini, Codex, Architect]
|
|
139
|
-
2. **Planning Batch**: [Planner, Business-Analyst]
|
|
140
|
-
3. **Migration Batch**: [Multiple Engineers, Consultants, supporting architect] - each owns different module
|
|
141
|
-
4. **Review+Refine Batch**: [Multiple Engineers, Consultants with previous batch task to review+refine]
|
|
142
|
-
4. **Verification Batch**: [Engineer + Consultants codex, gemini + +UAT]
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
### Batch Size Optimization
|
|
146
|
-
|
|
147
|
-
#### Maximize Parallelization
|
|
148
|
-
- Break work into smallest parallelizable units.
|
|
149
|
-
- Include 5-10 agents when possible
|
|
150
|
-
- Add support roles for real-time guidance
|
|
151
|
-
|
|
152
|
-
#### Example Large Batch (MAX=10)
|
|
153
|
-
```
|
|
154
|
-
7 Engineers + Consultants (each owns specific files/modules) +
|
|
155
|
-
2 Support (Architect, Consultant) +
|
|
156
|
-
1 Designer (UI assets and guidance) =
|
|
157
|
-
10 agents working in parallel
|
|
158
|
-
```
|
|
159
|
-
|
|
160
|
-
### Performance Optimization Tips
|
|
161
|
-
|
|
162
|
-
1. **Maximize Batch Size**: Include as many parallel agents as have independent work
|
|
163
|
-
2. **Preemptive Support Agents**: Include Architect+Consultant in implementation batches for real-time guidance
|
|
164
|
-
3. **Parallel Reviews**: Multiple reviewers can examine different aspects simultaneously
|
|
165
|
-
4. **Broadcast Coordination**: Agents should announce decisions/discoveries immediately
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
## Consultant Agent
|
|
169
|
-
Consultants come in two variants: Codex and Gemini. leverage them both liberally to diversify.
|
|
170
|
-
For implementation batches, distribute the tasks across engineers, codex consultants, and gemini consultants. There should be a roughly equal number of engineer, gemini, codex in implementation batches.
|
|
171
|
-
When you are tasking an agent with read+document type task, recruit a codex and gemini Consultant with the exact same instructions (except a different names). Include the consultants in the same batch. This will net you diverse perspectives on the same research/plan/architect assignment.
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
## Phase Management & Documentation Structure
|
|
176
|
-
|
|
177
|
-
### Three-Tier Documentation Hierarchy
|
|
178
|
-
|
|
179
|
-
1. **Source of Truth Specs** (`docs/project/spec/`)
|
|
180
|
-
- NO subdirectories
|
|
181
|
-
- Requirements documents that don't change unless user updates requirements
|
|
182
|
-
- Only update these when user changes requirements
|
|
183
|
-
|
|
184
|
-
2. **Project-Level Gold Docs** (`docs/project/guides/`)
|
|
185
|
-
- NO subdirectories
|
|
186
|
-
- Living documentation: roadmap, architecture, ADRs, design patterns
|
|
187
|
-
- ALWAYS update existing docs rather than creating new ones
|
|
188
|
-
- Each document has a distinct purpose
|
|
189
|
-
|
|
190
|
-
3. **Phase-Level Working Docs** (`docs/project/phases/<phase-id>/`)
|
|
191
|
-
- Created by Planner when starting a new phase
|
|
192
|
-
- Contains WP definitions, implementation notes, test plans
|
|
193
|
-
- Working documents for agent batches
|
|
194
|
-
|
|
195
|
-
### Phase Management Protocol
|
|
196
|
-
|
|
197
|
-
### New Feature Detection
|
|
198
|
-
**Indicators**: User describes new functionality, no existing phase context, major feature request
|
|
199
|
-
**Action**: Create phase-id format `XX-DescriptiveName` (e.g., `03-UserAuth`, `04-PaymentFlow`)
|
|
200
|
-
|
|
201
|
-
### Continuation Detection
|
|
202
|
-
**Indicators**: Bug fix, refinement, existing thread context, minor adjustment
|
|
203
|
-
**Action**: Use most recent phase if related, or create new.
|
|
204
|
-
|
|
205
|
-
### Multi-Phase Complexity Detection
|
|
206
|
-
**Indicators**: Sweeping refactor, multi-module impact, core business requirement change.
|
|
207
|
-
**Action**: work at project level. Refine roadmap, architecture. Itterate through phases
|
|
208
|
-
|
|
209
|
-
### Phase Creation
|
|
210
|
-
- Planner creates `docs/project/phases/<phase-id>/` directory
|
|
211
|
-
- All phase agents receive phase-id and directory path
|
|
212
|
-
- Phase contains: WP definitions, implementation notes, test artifacts
|
|
213
|
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
## Available Core Agents Reference
|
|
217
|
-
|
|
218
|
-
### Planning & Requirements
|
|
219
|
-
- **planner**: Creates phases, roadmaps, and work packages (works at project or phase level), validates acceptance criteria
|
|
220
|
-
- **architect**: Defines system shape, interfaces, technology decisions, Designs test strategies, Conducts targeted research for technical decisions
|
|
221
|
-
- **designer**: Creates UI/UX specifications, component libraries
|
|
222
|
-
- **engineer**: Implements features end-to-end with code, writes comprehensive test suites, and documentation. Reviews code for quality, security, and standards compliance. Ensures all builds, tests, and checks pass. Visually inspects the running application against UI/UX design/guide.
|
|
223
|
-
- **gemini|codex consultant**: diverse multi-hat. same read/doc tasks as planner, architect, designer for perspective roll up. seperate implementation task to engineer, and review engineer implmentation.
|
|
224
|
-
- **uat**: uses browser automation to manually test user flows. Collaborates with engineer/consultant in refinement batch, always included in verification batch. Max 1 UAT agent per batch.
|
|
225
|
-
|
|
226
|
-
## Critical Reminders
|
|
227
|
-
|
|
228
|
-
1. **You are the Primary Orchestrator** - You delegate everything
|
|
229
|
-
2. **TodoWrite continuously** - Update after every action
|
|
230
|
-
3. **Batch everything possible** - Launch parallel agents in single message
|
|
231
|
-
4. **Verify everything** - No skipping quality gates
|
|
232
|
-
5. **Context discipline** - Give agents minimal but complete context
|
|
233
|
-
6. **Phase management** - Provide phase-id when working at phase level
|
|
234
|
-
7. **Document hierarchy** - Respect spec/ vs guides/ vs phases/
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
[/CRITICAL ORCHESTRATION PROTOCOLS]
|
|
238
|
-
|
|
239
|
-
|
|
240
|
-
⚙️Remember: The key to effective orchestration is understanding which work can truly happen in parallel and launching those agents together, while respecting sequential dependencies between batches.⚙️
|