Imported from akillness/jeo-skills (
.agent-skills/graphify/SKILL.md) via skills.sh. Install upstream withnpx skills add akillness/jeo-skills --skill graphify. Copyright stays with the author.
Graphify
Graphify is a CLI. The primary path for every request in this skill is a real
graphify … command, not a slash command and not an improvised Python script.
Use this skill when the main question is "which graphify command answers this, over what scope, and what should we read next?"
The job is to:
- classify the request into one graph packet,
- choose one CLI mode,
- scope the corpus before runtime or token cost explodes,
- report artifacts and any degraded output truthfully,
- route search-only, wiki-only, or project-memory work to the right neighboring skill.
Read references/cli-command-map.md for the full command surface with real flags. Read references/install-matrix.md before installing anything — especially for jeo / jeopi / gjc / opencode. Read references/mode-packets-and-route-outs.md for an unfamiliar request, and references/build-and-fallback-recipes.md when native extraction is weak.
CLI quickstart
pip install graphifyy # PyPI package is graphifyy; the binary is graphify
graphify --version
graphify scope # what would actually be graphed?
graphify update . # build -> .graphify/graph.json + .graphify/GRAPH_REPORT.md
graphify summary # hubs, communities, representative nodes
graphify query "where is auth enforced?" --budget 1500
graphify explain <node> # one node, plain language
graphify path <source> <target> # shortest path between two nodes
graphify tree <node> --depth 2 # local neighbourhood
graphify export html # -> .graphify/graph.html
Three facts that keep answers truthful:
graphify builddoes not exist. The build command isgraphify update.graphify build --helpsilently falls through to the root help.- State lives in
.graphify/, notgraphify-out/.graphify-out/is the legacy layout;graphify migrate-statemoves it. Every--graph <path>flag defaults to<cwd>/.graphify/graph.json. graph.htmlis not produced bygraphify update. It comes fromgraphify export html.
When to use this skill
- The user explicitly wants
GRAPH_REPORT.md,graph.json,graph.html, a codebase graph, or a persistent knowledge graph - The request is about repo/corpus structure, relationship tracing, path queries, or architecture discovery that should survive the current session
- The corpus mixes code, docs, PDFs, notes, or screenshots and the user wants one durable structure layer
- The user wants to refresh, query, or explain an existing graph instead of re-reading raw files
- The user wants change-aware review context, affected execution flows, or risk scoring for a diff or PR
- The user wants Graphify installed into jeo, jeopi, gjc, opencode, Claude, Codex, Gemini, or another supported agent
When not to use this skill
- Only needs to find a symbol, file owner, config location, or reference chain →
codebase-search - Wants a persistent markdown knowledge base or filed research notes →
llm-wiki - Wants project/repo memory, manifests, or cross-agent handoff packets →
opencontext - Needs dependency-only JS/TS analysis or a quick repo tree diagram, not a durable graph
- Generic GraphRAG / text-KG architecture talk with no concrete Graphify ask
Install for jeo / jeopi / gjc / opencode
graphify install [platform] accepts exactly these ids: claude, codex, gemini,
opencode, aider, copilot, claw, droid, trae, trae-cn, hermes, kimi, kiro,
antigravity, antigravity-windows, vscode-copilot-chat, windows, vscode.
jeo, jeopi and gjc are not platform ids — graphify install jeo will fail the same way
graphify install agents does (error: unknown platform). Per this repo's
setup-all-skills-prompt.md, those three discover the shared ~/.agents/skills root natively,
which the unconditional universal id populates. So:
# CLI for everyone
pip install graphifyy && graphify --version
# skill into the shared root that jeo, jeopi, gjc and sst/opencode all read
npx skills add https://github.com/akillness/jeo-skills --skill graphify -a universal
ls "${SKILLS_ROOT:-$HOME/.agents/skills}/graphify/SKILL.md"
# optional: opencode plugin + tool.execute.before hook (sst/opencode only)
graphify install opencode # or: graphify install opencode --project
graphify install opencode --project writes .opencode/skills/graphify/SKILL.md,
.opencode/plugins/graphify.js, .opencode/opencode.json, and an AGENTS.md section.
graphify install claude --project writes .claude/skills/graphify/SKILL.md,
.claude/settings.json PreToolUse hooks, and a CLAUDE.md section.
The archived Go opencode-ai/opencode TUI has no skill loader — graphify install opencode
will not surface the skill there; bridge it as a command file or just use the CLI. Full detail:
references/install-matrix.md.
Instructions
Step 1: Normalize the request into one packet
repo-structure-packet— map a codebase or subsystem before editingrelationship-trace-packet— answer a path/query/explain question from an existing graphmixed-corpus-memory-packet— build durable structure across code + docs + assetsreview-diff-packet— produce review context or affected flows for changed filesinstall-packet— get Graphify into an agent for always-on userefresh-or-fallback-packet— update an existing graph, recover from weak output, or fall back
Start from the packet the user already has. Do not force every request through a feature tour.
Step 2: Pick one CLI mode
| Mode | Primary commands |
|---|---|
cli-build |
graphify scope → graphify update . |
cli-query |
graphify summary → query / explain / path / tree |
cli-export |
graphify export html|wiki|obsidian|svg|graphml|neo4j |
incremental-refresh |
graphify check-update → graphify update / watch / hook install |
review-context |
graphify review-context / affected-flows / detect-changes |
agent-serve |
graphify serve (stdio MCP server for graph.json) |
install |
graphify install <platform> or the ~/.agents/skills route |
structural-fallback |
build the smallest truthful structural graph when native extraction is empty or misleading |
Name one primary mode. Mention at most one fallback.
Step 3: Scope before spending
Run graphify scope first on anything unfamiliar. Good defaults:
- repo root only when repo-wide architecture is genuinely the ask
src/,app/,packages/<pkg>/, or one service directory for implementation workraw/,docs/, or a mixed research folder for corpus graphing- an existing
.graphify/when the job is query/refresh rather than rebuild
Use --scope auto|committed|tracked|all and .graphifyignore instead of hoping runtime behaves.
If the request is really locate/reference, route to codebase-search.
Step 4: Run the narrowest command set
Keep it to the commands the mode needs. Do not chain a build, an export, a wiki, and a watch loop when the user asked one question.
Step 5: Report degraded output honestly
Verified behavior: with no LLM API key configured, graphify update . still writes
graph.json and GRAPH_REPORT.md, but prints:
[graphify label] warning: community labeling failed (...); using Community N placeholders.
[graphify describe] description generation failed (...); continuing without descriptions.
When that happens, say the graph is structurally complete but unlabeled/undescribed, and offer
graphify update --fill-missing once a backend is configured. Never present placeholder
Community N names as meaningful clusters.
Step 6: Read artifacts in order
.graphify/GRAPH_REPORT.mdgraphify summary(cheaper and more focused than the HTML for agent work).graphify/graph.html(aftergraphify export html) for humans.graphify/graph.jsonlast, and prefergraphify query --budget <n>over pasting it
Step 7: Route adjacent work outward
codebase-search— exact text, symbol, config ownership, impact mapping before graphingllm-wiki— narrative synthesis, wiki pages, long-lived markdown knowledge basesopencontext— searchable decisions, manifests, stable links, project-memory handoffsurvey— tool/platform comparison before committing to Graphify
If the user asks "build or query the graph," stay here. If they ask "find the file fast," "file this as a wiki note," or "store this as project memory," route out.
Step 8: Return one concise graph brief
Packet · primary mode · commands actually run · scope · artifacts written · whether output was degraded or fallback · 1–3 next commands · one route-out if the next step belongs elsewhere.
Output format
Always return a graph build brief, graph query brief, graph refresh brief, review context brief, or Graphify install brief with:
- the packet in hand and one primary mode
- the real commands run, with their scope
- which files under
.graphify/exist or were created - honest labeling of degraded, placeholder, or fallback output
GRAPH_REPORT.md/graphify summaryread before rawgraph.json- one route-out when neighboring work now owns the next step
Examples
Example 1: understand a repo before editing
Input
Map this repo so I can understand the architecture before touching code.
Good output direction
repo-structure-packet, modecli-buildgraphify scope→graphify update .→graphify summary- reports
.graphify/GRAPH_REPORT.mdand.graphify/graph.json, and thatgraph.htmlneedsgraphify export html
Example 2: trace a relationship from an existing graph
Input
We already have a graph. What connects the auth controller to billing?
Good output direction
relationship-trace-packet, modecli-querygraphify summary→graphify path <auth> <billing>→graphify explain <node>- no rebuild
Example 3: review a diff
Input
What does this PR actually touch? I want reviewer context, not a diff dump.
Good output direction
review-diff-packet, modereview-contextgraphify review-context --base main --detail-level standardandgraphify affected-flows --base main --json
Example 4: install for our agents
Input
Install graphify for jeo, jeopi, gjc and opencode.
Good output direction
install-packetpip install graphifyy, then the skill into~/.agents/skillsvia-a universalfor jeo/jeopi/gjc, plus optionalgraphify install opencode- states plainly that
graphify install jeois not a valid platform id
Example 5: request is really search
Input
I just need to find where this config is defined and who references it.
Good output direction
- routes to
codebase-search; does not build a graph
Best practices
- Lead with a real
graphifycommand; never invent one —graphify builddoes not exist. - Write
.graphify/, notgraphify-out/; usegraphify migrate-statefor legacy repos. - Run
graphify scopebefore an expensive build on an unfamiliar corpus. - Prefer
GRAPH_REPORT.mdandgraphify summaryover rawgraph.json; cap traversals withgraphify query --budget <n>. - Keep build, query, export, refresh, review, serve, install, and fallback as distinct modes.
- Report placeholder
Community Nlabels and missing descriptions as degraded output, not success. - Use
graphify hook installorgraphify watchfor ongoing freshness instead of ad-hoc rebuilds. - Run
graphify portable-checkbefore committing.graphifyartifacts. - Treat structural fallback as a first-class honest mode, not a hidden failure.
- Route search-first work to
codebase-search, narrative memory tollm-wiki, project memory toopencontext. - After a graphify wiki build — or any
pip install --upgrade graphifyy— runscripts/patch_wikilink.pyif[[…]]links look broken. graphify's generator emits raw-label[[Community 36]]links that never resolve to its sluggedCommunity_36.mdpages; the patcher normalizes every link site to[[slug|label]]and is idempotent. Wire it into the install/upgrade step (jeo: thepost-implementationhook ahead ofgraphify update .) so the fix survives upgrades.
References
- CLI command map — every command and flag, grouped by job
- Install matrix — platform ids, jeo/jeopi/gjc/opencode routes
- Mode packets and route-outs
- Build and fallback recipes
scripts/patch_wikilink.py— idempotent wikilink-normalization patch (--self-test,--check)../codebase-search/SKILL.md·../llm-wiki/SKILL.md·../opencontext/SKILL.md- Graphify upstream: https://github.com/Graphify-Labs/graphify
- Graphify PyPI: https://pypi.org/project/graphifyy/