gsd-graphify
Skill1 starsChanged 31 days agoMITView on GitHub
Build, query, and inspect the project knowledge graph in .planning/graphs/
4 other projects use a version of this, 4 of them edited.
Adopted by
Most recently taken up by
- open-gsd/get-shit-done-reduxedited, first seen Oct 8, 2026
- adrianoanthonymma16-boop/opencode-agentsedited, first seen Sep 16, 2026
- open-gsd/gsd-coreedited, first seen Sep 2, 2026
- ZaneL1u/cloud-cli-proxyedited, first seen May 9, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 4
- open-gsd/get-shit-done-redux★ 11k62% same
- open-gsd/gsd-core★ 11k62% same
- ZaneL1u/cloud-cli-proxy★ 5785% same
- adrianoanthonymma16-boop/opencode-agents★ 158% same
Wrote their own version · 0
None found.
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 repository121 other files it gives its agents.
- analysis-documentationSkill
- browser-automationSkill
- business-metrics-calculatorSkill
- chat-attachment-is-not-a-fileSkill
- claude-code-masterySkill
- codebase-designSkill
- codex-cli-specialistSkill
- cohort-analysisSkill
- cut-the-curveSkill
- data-narrative-builderSkill
- data-quality-auditSkill
- domain-modelingSkill
- focused-fixSkill
- funnel-analysisSkill
- gate-must-derive-its-criterionSkill
- grill-with-docsSkill
- gsd-add-testsSkill
- gsd-ai-integration-phaseSkill
- gsd-audit-fixSkill
- gsd-audit-milestoneSkill
- gsd-audit-uatSkill
- gsd-autonomousSkill
- gsd-captureSkill
- gsd-cleanupSkill
- gsd-code-reviewSkill
- gsd-complete-milestoneSkill
- gsd-configSkill
- gsd-debugSkill
- gsd-discuss-phaseSkill
- gsd-docs-updateSkill
- gsd-eval-reviewSkill
- gsd-execute-phaseSkill
- gsd-exploreSkill
- gsd-extract-learningsSkill
- gsd-fastSkill
- gsd-forensicsSkill
- gsd-healthSkill
- gsd-helpSkill
- gsd-importSkill
- gsd-inboxSkill
- gsd-ingest-docsSkill
- gsd-managerSkill
- gsd-map-codebaseSkill
- gsd-milestone-summarySkill
- gsd-mvp-phaseSkill
- gsd-new-milestoneSkill
- gsd-new-projectSkill
- gsd-ns-contextSkill
- gsd-ns-ideateSkill
- gsd-ns-manageSkill
- gsd-ns-projectSkill
- gsd-ns-reviewSkill
- gsd-ns-workflowSkill
- gsd-pause-workSkill
- gsd-phaseSkill
- gsd-plan-phaseSkill
- gsd-plan-review-convergenceSkill
- gsd-pr-branchSkill
- gsd-profile-userSkill
- gsd-progressSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
32 rules. 8 are common, 3 are distinctive, and 21 are very specific to this project.
8
Common
Most of the 4 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
21
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 28
Check if graphify is enabled by reading .planning/config.json directly using the Read tool.
- Very specific: line 32
Read .planning/config.json using the Read tool
- Common: line 33
If the file does not exist: display the disabled message below and STOP
- Very specific: line 35
If graphify.enabled is NOT explicitly true: display the disabled message below and STOP
- Very specific: line 36
If graphify.enabled is true: proceed to Step 2
- Very specific: line 87
If the output contains "disabled": true, display the disabled message from Step 1 and STOP
- Very specific: line 88
If the output contains "error" field, display the error message and STOP
- Very specific: line 89
If no nodes found, display: No graph matches for '<term>'.
- Common: line 92
STOP: after displaying results. Do not spawn an agent.
- Very specific: line 103
If exists: false, display the message field
- Very specific: line 105
If built_at_commit is non-null, also display a Source commit: line:
- Very specific: line 109
If built_at_commit is null (pre-graphify-v0.7 graph), omit the source-commit line entirely — do not render "Source commit: unknown"
- Common: line 116
STOP: after displaying status. Do not spawn an agent.
- Very specific: line 130
If no snapshot exists, suggest running build twice (first to create, second to generate a diff baseline).
- Common: line 132
STOP: after displaying diff. Do not spawn an agent.
- Common: line 138
Run the pre-flight check first:
- Very specific: line 145
If disabled: true: display the disabled message from Step 1 and STOP
- Very specific: line 146
If error: display the error message and STOP
- Very specific: line 147
If action: "spawn_agent": pre-flight passed -- proceed with the inline build below
- Common: line 157
Run the build, copy artifacts, write the diff snapshot, and report the summary in a single foreground Bash call so the whole pipeline …
- Very specific: line 168
Do NOT pass run_in_background: true.
- Common: line 170
If the chain fails (non-zero exit):
- Very specific: line 172
Do NOT delete .planning/graphs/ -- the prior valid graph remains available
- Common: line 175
If the chain succeeds:
- Very specific: line 183
MVP-mode rendering: When a phase has Mode: mvp in ROADMAP.md (resolved via gsd-sdk query roadmap.get-phase --pick mode), render its graph …
- Very specific: line 185
Distinct fill color: Use #22c55e (green) for MVP-mode phase nodes.
- Distinctive: line 190
When the phase mode is null/absent, render with the standard color and label — no behavioral change for non-MVP phases.
- Distinctive: line 196
DO NOT spawn an agent for any operation -- build, query, status, and diff all run inline.
- Very specific: line 197
DO NOT pass run_in_background: true for the build chain -- the operation is fast and must complete in the foreground.
- Very specific: line 198
DO NOT modify graph files directly -- always go through graphify update .
- Distinctive: line 199
DO NOT skip the config gate check.
- Very specific: line 200
DO NOT use gsd-tools config get-value for the config gate -- it exits on missing keys.
“Common” is measured: kept by at least 6 in 10 of the 4 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
STOP -- DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's command system. Using the Read tool on this file wastes tokens. Begin executing Step 0 immediately.
CJS-only (graphify): graphify subcommands are not registered on gsd-sdk query. Use node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify … as documented in this command and in docs/CLI-TOOLS.md. Other tooling may still use gsd-sdk query where a handler exists.
Step 0 -- Banner
Before ANY tool calls, display this banner:
GSD > GRAPHIFYThen proceed to Step 1.
Step 1 -- Config Gate
Check if graphify is enabled by reading .planning/config.json directly using the Read tool.
DO NOT use the gsd-tools config get-value command -- it hard-exits on missing keys.
- Read
.planning/config.jsonusing the Read tool - If the file does not exist: display the disabled message below and STOP
- Parse the JSON content. Check if
config.graphify && config.graphify.enabled === true - If
graphify.enabledis NOT explicitlytrue: display the disabled message below and STOP - If
graphify.enabledistrue: proceed to Step 2
Disabled message:
GSD > GRAPHIFY
Knowledge graph is disabled. To activate:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs config-set graphify.enabled true
Then run /gsd-graphify build to create the initial graph.Step 2 -- Parse Argument
Parse $ARGUMENTS to determine the operation mode:
| Argument | Action |
build | Run inline build (Step 3) |
query <term> | Run inline query (Step 2a) |
status | Run inline status check (Step 2b) |
diff | Run inline diff check (Step 2c) |
| No argument or unknown | Show usage message |
Usage message (shown when no argument or unrecognized argument):
GSD > GRAPHIFY
Usage: /gsd-graphify <mode>
Modes:
build Build or rebuild the knowledge graph
query <term> Search the graph for a term
status Show graph freshness and statistics
diff Show changes since last buildStep 2a -- Query
Run:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify query <term>Parse the JSON output and display results:
- If the output contains
"disabled": true, display the disabled message from Step 1 and STOP - If the output contains
"error"field, display the error message and STOP - If no nodes found, display:
No graph matches for '<term>'. Try /gsd-graphify build to create or rebuild the graph. - Otherwise, display matched nodes grouped by type, with edge relationships and confidence tiers (EXTRACTED/INFERRED/AMBIGUOUS)
STOP after displaying results. Do not spawn an agent.
Step 2b -- Status
Run:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify statusParse the JSON output and display:
- If
exists: false, display the message field - Otherwise show last build time, node/edge/hyperedge counts, and STALE or FRESH indicator
- If
built_at_commitis non-null, also display aSource commit:line:commit_stale === false(rebuilt at HEAD):Source commit: <built_at_commit> (current)commit_stale === true(graph behind HEAD):Source commit: <built_at_commit> (<commits_behind> commits behind HEAD)commit_stale === null(unreachable commit / no git):Source commit: <built_at_commit> (freshness unknown)
- If
built_at_commitis null (pre-graphify-v0.7 graph), omit the source-commit line entirely — do not render "Source commit: unknown"
The mtime-based STALE/FRESH flag and the commit-based commit_stale measure
different things and can disagree (e.g., a CI-built graph rebuilt minutes ago
against an old checkout reads as FRESH on mtime but commit_stale: true).
Surface both so the agent can choose.
STOP after displaying status. Do not spawn an agent.
Step 2c -- Diff
Run:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify diffParse the JSON output and display:
- If
no_baseline: true, display the message field - Otherwise show node and edge change counts (added/removed/changed)
If no snapshot exists, suggest running build twice (first to create, second to generate a diff baseline).
STOP after displaying diff. Do not spawn an agent.
Step 3 -- Build (Inline)
Run the pre-flight check first:
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" graphify buildParse the JSON output:
- If
disabled: true: display the disabled message from Step 1 and STOP - If
error: display the error message and STOP - If
action: "spawn_agent": pre-flight passed -- proceed with the inline build below
(The spawn_agent action name is historical. The skill now performs the build inline because graphify v0.7+ split the build into a fast AST-extraction phase and a separate clustering + report-write phase. Sub-agent isolation kept the cached extraction phase alive but SIGTERM'd the post-extraction phase when the agent exited, leaving the cache populated but no graph.json artifacts written. The CLI still emits the spawn_agent signal so external callers and tests keep working.)
Display:
GSD > Building knowledge graph...Run the build, copy artifacts, write the diff snapshot, and report the summary in a single foreground Bash call so the whole pipeline survives to completion. Use a timeout of 600000 ms (10 minutes), which covers the graphify.build_timeout ceiling (default 300 s) with margin:
graphify update . \
&& cp graphify-out/graph.json .planning/graphs/graph.json \
&& cp graphify-out/graph.html .planning/graphs/graph.html \
&& cp graphify-out/GRAPH_REPORT.md .planning/graphs/GRAPH_REPORT.md \
&& node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" graphify build snapshot \
&& node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" graphify statusDo NOT pass run_in_background: true. Typical builds complete in 15-60 seconds and the entire chain must run foreground.
If the chain fails (non-zero exit):
- Display:
## GRAPHIFY BUILD FAILEDfollowed by the captured stderr - Do NOT delete
.planning/graphs/-- the prior valid graph remains available - STOP
If the chain succeeds:
- Parse the trailing
graphify statusJSON - Display:
## GRAPHIFY BUILD COMPLETEwith the node, edge, and hyperedge counts
MVP-Mode Node Rendering
MVP-mode rendering. When a phase has **Mode:** mvp in ROADMAP.md (resolved via gsd-sdk query roadmap.get-phase --pick mode), render its graph node with two distinct visual signals:
- Distinct fill color. Use
#22c55e(green) for MVP-mode phase nodes. Standard phases keep the default fill color. Two-channel signaling (color + label) handles color-blind and grayscale renders. MVPlabel suffix. Append(MVP)to the node's label text. Example: a phase originally labeledPhase 1: User Authrenders asPhase 1: User Auth (MVP).
Both signals fire together — never just one. Per PRD Q5 decision, the goal is unambiguous visual distinction in any render context.
When the phase mode is null/absent, render with the standard color and label — no behavioral change for non-MVP phases.
Anti-Patterns
- DO NOT spawn an agent for any operation -- build, query, status, and diff all run inline. Sub-agent isolation terminates background bash when the agent exits, which previously truncated graphify builds mid-write and left only the cache populated (#3166).
- DO NOT pass
run_in_background: truefor the build chain -- the operation is fast and must complete in the foreground. - DO NOT modify graph files directly -- always go through
graphify update .and the snapshot CLI. - DO NOT skip the config gate check.
- DO NOT use
gsd-tools config get-valuefor the config gate -- it exits on missing keys.
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.

