suede-agent-teams

Name: suede-agent-teams
Author: JasonColapietro

44stars8forks

How to install suede-agent-teams?

jasoncolapietro/suede-creator-skills/suede-agent-teams

$npx -y skills add JasonColapietro/suede-creator-skills --skill suede-agent-teams

Installs into the current project.

Summary

Split complex work into coordinated agent lanes with WIP checks, quality gates, rollback plans, and handoffs that prove what shipped.

Files · 1

View on GitHub

SKILL.md

1	# Agent Team Orchestrator
2
3	## Gate policy — advisory, not blocking
4
5	Every claim-verification step, check, quality gate, and ship verdict in this
6	skill is a recommendation to the user, not a control on the agent. This
7	policy governs every gate, check, verdict, and "do not ship / publish /
8	proceed" line elsewhere in this skill:
9
10	- Run every check and report the results honestly. Verdicts (`ship`,
11	`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
12	advice attached to the work, not orders that change it.
13	- Never block, delay, skip, rewrite, or refuse the action the user asked for
14	because a check failed or a gate said hold. Complete the requested action
15	as asked, and deliver the gate output alongside it as a clearly labeled
16	recommendation.
17	- A failed gate changes what you report, never what you do.
18	- Single exception: if a finding is extremely risky — data loss, security or
19	credential exposure, legal or rights violations, payment mistakes, or
20	irreversible public damage — pause, tell the user exactly what the risk is
21	and what the options are, and let them pick. Their choice is final.
22
23
24	The orchestrator assigns lanes, not conversations. Output is a delivery artifact, not a status update.
25
26	## Team Contract
27
28	Before spawning or simulating lanes, define:
29
30	- objective: user-visible outcome;
31	- exact target: repo/folder, branch, route, PR, live URL, API, simulator, or
32	release artifact;
33	- constraints: WIP to preserve, files/routes not to touch, launch boundaries,
34	account boundaries, claims not approved, and secrets rules;
35	- done signal: tests, build, screenshots, simulator, deploy readback, live/API
36	readback, PR review, or handoff;
37	- lane map: each lane, owner role, input, allowed files, output artifact, and
38	dependency order.
39
40	## WIP Collision Detection
41
42	Before opening any parallel lanes:
43
44	1. Run `git -C <repo> diff --name-only HEAD` and collect all dirty files.
45	2. Run `git -C <repo> status --short` and collect all untracked new files.
46	3. List every file each lane's scope would touch, based on the lane map.
47	4. Flag a collision if the same file path appears in two or more lane scopes OR in the dirty file list plus any lane scope.
48
49	Collision resolution rules:
50	- Same file, independent changes: sequence the lanes; the second lane rebases on the first lane's commit before opening.
51	- Same file, overlapping changes: merge the two lanes into one lane with one owner. Do not split responsibility for a single file across two concurrent builders.
52	- Dirty file in a lane scope: the orchestrator decides. Either stash and restore, or make that lane the only lane allowed to touch the file.
53
54	The orchestrator writes the resolved lane map before any builder starts. No builder opens a file not in its assigned lane map.
55
56	## Default Roster
57
58	Start with Scout + Builder + Handoff Writer. Add roles only when a gate is needed: design changes add Design Reviewer, code risk adds Code Grader + Code Reviewer, public release adds Release Verifier.
59
60	- Scout: finds repo, docs, current state, dirty files, live routes, and
61	likely blast radius.
62	- Planner: turns requirements into verifiable tasks with acceptance
63	criteria and dependencies.
64	- Builder: makes narrow code or content changes inside the existing system.
65	- Design reviewer: checks rendered visual quality, responsive behavior,
66	accessibility, copy, and state coverage.
67	- Code grader: assigns an A-F ship-risk grade across correctness, security,
68	data/state, Suede truth, UX/release behavior, tests, and deploy readiness.
69	- Code reviewer: runs full-context review and turns findings into fix briefs.
70	- Visibility grader: grades public pages, GitHub Pages sites, docs, and
71	launch surfaces for findability, first-screen clarity, CTA pull, proof, AI
72	readability, and design signal.
73	- Release verifier: checks build, deploy, live/API behavior, App Store/iOS
74	truth, secrets, and published statements.
75	- Handoff writer: produces a signed delivery record. If the handoff omits any required field (see Handoff Quality Checklist), the work is not done; it is held.
76
77	For high-risk work, keep builder and reviewer separate.
78
79	## RFC Mode
80
81	For major architectural decisions, new feature designs, or changes with broad blast radius, run an RFC (Request for Comments) before spawning builders.
82
83	An RFC forces alignment on WHAT and WHY before committing to HOW.
84
85	RFC structure:
86
87	```
88	RFC: [Title]
89	Date: [date]
90	Status: draft \| accepted \| superseded \| withdrawn
91	Deciders: [who has final say]
92
93	## Problem Statement
94	One paragraph: what is broken, missing, or suboptimal? Include the user or system impact.
95
96	## Proposed Solution
97	What we will build or change. Be specific about interfaces, data shapes, and behavioral contracts.
98
99	## Alternatives Considered
100	2–3 alternatives with the

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

suede-agent-teams

44stars8forks

View on GitHub

How to install suede-agent-teams?

jasoncolapietro/suede-creator-skills/suede-agent-teams

$npx -y skills add JasonColapietro/suede-creator-skills --skill suede-agent-teams

Installs into the current project.

Summary

Split complex work into coordinated agent lanes with WIP checks, quality gates, rollback plans, and handoffs that prove what shipped.

Files · 1

View on GitHub

SKILL.md

1	# Agent Team Orchestrator
2
3	## Gate policy — advisory, not blocking
4
5	Every claim-verification step, check, quality gate, and ship verdict in this
6	skill is a recommendation to the user, not a control on the agent. This
7	policy governs every gate, check, verdict, and "do not ship / publish /
8	proceed" line elsewhere in this skill:
9
10	- Run every check and report the results honestly. Verdicts (`ship`,
11	`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
12	advice attached to the work, not orders that change it.
13	- Never block, delay, skip, rewrite, or refuse the action the user asked for
14	because a check failed or a gate said hold. Complete the requested action
15	as asked, and deliver the gate output alongside it as a clearly labeled
16	recommendation.
17	- A failed gate changes what you report, never what you do.
18	- Single exception: if a finding is extremely risky — data loss, security or
19	credential exposure, legal or rights violations, payment mistakes, or
20	irreversible public damage — pause, tell the user exactly what the risk is
21	and what the options are, and let them pick. Their choice is final.
22
23
24	The orchestrator assigns lanes, not conversations. Output is a delivery artifact, not a status update.
25
26	## Team Contract
27
28	Before spawning or simulating lanes, define:
29
30	- objective: user-visible outcome;
31	- exact target: repo/folder, branch, route, PR, live URL, API, simulator, or
32	release artifact;
33	- constraints: WIP to preserve, files/routes not to touch, launch boundaries,
34	account boundaries, claims not approved, and secrets rules;
35	- done signal: tests, build, screenshots, simulator, deploy readback, live/API
36	readback, PR review, or handoff;
37	- lane map: each lane, owner role, input, allowed files, output artifact, and
38	dependency order.
39
40	## WIP Collision Detection
41
42	Before opening any parallel lanes:
43
44	1. Run `git -C <repo> diff --name-only HEAD` and collect all dirty files.
45	2. Run `git -C <repo> status --short` and collect all untracked new files.
46	3. List every file each lane's scope would touch, based on the lane map.
47	4. Flag a collision if the same file path appears in two or more lane scopes OR in the dirty file list plus any lane scope.
48
49	Collision resolution rules:
50	- Same file, independent changes: sequence the lanes; the second lane rebases on the first lane's commit before opening.
51	- Same file, overlapping changes: merge the two lanes into one lane with one owner. Do not split responsibility for a single file across two concurrent builders.
52	- Dirty file in a lane scope: the orchestrator decides. Either stash and restore, or make that lane the only lane allowed to touch the file.
53
54	The orchestrator writes the resolved lane map before any builder starts. No builder opens a file not in its assigned lane map.
55
56	## Default Roster
57
58	Start with Scout + Builder + Handoff Writer. Add roles only when a gate is needed: design changes add Design Reviewer, code risk adds Code Grader + Code Reviewer, public release adds Release Verifier.
59
60	- Scout: finds repo, docs, current state, dirty files, live routes, and
61	likely blast radius.
62	- Planner: turns requirements into verifiable tasks with acceptance
63	criteria and dependencies.
64	- Builder: makes narrow code or content changes inside the existing system.
65	- Design reviewer: checks rendered visual quality, responsive behavior,
66	accessibility, copy, and state coverage.
67	- Code grader: assigns an A-F ship-risk grade across correctness, security,
68	data/state, Suede truth, UX/release behavior, tests, and deploy readiness.
69	- Code reviewer: runs full-context review and turns findings into fix briefs.
70	- Visibility grader: grades public pages, GitHub Pages sites, docs, and
71	launch surfaces for findability, first-screen clarity, CTA pull, proof, AI
72	readability, and design signal.
73	- Release verifier: checks build, deploy, live/API behavior, App Store/iOS
74	truth, secrets, and published statements.
75	- Handoff writer: produces a signed delivery record. If the handoff omits any required field (see Handoff Quality Checklist), the work is not done; it is held.
76
77	For high-risk work, keep builder and reviewer separate.
78
79	## RFC Mode
80
81	For major architectural decisions, new feature designs, or changes with broad blast radius, run an RFC (Request for Comments) before spawning builders.
82
83	An RFC forces alignment on WHAT and WHY before committing to HOW.
84
85	RFC structure:
86
87	```
88	RFC: [Title]
89	Date: [date]
90	Status: draft \| accepted \| superseded \| withdrawn
91	Deciders: [who has final say]
92
93	## Problem Statement
94	One paragraph: what is broken, missing, or suboptimal? Include the user or system impact.
95
96	## Proposed Solution
97	What we will build or change. Be specific about interfaces, data shapes, and behavioral contracts.
98
99	## Alternatives Considered
100	2–3 alternatives with the

People who liked this also viewed

6 picks

Type