Graphify

Use this skill when the main question is "what graph mode should we trust, what artifact should we produce, and what should we read next?"

The job is not to dump every Graphify feature or pretend all repo-understanding work needs a graph. The job is to:

classify the request into one graph packet,
choose one honest execution mode,
scope the corpus before runtime or token pain explodes,
report artifacts and fallback truthfully,
route search-only, wiki-only, or project-memory work to the right neighboring skill.

Read references/mode-packets-and-route-outs.md before handling an unfamiliar request. Read references/build-and-fallback-recipes.md when choosing between assistant-native install, local Python, incremental refresh, and structural fallback.

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, graph-backed relationship tracing, path queries, or architecture discovery that should survive the current session
The corpus mixes code, docs, PDFs, notes, screenshots, or other assets and the user wants one durable structure layer
The user wants to refresh, query, or explain an existing Graphify output instead of re-reading raw files from scratch
The user asks to install Graphify into Claude, Codex, Gemini, OpenCode, or another coding assistant for always-on graph access

When not to use this skill

The user only needs to find a symbol, file owner, config location, or reference chain → use
```
codebase-search
```
The user wants a persistent markdown knowledge base or filed research notes → use
```
llm-wiki
```
The user wants project/repo memory, manifests, or cross-agent handoff packets → use
```
opencontext
```
The user needs dependency-only JS/TS analysis or a quick repo tree diagram, not a durable graph memory layer
The request is generic GraphRAG / text-KG architecture without a concrete Graphify or durable structure ask

Instructions

Step 1: Start from the graph packet already in hand

Use references/mode-packets-and-route-outs.md.

Normalize the request into one of these packet shapes:

```
repo-structure-packet
```
— map a codebase or subsystem before editing
```
relationship-trace-packet
```
— answer a path/query/explain question from an existing or newly built graph
```
mixed-corpus-memory-packet
```
— build durable structure across code + docs + assets + sources
```
assistant-install-packet
```
— install Graphify into an assistant for always-on use
```
refresh-or-fallback-packet
```
— update an existing graph, recover from empty/weak output, or switch to structural fallback

Capture the smallest useful frame:

markdown

Packet: repo-structure-packet
Scope: src/ + docs/architecture/
Need: GRAPH_REPORT.md + one path query
Graph state: no current outputs
Main risk: whole-repo graphing is too noisy

Rule: start from the packet the user already has. Do not force every request through a full feature tour.

Step 2: Choose one primary mode

Pick exactly one primary mode:

```
assistant-native-install
```
— install Graphify into Claude/Codex/Gemini/OpenCode because always-on
```
/graphify
```
access is the real goal
```
local-python-build
```
— run the local Python/API workflow because the environment needs a truthful non-native path
```
incremental-refresh
```
— update an existing graph on changed scope instead of rebuilding everything blindly
```
graph-query-followup
```
— start from current artifacts and answer focused graph-backed questions
```
structural-fallback
```
— produce a graphify-style structural graph when native extraction is unavailable, empty, or misleading for a markdown-heavy corpus

Optional: mention one fallback mode, but do not hand the user five equal options.

Step 3: Scope the corpus before doing anything expensive

Choose the smallest path that answers the question.

Good defaults:

repo root only when the user truly needs repo-wide architecture
```
src/
```
,
```
app/
```
,
```
packages/foo/
```
, or one service directory for implementation work
```
raw/
```
,
```
docs/
```
, or a mixed research folder for corpus graphing
existing
```
graphify-out/
```
when the job is query/refresh rather than rebuild

Rules:

avoid blind whole-repo graphing on large repos
prefer
```
.graphifyignore
```
or smaller scope over hoping runtime cost behaves
if the graph request is really a locate/reference request, route to
```
codebase-search
```

Step 4: Tell the truth about install and runtime shape

Use references/build-and-fallback-recipes.md.

Core facts to preserve:

official PyPI package name:
```
graphifyy
```
CLI command:
```
graphify
```
Python 3.10+
assistant-native installs exist for Claude / Codex / Gemini / OpenCode and related tools
local automation may need a Python/API path or structural fallback rather than assuming assistant-native
```
/graphify
```
is available

Never blur these cases:

always-on assistant install
local one-shot graph build / refresh
querying an existing graph
structural fallback because native extraction is not the honest answer

Step 5: Run the chosen mode with the narrowest recipe

Keep commands or steps minimal and mode-specific.

Typical recipes:

```
assistant-native-install
```
→ install / verify the assistant-specific Graphify integration
```
local-python-build
```
→ install
```
graphifyy
```
, verify runtime, run the Python pipeline or tested local workflow, and export
```
GRAPH_REPORT.md
```
,
```
graph.json
```
, and
```
graph.html
```
```
incremental-refresh
```
→ reuse existing artifacts and refresh only the changed scope when practical

graph-query-followup

→ read

GRAPH_REPORT.md

first, then run

query

path

, or

explain

```
structural-fallback
```
→ build the smallest truthful graph from filesystem structure, frontmatter, support files, and explicit mentions instead of pretending native semantic extraction succeeded

If the corpus is markdown-heavy and native extraction returns a 0-node or misleading graph, switch modes instead of retrying the same failing path.

Step 6: Read artifacts in the right order

Always prefer:

```
graphify-out/GRAPH_REPORT.md
```
```
graphify-out/graph.html
```
```
graphify-out/graph.json
```

Do not dump raw

graph.json

into a prompt if the report or a focused query is enough.

Step 7: Route adjacent work outward

This skill owns durable graph mode choice and graph-backed follow-up, not every repo/corpus task.

Typical route-outs:

```
codebase-search
```
— exact text, symbol, config/content ownership, and impact mapping before graphing
```
llm-wiki
```
— narrative synthesis, wiki pages, source filing, long-lived markdown knowledge bases
```
opencontext
```
— searchable decisions, manifests, stable links, and project-memory handoff
```
survey
```
— broader landscape scans when the real question is tool/platform comparison before choosing Graphify

If the user asks “build or query the graph,” stay here. If they ask “find the file/symbol fast,” “file this as a wiki note,” or “store this as project memory,” route out.

Step 8: Return one concise graph brief

Always return a short operator-style brief with:

packet
primary mode
scope
output directory / artifacts
whether the result was native Graphify or structural fallback
1–3 next steps or queries
one route-out if neighboring work now owns the next step

Output format

Always return a graph build brief, graph refresh brief, graph query brief, or Graphify install brief.

Required qualities:

identify the packet already in hand
choose one primary mode
name the scope explicitly
state which artifacts exist or were created
label fallback mode honestly when native extraction was not used
read from
```
GRAPH_REPORT.md
```
before over-focusing on raw graph JSON
route search-only, wiki-only, or project-memory work outward

Examples

Example 1: understand a repo before editing

Input

Map this repo with Graphify so I can understand the architecture before touching code.

Good output direction

```
repo-structure-packet
```

local-python-build

assistant-native-install

depending on environment

scopes the repo honestly
reports
```
GRAPH_REPORT.md
```
,
```
graph.json
```
,
```
graph.html
```

Example 2: trace a relationship from an existing graph

Input

We already have graphify-out. What connects the auth controller to billing?

Good output direction

```
relationship-trace-packet
```
```
graph-query-followup
```
reads
```
GRAPH_REPORT.md
```
first, then uses
```
query
```
/
```
path
```
avoids unnecessary rebuilds

Example 3: mixed corpus with markdown-heavy sources

Input

Turn this docs + screenshots + notes folder into a persistent graph we can reuse next week.

Good output direction

```
mixed-corpus-memory-packet
```
chooses
```
local-python-build
```
or
```
structural-fallback
```
explains whether the result is native Graphify or graphify-style structural fallback

Example 4: request is really search, not graphing

Input

I just need to find where this config is defined and who references it.

Good output direction

routes to
```
codebase-search
```
does not force Graphify where search is the bottleneck

Best practices

Use the smallest scope that answers the question.
Keep assistant-native install, local build, refresh, query, and fallback as distinct modes.
Prefer
```
GRAPH_REPORT.md
```
before raw graph JSON.
Treat structural fallback as a first-class honest mode, not a hidden failure.
Route search-first work to
```
codebase-search
```
instead of overselling graphing.
Route narrative memory to
```
llm-wiki
```
and project memory to
```
opencontext
```
.
Refresh compact and discovery surfaces whenever the front-door wording changes materially.
If a graph build is machine-specific or path-leaky, say so instead of presenting it as portable truth.

References

Mode packets and route-outs
Build and fallback recipes
```
../codebase-search/SKILL.md
```
```
../llm-wiki/SKILL.md
```
```
../opencontext/SKILL.md
```
Graphify upstream: https://github.com/safishamsi/graphify
Graphify PyPI: https://pypi.org/project/graphifyy/

graphify

NPX Install

Tags

SKILL.md Content

Graphify

When to use this skill

When not to use this skill

Instructions

Step 1: Start from the graph packet already in hand

Step 2: Choose one primary mode

Step 3: Scope the corpus before doing anything expensive

Step 4: Tell the truth about install and runtime shape

Step 5: Run the chosen mode with the narrowest recipe

Step 6: Read artifacts in the right order

Step 7: Route adjacent work outward

Step 8: Return one concise graph brief

Output format

Examples

Example 1: understand a repo before editing

Example 2: trace a relationship from an existing graph

Example 3: mixed corpus with markdown-heavy sources

Example 4: request is really search, not graphing

Best practices

References