Graphify

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

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

• 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

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

Step 2: Choose 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

Step 3: Scope the corpus before doing anything expensive

• 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

• 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

• 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

• 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

• 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

Step 6: Read artifacts in the right order

1. graphify-out/GRAPH_REPORT.md

2. graphify-out/graph.html

3. graphify-out/graph.json

graph.json

Step 7: Route adjacent work outward

• 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

Step 8: Return one concise graph brief

• 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

• 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

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

• repo-structure-packet

• local-python-build

  or

  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

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

• 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

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

• 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

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

• routes to

  codebase-search

• does not force Graphify where search is the bottleneck

Best practices

1. Use the smallest scope that answers the question.
2. Keep assistant-native install, local build, refresh, query, and fallback as distinct modes.
3. Prefer

   GRAPH_REPORT.md

   before raw graph JSON.
4. Treat structural fallback as a first-class honest mode, not a hidden failure.
5. Route search-first work to

   codebase-search

   instead of overselling graphing.
6. Route narrative memory to

   llm-wiki

   and project memory to

   opencontext

   .
7. Refresh compact and discovery surfaces whenever the front-door wording changes materially.
8. 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/