@mootup/moot-templates 0.1.0-rc.0
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/README.md +42 -0
- package/dist/index.d.ts +21 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +35 -0
- package/dist/index.js.map +1 -0
- package/package.json +39 -0
- package/templates/CLAUDE.md +233 -0
- package/templates/claude/hooks/auto-orient.sh +21 -0
- package/templates/claude/hooks/git-guard.sh +56 -0
- package/templates/claude/hooks/grep-baseline-diff.sh +41 -0
- package/templates/claude/hooks/handoff-status-check.sh +40 -0
- package/templates/claude/settings.json +51 -0
- package/templates/devcontainer/devcontainer.json +25 -0
- package/templates/devcontainer/post-create.sh +68 -0
- package/templates/devcontainer/run-moot-channel.sh +70 -0
- package/templates/devcontainer/run-moot-mcp.sh +74 -0
- package/templates/devcontainer/run-moot-notify.sh +59 -0
- package/templates/skills/doc-curation/SKILL.md +80 -0
- package/templates/skills/handoff/SKILL.md +46 -0
- package/templates/skills/leader-workflow/SKILL.md +135 -0
- package/templates/skills/librarian-workflow/SKILL.md +50 -0
- package/templates/skills/memory-audit/SKILL.md +85 -0
- package/templates/skills/product-workflow/SKILL.md +69 -0
- package/templates/skills/spec-checklist/SKILL.md +99 -0
- package/templates/skills/verify/SKILL.md +64 -0
- package/templates/teams/loop-3/CLAUDE.md +72 -0
- package/templates/teams/loop-3/README.md +6 -0
- package/templates/teams/loop-3/team.toml +108 -0
- package/templates/teams/loop-4/CLAUDE.md +72 -0
- package/templates/teams/loop-4/README.md +6 -0
- package/templates/teams/loop-4/team.toml +126 -0
- package/templates/teams/loop-4-observer/CLAUDE.md +76 -0
- package/templates/teams/loop-4-observer/README.md +7 -0
- package/templates/teams/loop-4-observer/team.toml +141 -0
- package/templates/teams/loop-4-parallel/CLAUDE.md +76 -0
- package/templates/teams/loop-4-parallel/README.md +6 -0
- package/templates/teams/loop-4-parallel/team.toml +142 -0
- package/templates/teams/loop-4-split-leader/CLAUDE.md +76 -0
- package/templates/teams/loop-4-split-leader/README.md +7 -0
- package/templates/teams/loop-4-split-leader/team.toml +140 -0
- package/templates/teams/loop-6/CLAUDE.md +43 -0
- package/templates/teams/loop-6/README.md +9 -0
- package/templates/teams/loop-6/team.toml +161 -0
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
toml_schema_version = "1"
|
|
2
|
+
|
|
3
|
+
[archetype]
|
|
4
|
+
id = "mootup/loop-4"
|
|
5
|
+
version = "1.0"
|
|
6
|
+
diverged_at = ""
|
|
7
|
+
|
|
8
|
+
[team]
|
|
9
|
+
name = "loop-4"
|
|
10
|
+
description = "Four-agent software development pipeline proven over 30+ features"
|
|
11
|
+
version = "1.0"
|
|
12
|
+
origin = "Observed from Convo project's agent team, April 2026"
|
|
13
|
+
|
|
14
|
+
# -- Roles --
|
|
15
|
+
# Order reflects the pipeline sequence.
|
|
16
|
+
|
|
17
|
+
[[roles]]
|
|
18
|
+
name = "product"
|
|
19
|
+
display_name = "Product"
|
|
20
|
+
harness = "claude-code"
|
|
21
|
+
model = "opus"
|
|
22
|
+
theme = "blue"
|
|
23
|
+
responsibilities = """
|
|
24
|
+
Product direction, prioritization, feature scoping. Owns git operations
|
|
25
|
+
(commits, branches, merges). Kicks off features, monitors pipeline,
|
|
26
|
+
runs retrospectives. Human interface -- interprets requirements, makes
|
|
27
|
+
judgment calls on scope and priority."""
|
|
28
|
+
|
|
29
|
+
startup_prompt = """
|
|
30
|
+
You are the Product agent. Call orientation() to get your identity,
|
|
31
|
+
focus space, and context in one call. Then subscribe to the channel.
|
|
32
|
+
Post a status_update confirming you are online."""
|
|
33
|
+
|
|
34
|
+
[[roles]]
|
|
35
|
+
name = "spec"
|
|
36
|
+
display_name = "Spec"
|
|
37
|
+
harness = "claude-code"
|
|
38
|
+
model = "opus"
|
|
39
|
+
theme = "magenta"
|
|
40
|
+
responsibilities = """
|
|
41
|
+
Design docs, specifications, test plans, architecture review. Verifies
|
|
42
|
+
technical claims against the codebase. Each spec includes security
|
|
43
|
+
considerations. Produces implementation-ready specs with complete
|
|
44
|
+
file content where possible."""
|
|
45
|
+
|
|
46
|
+
startup_prompt = """
|
|
47
|
+
You are the Spec agent. Call orientation() then subscribe to the channel.
|
|
48
|
+
Post a status_update confirming you are online. Wait for work."""
|
|
49
|
+
|
|
50
|
+
[[roles]]
|
|
51
|
+
name = "implementation"
|
|
52
|
+
display_name = "Implementation"
|
|
53
|
+
harness = "claude-code"
|
|
54
|
+
model = "opus"
|
|
55
|
+
theme = "cyan"
|
|
56
|
+
responsibilities = """
|
|
57
|
+
Code implementation based on specs. Writes common-case behavioral tests
|
|
58
|
+
before handoff (pipeline gate). Follows spec precisely -- asks for
|
|
59
|
+
clarification rather than guessing."""
|
|
60
|
+
|
|
61
|
+
startup_prompt = """
|
|
62
|
+
You are the Implementation agent. Call orientation() then subscribe to
|
|
63
|
+
the channel. Post a status_update confirming you are online. Wait for work."""
|
|
64
|
+
|
|
65
|
+
[[roles]]
|
|
66
|
+
name = "qa"
|
|
67
|
+
display_name = "QA"
|
|
68
|
+
harness = "claude-code"
|
|
69
|
+
model = "sonnet"
|
|
70
|
+
theme = "green"
|
|
71
|
+
responsibilities = """
|
|
72
|
+
Test strategy, test implementation, feature verification. Owns the docker
|
|
73
|
+
compose stack. Extends test coverage beyond spec requirements based on
|
|
74
|
+
own analysis. Includes security verification. May commit small repairs
|
|
75
|
+
directly when the intended behavior is unambiguous."""
|
|
76
|
+
|
|
77
|
+
startup_prompt = """
|
|
78
|
+
You are the QA agent. Call orientation() then subscribe to the channel.
|
|
79
|
+
Post a status_update confirming you are online. Wait for work."""
|
|
80
|
+
|
|
81
|
+
# -- Workflow --
|
|
82
|
+
|
|
83
|
+
[workflow]
|
|
84
|
+
description = """
|
|
85
|
+
Work flows through agents in sequence, one feature at a time:
|
|
86
|
+
Product --> Spec --> Implementation --> QA --> Product.
|
|
87
|
+
Each handoff is a channel message mentioning the next agent.
|
|
88
|
+
Product kicks off features, monitors for stalls, and merges to main."""
|
|
89
|
+
|
|
90
|
+
pipeline = ["product", "spec", "implementation", "qa"]
|
|
91
|
+
|
|
92
|
+
[workflow.threads]
|
|
93
|
+
feature = "[FEATURE]"
|
|
94
|
+
question = "[QUESTION]"
|
|
95
|
+
git_request = "[GIT-REQUEST]"
|
|
96
|
+
stack_request = "[STACK-REQUEST]"
|
|
97
|
+
|
|
98
|
+
[workflow.handoff]
|
|
99
|
+
method = "mention"
|
|
100
|
+
includes = ["summary of work done", "what next agent needs to do", "files changed", "branch name"]
|
|
101
|
+
|
|
102
|
+
# -- Git --
|
|
103
|
+
|
|
104
|
+
[git]
|
|
105
|
+
description = """
|
|
106
|
+
Each agent works in a git worktree. Feature branches from main,
|
|
107
|
+
agent branches from feature branch. Squash-merge features to main."""
|
|
108
|
+
|
|
109
|
+
strategy = "worktree"
|
|
110
|
+
feature_branch = "feat/{slug}"
|
|
111
|
+
agent_branch = "{role}/{slug}"
|
|
112
|
+
merge_to_main = "squash"
|
|
113
|
+
|
|
114
|
+
[git.ownership]
|
|
115
|
+
main_branch = "product"
|
|
116
|
+
stack = "qa"
|
|
117
|
+
|
|
118
|
+
# -- Resource ownership --
|
|
119
|
+
|
|
120
|
+
[resources]
|
|
121
|
+
description = """
|
|
122
|
+
Shared resources have a single owner to avoid contention."""
|
|
123
|
+
|
|
124
|
+
[resources.owners]
|
|
125
|
+
git = "product"
|
|
126
|
+
docker_stack = "qa"
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# {project_name}
|
|
2
|
+
|
|
3
|
+
TODO: Describe your project. What does it do? What problem does it solve?
|
|
4
|
+
|
|
5
|
+
## Status
|
|
6
|
+
|
|
7
|
+
TODO: What works, what doesn't. Update as the project evolves.
|
|
8
|
+
|
|
9
|
+
## Tech stack
|
|
10
|
+
|
|
11
|
+
TODO: Language, frameworks, databases, build tools.
|
|
12
|
+
|
|
13
|
+
## Running
|
|
14
|
+
|
|
15
|
+
TODO: How to run the project, run tests, build, deploy.
|
|
16
|
+
|
|
17
|
+
## Code conventions
|
|
18
|
+
|
|
19
|
+
TODO: Formatting, linting, type checking, naming conventions.
|
|
20
|
+
|
|
21
|
+
## Agent Workflow
|
|
22
|
+
|
|
23
|
+
{role_count} agents collaborate on this project: {role_list}. They communicate via the Convo shared context server. Pipeline agents use Claude Code. The Observer uses Cursor.
|
|
24
|
+
|
|
25
|
+
### Roles
|
|
26
|
+
|
|
27
|
+
{role_descriptions}
|
|
28
|
+
|
|
29
|
+
### Observer Role
|
|
30
|
+
|
|
31
|
+
The Librarian is an async observer -- it monitors the pipeline for shipped features and updates documentation, but does not block the main work pipeline. It runs on a different harness (Cursor) and receives notifications via the tmux notification daemon.
|
|
32
|
+
|
|
33
|
+
### Resource Ownership
|
|
34
|
+
|
|
35
|
+
{resource_ownership}
|
|
36
|
+
|
|
37
|
+
### Git Workflow
|
|
38
|
+
|
|
39
|
+
{git_description}
|
|
40
|
+
|
|
41
|
+
### Startup
|
|
42
|
+
|
|
43
|
+
On connecting to a space (including restarts and resumes), every agent must:
|
|
44
|
+
1. Call orientation() to get identity, focus space, and context
|
|
45
|
+
2. Subscribe to the channel for push notifications
|
|
46
|
+
3. Post a status_update confirming identity and readiness
|
|
47
|
+
|
|
48
|
+
### Work Pipeline
|
|
49
|
+
|
|
50
|
+
{workflow_description}
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
{pipeline_diagram}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
{handoff_protocol}
|
|
57
|
+
|
|
58
|
+
Before handing off, the agent must commit to their branch and request a merge from the leader via a `[GIT-REQUEST]` thread.
|
|
59
|
+
|
|
60
|
+
**Status updates on handoff:** Every agent must call `update_status` when receiving or completing a handoff.
|
|
61
|
+
|
|
62
|
+
### Channel Threading Protocol
|
|
63
|
+
|
|
64
|
+
{threading_protocol}
|
|
65
|
+
|
|
66
|
+
### Clarification Flow
|
|
67
|
+
|
|
68
|
+
When an agent is blocked and needs input, use `[QUESTION]` threads in the channel. Mention the target agent.
|
|
69
|
+
|
|
70
|
+
### Tracking Decisions
|
|
71
|
+
|
|
72
|
+
Use `propose_decision` for choices that involve tradeoffs, creativity, or judgment -- decisions where a different person might choose differently. Do NOT track mechanical or purely deductive decisions.
|
|
73
|
+
|
|
74
|
+
### Retrospective
|
|
75
|
+
|
|
76
|
+
After the verifier approves and the leader confirms a feature is complete, every agent posts a retro message in the `[FEATURE]` thread.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# loop-4-observer -- Standard Pipeline + Observer
|
|
2
|
+
|
|
3
|
+
Standard four-agent pipeline with an async Librarian for documentation curation.
|
|
4
|
+
Product --> Spec --> Implementation --> QA --> Product, with Librarian observing.
|
|
5
|
+
|
|
6
|
+
Use for projects generating enough specs and docs to warrant continuous curation.
|
|
7
|
+
Pipeline agents use Claude Code; the Observer uses Cursor.
|
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
toml_schema_version = "1"
|
|
2
|
+
|
|
3
|
+
[archetype]
|
|
4
|
+
id = "mootup/loop-4-observer"
|
|
5
|
+
version = "1.0"
|
|
6
|
+
diverged_at = ""
|
|
7
|
+
|
|
8
|
+
[team]
|
|
9
|
+
name = "loop-4-observer"
|
|
10
|
+
description = "Standard four-agent pipeline with async Librarian observer"
|
|
11
|
+
version = "1.0"
|
|
12
|
+
origin = "Observed from Convo project's agent team with Librarian, April 2026"
|
|
13
|
+
|
|
14
|
+
# -- Roles --
|
|
15
|
+
|
|
16
|
+
[[roles]]
|
|
17
|
+
name = "product"
|
|
18
|
+
display_name = "Product"
|
|
19
|
+
harness = "claude-code"
|
|
20
|
+
model = "opus"
|
|
21
|
+
theme = "blue"
|
|
22
|
+
responsibilities = """
|
|
23
|
+
Product direction, prioritization, feature scoping. Owns git operations
|
|
24
|
+
(commits, branches, merges). Kicks off features, monitors pipeline,
|
|
25
|
+
runs retrospectives. Human interface -- interprets requirements, makes
|
|
26
|
+
judgment calls on scope and priority."""
|
|
27
|
+
|
|
28
|
+
startup_prompt = """
|
|
29
|
+
You are the Product agent. Call orientation() to get your identity,
|
|
30
|
+
focus space, and context in one call. Then subscribe to the channel.
|
|
31
|
+
Post a status_update confirming you are online."""
|
|
32
|
+
|
|
33
|
+
[[roles]]
|
|
34
|
+
name = "spec"
|
|
35
|
+
display_name = "Spec"
|
|
36
|
+
harness = "claude-code"
|
|
37
|
+
model = "opus"
|
|
38
|
+
theme = "magenta"
|
|
39
|
+
responsibilities = """
|
|
40
|
+
Design docs, specifications, test plans, architecture review. Verifies
|
|
41
|
+
technical claims against the codebase. Each spec includes security
|
|
42
|
+
considerations. Produces implementation-ready specs with complete
|
|
43
|
+
file content where possible."""
|
|
44
|
+
|
|
45
|
+
startup_prompt = """
|
|
46
|
+
You are the Spec agent. Call orientation() then subscribe to the channel.
|
|
47
|
+
Post a status_update confirming you are online. Wait for work."""
|
|
48
|
+
|
|
49
|
+
[[roles]]
|
|
50
|
+
name = "implementation"
|
|
51
|
+
display_name = "Implementation"
|
|
52
|
+
harness = "claude-code"
|
|
53
|
+
model = "opus"
|
|
54
|
+
theme = "cyan"
|
|
55
|
+
responsibilities = """
|
|
56
|
+
Code implementation based on specs. Writes common-case behavioral tests
|
|
57
|
+
before handoff (pipeline gate). Follows spec precisely -- asks for
|
|
58
|
+
clarification rather than guessing."""
|
|
59
|
+
|
|
60
|
+
startup_prompt = """
|
|
61
|
+
You are the Implementation agent. Call orientation() then subscribe to
|
|
62
|
+
the channel. Post a status_update confirming you are online. Wait for work."""
|
|
63
|
+
|
|
64
|
+
[[roles]]
|
|
65
|
+
name = "qa"
|
|
66
|
+
display_name = "QA"
|
|
67
|
+
harness = "claude-code"
|
|
68
|
+
model = "sonnet"
|
|
69
|
+
theme = "green"
|
|
70
|
+
responsibilities = """
|
|
71
|
+
Test strategy, test implementation, feature verification. Owns the docker
|
|
72
|
+
compose stack. Extends test coverage beyond spec requirements based on
|
|
73
|
+
own analysis. Includes security verification. May commit small repairs
|
|
74
|
+
directly when the intended behavior is unambiguous."""
|
|
75
|
+
|
|
76
|
+
startup_prompt = """
|
|
77
|
+
You are the QA agent. Call orientation() then subscribe to the channel.
|
|
78
|
+
Post a status_update confirming you are online. Wait for work."""
|
|
79
|
+
|
|
80
|
+
[[roles]]
|
|
81
|
+
name = "librarian"
|
|
82
|
+
display_name = "Librarian"
|
|
83
|
+
harness = "cursor"
|
|
84
|
+
model = "sonnet"
|
|
85
|
+
theme = "white"
|
|
86
|
+
responsibilities = """
|
|
87
|
+
Documentation curation, spec indexing, stale content detection. Watches
|
|
88
|
+
for shipped features and updates docs. Does not block the pipeline.
|
|
89
|
+
Observer role -- monitors the system asynchronously."""
|
|
90
|
+
|
|
91
|
+
startup_prompt = """
|
|
92
|
+
You are the Librarian agent. Call orientation() to get your identity,
|
|
93
|
+
focus space, and context in one call. Then wait for work from the channel."""
|
|
94
|
+
|
|
95
|
+
# -- Workflow --
|
|
96
|
+
|
|
97
|
+
[workflow]
|
|
98
|
+
description = """
|
|
99
|
+
Work flows through agents in sequence, one feature at a time:
|
|
100
|
+
Product --> Spec --> Implementation --> QA --> Product.
|
|
101
|
+
The Librarian observes asynchronously but does not block the pipeline.
|
|
102
|
+
Each handoff is a channel message mentioning the next agent.
|
|
103
|
+
Product kicks off features, monitors for stalls, and merges to main."""
|
|
104
|
+
|
|
105
|
+
pipeline = ["product", "spec", "implementation", "qa"]
|
|
106
|
+
|
|
107
|
+
[workflow.threads]
|
|
108
|
+
feature = "[FEATURE]"
|
|
109
|
+
question = "[QUESTION]"
|
|
110
|
+
git_request = "[GIT-REQUEST]"
|
|
111
|
+
stack_request = "[STACK-REQUEST]"
|
|
112
|
+
|
|
113
|
+
[workflow.handoff]
|
|
114
|
+
method = "mention"
|
|
115
|
+
includes = ["summary of work done", "what next agent needs to do", "files changed", "branch name"]
|
|
116
|
+
|
|
117
|
+
# -- Git --
|
|
118
|
+
|
|
119
|
+
[git]
|
|
120
|
+
description = """
|
|
121
|
+
Each agent works in a git worktree. Feature branches from main,
|
|
122
|
+
agent branches from feature branch. Squash-merge features to main."""
|
|
123
|
+
|
|
124
|
+
strategy = "worktree"
|
|
125
|
+
feature_branch = "feat/{slug}"
|
|
126
|
+
agent_branch = "{role}/{slug}"
|
|
127
|
+
merge_to_main = "squash"
|
|
128
|
+
|
|
129
|
+
[git.ownership]
|
|
130
|
+
main_branch = "product"
|
|
131
|
+
stack = "qa"
|
|
132
|
+
|
|
133
|
+
# -- Resource ownership --
|
|
134
|
+
|
|
135
|
+
[resources]
|
|
136
|
+
description = """
|
|
137
|
+
Shared resources have a single owner to avoid contention."""
|
|
138
|
+
|
|
139
|
+
[resources.owners]
|
|
140
|
+
git = "product"
|
|
141
|
+
docker_stack = "qa"
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# {project_name}
|
|
2
|
+
|
|
3
|
+
TODO: Describe your project. What does it do? What problem does it solve?
|
|
4
|
+
|
|
5
|
+
## Status
|
|
6
|
+
|
|
7
|
+
TODO: What works, what doesn't. Update as the project evolves.
|
|
8
|
+
|
|
9
|
+
## Tech stack
|
|
10
|
+
|
|
11
|
+
TODO: Language, frameworks, databases, build tools.
|
|
12
|
+
|
|
13
|
+
## Running
|
|
14
|
+
|
|
15
|
+
TODO: How to run the project, run tests, build, deploy.
|
|
16
|
+
|
|
17
|
+
## Code conventions
|
|
18
|
+
|
|
19
|
+
TODO: Formatting, linting, type checking, naming conventions.
|
|
20
|
+
|
|
21
|
+
## Agent Workflow
|
|
22
|
+
|
|
23
|
+
{role_count} agents collaborate on this project: {role_list}. They communicate via the Convo shared context server.
|
|
24
|
+
|
|
25
|
+
### Roles
|
|
26
|
+
|
|
27
|
+
{role_descriptions}
|
|
28
|
+
|
|
29
|
+
### Parallel Dispatch
|
|
30
|
+
|
|
31
|
+
Two Implementation agents work in parallel. The leader dispatches features to whichever implementer is idle. This balances throughput when implementation is the bottleneck. Both implementers hand off to the same QA agent.
|
|
32
|
+
|
|
33
|
+
### Resource Ownership
|
|
34
|
+
|
|
35
|
+
{resource_ownership}
|
|
36
|
+
|
|
37
|
+
### Git Workflow
|
|
38
|
+
|
|
39
|
+
{git_description}
|
|
40
|
+
|
|
41
|
+
### Startup
|
|
42
|
+
|
|
43
|
+
On connecting to a space (including restarts and resumes), every agent must:
|
|
44
|
+
1. Call orientation() to get identity, focus space, and context
|
|
45
|
+
2. Subscribe to the channel for push notifications
|
|
46
|
+
3. Post a status_update confirming identity and readiness
|
|
47
|
+
|
|
48
|
+
### Work Pipeline
|
|
49
|
+
|
|
50
|
+
{workflow_description}
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
{pipeline_diagram}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
{handoff_protocol}
|
|
57
|
+
|
|
58
|
+
Before handing off, the agent must commit to their branch and request a merge from the leader via a `[GIT-REQUEST]` thread.
|
|
59
|
+
|
|
60
|
+
**Status updates on handoff:** Every agent must call `update_status` when receiving or completing a handoff.
|
|
61
|
+
|
|
62
|
+
### Channel Threading Protocol
|
|
63
|
+
|
|
64
|
+
{threading_protocol}
|
|
65
|
+
|
|
66
|
+
### Clarification Flow
|
|
67
|
+
|
|
68
|
+
When an agent is blocked and needs input, use `[QUESTION]` threads in the channel. Mention the target agent.
|
|
69
|
+
|
|
70
|
+
### Tracking Decisions
|
|
71
|
+
|
|
72
|
+
Use `propose_decision` for choices that involve tradeoffs, creativity, or judgment -- decisions where a different person might choose differently. Do NOT track mechanical or purely deductive decisions.
|
|
73
|
+
|
|
74
|
+
### Retrospective
|
|
75
|
+
|
|
76
|
+
After the verifier approves and the leader confirms a feature is complete, every agent posts a retro message in the `[FEATURE]` thread.
|
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
# loop-4-parallel -- Scaled Pipeline
|
|
2
|
+
|
|
3
|
+
Standard pipeline with dual implementers for sustained feature throughput.
|
|
4
|
+
Product --> Spec --> Implementation A/B --> QA --> Product.
|
|
5
|
+
|
|
6
|
+
Use when Implementation is the throughput bottleneck. Leader dispatches to whichever implementer is idle.
|
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
toml_schema_version = "1"
|
|
2
|
+
|
|
3
|
+
[archetype]
|
|
4
|
+
id = "mootup/loop-4-parallel"
|
|
5
|
+
version = "1.0"
|
|
6
|
+
diverged_at = ""
|
|
7
|
+
|
|
8
|
+
[team]
|
|
9
|
+
name = "loop-4-parallel"
|
|
10
|
+
description = "Standard pipeline with parallel implementers for scaled throughput"
|
|
11
|
+
version = "1.0"
|
|
12
|
+
origin = "Scaled loop-4 for sustained feature throughput"
|
|
13
|
+
|
|
14
|
+
# -- Roles --
|
|
15
|
+
|
|
16
|
+
[[roles]]
|
|
17
|
+
name = "product"
|
|
18
|
+
display_name = "Product"
|
|
19
|
+
harness = "claude-code"
|
|
20
|
+
model = "opus"
|
|
21
|
+
theme = "blue"
|
|
22
|
+
responsibilities = """
|
|
23
|
+
Product direction, prioritization, feature scoping. Owns git operations
|
|
24
|
+
(commits, branches, merges). Kicks off features, monitors pipeline,
|
|
25
|
+
runs retrospectives. Human interface -- interprets requirements, makes
|
|
26
|
+
judgment calls on scope and priority. Dispatches to whichever
|
|
27
|
+
implementer is idle."""
|
|
28
|
+
|
|
29
|
+
startup_prompt = """
|
|
30
|
+
You are the Product agent. Call orientation() to get your identity,
|
|
31
|
+
focus space, and context in one call. Then subscribe to the channel.
|
|
32
|
+
Post a status_update confirming you are online."""
|
|
33
|
+
|
|
34
|
+
[[roles]]
|
|
35
|
+
name = "spec"
|
|
36
|
+
display_name = "Spec"
|
|
37
|
+
harness = "claude-code"
|
|
38
|
+
model = "opus"
|
|
39
|
+
theme = "magenta"
|
|
40
|
+
responsibilities = """
|
|
41
|
+
Design docs, specifications, test plans, architecture review. Verifies
|
|
42
|
+
technical claims against the codebase. Each spec includes security
|
|
43
|
+
considerations. Produces implementation-ready specs with complete
|
|
44
|
+
file content where possible."""
|
|
45
|
+
|
|
46
|
+
startup_prompt = """
|
|
47
|
+
You are the Spec agent. Call orientation() then subscribe to the channel.
|
|
48
|
+
Post a status_update confirming you are online. Wait for work."""
|
|
49
|
+
|
|
50
|
+
[[roles]]
|
|
51
|
+
name = "implementation_a"
|
|
52
|
+
display_name = "Implementation A"
|
|
53
|
+
harness = "claude-code"
|
|
54
|
+
model = "opus"
|
|
55
|
+
theme = "cyan"
|
|
56
|
+
responsibilities = """
|
|
57
|
+
Code implementation based on specs. Writes common-case behavioral tests
|
|
58
|
+
before handoff (pipeline gate). Follows spec precisely -- asks for
|
|
59
|
+
clarification rather than guessing. One of two parallel implementers."""
|
|
60
|
+
|
|
61
|
+
startup_prompt = """
|
|
62
|
+
You are Implementation Agent A. Call orientation() then subscribe to
|
|
63
|
+
the channel. Post a status_update confirming you are online. Wait for work."""
|
|
64
|
+
|
|
65
|
+
[[roles]]
|
|
66
|
+
name = "implementation_b"
|
|
67
|
+
display_name = "Implementation B"
|
|
68
|
+
harness = "claude-code"
|
|
69
|
+
model = "opus"
|
|
70
|
+
theme = "cyan"
|
|
71
|
+
responsibilities = """
|
|
72
|
+
Code implementation based on specs. Writes common-case behavioral tests
|
|
73
|
+
before handoff (pipeline gate). Follows spec precisely -- asks for
|
|
74
|
+
clarification rather than guessing. One of two parallel implementers."""
|
|
75
|
+
|
|
76
|
+
startup_prompt = """
|
|
77
|
+
You are Implementation Agent B. Call orientation() then subscribe to
|
|
78
|
+
the channel. Post a status_update confirming you are online. Wait for work."""
|
|
79
|
+
|
|
80
|
+
[[roles]]
|
|
81
|
+
name = "qa"
|
|
82
|
+
display_name = "QA"
|
|
83
|
+
harness = "claude-code"
|
|
84
|
+
model = "sonnet"
|
|
85
|
+
theme = "green"
|
|
86
|
+
responsibilities = """
|
|
87
|
+
Test strategy, test implementation, feature verification. Owns the docker
|
|
88
|
+
compose stack. Extends test coverage beyond spec requirements based on
|
|
89
|
+
own analysis. Includes security verification. May commit small repairs
|
|
90
|
+
directly when the intended behavior is unambiguous."""
|
|
91
|
+
|
|
92
|
+
startup_prompt = """
|
|
93
|
+
You are the QA agent. Call orientation() then subscribe to the channel.
|
|
94
|
+
Post a status_update confirming you are online. Wait for work."""
|
|
95
|
+
|
|
96
|
+
# -- Workflow --
|
|
97
|
+
|
|
98
|
+
[workflow]
|
|
99
|
+
description = """
|
|
100
|
+
Work flows through agents in sequence, one feature at a time:
|
|
101
|
+
Product --> Spec --> Implementation --> QA --> Product.
|
|
102
|
+
Two Implementation agents work in parallel -- Product dispatches to
|
|
103
|
+
whichever is idle. This balances throughput when implementation is the
|
|
104
|
+
bottleneck."""
|
|
105
|
+
|
|
106
|
+
pipeline = ["product", "spec", "implementation_a", "qa"]
|
|
107
|
+
|
|
108
|
+
[workflow.threads]
|
|
109
|
+
feature = "[FEATURE]"
|
|
110
|
+
question = "[QUESTION]"
|
|
111
|
+
git_request = "[GIT-REQUEST]"
|
|
112
|
+
stack_request = "[STACK-REQUEST]"
|
|
113
|
+
|
|
114
|
+
[workflow.handoff]
|
|
115
|
+
method = "mention"
|
|
116
|
+
includes = ["summary of work done", "what next agent needs to do", "files changed", "branch name"]
|
|
117
|
+
|
|
118
|
+
# -- Git --
|
|
119
|
+
|
|
120
|
+
[git]
|
|
121
|
+
description = """
|
|
122
|
+
Each agent works in a git worktree. Feature branches from main,
|
|
123
|
+
agent branches from feature branch. Squash-merge features to main."""
|
|
124
|
+
|
|
125
|
+
strategy = "worktree"
|
|
126
|
+
feature_branch = "feat/{slug}"
|
|
127
|
+
agent_branch = "{role}/{slug}"
|
|
128
|
+
merge_to_main = "squash"
|
|
129
|
+
|
|
130
|
+
[git.ownership]
|
|
131
|
+
main_branch = "product"
|
|
132
|
+
stack = "qa"
|
|
133
|
+
|
|
134
|
+
# -- Resource ownership --
|
|
135
|
+
|
|
136
|
+
[resources]
|
|
137
|
+
description = """
|
|
138
|
+
Shared resources have a single owner to avoid contention."""
|
|
139
|
+
|
|
140
|
+
[resources.owners]
|
|
141
|
+
git = "product"
|
|
142
|
+
docker_stack = "qa"
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# {project_name}
|
|
2
|
+
|
|
3
|
+
TODO: Describe your project. What does it do? What problem does it solve?
|
|
4
|
+
|
|
5
|
+
## Status
|
|
6
|
+
|
|
7
|
+
TODO: What works, what doesn't. Update as the project evolves.
|
|
8
|
+
|
|
9
|
+
## Tech stack
|
|
10
|
+
|
|
11
|
+
TODO: Language, frameworks, databases, build tools.
|
|
12
|
+
|
|
13
|
+
## Running
|
|
14
|
+
|
|
15
|
+
TODO: How to run the project, run tests, build, deploy.
|
|
16
|
+
|
|
17
|
+
## Code conventions
|
|
18
|
+
|
|
19
|
+
TODO: Formatting, linting, type checking, naming conventions.
|
|
20
|
+
|
|
21
|
+
## Agent Workflow
|
|
22
|
+
|
|
23
|
+
{role_count} agents collaborate on this project: {role_list}. They communicate via the Convo shared context server.
|
|
24
|
+
|
|
25
|
+
### Roles
|
|
26
|
+
|
|
27
|
+
{role_descriptions}
|
|
28
|
+
|
|
29
|
+
### Product / Lead Separation
|
|
30
|
+
|
|
31
|
+
Product handles prioritization, requirements, and stakeholder communication. Lead runs the pipeline: dispatch to Spec, merge branches, monitor progress, process QA handoffs, run retros. Product dispatches features to Lead; Lead reports completion back to Product.
|
|
32
|
+
|
|
33
|
+
### Resource Ownership
|
|
34
|
+
|
|
35
|
+
{resource_ownership}
|
|
36
|
+
|
|
37
|
+
### Git Workflow
|
|
38
|
+
|
|
39
|
+
{git_description}
|
|
40
|
+
|
|
41
|
+
### Startup
|
|
42
|
+
|
|
43
|
+
On connecting to a space (including restarts and resumes), every agent must:
|
|
44
|
+
1. Call orientation() to get identity, focus space, and context
|
|
45
|
+
2. Subscribe to the channel for push notifications
|
|
46
|
+
3. Post a status_update confirming identity and readiness
|
|
47
|
+
|
|
48
|
+
### Work Pipeline
|
|
49
|
+
|
|
50
|
+
{workflow_description}
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
{pipeline_diagram}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
{handoff_protocol}
|
|
57
|
+
|
|
58
|
+
Before handing off, the agent must commit to their branch and request a merge from Lead via a `[GIT-REQUEST]` thread.
|
|
59
|
+
|
|
60
|
+
**Status updates on handoff:** Every agent must call `update_status` when receiving or completing a handoff.
|
|
61
|
+
|
|
62
|
+
### Channel Threading Protocol
|
|
63
|
+
|
|
64
|
+
{threading_protocol}
|
|
65
|
+
|
|
66
|
+
### Clarification Flow
|
|
67
|
+
|
|
68
|
+
When an agent is blocked and needs input, use `[QUESTION]` threads in the channel. Mention the target agent.
|
|
69
|
+
|
|
70
|
+
### Tracking Decisions
|
|
71
|
+
|
|
72
|
+
Use `propose_decision` for choices that involve tradeoffs, creativity, or judgment -- decisions where a different person might choose differently. Do NOT track mechanical or purely deductive decisions.
|
|
73
|
+
|
|
74
|
+
### Retrospective
|
|
75
|
+
|
|
76
|
+
After the verifier approves and the leader confirms a feature is complete, every agent posts a retro message in the `[FEATURE]` thread.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# loop-4-split-leader -- Separated Product/Lead
|
|
2
|
+
|
|
3
|
+
Pipeline with separated human-facing (Product) and team-facing (Lead) coordination.
|
|
4
|
+
Product <--> Lead --> Spec --> Implementation --> QA --> Lead.
|
|
5
|
+
|
|
6
|
+
Use when human interaction load is high enough to warrant a dedicated product interface,
|
|
7
|
+
or when coordinating multiple parallel pipelines.
|