saga

Name: saga
Author: warpdotdev

7.2kinstalls1forks

How to install saga?

warpdotdev/common-skills/saga

$npx -y skills add warpdotdev/common-skills --skill saga

Installs into the current project.

Summary

Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents. Use this skill whenever the user invokes /saga, asks to autonomously build a sizable feature end-to-end with minimal human intervention, wan

Files · 1

View on GitHub

SKILL.md

1	# Saga
2
3	Saga is an autonomous, spec-driven development workflow for medium-to-large features that should be implemented mostly without human intervention, except at a few discrete touch points. You act as the orchestrator: you turn a rough prompt into an airtight spec, then delegate implementation to a fleet of worker subagents while keeping your own context window clean.
4
5	The whole method rests on one bet: if the spec defines every task with validation criteria tight enough to form a contract, then workers can execute in parallel and self-verify, and the saga succeeds with almost no human babysitting. The quality of the saga is therefore decided in Phase 1, before a single line is written.
6
7	## Core principles
8
9	- Airtight contracts over good intentions. A task is only ready to delegate when its validation criteria are so explicit that meeting them leaves little-to-no possibility the task was done wrong. Ambiguity is the enemy; resolve it during planning, not during implementation.
10	- No whitespace. During planning, make every requirement explicit. Do not leave decisions to a worker's discretion unless the user has explicitly granted that discretion. Workers should never have to guess what "done" means.
11	- Protect the orchestrator's context. You are the long-lived coordinator. Push heavy reading, research, and implementation onto workers; receive compact reports back. Keep state on disk (in the saga directory's spec tree and `PROGRESS.md`) so your understanding survives compaction and you can re-read rather than re-hold. This maximizes time-to-compaction and keeps you coherent across the whole run.
12	- Validation is first-class. Every task and the saga as a whole carries verification criteria defined up front, and a concrete method for checking them (computer use, interactive CLI, or tests). See `references/validation-strategies.md`.
13	- A few human touch points, not zero. The human approves the spec (end of Phase 1), is consulted only when the spec genuinely cannot resolve a blocker (Phase 2), and does the final manual acceptance (Phase 3).
14
15	## The saga directory
16
17	Each saga lives in its own directory outside the repo, under `~/.sagas/`, so it survives across orchestrator sessions and can be resumed by a fresh agent. Name it uniquely from a slug of the feature plus a timestamp, e.g. `~/.sagas/dark-mode-20260609-0028/`. Confirm the exact path with the user and record it — it is the saga's stable identity.
18
19	The directory holds a tree of spec files plus a progress log. Each level carries its own validation criteria, so detail scales with the size of the saga instead of bloating one file:
20
21	```
22	~/.sagas/<saga-name>/
23	├── SAGA.md # overview, environment, saga-level exit criteria, milestone index
24	├── PROGRESS.md # live, continuously-updated execution log and current state
25	└── milestones/
26	├── 01-<slug>/
27	│ ├── MILESTONE.md # milestone spec + milestone-level validation criteria
28	│ └── tasks/
29	│ ├── 01-<slug>.md # task spec + task-level validation criteria
30	│ └── 02-<slug>.md
31	└── 02-<slug>/
32	├── MILESTONE.md
33	└── tasks/ ...
34	```
35
36	`SAGA.md` stays small — it indexes the milestones and holds only saga-wide content. Milestone and task specs hold the detail. This is what keeps your context clean: read only the spec for the milestone or task you are currently coordinating, and rely on `PROGRESS.md` for state rather than re-deriving it.
37
38	Use the templates and field definitions in `references/saga-spec-template.md` verbatim. Read it before drafting specs.
39
40	---
41
42	## Phase 1 — Planning & spec generation (orchestrator + user)
43
44	Goal: produce a comprehensive, unambiguous saga spec tree. This phase is fully collaborative with the user. It ends only when the user approves the spec.
45
46	When asking the user anything in this phase, always use the `ask_user_question` tool and provide concrete options (single- or multi-select) rather than open-ended questions. Set a `recommended_option_index` when there is a sensible defau

People who liked this also viewed

6 picks

Type

saga

7.2kinstalls1forks

View on GitHub

How to install saga?

warpdotdev/common-skills/saga

$npx -y skills add warpdotdev/common-skills --skill saga

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Saga
2
3	Saga is an autonomous, spec-driven development workflow for medium-to-large features that should be implemented mostly without human intervention, except at a few discrete touch points. You act as the orchestrator: you turn a rough prompt into an airtight spec, then delegate implementation to a fleet of worker subagents while keeping your own context window clean.
4
5	The whole method rests on one bet: if the spec defines every task with validation criteria tight enough to form a contract, then workers can execute in parallel and self-verify, and the saga succeeds with almost no human babysitting. The quality of the saga is therefore decided in Phase 1, before a single line is written.
6
7	## Core principles
8
9	- Airtight contracts over good intentions. A task is only ready to delegate when its validation criteria are so explicit that meeting them leaves little-to-no possibility the task was done wrong. Ambiguity is the enemy; resolve it during planning, not during implementation.
10	- No whitespace. During planning, make every requirement explicit. Do not leave decisions to a worker's discretion unless the user has explicitly granted that discretion. Workers should never have to guess what "done" means.
11	- Protect the orchestrator's context. You are the long-lived coordinator. Push heavy reading, research, and implementation onto workers; receive compact reports back. Keep state on disk (in the saga directory's spec tree and `PROGRESS.md`) so your understanding survives compaction and you can re-read rather than re-hold. This maximizes time-to-compaction and keeps you coherent across the whole run.
12	- Validation is first-class. Every task and the saga as a whole carries verification criteria defined up front, and a concrete method for checking them (computer use, interactive CLI, or tests). See `references/validation-strategies.md`.
13	- A few human touch points, not zero. The human approves the spec (end of Phase 1), is consulted only when the spec genuinely cannot resolve a blocker (Phase 2), and does the final manual acceptance (Phase 3).
14
15	## The saga directory
16
17	Each saga lives in its own directory outside the repo, under `~/.sagas/`, so it survives across orchestrator sessions and can be resumed by a fresh agent. Name it uniquely from a slug of the feature plus a timestamp, e.g. `~/.sagas/dark-mode-20260609-0028/`. Confirm the exact path with the user and record it — it is the saga's stable identity.
18
19	The directory holds a tree of spec files plus a progress log. Each level carries its own validation criteria, so detail scales with the size of the saga instead of bloating one file:
20
21	```
22	~/.sagas/<saga-name>/
23	├── SAGA.md # overview, environment, saga-level exit criteria, milestone index
24	├── PROGRESS.md # live, continuously-updated execution log and current state
25	└── milestones/
26	├── 01-<slug>/
27	│ ├── MILESTONE.md # milestone spec + milestone-level validation criteria
28	│ └── tasks/
29	│ ├── 01-<slug>.md # task spec + task-level validation criteria
30	│ └── 02-<slug>.md
31	└── 02-<slug>/
32	├── MILESTONE.md
33	└── tasks/ ...
34	```
35
36	`SAGA.md` stays small — it indexes the milestones and holds only saga-wide content. Milestone and task specs hold the detail. This is what keeps your context clean: read only the spec for the milestone or task you are currently coordinating, and rely on `PROGRESS.md` for state rather than re-deriving it.
37
38	Use the templates and field definitions in `references/saga-spec-template.md` verbatim. Read it before drafting specs.
39
40	---
41
42	## Phase 1 — Planning & spec generation (orchestrator + user)
43
44	Goal: produce a comprehensive, unambiguous saga spec tree. This phase is fully collaborative with the user. It ends only when the user approves the spec.
45
46	When asking the user anything in this phase, always use the `ask_user_question` tool and provide concrete options (single- or multi-select) rather than open-ended questions. Set a `recommended_option_index` when there is a sensible defau

People who liked this also viewed

6 picks

Type