0-init¶
Initialize a new project or onboard an existing one. The single entry point — detects brownfield projects automatically, routes by codebase size, or asks Product Development vs Knowledge Work for greenfield.
Plugin: core-standards
Category: Other
Command: /0-init
Initialize Project¶
The single entry point for starting any new project or onboarding an existing one. Detects brownfield projects automatically, routes by codebase size (Document-First or PRD-First), or asks Product Development vs Knowledge Work for greenfield projects.
When to Use¶
- Starting a new project →
/0-init - Onboarding an existing codebase →
/0-init(detects brownfield automatically) - Checking an existing project →
/vt-c-0-start(development) or/vt-c-pd-0-start(design) or/vt-c-kw-0-start(knowledge)
Project Type Routing¶
/0-init
│
├── Step 0: Brownfield Detection
│ Scans for source files (*.ts, *.py, *.rb, etc.)
│ │
│ ├── No source files → Greenfield (Step 1)
│ │ │
│ │ ├── "Product Development"
│ │ │ Next: /vt-c-pd-1-research → ... → /vt-c-3-build
│ │ │
│ │ └── "Knowledge Work"
│ │ Next: /vt-c-kw-1-plan → ... → /vt-c-kw-4-publish
│ │
│ └── Source files found → Brownfield
│ │
│ ├── Small/Medium (<500 files) → Document-First
│ │ Analyze → CLAUDE.md → Architecture doc → /vt-c-pd-2-prd
│ │
│ └── Large (>500 files) → PRD-First
│ Target module → Focused analysis → /vt-c-pd-2-prd
│
└── --skip-analysis → /vt-c-repo-init --adopt → Step 1
Invocation¶
# Interactive — detects brownfield or asks workflow type
/0-init
# Direct — product development project (greenfield)
/0-init product my-app
# Direct — knowledge work project (greenfield)
/0-init knowledge market-research
# Skip brownfield analysis (for developers who know the codebase)
/0-init --skip-analysis
Execution Instructions¶
Step 0: Brownfield Detection¶
Detect whether this repo contains existing source code before asking about project type.
0a. Check for --skip-analysis flag:
If --skip-analysis is in the arguments:
- Run /vt-c-repo-init --adopt for governance setup only
- Skip to Step 1 (PD vs KW choice)
0b. Count source files:
find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" \
-o -name "*.py" -o -name "*.rb" -o -name "*.go" -o -name "*.java" \
-o -name "*.rs" -o -name "*.swift" -o -name "*.kt" -o -name "*.cs" \
-o -name "*.php" -o -name "*.vue" -o -name "*.svelte" \) \
-not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/vendor/*" \
-not -path "*/dist/*" -not -path "*/build/*" -not -path "*/.worktrees/*" \
-not -path "*/__pycache__/*" -not -path "*/.tox/*" -not -path "*/.venv/*" | wc -l
If 0 source files found (including repos with only config files like package.json): - This is a greenfield project → skip to Step 1
If ≥1 source files found:
- Display: "Existing code detected ({N} source files)."
- Use AskUserQuestion:
- Yes — onboard existing project → proceed to Step 0c
- No — starting fresh in this repo → skip to Step 1
- Skip analysis — I know this codebase → run /vt-c-repo-init --adopt, then skip to Step 1
0c. Edge case checks:
-
Existing CLAUDE.md (EC-1): If CLAUDE.md exists, note: "Existing CLAUDE.md found — will be preserved and augmented with discovered conventions."
-
Existing .design-state.yaml (EC-2): If .design-state.yaml exists, display what's already set up. Note: "Partially onboarded. Filling gaps only."
-
Monorepo detection (EC-3): Check for multiple dependency manifests at different directory levels:
If >1 found at different paths → AskUserQuestion: "Multiple apps/modules detected: {list}. Which one to onboard?"
0d. Size classification and routing:
Use the source file count from Step 0b: - Small (<50 files) or Medium (50-500 files) → Document-First route - Large (>500 files) → PRD-First route
Display: "Detected {N} source files. Routing to {Document-First|PRD-First} workflow."
Document-First route (small/medium codebases):
- Codebase analysis via
Agent(subagent_type="Explore")— use focused glob patterns (e.g.,src/**/*.ts), not recursive tree walks. Target completion within 2 minutes (NFR-1): - Discover project structure (directories, entry points)
- Identify tech stack (frameworks, libraries, language versions)
- Extract conventions (naming, file organization, test patterns)
-
Find existing documentation (README, wiki, inline comments)
-
Generate or augment CLAUDE.md with discovered conventions:
If CLAUDE.md already exists (EC-1): append a## Repository Overview [project purpose, from README/package.json description] ## Tech Stack - Language: [name] [version from config] - Framework: [name] [version] - Database: [if detected] ## Build & Test Commands [extracted from package.json scripts / Makefile / etc.] ## Code Conventions - Naming: [camelCase/snake_case — from actual files] - File organization: [patterns discovered] - Test location: [co-located / separate test/ dir] ## Architecture [high-level module descriptions with purposes]## Discovered Conventionssection at the end. Never overwrite existing content. -
Generate architecture overview → write to
docs/architecture-overview.md -
Run
/vt-c-repo-init --adoptfor governance setup (.design-state.yaml, .repo-manifest.yaml) -
Display next step:
Then exit (do not proceed to Step 1).
PRD-First route (large codebases):
- Ask for target area via AskUserQuestion: "Which module or feature area are you working on?"
- Show detected top-level directories as options
-
Include a free text option for specific paths
-
Focused analysis of target module only via
Agent(subagent_type="Explore")scoped to the target path: - Module-level structure and conventions
-
Dependencies and integration points with rest of codebase
-
Generate or augment CLAUDE.md — same template as above but scoped to target module. If CLAUDE.md exists, append
## Discovered Conventionssection. -
Run
/vt-c-repo-init --adoptfor governance setup -
Display next step:
Then exit (do not proceed to Step 1).
Step 1: Parse Arguments¶
Extract from the invocation:
- Mode: product or knowledge (optional — if missing, go to Step 2)
- Project name: the directory/project name (optional — if missing, /vt-c-scaffold will ask)
If mode is provided, skip Step 2.
Step 2: Interactive Mode¶
If no mode argument was provided, use AskUserQuestion:
Options: - Product Development (Recommended) — For products leading to software. Includes user research, PRD, prototyping, and development phases. - Knowledge Work — For documentation, research, processes, or business deliverables. No code assumptions.
Step 3: Execute /vt-c-scaffold¶
Map the chosen mode to a scaffold type and execute the scaffold skill steps:
/0-init mode |
/vt-c-scaffold type |
Rationale |
|---|---|---|
product |
design |
Creates design-specific structure + .design-state.yaml |
knowledge |
knowledge |
Creates knowledge-specific structure |
Execute the /vt-c-scaffold skill inline with the mapped type and project name. This creates:
- Universal base (PRODUCT-VISION.md, PRD.md, CLAUDE.md, README.md, .gitignore)
- 00-inbox/README.md (universal inbox)
- 01-docs/journal/ (session journals)
- Type-specific directories
- Git initialization
- Project registration in toolkit intake
Note: /vt-c-scaffold handles all file creation, existing file detection, and git init. Do not duplicate this logic.
Step 4: Product Development Extras¶
Only for product mode:
-
Verify
.design-state.yaml:/vt-c-scaffold designcreates this. Confirm it exists. -
Offer repo governance (optional): Use AskUserQuestion:
Options: - Yes (Recommended) — Run
/vt-c-repo-initinline -
No — Skip, can enable later with
/vt-c-repo-init -
GitHub remote:
/vt-c-scaffoldalready offers this in its Step 8. No additional action needed.
Step 5: Display Workflow Overview¶
Show the complete workflow diagram for the chosen type.
Product Development:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Project Initialized: [project-name] (Product Development)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Your Workflow:
DESIGN PHASE
─────────────────────────────────────────────────────────────
/vt-c-pd-1-research User research (interviews, personas)
/vt-c-pd-pid Technical architecture & stack (PID)
/vt-c-pd-2-prd Create Product Requirements Document
/vt-c-pd-3-prototype Generate prototype with VisiTrans CD
/vt-c-pd-4-validate Usability testing and iteration
/vt-c-pd-6-handoff Development handoff
DEVELOPMENT PHASE (per spec)
─────────────────────────────────────────────────────────────
/vt-c-activate Load next specs for development
/vt-c-2-plan Architecture & task breakdown
/vt-c-3-build Implementation with /vt-c-journal captures
/vt-c-4-review Code review (mandatory)
/vt-c-5-finalize Pre-merge checks
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Knowledge Work:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Project Initialized: [project-name] (Knowledge Work)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Your Workflow:
─────────────────────────────────────────────────────────────
/vt-c-kw-1-plan Plan approach (research, structure, risks)
/vt-c-kw-2-execute Do the work with /vt-c-journal captures
/vt-c-kw-3-review Quality check deliverables
/vt-c-kw-4-publish Finalize and deliver
─────────────────────────────────────────────────────────────
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 6: Recommend Next Step¶
Product Development:
Next step: /vt-c-pd-1-research
Start with user research to understand your target users and their needs.
Supporting commands:
/vt-c-journal Capture decisions and learnings
/vt-c-consolidate Synthesize journal into docs
Knowledge Work:
Next step: /vt-c-kw-1-plan
Plan your approach, structure deliverables, and identify risks.
Supporting commands:
/vt-c-journal Capture decisions and learnings
/vt-c-consolidate Synthesize journal into docs
Edge Cases¶
- Current directory already has source code: Step 0 detects this and offers brownfield onboarding. Config-only repos (package.json without source files) are treated as greenfield (EC-4).
- Existing CLAUDE.md: Preserved and augmented with
## Discovered Conventionssection — never overwritten (EC-1). - Existing .design-state.yaml: Treated as partially onboarded — gaps filled, existing setup preserved (EC-2).
- Monorepo with multiple apps: Step 0 detects multiple dependency manifests and asks which module to onboard (EC-3).
00-inbox/already exists:/vt-c-scaffoldskips creation, does not overwrite.- User wants OneDrive integration: After
/0-init product, run/vt-c-pd-0-startwhich detects and sets up OneDrive project folders./0-initcreates the git repo structure; OneDrive structure is complementary. - User runs
/vt-c-pd-0-startdirectly: Still works as before./0-initis the recommended path, not the only path. - User runs
/vt-c-scaffolddirectly: Still works for all project types includingcodingandmixedwhich are not exposed through/0-init.
Relationship to Other Skills¶
| Skill | Role | Still standalone? |
|---|---|---|
/vt-c-scaffold |
Internal building block — creates files and folders | Yes |
/vt-c-pd-0-start |
Checks existing PD project, shows phase status | Yes |
/vt-c-kw-0-start |
Checks existing KW project, shows prerequisites | Yes |
/vt-c-0-start |
Checks existing dev project, shows prerequisites | Yes |
/0-init |
New — creates a new project from scratch | — |