THE IMPORT PATH
You have code. The forge joins mid-flight.
The forge doesn't just build from nothing. It can join a project already in flight. You've got code, you've got infrastructure, you've got history. The forge respects all of it — but it needs to understand it first.
Bilbo1. ADD THE METHODOLOGY
Initialize VoidForge in your existing project directory. This adds the methodology layer without touching your code.
npx thevoidforge initThis adds the VoidForge methodology: CLAUDE.md, slash commands, method docs, code patterns, and the naming registry. No runtime dependencies are added to your project. Point Claude Code at it and the forge absorbs the methodology.
Now launch Claude Code from your project directory:
cd my-project
claudeThis launches Claude Code. It reads the CLAUDE.md and loads the VoidForge methodology. All slash commands below are typed at the Claude Code prompt.
2. ASSESS THE CODEBASE
Before writing a PRD or building anything, let Picard's bridge crew map what you already have:
/assessThis chains three operations into one command. Picard runs a full architecture scan — schema, integrations, security posture, service boundaries. Thanos runs an assessment-mode Gauntlet (Rounds 1-2 only) that groups findings by root cause instead of domain. Dax and Troi diff your existing PRD against reality — or inventory what exists if you don't have a PRD yet.
The result is a State of the Codebase report in /logs/assessment.md — architecture summary, root causes grouped, PRD alignment, and a remediation plan. This becomes the foundation for everything that follows.
Assessment before action. I need to understand your architecture — the schema, the integrations, the security posture — before I can advise on what to build next. The assessment report becomes Sisko's briefing document.
Picard3. GENERATE YOUR PRD
Now that the assessment has mapped your existing system, have Sisko interview you about what to build next:
/prdSisko's 5-act interview is now informed by the assessment. He knows your stack, your schema, your security posture. The PRD he produces describes what you already have AND what you want to add — with frontmatter that captures your existing constraints so agents work within them instead of fighting them.
If you already have a PRD, the assessment report will have flagged where it drifted from reality. Run /prd --challenge to have Boromir red-team the existing PRD against the assessment findings.
4. BUILD WITH CAMPAIGN
Hand the PRD to Sisko and let the campaign engine sequence the work:
/campaignDax reads the PRD and assessment, orders missions by dependency, and Sisko briefs you on each one before execution. Each mission runs through the full pipeline — architect, build, review, security — without touching anything outside its scope.
Campaigns run autonomously by default — no confirmation prompts, auto-commits after each mission, auto-debriefs to capture learnings. Walk away and come back to a built project. The Victory Gauntlet at the end is non-negotiable. Use --interactive to pause between missions if you want to inspect each one.
I don't care who wrote the code before me. I test it the same way. If it breaks under pressure, I find it.
BatmanWHAT'S NEXT
Deep-dive into the tools: learn how the Gauntlet works (including the --assess flag for lightweight pre-build evaluation), or how campaigns break a full PRD into executable missions with checkpoint gauntlets and learned rules.
Once your imported project is hardened and your new features are built, the growth engine handles SEO, ads, social, and outreach — turning your existing project into a growth machine.