nexus-dev-toolkit
Developer workflow toolkit for Claude Code and OpenCode. Gives any team a structured Day 0 scaffold and repeatable Day 1 feature cycle via the EPAV methodology.
Why
Ad-hoc AI prompting doesn't scale. Every dev prompts differently, context drifts, and nobody knows what the AI was told last sprint.
nexus-dev-toolkit gives your team a single workflow:
- Day 0 — scaffold the project once, production-grade, zero credentials needed
- Day 1 — every feature follows the same four steps: evaluate → plan → apply → validate
Every skill, every rule, every pattern lives in the project repo — versioned, shared, and enforced.
Setup
1. Install prerequisites
uv (recommended package manager):
curl -LsSf https://astral.sh/uv/install.sh | sh
Claude Code:
npm install -g @anthropic-ai/claude-code
claude login
graphify (strongly recommended) — builds a queryable knowledge graph of your codebase. EPAV skills query this graph to understand blast radius and cross-file dependencies before touching any code.
| With graphify | Without graphify | |
|---|---|---|
| Context loading | Scoped subgraph — fast, low token cost | Full file reads — slow, high token cost |
| Blast radius | Accurate, graph-backed | Best-effort, grep-based |
| Auto-update | PostToolUse hook keeps graph current | N/A |
| EPAV skills | Full capability | Degraded but functional |
uv tool install graphifyy # PyPI package name has double y; command is "graphify"
graphify install # registers /graphify skill into Claude Code
codegraph (alternative to graphify) — a different knowledge-graph tool EPAV skills can use instead. Pick one, not both; nexus doctor warns if it finds graphs from both built in the same project.
npm i -g @colbymchenry/codegraph
codegraph install # wires codegraph into Claude Code / OpenCode / etc.
2. Install nexus-dev-toolkit
uv tool install nexus-dev-toolkit
3. Initialize your project
cd my-project
nexus init . # Claude Code (default), prompts for graphify/codegraph/none
nexus init . --tool opencode # OpenCode
nexus init . --graph-backend codegraph # skip the prompt, use codegraph
4. Place your reference docs
Before running /scaffold, put everything Claude needs in docs/:
docs/
├── arch-docs/ ← architecture doc, ADRs
├── figma/ ← Figma export ZIP
├── brd/ ← Business Requirements Document
└── prd/ ← Product Requirements Document
5. Start Day 0
Open the project in Claude Code and run:
/scaffold
/scaffold runs EVALUATE first then stops. You drive each phase by typing the next command:
/scaffold → (review) → /plan → (review) → /apply → (review) → /validate
6. Build the knowledge graph
After /scaffold completes, build whichever backend you chose at init:
/graphify . # if you chose graphify
codegraph install && codegraph init # if you chose codegraph, run in your terminal
This generates graphify-out/graph.json or .codegraph/codegraph.db — EPAV skills use whichever is present, or fall back to full file reads if neither is built yet. Run nexus doctor any time to check which backend is active.
The Workflow
Day 0 — /scaffold (once per project)
Produces a production-grade project from your architecture document and Figma design: correct stack, mock auth, mock data, design system, AGENTS.md — zero external dependencies. Runs npm install && npm run dev (or equivalent) from commit one.
Day 1 — EPAV (every feature, every sprint)
/evaluate <task> → /plan → /apply → /validate
Each step is a built-in skill in .claude/commands/. Every task starts from the dev tasks CSV. Every task ends with acceptance criteria verified.
What nexus init Creates
settings.json/graphify.js below are only created if you pick graphify (the default) at the --graph-backend prompt. Pick codegraph instead and neither is scaffolded — codegraph wires and syncs itself via codegraph install && codegraph init.
Claude Code (nexus init .):
.claude/
├── commands/ ← EPAV skills + 5 reviewer skills (/code-review, etc.)
├── agents/ ← 5 reviewer subagents (code-reviewer, database-reviewer, etc.)
└── settings.json ← PostToolUse: graphify auto-updates after every file edit (graphify backend only)
knowledge/
├── rules/ ← coding standards, arch decisions
├── patterns/ ← reusable implementation patterns
├── prompts/dev/ ← task prompt templates
└── retros/ ← retrospective notes
.mcp.json ← MCP server config
OpenCode (nexus init . --tool opencode):
.opencode/
├── commands/ ← same EPAV skills + reviewer skills
├── agents/ ← same reviewer subagents (adapted for OpenCode)
└── plugins/
└── graphify.js ← tool.execute.after: graphify auto-update (graphify backend only)
knowledge/ ← same structure
opencode.json ← MCP server config
Commands
nexus init . # Claude Code — set up .claude/ + knowledge/ + .mcp.json
nexus init . --tool opencode # OpenCode — set up .opencode/ + knowledge/ + opencode.json
nexus --version # show installed version
nexus update # update the CLI itself; asks whether to also sync in a real terminal
nexus update --sync # skip the prompt, always sync the current project's skills/agents too
nexus sync # sync built-in skills & agents to latest (custom files untouched)
nexus doctor # validate project setup
nexus skill list # list all skills in .claude/commands/
nexus skill add my-review # create a custom skill
nexus agent list # list all subagents in .claude/agents/
nexus agent add my-agent # create a custom subagent
nexus rule list # list all rules in knowledge/rules/
nexus rule add api-standards # create a project rule
MCP Server
nexus init writes .mcp.json automatically. For Claude Desktop, add manually:
{
"mcpServers": {
"nexus": {
"command": "uvx",
"args": ["--refresh", "--from", "nexus-dev-toolkit", "nexus-mcp"]
}
}
}
MCP Tools
| Tool | Purpose |
|---|---|
ingest_architecture_doc |
Load arch doc → knowledge/rules/arch-summary.md |
load_task |
Load a CSV task row into context |
generate_project_rules |
Generate AGENTS.md from arch doc |
resolve_package_versions |
Resolve exact package versions via real package manager |
Custom Skills
nexus skill add my-code-review
# Edit .claude/commands/my-code-review.md
# Type /my-code-review in Claude Code
Custom skills live alongside built-in skills in .claude/commands/ — versioned in your repo, shared across the team.
License
Metadata
Release files for nexus-dev-toolkit 3.1.9
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| nexus_dev_toolkit-3.1.9.tar.gz | 64.0 kB | With provenance | Details for nexus_dev_toolkit-3.1.9.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| nexus_dev_toolkit-3.1.9-py3-none-any.whl | Python 3 | none | any | Details for nexus_dev_toolkit-3.1.9-py3-none-any.whl |
Total release size: 137.4 kB
Release files / nexus_dev_toolkit-3.1.9.tar.gz
| Download URL | nexus_dev_toolkit-3.1.9.tar.gz |
|---|---|
| Size | 64.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
7e27df35c81f86a704824644bc560e2d6eedcbc77bfcccea927ca21c4f8bea15
|
|
BLAKE2b-256 checksum How to use checksums |
c94390ca19c53e06b785fb35ccdb0eb6ba3bbb32e099bbf0bb75b7ffb41e201b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.
Transparency logRelease files / nexus_dev_toolkit-3.1.9-py3-none-any.whl
| Download URL | nexus_dev_toolkit-3.1.9-py3-none-any.whl |
|---|---|
| Size | 73.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
0d22d26bce53bb07ff58a41800b5dc1d4177f26024d3fb2e47a718f3c4f5a7e3
|
|
BLAKE2b-256 checksum How to use checksums |
bcb2bed0ab6de3aa3debb49780c011e586a37b63ec9bdbd9a7b371283c34a7f2
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.
Transparency logSecurity for nexus-dev-toolkit 3.1.9
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for nexus_dev_toolkit-3.1.9.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.