graph-engineering
Skill4 starsChanged 4 months agoMITView on GitHub
Use when a workflow has explicit data dependencies, independently executable branches, typed joins, or node-local recovery needs that justify a bounded static dependency graph.
7 other projects use a version of this.
Adopted by
Most recently taken up by
- anuragsarkar97/skillstheir own version, first seen Nov 8, 2026
- Jamie-BitFlight/claude_skillstheir own version, first seen Sep 23, 2026
- calebnewtonusc/Chewbaccatheir own version, first seen Aug 11, 2026
- HM-Li/graph-engineeringtheir own version, first seen Aug 8, 2026
- vupercentmove/claude-skillstheir own version, first seen Aug 2, 2026
- codejunkie99/graph-engineeringtheir own version, first seen Jul 23, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- codejunkie99/graph-engineering★ 471same name
- Jamie-BitFlight/claude_skills★ 67same name
- calebnewtonusc/Chewbacca★ 8same name
- HM-Li/graph-engineering★ 4same name
- douinc/agent-skills★ 1same name
- anuragsarkar97/skills★ 0same name
- vupercentmove/claude-skills★ 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 repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agentic-engineeringSkill
- agent-teams-commandSkill
- context-managerSkill
- harness-engineeringSkill
- loop-engineeringSkill
- verify-before-claimSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 7 edited versions we read keep these.
5
Distinctive
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 20
Use Graph Engineering for dependency width.
- Distinctive: line 37
Run the admission gate before drawing a graph:
- Distinctive: line 42
Keep one-shot or Loop execution when work is mainly sequential, small, or cheaper to review serially.
- Very specific: line 61
Write the JSON contract and run scripts/validate_graph_contract.py <contract.json> --strict.
- Distinctive: line 66
Add only data, control, verification, failure, or compensation edges.
- Distinctive: line 90
Check static integrity: known endpoints, compatible schemas, reachability, acyclicity, single writers, complete joins, finite budgets, and …
- Distinctive: line 149
Every node, edge, join, effect, and terminal claim has fresh evidence.
“Common” is measured: kept by at least 6 in 10 of the 7 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
Graph Engineering
<skill_contract>
<input>A dependency-heavy objective with candidate nodes, data schemas, owners, effects, verifiers, joins, budgets, and durable state paths.</input>
<output>A validated static DAG contract with typed edges, explicit joins, node-local recovery, and graph-level receipts.</output>
<done>Static invariants and terminal acceptance checks pass with fresh node, join, budget, permission, and state evidence.</done>
<non_goals>Temporal loop design, worker-team command, runtime-kernel implementation, dynamic graphs, or universal parallelism.</non_goals>
Use Graph Engineering for dependency width. Use loop-engineering for repeated
execution through time, agent-teams-command for process ownership and IPC,
and harness-engineering for scheduler, permission, lease, and observability
infrastructure. A graph node may contain a bounded Loop or Agent Team.
Usage Template
Provide: objective/non-goals, candidate nodes, real data dependencies, payload
schemas, owners and write territories, join semantics, node/terminal verifiers,
effects and permissions, artifact/state paths, budgets, stop conditions, and
recovery. Load references/graph-contract.md for the full schema and boundary;
start from references/diamond-graph-example.json.
Workflow
<intake>Run the admission gate before drawing a graph:
- Identify which steps actually consume another step's output.
- Estimate independent width, critical path, scheduler overhead, and review load. Require measurable payback or stronger independent evaluation.
- Keep one-shot or Loop execution when work is mainly sequential, small, or cheaper to review serially.
- Limit V7.1 to a static DAG: sequence, pipeline, diamond, maker-checker, or
bounded subgraph. Put repetition inside a
loopnode; reject graph cycles and dynamic expansion.
</intake><unknowns_gate>
Return NEEDS_INPUT when objective, graph owner, dependency direction, payload
schema, writer, verifier, permission boundary, budget, join, or recovery is
missing and cannot be discovered safely. Probe candidate independence with a
small dry run. Do not invent an edge merely because two steps are adjacent.
</unknowns_gate>
<execute>- Write the JSON contract and run
scripts/validate_graph_contract.py <contract.json> --strict. - Give every node one owner, typed inputs/outputs, explicit reads/writes, verifier, timeout, attempt/tool caps, effect class, idempotency, and compensation.
- Add only data, control, verification, failure, or compensation edges. Schema-bearing edges must match both endpoint contracts.
- Enforce one writer per target. Agent workers use isolated artifacts or worktrees; the integration owner controls shared schemas and final writes.
- Declare a join for every multi-input node. Choose
all,reduce,first-success,quorum,barrier-verifier, orhuman-gate; name the exact input set and verifier. - Schedule only
READYnodes whose dependencies are verified. Persist every transition and edge payload reference before releasing successors. - Retry the failed node or smallest invalid subgraph after a changed diagnosis. Preserve verified branches; never replay the whole graph merely for convenience.
- Require human approval, a compensation route, and verified rollback before
any external, shared, destructive, published, credentialed, or financial
effect. In strict contracts, name the external node ID in
approval_required, feed it a typed approval receipt directly from ahuman-gate, and list each exact write target as allowed and not denied. - At terminal nodes, verify the end-to-end objective and graph guardrails; node success alone cannot certify graph success.
</execute><evaluate>Check static integrity: known endpoints, compatible schemas, reachability, acyclicity, single writers, complete joins, finite budgets, and compensated effects. Check runtime integrity: deterministic readiness, duplicate-delivery idempotency, checkpoint replay, permission denial without mutation, smallest-unit recovery, terminal evidence, and cleanup. Use an independent reviewer for consequential graph behavior.
</evaluate><retry_policy>
max_attempts comes from each node and never exceeds the graph cap. Retry only
after changing diagnosis, input, owner, tool, or strategy. Stop on a repeated
signature, incompatible edge, permission denial, invalid checkpoint, exhausted
review budget, or NO_PROGRESS. Whole-graph retry is forbidden in strict V7.1.
</retry_policy>
<state_contract>
Persist {run_id, graph_id, status, attempt, budget, evidence, unknowns,
last_error, next_action} plus contract/implementation hashes, node states,
edge payload locators, join decisions, writer leases, approvals, checkpoints,
compensations, terminal receipts, and cleanup. Use append-only events and an
atomic current checkpoint; chat history is not graph state.
</state_contract>
Failure Protocol
NEEDS_INPUT: a mandatory graph contract or authority field is unresolved.BLOCKED_DEPENDENCY: keep affected nodesWAITING; run only independent ready nodes.BLOCKED_PERMISSION: deny the effect, preserve state, and request approval.VERIFY_FAILED: reject the node/join artifact and recover the smallest unit.NO_PROGRESS: the same failure repeats after a changed attempt.max_attempts: 2by default and always finite.BUDGET_STOP: stop scheduling, checkpoint, compensate active effects, and return a partial graph receipt.
Output Contract
Return status, result (terminal decision and accepted artifacts), evidence
(validator, node, join, terminal, budget, approval, and cleanup receipts),
unknowns, and next_action (stop, retry node, compensate, approval, or
handoff).
Edge Cases
- Two workers both write
report.md: strict validation fails the single-writer invariant; isolate worker artifacts and let one reduce node own the report. - A branch passes but its sibling times out: preserve the verified branch, retry only the failed node within cap, and do not release the join until its declared mode and verifier pass.
Success Metrics
- The strict graph validator passes before execution.
- Graph admission shows bounded value beyond orchestration and review cost.
- Every node, edge, join, effect, and terminal claim has fresh evidence.
- Recovery replays the smallest failed unit from durable state.
Quality Gates
- Static DAG scope and Loop/Teams/Harness boundaries are explicit.
- Owners, payload schemas, writers, joins, verifiers, and budgets are exact.
- State replay and duplicate delivery preserve graph invariants.
- External effects have independent review, approval, compensation, and rollback.
- Terminal verification supports the end-to-end claim.
</skill_contract>
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.

