weave
Skill14 starsChanged 48 days agoMITView on GitHub
Runs a large multi-item delivery (N tickets, an epic, a codebase-wide migration, a sweep) as ONE native Workflow with TDD and review. Not for one task (/ward).
6 other projects use a version of this.
Adopted by
Most recently taken up by
- EtanHey/golemstheir own version, first seen Oct 28, 2026
- simota/agent-skillstheir own version, first seen Oct 23, 2026
- GabrielKqw/weave-agent-workflowtheir own version, first seen Oct 11, 2026
- KKenny0/weavetheir own version, first seen Jul 14, 2026
- entropyvortex/meta-llm-chartertheir own version, first seen Jul 7, 2026
- mandlcho/skillstheir own version, first seen May 23, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- entropyvortex/meta-llm-charter★ 248same name
- simota/agent-skills★ 96same name
- GabrielKqw/weave-agent-workflow★ 5same name
- KKenny0/weave★ 1same name
- mandlcho/skills★ 1same name
- EtanHey/golems★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- accelerateSkill
- almanacSkill
- autopsySkill
- blueprintSkill
- certifySkill
- chronicleSkill
- confluenceSkill
- conjureSkill
- deploySkill
- divineSkill
- inscribeSkill
- jiraSkill
- knowledge-graphSkill
- magicSkill
- manifestSkill
- orchestrateSkill
- portalSkill
- scrutinizeSkill
- sealSkill
- sentinelSkill
- statuslineSkill
- transmuteSkill
- unravelSkill
- wardSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 25
Fold first: When all units together touch 3 files or fewer and about 300 changed lines or fewer, do not compose a Workflow: run them in …
- Distinctive: line 58
When a unit lands something that breaks what another Claude Code session is building on, and cross-session messaging is available, send …
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/weave — compose & run a delivery pipeline as one Workflow
Bundled command: if
kgis not found, run it as${CLAUDE_PLUGIN_ROOT}/tools/kgand give subagents that full path. If that is missing too (Claude chat ships no plugin tools), skip thekgsteps and search the code directly.
When the task is "deliver many similar units" — N stories/tickets, a set of features/endpoints, a codebase-wide migration, a batch sweep — don't hand-roll dozens of Agent calls. Compose a single native Workflow that delivers all of them, and run it via the Workflow tool. The Workflow engine is the fast, deterministic fan-out (pipeline/parallel/orchestrator-worker) Claude reaches for anyway; this skill makes magician own it, with the guardrails baked in.
/transmute is a common upstream caller: its Jira stories become args.units (id/goal/AC only; Phase 0 derives each unit's kg scope and blast). Its parity contract adds evaluator criteria: diff each build against the contract's behavioral golden, never the environmental baseline.
The full, copy-and-adapt Workflow template (schemas, stages, kg grounding, the verify + remediate loop) is in references/template.md.
When to use
Trigger phrases: "implement these N stories/tickets/tasks", "deliver the epic", "build out all these features/endpoints", "migrate X across the codebase", "do all of the following", any batch or sweep of similar units. Not for one task (/ward) or an existing blueprint (/orchestrate).
Phase 0 — scope, ground, and plan (gate before running)
- Enumerate the units. The N things to deliver (tickets, files, features). Pull ticket detail via
magician:jiraif relevant; read a blueprint from.workspace/shared/plans/if one exists. Fold first. When all units together touch 3 files or fewer and about 300 changed lines or fewer, do not compose a Workflow: run them in order in the main loop, one/wardcycle each (lore/fold-first.md). The guardrails below still apply. - Ground in the codebase (kg, not grep).
kg check; if there is no index, offer to build one (kg init) and run it only on the user's explicit yes — a shared graph is what keeps every worker cheap and consistent. With that yes, index every repo the work touches (kg initin each repo — kg is per-repo; cross-repo parity/migration greps are the wrong tool, see knowledge-graph/references/retrieval.md); on a no, ground with targetedGrep/Readinstead. For each unit,kg query/kg blastto scope the files it touches and its blast radius (pass these asfile:linepointers into worker prompts; never paste whole files). A hand-rolled Workflow script must ground via kg too — don't fan out grep/whole-file-read loops. Pick the structure (adaptive — see below) and the per-stage model/effort.
A plan folder as the composed workflow. When
$ARGUMENTSnames a/blueprintfolder that holdsplan.workflow.js(rendered byplan-render workflownext toplan.json; onephase()per wave, oneagent()with aschemaper step, deferred steps omitted, literalmeta), that file is the composition: skip the structure choice, read it, pass its contents as theWorkflowscript and run it under the same write gates — the plan's approvedverifycommands are each agent's definition of done. Re-render (plan-render all) rather than hand-editing it when the plan changes; ameta.descriptionversion that differs fromplan.json.versionis stale. For a batch of units that has no plan yet, compose as below and, when the units are large enough to deserve a reviewed plan each, emit aplan.jsonwith one step per unit so the/blueprintpage reviews the batch.- Show the plan and get a go. A large Workflow spawns many agents and costs real tokens. Use AskUserQuestion: list the units, the structure, the guardrails, and the rough agent/token scale. Wait for approval before running. Once approved, run to completion autonomously — don't stop to ask the owner about individual reads; Claude Code's built-in read-only commands never prompt, and anything else prompts once unless the user runs in auto mode or approves it. Only the write gates below are yours to stop on (lore/autonomy.md). Gather → plan → memorize → execute.
Adaptive within guardrails
Choose the shape that fits (Anthropic agent patterns), tuning depth, agent count, and model/effort to the task:
- Per-item
pipeline()(default for N similar units) — each unit flows implement → certify → review independently, no barrier; wall-clock = slowest single chain. parallel()barrier — when a step needs all prior results (cross-unit dedup, a consolidation pass, "0 found → skip").- Orchestrator-worker — decompose first, then fan out workers over the decomposition.
- Evaluator-optimizer loop (built into the default template) — review → remediate → re-certify → re-review until clean, bounded by a round cap +
budget.remaining(). The pipeline ships a clean changeset, not a to-do list. For parity/mirror deliveries (units must mirror a gold 1:1), encodesingle_purpose/no-folding +mirrors_goldacceptance in the evaluator schema (references/template.md → Adapting it) — a generic review green-lights folding; for a full comprehend→parity job use/transmute.
You may deviate from any single skill's canned steps to fit the task. You may not drop these non-negotiables, whatever shape you pick:
<HARD-GATE>
1. **TDD per unit** — a failing test first, then green, then refactor (the `/ward` discipline).
2. **kg grounding** — workers locate code via `kg query`/`kg blast` and receive `file:line` pointers; no whole-file pastes.
3. **certify before "done"** — tests + types + lint + build pass for each unit before it counts as delivered, and the code matches the project's conventions ([lore/code-standards.md](../../lore/code-standards.md)) — style the reviewer would flag (async/await vs `.then`, etc.) is caught here, not after review.
4. **Review before ship, then remediate in-pipeline** — multi-lens (`magician:reviewer`/`sentinel`/`simplifier`/`verifier`) + adversarial verify on every Critical/High finding, then the bounded remediate loop (fix → re-certify → re-review) resolves confirmed findings before the pipeline reports done.
5. **Write gates** — the Workflow may read, implement on a branch/worktree, and test; it must **not** push, open/merge PRs, or do anything destructive without explicit user confirmation. Keep commits one-per-unit and surface them.
6. **No context loss** — every worker prompt is fully self-contained (Goal/Scope/Inputs/Constraints/Return per [lore/subagent-context.md](../../lore/subagent-context.md)); pass artifact **paths**, not dumps; workers return distilled summaries (~1–2k tokens), not raw output. Write a running `.workspace/local/session-state.md` (goal · done/remaining units · decisions · blockers · artifact paths) and have every worker read it first, so a compaction mid-run loses nothing.
</HARD-GATE>Run it
Adapt the template into a Workflow({script}) call. Keep the script's meta a pure literal; group stages with phase(); give every agent() a schema with bounded strings (summary ≤ 1200 chars, files_changed[], obstacles[] — the template's IMPL/CERT/FINDINGS/VERDICT), a label, and a stallMs, so you receive distilled results, never raw logs. Siblings of a parallel() are held up to CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS (default 5000) to reuse the first agent's cached prefix — put the shared prompt text first and the per-unit text last. Isolate file-mutating parallel workers with isolation: 'worktree' only when they'd otherwise collide. Read each phase's results before the next decision — you stay in the loop. A worker that needs a human decision puts the question in its obstacles[].NEXT and continues or stops; it never waits. After each phase, collect those questions, merge duplicates, and ask them in ONE AskUserQuestion (lore/obstacles.md).
For very large or open-ended scope, run /weave in successive Workflows (one phase each) rather than one giant script, so you review between phases. For a long unattended delivery, pair with /goal so Claude keeps driving across turns until every unit is delivered + certified. Collect stage results as they land.
When a unit lands something that breaks what another Claude Code session is building on, and cross-session messaging is available, send that session one self-contained sentence with artifact paths. Feature-detect and skip silently; the pipeline never waits on a peer. See lore/cross-session.md.
Effort & models
Stages run on the latest code-optimal tier; narrow lenses on small diffs can take a cheaper tier. Effort: medium for implementation turns, high for certify/review/security turns; on Bedrock/Vertex/gateways hold one level (an effort change drops the cache there). The hardest units go to xhigh; max is session-only and an opt-in for frontier problems. Suggest a model upgrade rather than switching silently if the session is on an older one (lore/models.md).
Size the fan-out to the units, not the appetite. Current models spawn subagents readily; on small units that costs more than it returns. One stage agent per unit is the default — split a unit across agents only when its tracks are genuinely independent, and keep spawn counts low. The review lenses and the adversarial verify are the checks; don't add agents on top of them to re-check the same work. See lore/model-behavior.md.
Obstacles
As a consumer — every dispatched unit returns an Obstacles block on a non-clean run. Roll them up into one report kept distinct from the deliverables (never let a blocked unit read as done), detect a pattern by a normalized BLOCKER + SCOPE signature, and memorize a confirmed pattern with ctx learn --add "<signature -> workaround / next-action>" written from your own signature — never verbatim worker text, never secrets or PII. Full consumer protocol: lore/obstacles.md.
As a producer — if this skill runs as a dispatched unit and hits something that blocks or degrades the work, do not wait for a human who is not there and do not silently ship a degraded result — return the Obstacles block from lore/obstacles.md (fields: STATUS, OBSTACLE, BLOCKER, SEVERITY, WORKAROUND, RECURRENCE, SCOPE, NEXT) to the caller alongside whatever you completed; interactively, say the same in prose.
Completion Signal
"Weave complete:
<N>/<N>units delivered (1 commit each), certified, reviewed (<C>criticals resolved over<R>remediation round(s)); cost ≈ $X (session delta). Branch<name>— ready for you to push/PR (write-gated)."
Cost clause: only with a reading at start and end, from ~/.claude/magician/status/${CLAUDE_SESSION_ID}.cost (status line) or the mods band's $.session.usage(). Report the difference. Omit the clause otherwise. Never estimate it.
Grounding for a unit's domain → /magic. Reviewing the whole changeset afterward → /divine. Shipping → /seal (gated).
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.

