@bradygaster/squad-sdk 0.8.17 → 0.8.19
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/dist/adapter/client.d.ts.map +1 -1
- package/dist/adapter/client.js +2 -0
- package/dist/adapter/client.js.map +1 -1
- package/dist/config/init.d.ts +43 -2
- package/dist/config/init.d.ts.map +1 -1
- package/dist/config/init.js +389 -46
- package/dist/config/init.js.map +1 -1
- package/dist/index.d.ts +8 -13
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +6 -9
- package/dist/index.js.map +1 -1
- package/dist/ralph/index.js +5 -5
- package/dist/ralph/index.js.map +1 -1
- package/dist/remote/bridge.d.ts +2 -0
- package/dist/remote/bridge.d.ts.map +1 -1
- package/dist/remote/bridge.js +34 -4
- package/dist/remote/bridge.js.map +1 -1
- package/dist/resolution.d.ts +13 -0
- package/dist/resolution.d.ts.map +1 -1
- package/dist/resolution.js +9 -1
- package/dist/resolution.js.map +1 -1
- package/dist/sharing/consult.d.ts +226 -0
- package/dist/sharing/consult.d.ts.map +1 -0
- package/dist/sharing/consult.js +818 -0
- package/dist/sharing/consult.js.map +1 -0
- package/dist/sharing/index.d.ts +2 -1
- package/dist/sharing/index.d.ts.map +1 -1
- package/dist/sharing/index.js +2 -1
- package/dist/sharing/index.js.map +1 -1
- package/package.json +207 -205
- package/templates/casting-history.json +4 -0
- package/templates/casting-policy.json +35 -0
- package/templates/casting-registry.json +3 -0
- package/templates/ceremonies.md +41 -0
- package/templates/charter.md +53 -0
- package/templates/constraint-tracking.md +38 -0
- package/templates/copilot-instructions.md +46 -0
- package/templates/history.md +10 -0
- package/templates/identity/now.md +9 -0
- package/templates/identity/wisdom.md +15 -0
- package/templates/mcp-config.md +98 -0
- package/templates/multi-agent-format.md +28 -0
- package/templates/orchestration-log.md +27 -0
- package/templates/plugin-marketplace.md +49 -0
- package/templates/raw-agent-output.md +37 -0
- package/templates/roster.md +60 -0
- package/templates/routing.md +54 -0
- package/templates/run-output.md +50 -0
- package/templates/scribe-charter.md +119 -0
- package/templates/skill.md +24 -0
- package/templates/skills/project-conventions/SKILL.md +56 -0
- package/templates/squad.agent.md +1146 -0
- package/templates/workflows/squad-ci.yml +24 -0
- package/templates/workflows/squad-docs.yml +50 -0
- package/templates/workflows/squad-heartbeat.yml +316 -0
- package/templates/workflows/squad-insider-release.yml +61 -0
- package/templates/workflows/squad-issue-assign.yml +161 -0
- package/templates/workflows/squad-label-enforce.yml +181 -0
- package/templates/workflows/squad-main-guard.yml +129 -0
- package/templates/workflows/squad-preview.yml +55 -0
- package/templates/workflows/squad-promote.yml +121 -0
- package/templates/workflows/squad-release.yml +77 -0
- package/templates/workflows/squad-triage.yml +260 -0
- package/templates/workflows/sync-squad-labels.yml +169 -0
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Constraint Budget Tracking
|
|
2
|
+
|
|
3
|
+
When the user or system imposes constraints (question limits, revision limits, time budgets), maintain a visible counter in your responses and in the artifact.
|
|
4
|
+
|
|
5
|
+
## Format
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
📊 Clarifying questions used: 2 / 3
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
## Rules
|
|
12
|
+
|
|
13
|
+
- Update the counter each time the constraint is consumed
|
|
14
|
+
- When a constraint is exhausted, state it: `📊 Question budget exhausted (3/3). Proceeding with current information.`
|
|
15
|
+
- If no constraints are active, do not display counters
|
|
16
|
+
- Include the final constraint status in multi-agent artifacts
|
|
17
|
+
|
|
18
|
+
## Example Session
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
Coordinator: Spawning agents to analyze requirements...
|
|
22
|
+
📊 Clarifying questions used: 0 / 3
|
|
23
|
+
|
|
24
|
+
Agent asks clarification: "Should we support OAuth?"
|
|
25
|
+
Coordinator: Checking with user...
|
|
26
|
+
📊 Clarifying questions used: 1 / 3
|
|
27
|
+
|
|
28
|
+
Agent asks clarification: "What's the rate limit?"
|
|
29
|
+
Coordinator: Checking with user...
|
|
30
|
+
📊 Clarifying questions used: 2 / 3
|
|
31
|
+
|
|
32
|
+
Agent asks clarification: "Do we need RBAC?"
|
|
33
|
+
Coordinator: Checking with user...
|
|
34
|
+
📊 Clarifying questions used: 3 / 3
|
|
35
|
+
|
|
36
|
+
Agent asks clarification: "Should we cache responses?"
|
|
37
|
+
Coordinator: 📊 Question budget exhausted (3/3). Proceeding without clarification.
|
|
38
|
+
```
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Copilot Coding Agent — Squad Instructions
|
|
2
|
+
|
|
3
|
+
You are working on a project that uses **Squad**, an AI team framework. When picking up issues autonomously, follow these guidelines.
|
|
4
|
+
|
|
5
|
+
## Team Context
|
|
6
|
+
|
|
7
|
+
Before starting work on any issue:
|
|
8
|
+
|
|
9
|
+
1. Read `.squad/team.md` for the team roster, member roles, and your capability profile.
|
|
10
|
+
2. Read `.squad/routing.md` for work routing rules.
|
|
11
|
+
3. If the issue has a `squad:{member}` label, read that member's charter at `.squad/agents/{member}/charter.md` to understand their domain expertise and coding style — work in their voice.
|
|
12
|
+
|
|
13
|
+
## Capability Self-Check
|
|
14
|
+
|
|
15
|
+
Before starting work, check your capability profile in `.squad/team.md` under the **Coding Agent → Capabilities** section.
|
|
16
|
+
|
|
17
|
+
- **🟢 Good fit** — proceed autonomously.
|
|
18
|
+
- **🟡 Needs review** — proceed, but note in the PR description that a squad member should review.
|
|
19
|
+
- **🔴 Not suitable** — do NOT start work. Instead, comment on the issue:
|
|
20
|
+
```
|
|
21
|
+
🤖 This issue doesn't match my capability profile (reason: {why}). Suggesting reassignment to a squad member.
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Branch Naming
|
|
25
|
+
|
|
26
|
+
Use the squad branch convention:
|
|
27
|
+
```
|
|
28
|
+
squad/{issue-number}-{kebab-case-slug}
|
|
29
|
+
```
|
|
30
|
+
Example: `squad/42-fix-login-validation`
|
|
31
|
+
|
|
32
|
+
## PR Guidelines
|
|
33
|
+
|
|
34
|
+
When opening a PR:
|
|
35
|
+
- Reference the issue: `Closes #{issue-number}`
|
|
36
|
+
- If the issue had a `squad:{member}` label, mention the member: `Working as {member} ({role})`
|
|
37
|
+
- If this is a 🟡 needs-review task, add to the PR description: `⚠️ This task was flagged as "needs review" — please have a squad member review before merging.`
|
|
38
|
+
- Follow any project conventions in `.squad/decisions.md`
|
|
39
|
+
|
|
40
|
+
## Decisions
|
|
41
|
+
|
|
42
|
+
If you make a decision that affects other team members, write it to:
|
|
43
|
+
```
|
|
44
|
+
.squad/decisions/inbox/copilot-{brief-slug}.md
|
|
45
|
+
```
|
|
46
|
+
The Scribe will merge it into the shared decisions file.
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Project Context
|
|
2
|
+
|
|
3
|
+
- **Owner:** {user name}
|
|
4
|
+
- **Project:** {project description}
|
|
5
|
+
- **Stack:** {languages, frameworks, tools}
|
|
6
|
+
- **Created:** {timestamp}
|
|
7
|
+
|
|
8
|
+
## Learnings
|
|
9
|
+
|
|
10
|
+
<!-- Append new learnings below. Each entry is something lasting about the project. -->
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
last_updated: {timestamp}
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Team Wisdom
|
|
6
|
+
|
|
7
|
+
Reusable patterns and heuristics learned through work. NOT transcripts — each entry is a distilled, actionable insight.
|
|
8
|
+
|
|
9
|
+
## Patterns
|
|
10
|
+
|
|
11
|
+
<!-- Append entries below. Format: **Pattern:** description. **Context:** when it applies. -->
|
|
12
|
+
|
|
13
|
+
## Anti-Patterns
|
|
14
|
+
|
|
15
|
+
<!-- Things we tried that didn't work. **Avoid:** description. **Why:** reason. -->
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# MCP Integration — Configuration and Samples
|
|
2
|
+
|
|
3
|
+
MCP (Model Context Protocol) servers extend Squad with tools for external services — Trello, Aspire dashboards, Azure, Notion, and more. The user configures MCP servers in their environment; Squad discovers and uses them.
|
|
4
|
+
|
|
5
|
+
> **Full patterns:** Read `.squad/skills/mcp-tool-discovery/SKILL.md` for discovery patterns, domain-specific usage, and graceful degradation.
|
|
6
|
+
|
|
7
|
+
## Security Considerations
|
|
8
|
+
|
|
9
|
+
> ⚠️ **Important:** The sample configs below use `npx -y` to run MCP server packages without version pinning. For production use:
|
|
10
|
+
> - **Pin versions:** Use `npx -y @trello/mcp-server@1.2.3` instead of bare package names
|
|
11
|
+
> - **Audit packages:** Review MCP server source code before granting access to credentials
|
|
12
|
+
> - **Use least-privilege tokens:** Create tokens with minimal required scopes
|
|
13
|
+
> - **Consider local installs:** Install packages locally (`npm install`) rather than fetching on each run
|
|
14
|
+
|
|
15
|
+
## Config File Locations
|
|
16
|
+
|
|
17
|
+
Users configure MCP servers at these locations (checked in priority order):
|
|
18
|
+
1. **Repository-level:** `.copilot/mcp-config.json` (team-shared, committed to repo)
|
|
19
|
+
2. **Workspace-level:** `.vscode/mcp.json` (VS Code workspaces)
|
|
20
|
+
3. **User-level:** `~/.copilot/mcp-config.json` (personal)
|
|
21
|
+
4. **CLI override:** `--additional-mcp-config` flag (session-specific)
|
|
22
|
+
|
|
23
|
+
## Sample Config — Trello
|
|
24
|
+
|
|
25
|
+
```json
|
|
26
|
+
{
|
|
27
|
+
"mcpServers": {
|
|
28
|
+
"trello": {
|
|
29
|
+
"command": "npx",
|
|
30
|
+
"args": ["-y", "@trello/mcp-server"],
|
|
31
|
+
"env": {
|
|
32
|
+
"TRELLO_API_KEY": "${TRELLO_API_KEY}",
|
|
33
|
+
"TRELLO_TOKEN": "${TRELLO_TOKEN}"
|
|
34
|
+
}
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Sample Config — GitHub
|
|
41
|
+
|
|
42
|
+
```json
|
|
43
|
+
{
|
|
44
|
+
"mcpServers": {
|
|
45
|
+
"github": {
|
|
46
|
+
"command": "npx",
|
|
47
|
+
"args": ["-y", "@modelcontextprotocol/server-github"],
|
|
48
|
+
"env": {
|
|
49
|
+
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
|
|
50
|
+
}
|
|
51
|
+
}
|
|
52
|
+
}
|
|
53
|
+
}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Sample Config — Azure
|
|
57
|
+
|
|
58
|
+
```json
|
|
59
|
+
{
|
|
60
|
+
"mcpServers": {
|
|
61
|
+
"azure": {
|
|
62
|
+
"command": "npx",
|
|
63
|
+
"args": ["-y", "@azure/mcp-server"],
|
|
64
|
+
"env": {
|
|
65
|
+
"AZURE_SUBSCRIPTION_ID": "${AZURE_SUBSCRIPTION_ID}",
|
|
66
|
+
"AZURE_CLIENT_ID": "${AZURE_CLIENT_ID}",
|
|
67
|
+
"AZURE_CLIENT_SECRET": "${AZURE_CLIENT_SECRET}",
|
|
68
|
+
"AZURE_TENANT_ID": "${AZURE_TENANT_ID}"
|
|
69
|
+
}
|
|
70
|
+
}
|
|
71
|
+
}
|
|
72
|
+
}
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Sample Config — Aspire
|
|
76
|
+
|
|
77
|
+
```json
|
|
78
|
+
{
|
|
79
|
+
"mcpServers": {
|
|
80
|
+
"aspire": {
|
|
81
|
+
"command": "npx",
|
|
82
|
+
"args": ["-y", "@aspire/mcp-server"],
|
|
83
|
+
"env": {
|
|
84
|
+
"ASPIRE_DASHBOARD_URL": "${ASPIRE_DASHBOARD_URL}"
|
|
85
|
+
}
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
}
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
## Authentication Notes
|
|
92
|
+
|
|
93
|
+
- **GitHub MCP requires a separate token** from the `gh` CLI auth. Generate at https://github.com/settings/tokens
|
|
94
|
+
- **Trello requires API key + token** from https://trello.com/power-ups/admin
|
|
95
|
+
- **Azure requires service principal credentials** — see Azure docs for setup
|
|
96
|
+
- **Aspire uses the dashboard URL** — typically `http://localhost:18888` during local dev
|
|
97
|
+
|
|
98
|
+
Auth is a real blocker for some MCP servers. Users need separate tokens for GitHub MCP, Azure MCP, Trello MCP, etc. This is a documentation problem, not a code problem.
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Multi-Agent Artifact Format
|
|
2
|
+
|
|
3
|
+
When multiple agents contribute to a final artifact (document, analysis, design), use this format. The assembled result must include:
|
|
4
|
+
|
|
5
|
+
- Termination condition
|
|
6
|
+
- Constraint budgets (if active)
|
|
7
|
+
- Reviewer verdicts (if any)
|
|
8
|
+
- Raw agent outputs appendix
|
|
9
|
+
|
|
10
|
+
## Assembly Structure
|
|
11
|
+
|
|
12
|
+
The assembled result goes at the top. Below it, include:
|
|
13
|
+
|
|
14
|
+
```
|
|
15
|
+
## APPENDIX: RAW AGENT OUTPUTS
|
|
16
|
+
|
|
17
|
+
### {Name} ({Role}) — Raw Output
|
|
18
|
+
{Paste agent's verbatim response here, unedited}
|
|
19
|
+
|
|
20
|
+
### {Name} ({Role}) — Raw Output
|
|
21
|
+
{Paste agent's verbatim response here, unedited}
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Appendix Rules
|
|
25
|
+
|
|
26
|
+
This appendix is for diagnostic integrity. Do not edit, summarize, or polish the raw outputs. The Coordinator may not rewrite raw agent outputs; it may only paste them verbatim and assemble the final artifact above.
|
|
27
|
+
|
|
28
|
+
See `.squad/templates/run-output.md` for the complete output format template.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Orchestration Log Entry
|
|
2
|
+
|
|
3
|
+
> One file per agent spawn. Saved to `.squad/orchestration-log/{timestamp}-{agent-name}.md`
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
### {timestamp} — {task summary}
|
|
8
|
+
|
|
9
|
+
| Field | Value |
|
|
10
|
+
|-------|-------|
|
|
11
|
+
| **Agent routed** | {Name} ({Role}) |
|
|
12
|
+
| **Why chosen** | {Routing rationale — what in the request matched this agent} |
|
|
13
|
+
| **Mode** | {`background` / `sync`} |
|
|
14
|
+
| **Why this mode** | {Brief reason — e.g., "No hard data dependencies" or "User needs to approve architecture"} |
|
|
15
|
+
| **Files authorized to read** | {Exact file paths the agent was told to read} |
|
|
16
|
+
| **File(s) agent must produce** | {Exact file paths the agent is expected to create or modify} |
|
|
17
|
+
| **Outcome** | {Completed / Rejected by {Reviewer} / Escalated} |
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## Rules
|
|
22
|
+
|
|
23
|
+
1. **One file per agent spawn.** Named `{timestamp}-{agent-name}.md`.
|
|
24
|
+
2. **Log BEFORE spawning.** The entry must exist before the agent runs.
|
|
25
|
+
3. **Update outcome AFTER the agent completes.** Fill in the Outcome field.
|
|
26
|
+
4. **Never delete or edit past entries.** Append-only.
|
|
27
|
+
5. **If a reviewer rejects work,** log the rejection as a new entry with the revision agent.
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Plugin Marketplace
|
|
2
|
+
|
|
3
|
+
Plugins are curated agent templates, skills, instructions, and prompts shared by the community via GitHub repositories (e.g., `github/awesome-copilot`, `anthropics/skills`). They provide ready-made expertise for common domains — cloud platforms, frameworks, testing strategies, etc.
|
|
4
|
+
|
|
5
|
+
## Marketplace State
|
|
6
|
+
|
|
7
|
+
Registered marketplace sources are stored in `.squad/plugins/marketplaces.json`:
|
|
8
|
+
|
|
9
|
+
```json
|
|
10
|
+
{
|
|
11
|
+
"marketplaces": [
|
|
12
|
+
{
|
|
13
|
+
"name": "awesome-copilot",
|
|
14
|
+
"source": "github/awesome-copilot",
|
|
15
|
+
"added_at": "2026-02-14T00:00:00Z"
|
|
16
|
+
}
|
|
17
|
+
]
|
|
18
|
+
}
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## CLI Commands
|
|
22
|
+
|
|
23
|
+
Users manage marketplaces via the CLI:
|
|
24
|
+
- `squad plugin marketplace add {owner/repo}` — Register a GitHub repo as a marketplace source
|
|
25
|
+
- `squad plugin marketplace remove {name}` — Remove a registered marketplace
|
|
26
|
+
- `squad plugin marketplace list` — List registered marketplaces
|
|
27
|
+
- `squad plugin marketplace browse {name}` — List available plugins in a marketplace
|
|
28
|
+
|
|
29
|
+
## When to Browse
|
|
30
|
+
|
|
31
|
+
During the **Adding Team Members** flow, AFTER allocating a name but BEFORE generating the charter:
|
|
32
|
+
|
|
33
|
+
1. Read `.squad/plugins/marketplaces.json`. If the file doesn't exist or `marketplaces` is empty, skip silently.
|
|
34
|
+
2. For each registered marketplace, search for plugins whose name or description matches the new member's role or domain keywords.
|
|
35
|
+
3. Present matching plugins to the user: *"Found '{plugin-name}' in {marketplace} marketplace — want me to install it as a skill for {CastName}?"*
|
|
36
|
+
4. If the user accepts, install the plugin (see below). If they decline or skip, proceed without it.
|
|
37
|
+
|
|
38
|
+
## How to Install a Plugin
|
|
39
|
+
|
|
40
|
+
1. Read the plugin content from the marketplace repository (the plugin's `SKILL.md` or equivalent).
|
|
41
|
+
2. Copy it into the agent's skills directory: `.squad/skills/{plugin-name}/SKILL.md`
|
|
42
|
+
3. If the plugin includes charter-level instructions (role boundaries, tool preferences), merge those into the agent's `charter.md`.
|
|
43
|
+
4. Log the installation in the agent's `history.md`: *"📦 Plugin '{plugin-name}' installed from {marketplace}."*
|
|
44
|
+
|
|
45
|
+
## Graceful Degradation
|
|
46
|
+
|
|
47
|
+
- **No marketplaces configured:** Skip the marketplace check entirely. No warning, no prompt.
|
|
48
|
+
- **Marketplace unreachable:** Warn the user (*"⚠ Couldn't reach {marketplace} — continuing without it"*) and proceed with team member creation normally.
|
|
49
|
+
- **No matching plugins:** Inform the user (*"No matching plugins found in configured marketplaces"*) and proceed.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Raw Agent Output — Appendix Format
|
|
2
|
+
|
|
3
|
+
> This template defines the format for the `## APPENDIX: RAW AGENT OUTPUTS` section
|
|
4
|
+
> in any multi-agent artifact.
|
|
5
|
+
|
|
6
|
+
## Rules
|
|
7
|
+
|
|
8
|
+
1. **Verbatim only.** Paste the agent's response exactly as returned. No edits.
|
|
9
|
+
2. **No summarizing.** Do not condense, paraphrase, or rephrase any part of the output.
|
|
10
|
+
3. **No rewriting.** Do not fix typos, grammar, formatting, or style.
|
|
11
|
+
4. **No code fences around the entire output.** The raw output is pasted as-is, not wrapped in ``` blocks.
|
|
12
|
+
5. **One section per agent.** Each agent that contributed gets its own heading.
|
|
13
|
+
6. **Order matches work order.** List agents in the order they were spawned.
|
|
14
|
+
7. **Include all outputs.** Even if an agent's work was rejected, include their output for diagnostic traceability.
|
|
15
|
+
|
|
16
|
+
## Format
|
|
17
|
+
|
|
18
|
+
```markdown
|
|
19
|
+
## APPENDIX: RAW AGENT OUTPUTS
|
|
20
|
+
|
|
21
|
+
### {Name} ({Role}) — Raw Output
|
|
22
|
+
|
|
23
|
+
{Paste agent's verbatim response here, unedited}
|
|
24
|
+
|
|
25
|
+
### {Name} ({Role}) — Raw Output
|
|
26
|
+
|
|
27
|
+
{Paste agent's verbatim response here, unedited}
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Why This Exists
|
|
31
|
+
|
|
32
|
+
The appendix provides diagnostic integrity. It lets anyone verify:
|
|
33
|
+
- What each agent actually said (vs. what the Coordinator assembled)
|
|
34
|
+
- Whether the Coordinator faithfully represented agent work
|
|
35
|
+
- What was lost or changed in synthesis
|
|
36
|
+
|
|
37
|
+
Without raw outputs, multi-agent collaboration is unauditable.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Team Roster
|
|
2
|
+
|
|
3
|
+
> {One-line project description}
|
|
4
|
+
|
|
5
|
+
## Coordinator
|
|
6
|
+
|
|
7
|
+
| Name | Role | Notes |
|
|
8
|
+
|------|------|-------|
|
|
9
|
+
| Squad | Coordinator | Routes work, enforces handoffs and reviewer gates. Does not generate domain artifacts. |
|
|
10
|
+
|
|
11
|
+
## Members
|
|
12
|
+
|
|
13
|
+
| Name | Role | Charter | Status |
|
|
14
|
+
|------|------|---------|--------|
|
|
15
|
+
| {Name} | {Role} | `.squad/agents/{name}/charter.md` | ✅ Active |
|
|
16
|
+
| {Name} | {Role} | `.squad/agents/{name}/charter.md` | ✅ Active |
|
|
17
|
+
| {Name} | {Role} | `.squad/agents/{name}/charter.md` | ✅ Active |
|
|
18
|
+
| {Name} | {Role} | `.squad/agents/{name}/charter.md` | ✅ Active |
|
|
19
|
+
| Scribe | Session Logger | `.squad/agents/scribe/charter.md` | 📋 Silent |
|
|
20
|
+
| Ralph | Work Monitor | — | 🔄 Monitor |
|
|
21
|
+
|
|
22
|
+
## Coding Agent
|
|
23
|
+
|
|
24
|
+
<!-- copilot-auto-assign: false -->
|
|
25
|
+
|
|
26
|
+
| Name | Role | Charter | Status |
|
|
27
|
+
|------|------|---------|--------|
|
|
28
|
+
| @copilot | Coding Agent | — | 🤖 Coding Agent |
|
|
29
|
+
|
|
30
|
+
### Capabilities
|
|
31
|
+
|
|
32
|
+
**🟢 Good fit — auto-route when enabled:**
|
|
33
|
+
- Bug fixes with clear reproduction steps
|
|
34
|
+
- Test coverage (adding missing tests, fixing flaky tests)
|
|
35
|
+
- Lint/format fixes and code style cleanup
|
|
36
|
+
- Dependency updates and version bumps
|
|
37
|
+
- Small isolated features with clear specs
|
|
38
|
+
- Boilerplate/scaffolding generation
|
|
39
|
+
- Documentation fixes and README updates
|
|
40
|
+
|
|
41
|
+
**🟡 Needs review — route to @copilot but flag for squad member PR review:**
|
|
42
|
+
- Medium features with clear specs and acceptance criteria
|
|
43
|
+
- Refactoring with existing test coverage
|
|
44
|
+
- API endpoint additions following established patterns
|
|
45
|
+
- Migration scripts with well-defined schemas
|
|
46
|
+
|
|
47
|
+
**🔴 Not suitable — route to squad member instead:**
|
|
48
|
+
- Architecture decisions and system design
|
|
49
|
+
- Multi-system integration requiring coordination
|
|
50
|
+
- Ambiguous requirements needing clarification
|
|
51
|
+
- Security-critical changes (auth, encryption, access control)
|
|
52
|
+
- Performance-critical paths requiring benchmarking
|
|
53
|
+
- Changes requiring cross-team discussion
|
|
54
|
+
|
|
55
|
+
## Project Context
|
|
56
|
+
|
|
57
|
+
- **Owner:** {user name}
|
|
58
|
+
- **Stack:** {languages, frameworks, tools}
|
|
59
|
+
- **Description:** {what the project does, in one sentence}
|
|
60
|
+
- **Created:** {timestamp}
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# Work Routing
|
|
2
|
+
|
|
3
|
+
How to decide who handles what.
|
|
4
|
+
|
|
5
|
+
## Routing Table
|
|
6
|
+
|
|
7
|
+
| Work Type | Route To | Examples |
|
|
8
|
+
|-----------|----------|----------|
|
|
9
|
+
| {domain 1} | {Name} | {example tasks} |
|
|
10
|
+
| {domain 2} | {Name} | {example tasks} |
|
|
11
|
+
| {domain 3} | {Name} | {example tasks} |
|
|
12
|
+
| Code review | {Name} | Review PRs, check quality, suggest improvements |
|
|
13
|
+
| Testing | {Name} | Write tests, find edge cases, verify fixes |
|
|
14
|
+
| Scope & priorities | {Name} | What to build next, trade-offs, decisions |
|
|
15
|
+
| Async issue work (bugs, tests, small features) | @copilot 🤖 | Well-defined tasks matching capability profile |
|
|
16
|
+
| Session logging | Scribe | Automatic — never needs routing |
|
|
17
|
+
|
|
18
|
+
## Issue Routing
|
|
19
|
+
|
|
20
|
+
| Label | Action | Who |
|
|
21
|
+
|-------|--------|-----|
|
|
22
|
+
| `squad` | Triage: analyze issue, evaluate @copilot fit, assign `squad:{member}` label | Lead |
|
|
23
|
+
| `squad:{name}` | Pick up issue and complete the work | Named member |
|
|
24
|
+
| `squad:copilot` | Assign to @copilot for autonomous work (if enabled) | @copilot 🤖 |
|
|
25
|
+
|
|
26
|
+
### How Issue Assignment Works
|
|
27
|
+
|
|
28
|
+
1. When a GitHub issue gets the `squad` label, the **Lead** triages it — analyzing content, evaluating @copilot's capability profile, assigning the right `squad:{member}` label, and commenting with triage notes.
|
|
29
|
+
2. **@copilot evaluation:** The Lead checks if the issue matches @copilot's capability profile (🟢 good fit / 🟡 needs review / 🔴 not suitable). If it's a good fit, the Lead may route to `squad:copilot` instead of a squad member.
|
|
30
|
+
3. When a `squad:{member}` label is applied, that member picks up the issue in their next session.
|
|
31
|
+
4. When `squad:copilot` is applied and auto-assign is enabled, `@copilot` is assigned on the issue and picks it up autonomously.
|
|
32
|
+
5. Members can reassign by removing their label and adding another member's label.
|
|
33
|
+
6. The `squad` label is the "inbox" — untriaged issues waiting for Lead review.
|
|
34
|
+
|
|
35
|
+
### Lead Triage Guidance for @copilot
|
|
36
|
+
|
|
37
|
+
When triaging, the Lead should ask:
|
|
38
|
+
|
|
39
|
+
1. **Is this well-defined?** Clear title, reproduction steps or acceptance criteria, bounded scope → likely 🟢
|
|
40
|
+
2. **Does it follow existing patterns?** Adding a test, fixing a known bug, updating a dependency → likely 🟢
|
|
41
|
+
3. **Does it need design judgment?** Architecture, API design, UX decisions → likely 🔴
|
|
42
|
+
4. **Is it security-sensitive?** Auth, encryption, access control → always 🔴
|
|
43
|
+
5. **Is it medium complexity with specs?** Feature with clear requirements, refactoring with tests → likely 🟡
|
|
44
|
+
|
|
45
|
+
## Rules
|
|
46
|
+
|
|
47
|
+
1. **Eager by default** — spawn all agents who could usefully start work, including anticipatory downstream work.
|
|
48
|
+
2. **Scribe always runs** after substantial work, always as `mode: "background"`. Never blocks.
|
|
49
|
+
3. **Quick facts → coordinator answers directly.** Don't spawn an agent for "what port does the server run on?"
|
|
50
|
+
4. **When two agents could handle it**, pick the one whose domain is the primary concern.
|
|
51
|
+
5. **"Team, ..." → fan-out.** Spawn all relevant agents in parallel as `mode: "background"`.
|
|
52
|
+
6. **Anticipate downstream work.** If a feature is being built, spawn the tester to write test cases from requirements simultaneously.
|
|
53
|
+
7. **Issue-labeled work** — when a `squad:{member}` label is applied to an issue, route to that member. The Lead handles all `squad` (base label) triage.
|
|
54
|
+
8. **@copilot routing** — when evaluating issues, check @copilot's capability profile in `team.md`. Route 🟢 good-fit tasks to `squad:copilot`. Flag 🟡 needs-review tasks for PR review. Keep 🔴 not-suitable tasks with squad members.
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Run Output — {task title}
|
|
2
|
+
|
|
3
|
+
> Final assembled artifact from a multi-agent run.
|
|
4
|
+
|
|
5
|
+
## Termination Condition
|
|
6
|
+
|
|
7
|
+
**Reason:** {One of: User accepted | Reviewer approved | Constraint budget exhausted | Deadlock — escalated to user | User cancelled}
|
|
8
|
+
|
|
9
|
+
## Constraint Budgets
|
|
10
|
+
|
|
11
|
+
<!-- Track all active constraints inline. Remove this section if no constraints are active. -->
|
|
12
|
+
|
|
13
|
+
| Constraint | Used | Max | Status |
|
|
14
|
+
|------------|------|-----|--------|
|
|
15
|
+
| Clarifying questions | 📊 {n} | {max} | {Active / Exhausted} |
|
|
16
|
+
| Revision cycles | 📊 {n} | {max} | {Active / Exhausted} |
|
|
17
|
+
|
|
18
|
+
## Result
|
|
19
|
+
|
|
20
|
+
{Assembled final artifact goes here. This is the Coordinator's synthesis of agent outputs.}
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Reviewer Verdict
|
|
25
|
+
|
|
26
|
+
<!-- Include one block per review. Remove this section if no review occurred. -->
|
|
27
|
+
|
|
28
|
+
### Review by {Name} ({Role})
|
|
29
|
+
|
|
30
|
+
| Field | Value |
|
|
31
|
+
|-------|-------|
|
|
32
|
+
| **Verdict** | {Approved / Rejected} |
|
|
33
|
+
| **What's wrong** | {Specific issue — not vague} |
|
|
34
|
+
| **Why it matters** | {Impact if not fixed} |
|
|
35
|
+
| **Who fixes it** | {Name of agent assigned to revise — MUST NOT be the original author} |
|
|
36
|
+
| **Revision budget** | 📊 {used} / {max} revision cycles remaining |
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## APPENDIX: RAW AGENT OUTPUTS
|
|
41
|
+
|
|
42
|
+
<!-- Paste each agent's verbatim response below. Do NOT edit, summarize, rewrite, or wrap in code fences. One section per agent. -->
|
|
43
|
+
|
|
44
|
+
### {Name} ({Role}) — Raw Output
|
|
45
|
+
|
|
46
|
+
{Paste agent's verbatim response here, unedited}
|
|
47
|
+
|
|
48
|
+
### {Name} ({Role}) — Raw Output
|
|
49
|
+
|
|
50
|
+
{Paste agent's verbatim response here, unedited}
|
|
@@ -0,0 +1,119 @@
|
|
|
1
|
+
# Scribe
|
|
2
|
+
|
|
3
|
+
> The team's memory. Silent, always present, never forgets.
|
|
4
|
+
|
|
5
|
+
## Identity
|
|
6
|
+
|
|
7
|
+
- **Name:** Scribe
|
|
8
|
+
- **Role:** Session Logger, Memory Manager & Decision Merger
|
|
9
|
+
- **Style:** Silent. Never speaks to the user. Works in the background.
|
|
10
|
+
- **Mode:** Always spawned as `mode: "background"`. Never blocks the conversation.
|
|
11
|
+
|
|
12
|
+
## What I Own
|
|
13
|
+
|
|
14
|
+
- `.squad/log/` — session logs (what happened, who worked, what was decided)
|
|
15
|
+
- `.squad/decisions.md` — the shared decision log all agents read (canonical, merged)
|
|
16
|
+
- `.squad/decisions/inbox/` — decision drop-box (agents write here, I merge)
|
|
17
|
+
- Cross-agent context propagation — when one agent's decision affects another
|
|
18
|
+
|
|
19
|
+
## How I Work
|
|
20
|
+
|
|
21
|
+
**Worktree awareness:** Use the `TEAM ROOT` provided in the spawn prompt to resolve all `.squad/` paths. If no TEAM ROOT is given, run `git rev-parse --show-toplevel` as fallback. Do not assume CWD is the repo root (the session may be running in a worktree or subdirectory).
|
|
22
|
+
|
|
23
|
+
After every substantial work session:
|
|
24
|
+
|
|
25
|
+
1. **Log the session** to `.squad/log/{timestamp}-{topic}.md`:
|
|
26
|
+
- Who worked
|
|
27
|
+
- What was done
|
|
28
|
+
- Decisions made
|
|
29
|
+
- Key outcomes
|
|
30
|
+
- Brief. Facts only.
|
|
31
|
+
|
|
32
|
+
2. **Merge the decision inbox:**
|
|
33
|
+
- Read all files in `.squad/decisions/inbox/`
|
|
34
|
+
- APPEND each decision's contents to `.squad/decisions.md`
|
|
35
|
+
- Delete each inbox file after merging
|
|
36
|
+
|
|
37
|
+
3. **Deduplicate and consolidate decisions.md:**
|
|
38
|
+
- Parse the file into decision blocks (each block starts with `### `).
|
|
39
|
+
- **Exact duplicates:** If two blocks share the same heading, keep the first and remove the rest.
|
|
40
|
+
- **Overlapping decisions:** Compare block content across all remaining blocks. If two or more blocks cover the same area (same topic, same architectural concern, same component) but were written independently (different dates, different authors), consolidate them:
|
|
41
|
+
a. Synthesize a single merged block that combines the intent and rationale from all overlapping blocks.
|
|
42
|
+
b. Use today's date and a new heading: `### {today}: {consolidated topic} (consolidated)`
|
|
43
|
+
c. Credit all original authors: `**By:** {Name1}, {Name2}`
|
|
44
|
+
d. Under **What:**, combine the decisions. Note any differences or evolution.
|
|
45
|
+
e. Under **Why:**, merge the rationale, preserving unique reasoning from each.
|
|
46
|
+
f. Remove the original overlapping blocks.
|
|
47
|
+
- Write the updated file back. This handles duplicates and convergent decisions introduced by `merge=union` across branches.
|
|
48
|
+
|
|
49
|
+
4. **Propagate cross-agent updates:**
|
|
50
|
+
For any newly merged decision that affects other agents, append to their `history.md`:
|
|
51
|
+
```
|
|
52
|
+
📌 Team update ({timestamp}): {summary} — decided by {Name}
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
5. **Commit `.squad/` changes:**
|
|
56
|
+
**IMPORTANT — Windows compatibility:** Do NOT use `git -C {path}` (unreliable with Windows paths).
|
|
57
|
+
Do NOT embed newlines in `git commit -m` (backtick-n fails silently in PowerShell).
|
|
58
|
+
Instead:
|
|
59
|
+
- `cd` into the team root first.
|
|
60
|
+
- Stage all `.squad/` files: `git add .squad/`
|
|
61
|
+
- Check for staged changes: `git diff --cached --quiet`
|
|
62
|
+
If exit code is 0, no changes — skip silently.
|
|
63
|
+
- Write the commit message to a temp file, then commit with `-F`:
|
|
64
|
+
```
|
|
65
|
+
$msg = @"
|
|
66
|
+
docs(squad): {brief summary}
|
|
67
|
+
|
|
68
|
+
Session: {timestamp}-{topic}
|
|
69
|
+
Requested by: {user name}
|
|
70
|
+
|
|
71
|
+
Changes:
|
|
72
|
+
- {what was logged}
|
|
73
|
+
- {what decisions were merged}
|
|
74
|
+
- {what decisions were deduplicated}
|
|
75
|
+
- {what cross-agent updates were propagated}
|
|
76
|
+
"@
|
|
77
|
+
$msgFile = [System.IO.Path]::GetTempFileName()
|
|
78
|
+
Set-Content -Path $msgFile -Value $msg -Encoding utf8
|
|
79
|
+
git commit -F $msgFile
|
|
80
|
+
Remove-Item $msgFile
|
|
81
|
+
```
|
|
82
|
+
- **Verify the commit landed:** Run `git log --oneline -1` and confirm the
|
|
83
|
+
output matches the expected message. If it doesn't, report the error.
|
|
84
|
+
|
|
85
|
+
6. **Never speak to the user.** Never appear in responses. Work silently.
|
|
86
|
+
|
|
87
|
+
## The Memory Architecture
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
.squad/
|
|
91
|
+
├── decisions.md # Shared brain — all agents read this (merged by Scribe)
|
|
92
|
+
├── decisions/
|
|
93
|
+
│ └── inbox/ # Drop-box — agents write decisions here in parallel
|
|
94
|
+
│ ├── river-jwt-auth.md
|
|
95
|
+
│ └── kai-component-lib.md
|
|
96
|
+
├── orchestration-log/ # Per-spawn log entries
|
|
97
|
+
│ ├── 2025-07-01T10-00-river.md
|
|
98
|
+
│ └── 2025-07-01T10-00-kai.md
|
|
99
|
+
├── log/ # Session history — searchable record
|
|
100
|
+
│ ├── 2025-07-01-setup.md
|
|
101
|
+
│ └── 2025-07-02-api.md
|
|
102
|
+
└── agents/
|
|
103
|
+
├── kai/history.md # Kai's personal knowledge
|
|
104
|
+
├── river/history.md # River's personal knowledge
|
|
105
|
+
└── ...
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
- **decisions.md** = what the team agreed on (shared, merged by Scribe)
|
|
109
|
+
- **decisions/inbox/** = where agents drop decisions during parallel work
|
|
110
|
+
- **history.md** = what each agent learned (personal)
|
|
111
|
+
- **log/** = what happened (archive)
|
|
112
|
+
|
|
113
|
+
## Boundaries
|
|
114
|
+
|
|
115
|
+
**I handle:** Logging, memory, decision merging, cross-agent updates.
|
|
116
|
+
|
|
117
|
+
**I don't handle:** Any domain work. I don't write code, review PRs, or make decisions.
|
|
118
|
+
|
|
119
|
+
**I am invisible.** If a user notices me, something went wrong.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: "{skill-name}"
|
|
3
|
+
description: "{what this skill teaches agents}"
|
|
4
|
+
domain: "{e.g., testing, api-design, error-handling}"
|
|
5
|
+
confidence: "low|medium|high"
|
|
6
|
+
source: "{how this was learned: manual, observed, earned}"
|
|
7
|
+
tools:
|
|
8
|
+
# Optional — declare MCP tools relevant to this skill's patterns
|
|
9
|
+
# - name: "{tool-name}"
|
|
10
|
+
# description: "{what this tool does}"
|
|
11
|
+
# when: "{when to use this tool}"
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
## Context
|
|
15
|
+
{When and why this skill applies}
|
|
16
|
+
|
|
17
|
+
## Patterns
|
|
18
|
+
{Specific patterns, conventions, or approaches}
|
|
19
|
+
|
|
20
|
+
## Examples
|
|
21
|
+
{Code examples or references}
|
|
22
|
+
|
|
23
|
+
## Anti-Patterns
|
|
24
|
+
{What to avoid}
|