Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ayeshakhalid192007-dev/graph-engineering-crash-course --skill propose-graph-diffgit clone --depth 1 https://github.com/ayeshakhalid192007-dev/graph-engineering-crash-courseWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ayeshakhalid192007-dev/graph-engineering-crash-course/propose-graph-diff)<a href="https://agentmods.dev/skills/ayeshakhalid192007-dev/graph-engineering-crash-course/propose-graph-diff"><img src="https://agentmods.dev/badge/skills/ayeshakhalid192007-dev/graph-engineering-crash-course/propose-graph-diff/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ayeshakhalid192007-dev/graph-engineering-crash-course/propose-graph-diff"><img src="https://agentmods.dev/badge/skills/ayeshakhalid192007-dev/graph-engineering-crash-course/propose-graph-diff.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00049 | $0.01110 |
| Opus 5.5 | $0.00020 | $0.00444 |
| Sonnet 5.5 | $0.00010 | $0.00222 |
| Haiku 4.5 | $0.00005 | $0.00111 |
Grade A, and why
propose-graph-diff scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
propose-graph-diff
Reads the graph's current JSON state and a proposed node/edge addition, produces the minimal diff a pull request would show, cross-checks the proposal against facts already on file, and flags anything that doesn't line up — without ever merging the change itself.
Instructions
You are a Claude Code skill implementing the file-graph-for-small-teams
pattern. Follow these steps in order:
- Read the current graph file's state — the existing nodes and
edges — as the base to diff against. Default to
graph.jsonas given in this kit'sREADME.mdunless told otherwise. - Read the proposed addition exactly as given — the new node and its edges. Do not invent, infer, or add any node or edge beyond what was actually proposed, even if you think the graph is "obviously" missing something related.
- Produce a minimal diff: only the new or changed lines, in the same shape the existing file uses, not a full rewrite of the file. A reviewer looking at a pull request needs to see exactly what changed, not re-verify the entire graph from scratch.
- Before finalizing the diff, cross-check every claimed attribution in the proposed edges against any other fact already on file about the same subject or object — for example, an announcer ID logged on an existing host node, or another edge already asserting something about the same reel. If a proposed edge conflicts with an existing cross-reference, do not silently include it as if uncontested.
- Flag conflicts explicitly, but still include the diff. Do not drop the proposed line and do not silently correct it to what you think is right — this skill's job is to produce the diff and name the conflict, not to decide which fact wins. That decision belongs to whoever reviews the pull request.
- Never write directly to the shared graph file. This skill's output is a diff and a flag list for a human to review and merge through a normal pull request — merging into the shared file is a human git action this skill does not perform.
- Report the diff for every proposal, plus a separate flagged list naming the specific conflicting fact for anything flagged, so a reviewer can tell "clean addition" apart from "needs a second look" at a glance.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 95 lines · 49 tokens per session scan A 8d35329885ea
propose-graph-diff is a skill published in the GitHub repository ayeshakhalid192007-dev/graph-engineering-crash-course (5 stars, last pushed 1mo ago), licensed MIT. It adds 49 tokens to every session and 1,110 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
review
Use when a green diff needs adversarial judgment in the rsc SDD chain, between verify and ship — give a review keyed to the spec/plan/constitution in 02-DOCS/wiki/sdd/, or receive one and verify each comment before agreeing. NOT running lint/type/tests (that is verify), NOT the spec-less standalone pass (that is…
code-review
Use to judge a concrete diff, branch, or GitHub PR on its own merits with no rsc-SDD spec/plan chain to key off — the spec-less giving pass behind /code-review: only findings you can defend, one verdict, read-only unless --comment or --fix. NOT the SDD gate keyed to 02-DOCS/wiki/sdd/ that also processes incoming…
simplify
Review recent code changes for reuse, code quality, and efficiency, then directly apply straightforward cleanup improvements. Use when the user wants a post-implementation cleanup pass, pre-PR polish, or asks to simplify/refine recent changes. Invoke with /simplify or /simplify .
find-simplifications
Use for a periodic repo-wide sweep of qwen-code for accumulated excess surface — dead components and files, orphaned locale keys, exports nothing consumes, added-then-removed scaffolding — filing candidates on a tracking issue and landing only what a maintainer has said yes to. Repo-wide and evidence-first; every…
swarm-pr-review
Run a graph-guided, tool-augmented PR review using context packing, parallel exploration, mandatory repository-agnostic risk-family coverage with dispatch scaled to diff size and risk, independent reviewer validation, critic challenge, and metrics writeback. Use for deep pull request review with low false-positive…
include-test-files-that-assert-on-behavior-being-changed-in-decl
When delegating a task affected by this skill, include.