team

Name: team
Author: Rune-kit

80stars21forks

How to install team?

rune-kit/rune/team

$npx -y skills add Rune-kit/rune --skill team

Installs into the current project.

Summary

Multi-agent meta-orchestrator. Use when task spans 5+ files or 3+ modules, or when user says 'parallel', 'split this up', 'do all of these'. Decomposes large tasks into parallel workstreams, assigns to isolated cook instances, coordinates merging.

Files · 1

View on GitHub

SKILL.md

1	# team
2
3	## Purpose
4
5	Meta-orchestrator for complex tasks requiring parallel workstreams. Team decomposes large features into independent subtasks, assigns each to an isolated cook instance (using git worktrees), coordinates progress, and merges results. Uses opus for strategic decomposition and conflict resolution.
6
7	<HARD-GATE>
8	- MAX 3 PARALLEL AGENTS: Never launch more than 3 Task calls simultaneously. If more than 3 streams exist, batch them.
9	- No merge without conflict resolution complete (Phase 3 clean).
10	- Full integration tests MUST run before reporting success.
11	</HARD-GATE>
12
13	## Triggers
14
15	- `/rune team <task>` — manual invocation for large features
16	- Auto-trigger: when task affects 5+ files or spans 3+ modules
17
18	## Mode Selection (Auto-Detect)
19
20	```
21	IF streams ≤ 2 AND total files ≤ 5:
22	→ LITE MODE (lightweight parallel, no worktrees)
23	ELSE:
24	→ FULL MODE (worktree isolation, opus coordination)
25	```
26
27	### Lite Mode
28
29	For small parallel tasks that don't warrant full worktree isolation:
30
31	```
32	Lite Mode Rules:
33	- Max 2 parallel agents (haiku coordination, sonnet workers)
34	- NO worktree creation — agents work on same branch
35	- File ownership still enforced (disjoint file sets)
36	- Simplified merge: sequential git add (no merge conflicts possible with disjoint files)
37	- Skip Phase 3 (COORDINATE) — no conflicts with disjoint files
38	- Skip integrity-check — small scope, direct output review
39	- Coordinator model: haiku (not opus) — saves cost
40
41	Lite Mode Phases:
42	Phase 1: DECOMPOSE (haiku) — identify 2 streams with disjoint files
43	Phase 2: ASSIGN — launch 2 parallel Task agents (sonnet, no worktree)
44	Phase 4: MERGE — sequential git add (no merge needed)
45	Phase 5: VERIFY — integration tests on result
46	```
47
48	Announce mode: "Team lite mode: 2 streams, ≤5 files, no worktrees needed."
49	Override: User can say "full mode" to force worktree isolation.
50
51	### Full Mode
52
53	Standard team workflow with worktree isolation (Phases 1-5 as documented below).
54
55	### Complexity Tiers (DAG Stage Selection)
56
57	Before decomposing, classify the task into a complexity tier. Each tier defines a different DAG (directed acyclic graph) of stages, ensuring the right amount of process for the task's complexity.
58
59	\| Tier \| Signals \| DAG Stages \| Context Windows \|
60	\|------\|---------\|------------\|-----------------\|
61	\| Trivial \| ≤3 files, single module, no shared contracts \| impl → test \| 1 (single cook) \|
62	\| Medium \| 4-10 files, 2-3 modules, shared interfaces \| research → plan → impl → test → review → fix \| 3 (plan, impl+test, review+fix) \|
63	\| Large \| 10+ files, 3+ modules, breaking changes or RFC \| research → plan → impl → test → review₁ → fix → review₂ → final merge \| 4+ (plan, impl+test, review₁+fix, review₂+merge) \|
64
65	Key principle — reviewer isolation: The agent that writes code MUST NOT review its own code. Each review stage uses a separate context window (separate Task invocation) that has never seen the implementation reasoning. This prevents author bias from contaminating the review.
66
67	Stage → Context Window mapping:
68	- `research + plan` = Context Window 1 (opus — architectural reasoning)
69	- `impl + test` = Context Window 2 (sonnet — code writing)
70	- `review₁ + fix` = Context Window 3 (sonnet — fresh eyes, no impl context)
71	- `review₂ + merge` = Context Window 4 (sonnet — final verification, Large tier only)
72
73	Merge queue: When multiple streams complete at different times, use dependency order for merging. If a later stream's merge creates conflicts with an already-merged stream, provide the conflicting stream's cook report as conflict context to the resolution agent — never resolve blindly.
74
75	## Calls (outbound)
76
77	- `plan` (L2): high-level task decomposition into independent workstreams
78	- `scout` (L2): understand full project scope and module boundaries
79	# Exception: L1→L1 meta-orchestration (team is the only L1 that calls other L1s)
80	- `cook` (L1): delegate feature tasks to parallel instances (worktree isolation)
81	- `launch` (L1): delegate deployment/marketing when build is complete
82	- `rescue` (L1): delegate legacy refactoring when rescue work detected
83	- `integrity-check` (L3): verify cook report integrity before merge
84	- `completion-gate` (L3): validate workstream completion claims against evidence
85	- `constraint-check` (L3): audit HARD-GATE compliance across parallel streams
86	- `scope-guard` (L3): pre-merge scope verification — validate each stream's actual file changes against declared ownership
87	- `worktree` (L3): cr

People who liked this also viewed

6 picks

Type

team

80stars21forks

View on GitHub

How to install team?

rune-kit/rune/team

$npx -y skills add Rune-kit/rune --skill team

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# team
2
3	## Purpose
4
5	Meta-orchestrator for complex tasks requiring parallel workstreams. Team decomposes large features into independent subtasks, assigns each to an isolated cook instance (using git worktrees), coordinates progress, and merges results. Uses opus for strategic decomposition and conflict resolution.
6
7	<HARD-GATE>
8	- MAX 3 PARALLEL AGENTS: Never launch more than 3 Task calls simultaneously. If more than 3 streams exist, batch them.
9	- No merge without conflict resolution complete (Phase 3 clean).
10	- Full integration tests MUST run before reporting success.
11	</HARD-GATE>
12
13	## Triggers
14
15	- `/rune team <task>` — manual invocation for large features
16	- Auto-trigger: when task affects 5+ files or spans 3+ modules
17
18	## Mode Selection (Auto-Detect)
19
20	```
21	IF streams ≤ 2 AND total files ≤ 5:
22	→ LITE MODE (lightweight parallel, no worktrees)
23	ELSE:
24	→ FULL MODE (worktree isolation, opus coordination)
25	```
26
27	### Lite Mode
28
29	For small parallel tasks that don't warrant full worktree isolation:
30
31	```
32	Lite Mode Rules:
33	- Max 2 parallel agents (haiku coordination, sonnet workers)
34	- NO worktree creation — agents work on same branch
35	- File ownership still enforced (disjoint file sets)
36	- Simplified merge: sequential git add (no merge conflicts possible with disjoint files)
37	- Skip Phase 3 (COORDINATE) — no conflicts with disjoint files
38	- Skip integrity-check — small scope, direct output review
39	- Coordinator model: haiku (not opus) — saves cost
40
41	Lite Mode Phases:
42	Phase 1: DECOMPOSE (haiku) — identify 2 streams with disjoint files
43	Phase 2: ASSIGN — launch 2 parallel Task agents (sonnet, no worktree)
44	Phase 4: MERGE — sequential git add (no merge needed)
45	Phase 5: VERIFY — integration tests on result
46	```
47
48	Announce mode: "Team lite mode: 2 streams, ≤5 files, no worktrees needed."
49	Override: User can say "full mode" to force worktree isolation.
50
51	### Full Mode
52
53	Standard team workflow with worktree isolation (Phases 1-5 as documented below).
54
55	### Complexity Tiers (DAG Stage Selection)
56
57	Before decomposing, classify the task into a complexity tier. Each tier defines a different DAG (directed acyclic graph) of stages, ensuring the right amount of process for the task's complexity.
58
59	\| Tier \| Signals \| DAG Stages \| Context Windows \|
60	\|------\|---------\|------------\|-----------------\|
61	\| Trivial \| ≤3 files, single module, no shared contracts \| impl → test \| 1 (single cook) \|
62	\| Medium \| 4-10 files, 2-3 modules, shared interfaces \| research → plan → impl → test → review → fix \| 3 (plan, impl+test, review+fix) \|
63	\| Large \| 10+ files, 3+ modules, breaking changes or RFC \| research → plan → impl → test → review₁ → fix → review₂ → final merge \| 4+ (plan, impl+test, review₁+fix, review₂+merge) \|
64
65	Key principle — reviewer isolation: The agent that writes code MUST NOT review its own code. Each review stage uses a separate context window (separate Task invocation) that has never seen the implementation reasoning. This prevents author bias from contaminating the review.
66
67	Stage → Context Window mapping:
68	- `research + plan` = Context Window 1 (opus — architectural reasoning)
69	- `impl + test` = Context Window 2 (sonnet — code writing)
70	- `review₁ + fix` = Context Window 3 (sonnet — fresh eyes, no impl context)
71	- `review₂ + merge` = Context Window 4 (sonnet — final verification, Large tier only)
72
73	Merge queue: When multiple streams complete at different times, use dependency order for merging. If a later stream's merge creates conflicts with an already-merged stream, provide the conflicting stream's cook report as conflict context to the resolution agent — never resolve blindly.
74
75	## Calls (outbound)
76
77	- `plan` (L2): high-level task decomposition into independent workstreams
78	- `scout` (L2): understand full project scope and module boundaries
79	# Exception: L1→L1 meta-orchestration (team is the only L1 that calls other L1s)
80	- `cook` (L1): delegate feature tasks to parallel instances (worktree isolation)
81	- `launch` (L1): delegate deployment/marketing when build is complete
82	- `rescue` (L1): delegate legacy refactoring when rescue work detected
83	- `integrity-check` (L3): verify cook report integrity before merge
84	- `completion-gate` (L3): validate workstream completion claims against evidence
85	- `constraint-check` (L3): audit HARD-GATE compliance across parallel streams
86	- `scope-guard` (L3): pre-merge scope verification — validate each stream's actual file changes against declared ownership
87	- `worktree` (L3): cr

People who liked this also viewed

6 picks

Type