agentleFS
kaotyprkaotypr/context-circuit/.agents/skills/cc-stacked/SKILL.md

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.

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
  1. Very specific:

    Use --intent ID for only that intent's linked plans.

    line 15
  2. Very specific:

    Run to completion without further prompting: prepare each worktree from the reported start through .agents/skills/cc-worktree/SKILL.md, …

    line 37
  3. Distinctive:

    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 …

    line 55
  4. Distinctive:

    Stop and report, preserving all work, on: failing checks after implementation or after a resolved merge.

    line 74
  5. Distinctive:

    Never unwind completed plans.

    line 80

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 auto

For 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.