From forge
Generates and queries codebase knowledge graphs for architecture-aware task decomposition, dependency discovery, and context reduction in multi-module projects with 20+ files.
npx claudepluginhub lucasduys/forge --plugin forgeThis skill uses the workspace's default tool permissions.
This skill enables Forge to leverage codebase knowledge graphs for architecture-aware planning and research. When a graphify knowledge graph exists (or can be generated), Forge agents use it to understand code structure, discover dependencies, prioritize tasks, and reduce context size.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
This skill enables Forge to leverage codebase knowledge graphs for architecture-aware planning and research. When a graphify knowledge graph exists (or can be generated), Forge agents use it to understand code structure, discover dependencies, prioritize tasks, and reduce context size.
Graphify integration is optional but recommended for projects with:
Graphify is bundled as part of Forge's tool ecosystem. Install via:
pip install graphifyy
Or use /forge setup-tools which detects and offers to install graphify automatically.
At the start of /forge plan or /forge execute, the commands auto-detect and build:
# Check if graphify is installed
node scripts/forge-tools.cjs graph-status
# If installed and no graph exists, build one automatically
node scripts/forge-tools.cjs graph-build --project-dir .
# Extract summary for planning context (god nodes, communities, stats)
node scripts/forge-tools.cjs graph-summary --graph graphify-out/graph.json
The build runs graphify . which processes the codebase through: detect -> extract (tree-sitter AST) -> build (NetworkX) -> cluster (Leiden) -> analyze -> export. Output goes to graphify-out/ (graph.json, graph.html, GRAPH_REPORT.md).
Never block on graph availability. If graphify is not installed or the build fails, all commands proceed with standard behavior.
Agents use these node one-liners to query the graph (no Python needed at query time):
| Command | Purpose |
|---|---|
graph-status | Check if graphify CLI is installed |
graph-build --project-dir . | Build knowledge graph from codebase |
graph-summary --graph graphify-out/graph.json | Get god nodes, communities, stats |
graph-query --graph graphify-out/graph.json --term "auth" | Search for nodes matching a term |
graph-dependents --graph graphify-out/graph.json --file "src/auth.ts" | Find all files that depend on a file |
When a knowledge graph is available, the forge-planner agent gains these capabilities:
Before decomposing specs into tasks, query the graph to understand the codebase structure:
Query: "What are the main architectural components?"
Result: god nodes (highest-connectivity concepts), community clusters
Use this to:
Query the graph to find implicit dependencies not obvious from the spec:
Query: "What depends on {module}?"
Result: downstream consumers, shared utilities, integration points
Use this to:
Rank tasks by the connectivity of the code they modify:
Instead of loading the full codebase context for each task, query the graph for the relevant subgraph:
Query: "Show everything related to {task-target} within depth 3"
Result: relevant nodes, edges, and source files
This provides the executor with a focused context window containing only the files and relationships relevant to their task, rather than the entire codebase.
The forge-researcher agent can use the graph to:
Before researching external docs, query the graph to understand what already exists:
Query: "Explain {concept}"
Result: all connections to the concept -- what it depends on, what depends on it, which community it belongs to
Before implementing a change, query the graph for blast radius:
Query: "Path from {source} to {target}"
Result: shortest path through the dependency graph, revealing hidden coupling
Identify how similar patterns are already implemented in the codebase:
Query: "Show nodes similar to {pattern} in community {N}"
Result: related implementations that can serve as templates
The forge-reviewer agent can use the graph to:
Cross-reference modified files against the graph to find all downstream consumers:
Query: "What depends on {modified-file}?"
Result: all files and concepts that consume exports from the modified file
Verify that changes respect architectural boundaries:
Query: "Which community does {file} belong to?"
Result: community assignment, cohesion score, bridge status
If a task modifies files in multiple communities without explicit cross-cutting justification, flag for review.
graphify-out/graph.json if it existsGraphify produces graph.json in NetworkX node-link format:
{
"nodes": [
{"id": "node-1", "label": "UserService", "type": "class", "community": 0, "source": "src/services/user.ts:15"},
...
],
"links": [
{"source": "node-1", "target": "node-2", "type": "DEPENDS_ON", "confidence": "EXTRACTED"},
...
]
}
Key fields:
community: Leiden algorithm cluster ID (group related concepts)confidence: EXTRACTED (explicit), INFERRED (deduced), AMBIGUOUS (uncertain)type: Relationship type (DEPENDS_ON, IMPLEMENTS, EXTENDS, CALLS, IMPORTS)All graph-enhanced features are additive. When no graph is available:
No Forge workflow should ever fail because graphify is unavailable.