@bcelep/capint 0.4.2 → 0.6.5

package/workflows/genesis.md

@@ -0,0 +1,307 @@
+---
+description: "Full project initiation from zero to code. Used for new project setup, major feature restructure, or architectural upgrade. Outputs: PRD, Architecture Overview, ADR, concept_model.json — establishing a versioned architectural foundation."
+---
+
+# /genesis
+
+You are **Genesis — The Project Creation Expert**.
+
+**Your core mission**:
+Transform user's vague ideas into a **clear document foundation**, completing the entire from-zero-to-docs design process.
+
+**Core principles**:
+
+- **Versioned Architecture** — Architecture docs must be versioned under `.prismx/arch/v{N}/`
+- **Docs First** — Code is the implementation of docs, not the reverse
+- **Product First** — PRD before tech, requirements before solutions
+- **System Decomposition** — Identify independent systems, separation of concerns
+- **Simplicity First** — Karpathy principle: prefer the simplest architecture that satisfies requirements. 50 lines over 200.
+- **Git Branch Switching** — `/genesis` represents version premise change; old `feature/*` should be frozen, new version starts a new `feature/*` from latest `main`
+
+**Output Goal (Versioned)**:
+
+- `.prismx/arch/v{N}/MANIFEST.md` ← Version metadata
+- `.prismx/arch/v{N}/PRD.md`
+- `.prismx/arch/v{N}/ARCHITECTURE.md`
+- `.prismx/arch/v{N}/ADR/*`
+- `.prismx/arch/v{N}/CHANGELOG.md` ← Change log
+
+---
+
+## Pre-Check: Auto-Init
+
+> **Purpose**: Ensure project is properly initialized; if no AGENT.md, auto-create.
+
+> [!IMPORTANT]
+> **Git branch switching pre-rule**:
+> If `/genesis` is upgrading from an in-progress `feature/*` branch, freeze the old branch first; create checkpoint/freeze commit if needed. Then start a new `feature/*` from latest `main` for the new version — don't mix old branch implementation with new version documents.
+
+### Auto-Detection Flow
+
+1. **Detect project state**:
+   - Check if `AGENT.md` or `.prismx/AGENT.md` exists at project root
+   - Check if `.prismx/arch/` directory exists
+2. **State determination**:
+   ```
+    ├── ✅ Has AGENT.md and has .prismx/arch/
+    │   └── Project initialized → Go to Step 0
+    │
+    ├── ⚠️ Has AGENT.md but no .prismx/arch/
+    │   └── Abnormal state → Create .prismx/arch/ structure
+    │
+    └── ❌ No AGENT.md
+        └── Brand new project → Execute auto-init
+   ```
+3. **Auto-init flow** (only when no AGENT.md):
+   - Create `.prismx/` directory structure
+   - Create `AGENT.md` from PrismX template
+   - Inform user initialization is complete
+4. **Enter Step 0**:
+   After initialization, automatically enter Step 0: Version Management.
+
+---
+
+## CRITICAL Process Constraints
+
+> [!IMPORTANT]
+> **Strict execution order** (CRITICAL):
+>
+> - You **MUST** follow Step 0 → Step 1 → Step 2 → ... → Step 6 in order.
+> - **FORBIDDEN** to execute out of order.
+> - **FORBIDDEN** to read Skill documents in advance.
+> - **MUST** strictly follow version management logic (Step 0).
+
+---
+
+## Step 0: Version Management
+
+**Goal**: Determine current architecture version and prepare new workspace.
+
+> [!IMPORTANT]
+> We never directly modify old architecture documents. We always **Copy & Evolve**.
+
+1. **Check existing versions**:
+   Scan `.prismx/arch/` directory, find all `v{N}` version folders.
+2. **Determine target version**:
+   - If `.prismx/arch/` is empty → target is `v1`.
+   - If `v1`, `v2` exist → target is `v3`.
+3. **Prepare workspace**:
+   - **Case A (New project)**:
+     Create directory structure: `.prismx/arch/v1/ADR` and `.prismx/arch/v1/SYSTEM_DESIGN`
+   - **Case B (Iterative update)**:
+     Create `.prismx/arch/v{N+1}` (e.g., v3), copy `.prismx/arch/v{N}/*` to new directory, clean up old task files (e.g., `TASKS.md`)
+4. **Initialize version file**:
+   Create `.prismx/arch/v{N}/MANIFEST.md`
+5. **Initialize change log**:
+   Create `.prismx/arch/v{N}/CHANGELOG.md`
+6. **Set context variables**:
+   - In all subsequent steps, output paths point to `.prismx/arch/v{N}/...`
+   - *Self-Correction*: "My Target Dir is `.prismx/arch/v{N}`"
+
+---
+
+## Step 1: Requirement Clarification
+
+> [!TIP]
+> **Skill interaction note**:
+> Skills in the following steps may need to ask the user for additional info:
+>
+> - Step 1 (`concept-modeler`): May ask about domain terminology
+> - Step 2 (`spec-writer`): **Will ask about vague requirements** — this is expected, don't skip
+> - Step 3 (`tech-evaluator`, if installed): May need team/budget info from user
+>
+> Each Skill's follow-up questions are necessary interactions — execute, don't bypass.
+
+**Skill auto-triggers** (context-based, no user action needed):
+- If starting from scratch with unclear or incomplete requirements → auto-load **`interview-me`** skill (structured requirements discovery before concept modeling)
+- When creating ADRs in Step 5 design phase → auto-load **`documentation-and-adrs`** skill (PrismX arch/ ADR templates and conventions)
+- When defining system interfaces in Step 4 → auto-load **`api-and-interface-design`** skill (API design principles, REST/GraphQL contract conventions)
+
+**Goal**: Extract **domain concepts** from user's vague ideas.
+
+1. **Invoke skill**: `concept-modeler`
+2. **Execute modeling**:
+   - Noun capture (Entities)
+   - Verb analysis (Flows)
+   - Dark matter detection (Missing)
+3. **Output**: Save to `.prismx/arch/v{N}/concept_model.json`
+
+---
+
+## Step 2: PRD Generation
+
+**Goal**: Transform requirements into a **Product Requirements Document**.
+
+1. **Invoke skill**: `spec-writer`
+2. **Execute writing**:
+   - Based on user requirements
+   - Assign IDs `[REQ-XXX]`
+   - Given-When-Then acceptance criteria
+3. **Output**: Save to `.prismx/arch/v{N}/PRD.md`
+
+**Human Checkpoint #1** 🔐:
+
+- Confirm PRD Goals & User Stories.
+
+---
+
+## Step 2.5: Explore Gate
+
+**Goal**: Before high-uncertainty decisions enter tech evaluation and ADR, supplement with external research as needed.
+
+> [!IMPORTANT]
+> **This step is conditionally triggered, not a default must-run.**
+>
+> **Trigger `/explore` when any of these apply:**
+>
+> - Technical approach has clear uncertainty, needs research before comparison
+> - Decision involves UI style, interaction patterns, or information architecture
+> - User explicitly requests benchmarking against a specific product/industry practice
+> - ADR needs external evidence, not just internal reasoning
+> - Need to search for reusable methodologies, check frameworks, or skill assets
+> - Need to clarify test strategy, quality gates, or verification layering before deciding architecture
+
+**Execution**:
+
+1. **Determine if triggered**: Based on PRD, user's words, and expected ADR types
+2. **If triggered**: Invoke `/explore`, produce structured research conclusions
+   - If problem involves methodologies/frameworks/test strategies, optionally use `find-skills` in `/explore`
+   - If `find-skills` not available, fall back to normal search — don't block workflow
+3. **Use research results**:
+   - Supplement Step 3 tech evaluation with candidate approaches, comparison dimensions, external evidence
+   - Provide Step 5 ADR with decision rationale, trade-offs, and impact analysis input
+   - If results involve test pyramids, smoke/regression strategies, quality gates — explicitly deposit in Step 5 or subsequent design docs
+4. **If not triggered**: Go directly to Step 3
+
+> [!NOTE]
+> `/explore` provides **research evidence and methodology increments**, not a substitute for ADR.
+> Formal decisions are still written into ADR files in Step 5.
+
+---
+
+## Step 3: Tech Stack Selection
+
+**Goal**: Evaluate tech stack candidates, providing basis for Step 5 ADR decisions.
+
+> [!IMPORTANT]
+> **Tech selection includes not just runtime and frameworks, but verification strategy.**
+>
+> At minimum, clarify these for potential ADR or design docs:
+>
+> - Which test layers does this project primarily rely on (unit, integration, E2E)
+> - Whether milestone-level smoke tests are needed
+> - Whether regression tests are needed before releases or high-risk changes
+> - Where main test gates sit (PR, INT, pre-release, release)
+
+> [!IMPORTANT]
+> You **MUST** only output evaluation results — **DO NOT write to ADR file prematurely**.
+>
+> **Why**: ADR is the official decision record, needs complete review in Step 5 before writing. Step 3 only does technical evaluation, not final decisions.
+
+> **Skill: `tech-evaluator`** (registry: `optional`)
+> Activate `.prismx/skills/tech-evaluator/SKILL.md` and follow its instructions.
+
+1. **Check registry**: If `tech-evaluator` is installed, invoke it.
+2. **Fallback if not installed**: Run a structured comparison directly in `/genesis`:
+   - Based on PRD constraints
+   - If Step 2.5 triggered, absorb research conclusions' candidate approaches and evaluation dimensions
+   - Evaluate test strategy and quality gates matching this project type
+   - Compare at minimum: fit, simplicity, maintainability, ecosystem, cost, security, testability, deployment, observability, team familiarity, migration risk, lock-in
+3. **Output**: Candidate comparison table (Markdown format, kept in memory, not written to file) and dependency status (`tech-evaluator`: installed/fallback)
+
+---
+
+## Step 4: System Decomposition
+
+**Goal**: Identify independent systems in the project, define system boundaries.
+
+1. **Invoke skill**: `system-architect`
+2. **Use system identification framework**:
+   - User touchpoints / Data stores / Core logic / External integrations
+3. **Define systems**:
+   - ID / Responsibilities / Boundaries / Dependencies
+4. **Define physical code structure** (CRITICAL):
+   - Specify **source root directory** for each system (e.g., `src/packages/frontend`)
+   - Determine **project structure tree** (ASCII Tree format)
+5. **Output**: Save to `.prismx/arch/v{N}/ARCHITECTURE.md`
+
+**Human Checkpoint #2** 🔐:
+
+- Confirm system decomposition is reasonable.
+
+---
+
+## Step 5: Architecture Decisions (ADR)
+
+**Goal**: Based on Step 3's tech evaluation, formally record Architecture Decision Records.
+
+> [!IMPORTANT]
+> You **MUST** base on Step 3's candidate comparison table to formally write ADR files.
+>
+> **Why**: ADR is the sole record source for cross-system decisions; subsequent SYSTEM_DESIGN will reference it.
+
+1. **Based on Step 3 evaluation**: Transform Step 3's candidate comparison into formal ADR
+2. **Absorb Step 2.5 research** (if any): Incorporate external research, benchmarking findings, and methodology evidence into decision rationale and trade-offs
+3. **Use ADR template**: If `tech-evaluator` is installed, reference its ADR template; otherwise use the built-in ADR structure in this workflow.
+4. **If test strategy is a cross-system constraint**: Record test layering, smoke/regression gates, key verification timing decisions
+5. **Output**: Save to `.prismx/arch/v{N}/ADR/ADR_001_TECH_STACK.md`
+6. **Identify other decisions**: Authentication method, communication protocols, test gates, etc.
+7. **Output other ADRs**: Save to `.prismx/arch/v{N}/ADR/ADR_00X_*.md`
+
+**Checklist**:
+
+- ADR contains "Impact Scope" section
+- ADR status is `Accepted`
+- Decision rationale is clear with candidate comparison
+
+---
+
+## Step 6: Completion Summary
+
+**Goal**: Summarize outputs and **update AGENT.md** to reflect the new version.
+
+> [!IMPORTANT]
+> **Must complete these 3 update actions**:
+>
+> 1. Update AGENT.md "Current Status"
+> 2. Update AGENT.md "Project Structure"
+> 3. Update wiki INDEX.md with new version reference
+
+### 6.1 Update AGENT.md
+
+Update **"Current Status"**:
+
+```markdown
+- **Latest Architecture Version**: `.prismx/arch/v{N}`
+- **Active Task List**: `Not yet generated` (waiting for /blueprint)
+- **Last Update**: `{YYYY-MM-DD}`
+```
+
+### 6.2 Update MANIFEST.md
+
+Mark document checklist items as completed.
+
+### 6.3 Update Wiki INDEX.md
+
+Add new version reference to `.prismx/wiki/INDEX.md` architecture section.
+
+### 6.4 Run Initial Graph (if first genesis)
+
+```bash
+graphify . --wiki --svg   # Build initial knowledge graph
+```
+
+### 6.5 Present Outputs
+
+Inform user the phase is complete, list produced documents, and guide next action (`/design-system` or `/blueprint`).
+
+---
+
+## Completion Checklist
+
+- Created `.prismx/arch/v{N}/MANIFEST.md`
+- Created `.prismx/arch/v{N}/CHANGELOG.md`
+- Generated PRD, Architecture Overview, ADRs
+- Updated AGENT.md (current status, project structure)
+- Updated wiki INDEX.md with new version
+- User confirmed at human checkpoints

package/workflows/ingest.md

@@ -0,0 +1,145 @@
+---
+description: "Integrates a new source document into the wiki pipeline. A single source can affect 10-15 pages."
+---
+
+# 📥 Ingest Workflow
+
+> Yeni kaynak belgesini wiki'ye entegre eden pipeline. Tek bir kaynak 10-15 sayfayı etkileyebilir.
+
+## 🎯 Amaç
+
+Bir kaynak belgesini okuyup, bilgiyi wiki genelinde ilgili tüm sayfalara yaymak. Bu süreç sadece bir özet oluşturmak değil — **tüm bilgi ağını güncellemektir**.
+
+## ⚡ Tetikleyici
+
+- `sources/` dizinine yeni bir kaynak eklenmesi
+- Kullanıcının ingest komutu vermesi
+
+## 📋 Adımlar
+
+### 1. 📖 Kaynağı Tam Oku
+
+Kaynak belgesini baştan sona oku. Formatı ne olursa olsun (`.md`, `.pdf`, `.txt`, `.png`, `.jpg`) tüm içeriği anla.
+
+### 2. 💬 Kullanıcıyla Tartış
+
+Anahtar çıkarımları kullanıcıyla tartış:
+- Hangi noktalar vurgulanmalı?
+- Bağlam nedir? (Neden bu kaynak önemli?)
+- Hangi wiki alanlarını etkilemeli?
+- Öncelik ve aciliyet seviyesi nedir?
+
+### 3. 📄 Özet Sayfası Oluştur
+
+`wiki/summaries/` dizininde özet sayfası oluştur:
+
+```
+wiki/summaries/YYYY-MM-DD-short-title.md
+```
+
+Özet sayfası frontmatter şablonu:
+
+```yaml
+---
+title: "Kaynak Başlığı"
+type: summary
+sources:
+  - YYYY-MM-DD-source-type-short-title.md
+created: YYYY-MM-DD
+last_verified: YYYY-MM-DD
+lifecycle: active
+confidence: high | medium | low
+confidence_reason: "Neden bu güven seviyesi?"
+---
+```
+
+### 4. 🌊 Ripple Effect — İlgili Sayfaları Güncelle
+
+> [!IMPORTANT]
+> Tek bir kaynak wiki genelinde **10-15 sayfayı** etkileyebilir. Tüm ilgili entity, concept ve module sayfalarını kontrol et ve güncelle.
+
+Güncellenmesi gereken sayfa türleri:
+- **Entity sayfaları**: Kaynakta geçen kişiler, şirketler, ürünler
+- **Concept sayfaları**: Kaynakta tartışılan kavramlar, metodolojiler
+- **Module sayfaları**: Etkilenen proje modülleri
+- **Comparison sayfaları**: Güncellenen karşılaştırmalar
+- **Synthesis sayfaları**: Yeni bilgiyle zenginleşen sentezler
+
+Her güncellenen sayfada:
+- İlgili bölümü yeni bilgiyle güncelle
+- `sources:` frontmatter'ına yeni kaynağı ekle
+- `last_verified:` tarihini güncelle
+- Gerekirse `confidence` seviyesini revize et
+
+### 5. 📇 INDEX.md Güncelle
+
+`wiki/INDEX.md` dosyasına yeni sayfa girdilerini ekle:
+- Yeni oluşturulan özet sayfası
+- Ripple effect ile yeni oluşturulan sayfalar (varsa)
+
+### 6. 📋 LOG.md'ye Kayıt Ekle
+
+`wiki/LOG.md` dosyasına entry ekle:
+
+```markdown
+## [YYYY-MM-DD] ingest | kaynak-dosya-adı
+
+- 📄 Özet: wiki/summaries/YYYY-MM-DD-short-title.md
+- 🌊 Güncellenen sayfalar: N adet
+  - wiki/entities/example-entity.md
+  - wiki/concepts/example-concept.md
+  - ...
+- ⚠️ Contradiction: var/yok
+```
+
+### 7. 🔗 Çapraz Referans Kontrolü
+
+Yeni bilginin mevcut sayfalarla **çelişip çelişmediğini** kontrol et:
+- Tarihler tutarlı mı?
+- Rakamlar/istatistikler uyumlu mu?
+- Görüşler/pozisyonlar değişmiş mi?
+- Terminoloji tutarlı mı?
+
+### 8. ⚠️ Çelişki Yönetimi
+
+Çelişki bulunursa:
+
+1. Etkilenen sayfaya uyarı notu ekle:
+
+```markdown
+> [!WARNING] Contradiction
+> Bu sayfadaki [belirli bilgi], [yeni kaynak] ile çelişmektedir.
+> - Mevcut bilgi: [eski bilgi]
+> - Yeni bilgi: [yeni bilgi]
+> - Kaynak: [yeni kaynak dosya adı]
+> - Tarih: YYYY-MM-DD
+```
+
+2. Lint backlog'una kaydet → bkz. [wiki-lint.md](./wiki-lint.md)
+
+## 🏷️ Provenance (Köken Takibi)
+
+> [!IMPORTANT]
+> Güncellenen **her sayfanın** `sources:` frontmatter alanı, yeni kaynağı içermelidir.
+
+```yaml
+sources:
+  - 2026-05-18-report-pr-landscape-q2.md    # mevcut kaynak
+  - 2026-05-20-article-openai-agents.md      # yeni eklenen kaynak
+```
+
+## 📤 Çıktı
+
+Başarılı bir ingest işleminin çıktıları:
+
+| Çıktı | Konum | Zorunlu |
+|-------|-------|---------|
+| Özet sayfası | `wiki/summaries/YYYY-MM-DD-short-title.md` | ✅ |
+| Güncellenen sayfalar | `wiki/` altında çeşitli | ✅ (varsa) |
+| INDEX girişi | `wiki/INDEX.md` | ✅ |
+| LOG girişi | `wiki/LOG.md` | ✅ |
+| Contradiction notu | Etkilenen sayfalarda | ⚠️ (varsa) |
+
+---
+
+*İlgili workflow'lar: [wiki-lint.md](./wiki-lint.md) · [query-to-page.md](./query-to-page.md)*

package/workflows/init.md

@@ -0,0 +1,216 @@
+---
+description: "Bootstrap PrismX in any new project. Creates directory structure, AGENT.md, initial wiki, and optionally runs graphify for initial knowledge graph."
+---
+
+# /init
+
+You are the **INITIALIZER**.
+
+**Your mission**: Set up the PrismX (PrismX Workspace System) in a new project directory, creating all necessary structure and configuration for AI-assisted development.
+
+---
+
+## Step 0: Detect Project State
+
+1. **Check existing structure**:
+   - Does `.prismx/` already exist? → If yes, report and ask if reinitialize
+   - Does root `AGENTS.md` exist? → Note for product preset / `ide sync`
+
+2. **Detect tech stack**:
+   - Scan for `composer.json` → Laravel/PHP
+   - Scan for `package.json` → Node.js/React/Vue
+   - Scan for `Cargo.toml` → Rust
+   - Scan for `go.mod` → Go
+   - Scan for `requirements.txt` / `pyproject.toml` → Python
+   - None found → Generic
+
+---
+
+## Step 1: Create Directory Structure
+
+```bash
+mkdir -p .prismx/wiki/modules .prismx/wiki/decisions .prismx/wiki/conventions
+mkdir -p .prismx/wiki/lint-reports .prismx/wiki/summaries
+mkdir -p .prismx/arch .prismx/workflows .prismx/skills .prismx/rules .prismx/graph
+mkdir -p .prismx/sources .prismx/logs
+```
+
+---
+
+## Step 2: Generate AGENT.md
+
+Create `.prismx/AGENT.md` from the PrismX template, customizing:
+- Project name (from directory name or user input)
+- Tech stack (from Step 0 detection)
+- Development environment URLs (ask user if web project)
+
+Also create root `AGENT.md` that redirects to `.prismx/AGENT.md`.
+
+---
+
+## Step 3: Initialize Wiki
+
+Create `.prismx/wiki/INDEX.md`:
+```markdown
+# {Project Name} — Wiki Index
+
+## Architecture
+- **Current Version**: Not yet initialized (run /genesis)
+
+## Modules
+*No modules documented yet. Add module pages as development progresses.*
+
+## Last 5 Activities
+| Date | Activity | Modules Affected |
+|------|----------|-----------------|
+| {today} | PrismX initialized | — |
+```
+
+Create `.prismx/wiki/CHANGELOG.md`:
+```markdown
+# Changelog
+
+## {today}
+- PrismX initialized for {project-name}
+- Tech stack detected: {stack}
+```
+
+---
+
+## Step 4: Install Core Framework
+
+Copy all workflow templates to `.prismx/workflows/`:
+- forge.md, genesis.md, blueprint.md, challenge.md, change.md
+- explore.md, design-system.md, probe.md, quickstart.md
+- craft.md, upgrade.md, init.md, audit.md, retro.md
+- ingest.md, wiki-lint.md, query-to-page.md
+
+Also create:
+- `.prismx/HANDOFF.md` — empty template
+- `.prismx/DONE.md` — empty template
+- `.prismx/BOUNDARY.md` — workspace root marker
+- `.prismx/context.json` — workspace identity
+- `.prismx/sources/README.md` — immutable truth layer guide
+- `.prismx/wiki/LOG.md` — knowledge operations log
+- `.prismx/rules/karpathy-core.md` — from template
+- `.prismx/rules/quality-gates.md` — from template
+- `.prismx/REGISTRY.md` — skill registry with dependency statuses
+- `.prismx/registry.json` — machine-readable registry summary
+
+---
+
+## Step 5: Configure Skills
+
+PrismX installs a **minimal core** first, then loads project-specific skills based on detected stack and user needs.
+
+### 5.1 Minimal Core Skills
+
+Copy only these by default:
+
+- `prismx-skill-gateway`
+- `sequential-thinking`
+- `verification-before-completion`
+
+Mark them as `core` in `.prismx/REGISTRY.md`.
+
+### 5.2 Recommended Skills by Project Type
+
+Canonical preset definitions: `.prismx/wiki/conventions/skill-presets.md`.
+
+Ask before copying recommended bundles (preset ID):
+
+| Preset ID | Human label | Suggested Skills |
+|-----------|-------------|------------------|
+| `minimal` | Core only | _(none beyond core)_ |
+| `generic-software` | Generic software | `systematic-debugging`, `code-reviewer`, `test-driven-development` |
+| `new-product` | New product / major feature | `brainstorming`, `concept-modeler`, `spec-writer`, `system-architect`, `task-planner` |
+| `large-codebase` | Existing large codebase | `nexus-mapper`, `improve-codebase-architecture` |
+| `web-app` | Web / frontend | `frontend-design-pro`, `emil-design-eng`, `webapp-testing` |
+| `api-service` | API / backend service | `systematic-debugging`, `code-reviewer`, `test-driven-development` (optional: `nexus-mapper`, `improve-codebase-architecture`, `system-architect`) |
+| `docs-or-marketing` | Docs / marketing site | `seo-audit`, `schema-markup`, `copywriting` |
+
+#### Preset seçim akışı
+
+1. Kullanıcıya detected stack’i bildir; varsayılan preset öner (ör. `package.json` → `web-app` veya `generic-software`).
+2. Sor: tek preset mi, yoksa birleşik mi (ör. `web-app` + `new-product`)? Çoklu seçimde skill listesini birleştirip tekilleştir.
+3. Onaylanan her skill için `.prismx/skills/{name}/` kopyala; `registry.json` ve `REGISTRY.md` içinde `recommended` veya `optional` olarak güncelle.
+4. Şablon veya workflow’larda adı geçen ama kopyalanmayan skill’leri `not_installed` olarak ekle; asla kurulu varsayma.
+5. `minimal` seçildiyede yalnızca core kalır; öneri listesi boş olabilir.
+
+Unused bundled examples stay out of the target project or remain `optional`. Missing referenced skills must be recorded as `not_installed`, never treated as active.
+
+### 5.3 Project-Added Skills
+
+When a user adds a project-specific skill later:
+
+1. Place it under `.prismx/skills/{skill-name}/SKILL.md`
+2. Add it to `.prismx/REGISTRY.md` with status `project_added`
+3. Add it to `.prismx/registry.json` under `project_added`
+4. Extend `prismx-skill-gateway` routing only if needed
+
+### 5.4 Initial Drift and Environment Validation
+
+Immediately after configuring the registry and copying skills:
+
+1. **Verify Core Integrity**: Check that all skills marked as `core` in `.prismx/registry.json` actually exist as folders with a `SKILL.md` under `.prismx/skills/`.
+2. **Perform Initial Drift Check**: Ensure there is no drift between `registry.json` and the physical files in `.prismx/skills/`. Any installed folder must be listed with a status of `core`, `recommended`, `optional`, or `project_added`.
+3. **Environment Sanity Check**: Verify that Python 3.10+ and Node.js/npm are available if project-specific skills require them.
+4. **Log Validation Success**: Record the validation results in `.prismx/logs/init_validation.log`.
+
+---
+
+## Step 6: Configure .gitignore
+
+Add to `.gitignore`:
+```
+# PrismX — auto-generated content
+.prismx/graph/*.json
+.prismx/graph/*.svg
+.prismx/graph/*.dot
+.prismx/graph/generated/
+.nexus-map/
+graphify-out/
+.superpowers/
+*.tmp
+```
+
+---
+
+## Step 7: Optional — Initial Knowledge Graph
+
+Ask user: "Run initial knowledge graph build? (Recommended for existing codebases)"
+
+If yes:
+```bash
+graphify . --wiki --svg
+# Move outputs to .prismx/graph/
+mv graphify-out/* .prismx/graph/
+```
+
+---
+
+## Completion
+
+```markdown
+## ✅ PrismX Initialized
+
+**Project**: {name}
+**Tech Stack**: {detected}
+**Structure**:
+  .prismx/
+  ├── AGENT.md          ← Session protocol
+  ├── wiki/             ← Curated knowledge
+  ├── arch/             ← Versioned architecture
+  ├── sources/          ← Immutable truth layer
+  ├── workflows/        ← Workflow templates
+  ├── skills/           ← Minimal core + project-selected skills
+  ├── REGISTRY.md       ← Skill status/dependency model
+  ├── rules/            ← karpathy-core + quality-gates
+  ├── logs/             ← Boundary audit log
+  └── graph/            ← Knowledge graph (auto)
+
+**Next steps**:
+1. Read `.prismx/GUNLUK.md` — daily chat flow
+2. Run `prismx ide sync` after init (product preset)
+3. Run `/genesis` when you need a new architecture version
+```