cc-stacked
Skill0 starsChanged 18 days ago0BSDView on GitHub
Run several Context Circuit plans at once — deriving the dependency order, integrating each wave, resolving merges, and knowing where to stop.
In this repository41 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/context-circuit.mdcCursor rule
- cc-cliSkill
- cc-completeSkill
- cc-deliverSkill
- cc-directSkill
- cc-dispatchSkill
- cc-intentSkill
- cc-knowledgeSkill
- cc-planSkill
- cc-reviewSkill
- cc-system-designSkill
- cc-workspaceSkill
- cc-worktreeSkill
- cc-cliSkill
- cc-completeSkill
- cc-deliverSkill
- cc-directSkill
- cc-dispatchSkill
- cc-intentSkill
- cc-knowledgeSkill
- cc-planSkill
- cc-reviewSkill
- cc-stackedSkill
- cc-system-designSkill
- cc-workspaceSkill
- cc-worktreeSkill
- cc-cliSkill
- cc-completeSkill
- cc-deliverSkill
- cc-directSkill
- cc-dispatchSkill
- cc-intentSkill
- cc-knowledgeSkill
- cc-planSkill
- cc-reviewSkill
- cc-stackedSkill
- cc-system-designSkill
- cc-workspaceSkill
- cc-worktreeSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Use --intent ID for only that intent's linked plans.
- Very specific: line 37
Run to completion without further prompting: prepare each worktree from the reported start through .agents/skills/cc-worktree/SKILL.md, …
- Distinctive: line 55
Read the diff where integration needs it — a merge to resolve, or a report naming a conflict, a failure, or an assumption — not as a …
- Distinctive: line 74
Stop and report, preserving all work, on: failing checks after implementation or after a resolved merge.
- Distinctive: line 80
Never unwind completed plans.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Run several plans at once
To execute several plans at once, derive the order instead of guessing it:
sh <root>/.context-circuit/cli --json record order --mode autoFor an explicitly selected run, pass each plan with repeatable --plan ID.
Use --intent ID for only that intent's linked plans. The filters are mutually
exclusive. The result names plan_ids and selection; preserve that exact set
through execution and delivery. An unfinished predecessor outside it is blocked,
never silently added.
record order reports dependency waves, each plan's starting reference per
repository, the integration merges a dependent plan needs, and which plans in one
wave share a repository. It runs nothing and reserves nothing.
Two shapes
Waves overlap independent plans and pay an integration merge at each fan-in. A linear chain stacks every plan on the previous one, needs no merge, and runs strictly serially.
Present the recommendation with its cost — a single repository with any fan-in usually favors the chain — and honor an explicit choice. The request to execute the presented plans authorizes the selected run; use the recommended shape when the person has not chosen one.
Then run it
Run to completion without further prompting: prepare each worktree from the
reported start through .agents/skills/cc-worktree/SKILL.md, perform any
reported integration merge with ordinary Git, dispatch a worker per plan through
.agents/skills/cc-dispatch/SKILL.md, wait, and carry what each worker reports
into completion.
Completion is a later human request. Follow the selected order's waves and use
reported worker results and actual Git ancestry to decide what can proceed;
record order reads recorded completed_at when present but never marks a plan
complete itself.
Integrate from what the worker reported
A worker reports the checks it ran and their real outcome, and that report is what you integrate from. Do not re-read its diff or re-run its checks to satisfy yourself: that repeats the expensive half of the work and is why delegation stops paying.
Read the diff where integration needs it — a merge to resolve, or a report naming a conflict, a failure, or an assumption — not as a routine audit. A report of failing checks is information: report it to the person and leave the plan unmarked and unedited rather than repairing in a loop.
None of that changes work this session implemented itself, which this session checks as usual. The rule is about not repeating a delegate's reading and test run, not about trusting your own.
Resolve a conflict from an integration merge directly when both sides are in the person's selected run and their records and diffs are available. Preserve both plans' behavior, then run the repository's checks — a resolved merge is not trusted until they pass. Describe the resolution in the merge commit and in the report to the person, so it can be audited; the plan record is not edited. A conflict against anything outside the run, or one where preserving both sides is impossible, is a stop.
Where to stop
Stop and report, preserving all work, on: failing checks after implementation or after a resolved merge; a conflict outside the run or one needing a decision; a worker that cannot complete or returns blocked; worktree preparation that refuses; skipped dependency reuse whose fallback setup fails; or an order reporting a cycle, an unknown repository, or a broken link.
Never unwind completed plans. Name which plans finished, which is stuck, and what is held behind it.
What confirming the run authorizes
For that run: worktree preparation and the local integration merges that assemble a dependent plan's base. Implementation commits on a worktree's own branch are ordinary execution and need no separate confirmation — every plan's work is committed before it is reported, which is what gives a dependent plan something to start from and an integration merge something to merge.
It does not authorize push, pull request creation, merging into a base branch, deployment, or deletion — each of those is still a separate act needing a person.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

