Generates and updates README.md and API reference docs by building a knowledge graph of your codebase with graphify, then writing accurate docs from it.
How this skill is triggered — by the user, by Claude, or both
Slash command
/opendirectory-gtm-skills:docs-from-codeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a technical writer. Your job is to generate accurate, developer-friendly docs by first building a knowledge graph of the codebase with graphify, then using that graph to write docs grounded in what actually exists.
You are a technical writer. Your job is to generate accurate, developer-friendly docs by first building a knowledge graph of the codebase with graphify, then using that graph to write docs grounded in what actually exists.
DO NOT invent code. If you cannot find a clear description for something, write [Description needed]. Accurate but sparse docs are better than confident but wrong docs.
Before starting: Confirm you are inside a codebase directory. If the user pointed you at a remote repo, clone it first. If neither, ask: "Can you point me to the project directory or repository URL?"
graphify uses tree-sitter AST (20 languages, no LLM) for code structure and Claude subagents for semantic understanding of docs and comments.
pip install graphifyy
graphify . --no-viz
--no-viz skips HTML output. You only need GRAPH_REPORT.md and graph.json.
This produces graphify-out/ in the project root:
GRAPH_REPORT.md — god nodes, community clusters, surprising connections, suggested questionsgraph.json — full queryable knowledge graph (persistent, SHA256-cached)QA: Did graphify-out/GRAPH_REPORT.md get created? How many nodes and edges? If graphify fails, go to Step 1B.
# TypeScript/JS projects:
cd <skill-directory>/scripts && npm install
npx ts-node extract_ts.ts <project-root> <project-root>/.docs-extract.json
# Python projects:
python3 <skill-directory>/scripts/extract_py.py <project-root> <project-root>/.docs-extract.json
Read references/extraction-guide.md for framework-specific notes on the fallback output.
Read graphify-out/GRAPH_REPORT.md in full. This gives you:
Then run targeted queries for specific doc sections:
# API routes
graphify query "show all API routes and endpoints" --graph graphify-out/graph.json
# Data models
graphify query "what are the main data models and types?" --graph graphify-out/graph.json
# Auth flow
graphify query "how does authentication work?" --graph graphify-out/graph.json
# Entry points
graphify query "what is the entry point and how is the app initialised?" --graph graphify-out/graph.json
Each query returns a focused subgraph. Relationships are tagged EXTRACTED (found in source) or INFERRED (with confidence score). Trust EXTRACTED fully. Use INFERRED but flag uncertainty.
QA: Cross-check 2-3 routes from the query against actual source files before writing docs.
Before writing anything new, check what already exists:
README.md if present. Note which sections exist and which are stale or missing.docs/API.md, docs/api.md, or API.md if present.CHANGELOG.md for context on recent changes worth noting.Decide what to generate:
references/output-template.mdQA: List exactly what you will write or update before starting.
Read references/output-template.md for the exact templates to use.
README — Project Description:
From package.json or pyproject.toml description + god nodes summary from GRAPH_REPORT.md.
README — Architecture Section: Use god nodes and community clusters to write a plain-English architecture overview. Example:
"The system is organised around 3 core modules:
AuthService(god node, connects to 14 other components),DatabaseAdapter(bridges all data access), andEventBus(central to async flows). The auth and request-handling modules are tightly coupled; the analytics module is independent."
README — Installation and Quick Start:
From the entry point file + scripts in package.json or Makefile.
API Reference (docs/API.md):
From the graphify query "show all API routes" output. One section per resource, grouped by path prefix. For each route: method, path, description (from docstring or rationale node), request/response shape (from linked type nodes), curl example.
Flag anything without a docstring as [Description needed]. Do not invent behaviour.
QA: Check 3 random routes in the generated docs/API.md against the actual source file. Do the paths and descriptions match?
README.md to the project root (full file or updated sections only).docs/API.md if routes were found. Create docs/ if needed.rm -rf graphify-out/ .docs-extract.jsonAsk the user: "Docs written. Should I open a GitHub PR with these changes?"
If yes:
git checkout -b docs/auto-generated-$(date +%Y%m%d)
git add README.md docs/
git commit -m "docs: auto-generate README and API reference from codebase"
gh pr create \
--title "docs: auto-generated README and API reference" \
--body "Generated by docs-from-code skill using graphify knowledge graph. All routes and types verified against source."
QA: Did the files write? Do paths exist? Did the PR open cleanly?
docs/API.md matches a real path from the graphify query output[Description needed], not fabricatednpx claudepluginhub varnan-tech/opendirectory --plugin opendirectory-gtm-skillsGenerates API docs, architecture diagrams, user guides, and technical references from code using AI analysis and best practices. Useful for documentation pipelines and repo standardization.
Builds a local knowledge graph of code, docs, and mixed media using tree-sitter extraction and LLM-based relationship inference. Query via CLI commands instead of reading raw files.