prizmkit 1.0.0 → 1.0.1

package/bundled/skills/prizmkit-retrospective/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: "prizmkit-retrospective"
+description: "Post-feature retrospective. Extracts lessons from completed features, updates Prizm docs TRAPS and RULES. Invoke after feature completion. (project)"
+---
+
+# PrizmKit Retrospective
+
+Post-feature retrospective analysis that extracts lessons learned, updates Prizm documentation with discovered traps and rules, and documents improvements for future reference.
+
+### When to Use
+- After completing a feature (spec, plan, tasks, implementation all done)
+- User says "retrospective", "retro", "lessons learned", "what did we learn"
+- Before starting a new major feature (to apply lessons from the last one)
+
+### prizmkit.retrospective
+
+PRECONDITION: Completed feature with spec.md, plan.md, tasks.md in .prizmkit/specs/
+
+### Steps
+
+#### Step 1: Gather Feature Artifacts
+Read all feature artifacts from .prizmkit/specs/###-feature-name/:
+- spec.md (original requirements and acceptance criteria)
+- plan.md (architecture decisions and implementation plan)
+- tasks.md (task breakdown and status)
+- data-model.md (if exists)
+- contracts/ directory (if exists)
+
+#### Step 2: Analyze Implementation
+Compare planned vs actual:
+- Tasks completed vs skipped — why were tasks skipped?
+- Architecture deviations from plan — what changed and why?
+- Unexpected challenges encountered — what surprised us?
+- Time-intensive areas — what took longer than expected?
+
+#### Step 3: Extract Lessons
+Categorize findings:
+- **What went well** (reinforce these patterns)
+- **What went wrong** (create anti-patterns to avoid)
+- **What was surprising** (new patterns to document)
+- **What would you do differently** (improvement candidates)
+
+NOTE: If bug fixes were performed during this feature's implementation, they are refinements of the feature itself (completing its intended behavior), NOT separate features. Do not create separate documentation entries or REGISTRY records for bug fixes.
+
+#### Step 4: Generate Retrospective Document
+Write retrospective.md in .prizmkit/specs/###-feature-name/:
+```markdown
+# Retrospective: <feature-name>
+Date: YYYY-MM-DD
+
+## Summary Statistics
+- Tasks total: N
+- Tasks completed: N
+- Tasks skipped: N (with reasons)
+
+## Key Decisions
+- Decision: <what> | Outcome: <good/bad/neutral> | Lesson: <takeaway>
+
+## Patterns Discovered
+- Pattern: <name> | Context: <when to apply> | Benefit: <why>
+
+## Anti-Patterns Discovered
+- Anti-pattern: <name> | Context: <when it occurred> | Fix: <what to do instead>
+
+## Improvement Suggestions
+- Skill: <skill-name> | Suggestion: <what to improve>
+```
+
+#### Step 5: Update Prizm Docs
+For each lesson learned, update the relevant `.prizm-docs/` files:
+- Add discovered pitfalls to the affected module's TRAPS section
+- Add new conventions or rules to the affected module's RULES section
+- Append decisions to DECISIONS section with rationale
+- Update changelog.prizm with retrospective findings
+
+#### Step 6: Handoff
+Suggest next action:
+- `prizmkit.specify` — start next feature
+- No action needed — just documenting for future reference

package/bundled/skills/prizmkit-security-audit/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: "prizmkit-security-audit"
+tier: 2
+description: "[Tier 2] AI-assisted security review checklist via static code analysis. Identifies common vulnerability patterns and hardcoded secrets. Not an automated scanner. (project)"
+---
+
+# PrizmKit Security Audit
+
+Comprehensive security scanner that identifies vulnerabilities, hardcoded secrets, and insecure patterns across the codebase. Generates a severity-rated report with actionable fix suggestions.
+
+### When to Use
+- User says "security audit", "security review", "check for vulnerabilities"
+- Before deployment or release
+- After adding authentication, authorization, or data handling code
+- During code review of security-sensitive changes
+
+### prizmkit.security-audit
+
+### Steps
+
+#### Step 1: Load Project Context
+Read .prizm-docs/root.prizm for:
+- Project tech stack and languages
+- Architecture overview
+- Module structure
+
+#### Step 2: Scan for Vulnerabilities
+Scan code files across these categories:
+
+**Injection**
+- SQL injection: raw query concatenation, unsanitized user input in queries
+- XSS: unescaped output in templates, innerHTML usage, dangerouslySetInnerHTML
+- Command injection: shell exec with user input, unsanitized system calls
+- LDAP injection: unescaped LDAP filter construction
+
+**Authentication**
+- Weak password handling: plaintext storage, weak hashing (MD5, SHA1)
+- Missing auth checks: unprotected routes/endpoints
+- Session management: predictable session IDs, missing expiration
+
+**Authorization**
+- Broken access control: missing role checks, horizontal privilege escalation
+- IDOR: direct object references without ownership validation
+- Privilege escalation: admin functions without proper guards
+
+**Data Exposure**
+- Hardcoded credentials: API keys, tokens, passwords in source code
+- Sensitive data in logs: PII, credentials, tokens logged in plaintext
+- Unencrypted sensitive data: passwords, SSN, credit cards stored in plain text
+
+**Configuration**
+- Debug mode enabled in production configs
+- Default credentials in configuration files
+- Insecure defaults: CORS *, permissive CSP, disabled CSRF
+
+**Dependencies**
+- Cross-reference package manifests (package.json, requirements.txt, etc.)
+- Flag known vulnerable version ranges where identifiable
+
+**Cryptography**
+- Weak algorithms: DES, RC4, MD5 for security purposes
+- Hardcoded encryption keys or IVs
+- Improper random generation: Math.random() for security tokens
+
+**Input Validation**
+- Missing validation on user inputs
+- Improper sanitization or escaping
+- Regex DoS (ReDoS) patterns
+
+#### Step 3: Check Sensitive File Handling
+- Verify .gitignore covers: .env, credentials.json, *.pem, *.key, *.p12
+- Check for sensitive files already tracked in git
+- Flag any secrets that may have been committed historically
+
+#### Step 4: Classify Findings
+Rate each finding by severity:
+- **CRITICAL**: Actively exploitable, data breach risk, hardcoded production secrets
+- **HIGH**: Significant vulnerability requiring immediate attention
+- **MEDIUM**: Security weakness that should be addressed
+- **LOW**: Minor issue or best practice improvement
+
+Maximum 50 findings per report.
+
+#### Step 5: Generate Report
+Output structured security report to conversation (READ-ONLY, no file modifications):
+
+```markdown
+# Security Audit Report
+Date: YYYY-MM-DD
+Project: <project-name>
+
+## Summary
+- Critical: N | High: N | Medium: N | Low: N
+- Files scanned: N
+- Categories checked: N
+
+## Critical Findings
+### [C-001] <Title>
+- **File**: path/to/file.ext:line
+- **Category**: Injection / Auth / etc.
+- **Description**: What the issue is
+- **Impact**: What could happen if exploited
+- **Fix**: How to remediate
+
+## High Findings
+...
+
+## Medium Findings
+...
+
+## Low Findings
+...
+
+## Recommendations
+1. Immediate actions (Critical + High)
+2. Short-term improvements (Medium)
+3. Long-term hardening (Low + best practices)
+```
+
+#### Step 6: Suggest Fixes
+For CRITICAL and HIGH findings:
+- Provide specific code fix suggestions
+- Reference security best practices
+- Link to relevant documentation where applicable
+
+#### Step 7: Record Findings (Optional)
+If `.prizm-docs/` exists:
+- Update affected module RULES with security conventions discovered
+- Update affected module TRAPS with security pitfalls found
+- Track security posture improvements over time via changelog.prizm

package/bundled/skills/prizmkit-specify/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: "prizmkit-specify"
+description: "Create structured feature specifications from natural language. Invoke when starting a new feature, user says 'specify', 'define feature', or 'write requirements'. (project)"
+---
+
+# PrizmKit Specify
+
+Create structured feature specifications from natural language descriptions. This skill transforms a feature idea into a well-structured spec with user stories, acceptance criteria, and scope boundaries.
+
+## Commands
+
+### prizmkit.specify
+
+Create a new feature specification.
+
+**STEPS:**
+
+1. Ask user for feature description (natural language)
+2. Auto-generate 2-4 word feature slug from description
+3. Determine next feature number by scanning `.prizmkit/specs/`
+4. Create directory: `.prizmkit/specs/###-feature-name/`
+5. Read Prizm docs (`.prizm-docs/root.prizm`) for project context
+6. Generate `spec.md` from template (`${SKILL_DIR}/assets/spec-template.md`) focusing on:
+   - Feature title and description
+   - User stories (As a... I want... So that...)
+   - Acceptance criteria (Given/When/Then)
+   - Scope boundaries (In scope / Out of scope)
+   - Dependencies and constraints
+   - `[NEEDS CLARIFICATION]` markers for ambiguous items (max 3)
+7. Run internal quality validation loop (max 3 iterations):
+   - Check: All user stories have acceptance criteria?
+   - Check: Scope boundaries clearly defined?
+   - Check: No more than 3 `[NEEDS CLARIFICATION]` markers?
+8. Output: `spec.md` path and summary
+
+**KEY RULES:**
+- Focus on WHAT and WHY, never HOW (no tech stack details)
+- Max 3 `[NEEDS CLARIFICATION]` markers
+- Every user story MUST have at least one acceptance criterion in Given/When/Then format
+- Scope boundaries MUST be explicitly defined
+- Feature numbers are zero-padded to 3 digits (e.g., `001`, `012`)
+
+**HANDOFF:** `prizmkit.plan` or `prizmkit.clarify`
+
+## Template
+
+The spec template is located at `${SKILL_DIR}/assets/spec-template.md`.
+
+## Output
+
+All outputs are written to `.prizmkit/specs/###-feature-name/`:
+- `spec.md` — The feature specification

package/bundled/skills/prizmkit-specify/assets/spec-template.md

@@ -0,0 +1,37 @@
+# Feature: [FEATURE_TITLE]
+
+## Overview
+[One paragraph describing the feature purpose and business value]
+
+## User Stories
+
+### US1: [Story Title]
+**As a** [role]
+**I want** [capability]
+**So that** [benefit]
+
+**Acceptance Criteria:**
+- [ ] Given [context], When [action], Then [expected result]
+
+## Scope
+
+### In Scope
+- [Item 1]
+
+### Out of Scope
+- [Item 1]
+
+## Dependencies
+- [Dependency 1]: [Why needed]
+
+## Constraints
+- [Constraint 1]
+
+## Clarifications
+[NEEDS CLARIFICATION]: [Ambiguous item]
+
+## Review Checklist
+- [ ] All user stories have acceptance criteria
+- [ ] Scope boundaries are clearly defined
+- [ ] Dependencies are identified
+- [ ] No implementation details (WHAT not HOW)

package/bundled/skills/prizmkit-summarize/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: "prizmkit-summarize"
+description: "Archive completed features to REGISTRY.md. Extracts metadata from specs, scans code, updates feature index. Invoke after code review passes or feature is done. (project)"
+---
+
+# PrizmKit Summarize
+
+Archive completed features to the feature registry. Extracts metadata from specs and code, generates a registry entry, and appends a changelog record. Idempotent — re-running produces the same output.
+
+## Commands
+
+### prizmkit.summarize
+
+Archive a completed feature to the registry.
+
+**PRECONDITION:** `spec.md`, `plan.md`, `tasks.md` exist in `.prizmkit/specs/###-feature-name/`
+
+**STEPS:**
+
+1. Read `spec.md`, `plan.md`, `tasks.md`
+2. Analyze `tasks.md` completion rate — warn if < 100%
+3. Scan actual code directories for core file paths
+4. Generate REGISTRY entry:
+   - Feature number and name
+   - Branch name
+   - Status (complete/partial)
+   - Key files and directories
+   - API endpoints added/modified
+   - Data model changes
+   - Completion date
+5. Append to `.prizmkit/specs/REGISTRY.md` (create from template `${SKILL_DIR}/assets/registry-template.md` if not exists)
+6. Append changelog entry
+7. Output: registry entry summary
+
+**KEY RULES:**
+- Idempotent: same input MUST produce same output on re-run
+- If `tasks.md` completion < 100%, status is "Partial" with warning
+- REGISTRY.md is append-only — never modify existing entries
+- Changelog entries use format: `YYYY-MM-DD | [###] [Feature Name] | [Status]`
+- If REGISTRY.md does not exist, create it from template before appending
+- **Bug fixes MUST NOT create new REGISTRY.md entries.** Bugs are refinements of incomplete existing features, not new functionality. Bug fix commits should only update the original feature's changelog, not generate a new registry entry. Do NOT invoke this skill for bug fix commits.
+
+**HANDOFF:** `prizmkit.specify` (start next feature) or `prizmkit.retrospective` (extract lessons)
+
+## Template
+
+The registry template is located at `${SKILL_DIR}/assets/registry-template.md`.
+
+## Output
+
+- `.prizmkit/specs/REGISTRY.md` — Updated with new feature entry and changelog record

package/bundled/skills/prizmkit-summarize/assets/registry-template.md

@@ -0,0 +1,18 @@
+# PrizmKit Feature Registry
+
+> Auto-generated by prizmkit-summarize. Do not edit manually.
+
+## Features
+
+### [###] [Feature Name]
+- **Branch**: ###-feature-name
+- **Status**: Complete | Partial
+- **Date**: YYYY-MM-DD
+- **Key Files**: [list]
+- **API Changes**: [summary]
+- **Data Changes**: [summary]
+
+---
+
+## Changelog
+- YYYY-MM-DD | [###] [Feature Name] | [Status]

package/bundled/skills/prizmkit-tasks/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: "prizmkit-tasks"
+description: "Generate executable task breakdown from implementation plan. Creates tasks.md with dependency ordering, parallel markers, and file paths. Invoke after 'plan'. (project)"
+---
+
+# PrizmKit Tasks
+
+Generate an executable task breakdown from an implementation plan. Produces tasks.md organized by phases with dependency ordering, parallel execution markers, and target file paths.
+
+## Commands
+
+### prizmkit.tasks
+
+Create a detailed task breakdown for implementation.
+
+**PRECONDITION:** `spec.md` and `plan.md` exist in `.prizmkit/specs/###-feature-name/`
+
+**STEPS:**
+
+1. Read `spec.md`, `plan.md`, `data-model.md` (if exists), `contracts/` (if exists)
+2. Generate `tasks.md` from template (`${SKILL_DIR}/assets/tasks-template.md`) organized by:
+   - Phase: Setup → Foundational → User Stories (US1→US2→...) → Polish
+   - Each task: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
+   - `[P]` marker for tasks that can run in parallel
+   - Each user story section is independently implementable and testable
+3. Implementation strategy selection (ask user):
+   - **MVP-first**: core features → iterate
+   - **Incremental**: story-by-story delivery
+   - **Parallel**: independent stories in parallel
+4. Include checkpoint tasks between phases for validation
+5. Output: `tasks.md` path and task count summary
+
+**KEY RULES:**
+- Task IDs use zero-padded numbering: `[T-001]`, `[T-010]`, `[T-100]`
+- Setup tasks start at T-001, Foundational at T-010, User Stories at T-100+, Polish at T-900
+- Every task MUST reference a target file path
+- `[P]` marker indicates tasks that can execute in parallel within their phase
+- Checkpoint tasks MUST appear between phases
+- Each user story section MUST be independently testable
+
+**HANDOFF:** `prizmkit.implement`
+
+## Template
+
+The tasks template is located at `${SKILL_DIR}/assets/tasks-template.md`.
+
+## Output
+
+All outputs are written to `.prizmkit/specs/###-feature-name/`:
+- `tasks.md` — The task breakdown

package/bundled/skills/prizmkit-tasks/assets/tasks-template.md

@@ -0,0 +1,21 @@
+# Tasks: [FEATURE_TITLE]
+
+## Strategy: [MVP-first | Incremental | Parallel]
+
+## Phase: Setup
+- [ ] [T-001] Project scaffolding — file: [path]
+
+## Phase: Foundational
+- [ ] [T-010] [Data model / Schema changes] — file: [path]
+
+## Phase: User Story 1 — [Title]
+- [ ] [T-100] [P] [US1] [Task description] — file: [path]
+
+## Phase: Polish
+- [ ] [T-900] Final integration test
+- [ ] [T-901] Documentation update
+
+## Checkpoints
+- [ ] [CP-1] After Setup: project builds and tests pass
+- [ ] [CP-2] After Foundational: data model verified
+- [ ] [CP-3] After each US: acceptance criteria pass

package/bundled/skills/prizmkit-tech-debt-tracker/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: "prizmkit-tech-debt-tracker"
+tier: 1
+description: "[Tier 1] Identify and track technical debt via code pattern analysis. Scans TODOs, complexity hotspots, code smells. AI strength. (project)"
+---
+
+# PrizmKit Tech Debt Tracker
+
+Systematic technical debt identification and tracking. Scans the codebase for code smells, TODO markers, complexity hotspots, missing tests, and other debt indicators. Generates a prioritized report with actionable recommendations.
+
+### When to Use
+- User says "tech debt", "code quality", "what needs cleanup"
+- During sprint planning to identify maintenance work
+- Before major refactoring efforts
+- Periodically as part of codebase health monitoring
+
+### prizmkit.tech-debt
+
+### Steps
+
+#### Step 1: Load Project Context
+Read .prizm-docs/ for:
+- Project structure and module boundaries
+- Tech stack and language conventions
+- Existing architecture documentation
+
+#### Step 2: Scan for Debt Indicators
+
+**TODO/FIXME/HACK/XXX Markers**
+- Search all source files for marker comments
+- Categorize by file and module
+- Extract context (the comment text and surrounding code)
+
+**Complexity Hotspots**
+- Files exceeding 500 lines of code
+- Deeply nested logic (4+ levels of nesting)
+- Functions/methods exceeding 100 lines
+- High cyclomatic complexity (many branches/conditions)
+
+**Code Duplication**
+- Similar code blocks appearing across multiple files
+- Copy-pasted logic with minor variations
+- Repeated patterns that could be abstracted
+
+**Missing Tests**
+- Source files without corresponding test files
+- Public APIs without test coverage
+- Critical paths without integration tests
+
+**Outdated Patterns**
+- Deprecated API usage
+- Old language syntax (var instead of let/const, callbacks instead of async/await)
+- Legacy framework patterns
+
+**Dead Code**
+- Unused imports and variables
+- Unreachable code blocks
+- Commented-out code blocks (>5 lines)
+- Exported functions with no consumers
+
+**Poor Naming**
+- Single-letter variables outside of loops/lambdas
+- Misleading names (obvious cases only)
+- Inconsistent naming conventions within a module
+
+**Missing Documentation**
+- Public APIs without doc comments
+- Complex functions without explanatory comments
+- Missing README in significant directories
+
+#### Step 3: Calculate Debt Score
+Per module:
+- CRITICAL issues: weight x4 (security-adjacent, data-loss risk)
+- HIGH issues: weight x3 (maintainability blockers)
+- MEDIUM issues: weight x2 (code quality)
+- LOW issues: weight x1 (best practices)
+
+Normalize by module size (lines of code) to get debt density.
+
+#### Step 4: Generate Prioritized Report
+Write to .prizmkit/tech-debt.md (overwrite each run):
+
+```markdown
+# Technical Debt Report
+Generated: YYYY-MM-DD
+
+## Summary
+- Total debt items: N
+- Critical: N | High: N | Medium: N | Low: N
+- Modules scanned: N
+
+## Top 10 Hotspots (by debt score)
+| Rank | Module/File | Score | Top Issues |
+|------|-------------|-------|------------|
+| 1    | path/file   | 42    | complexity, missing tests |
+
+## Debt by Category
+| Category | Count | Severity Breakdown |
+|----------|-------|--------------------|
+| TODO markers | N | H:N M:N L:N |
+| Complexity | N | C:N H:N M:N |
+| Missing tests | N | H:N M:N |
+| Dead code | N | M:N L:N |
+| Duplication | N | M:N L:N |
+| Documentation | N | L:N |
+
+## Trend
+(If previous report exists in .prizmkit/):
+- Previous total: N → Current: N (improving/degrading)
+- Categories improving: ...
+- Categories degrading: ...
+
+## Detailed Findings
+
+### Critical
+- [File:Line] Description | Impact | Suggested Fix
+
+### High
+- [File:Line] Description | Impact | Suggested Fix
+
+### Medium
+...
+
+### Low
+...
+```
+
+#### Step 5: Output Summary
+Display to conversation:
+- Overall debt score and trend
+- Top 3 highest-impact items to address first
+- Estimated effort categories (quick fix / medium effort / large refactor)
+
+#### Step 6: Suggest Action Items
+Recommend top 3 highest-impact debt items to address first, considering:
+- Severity (critical > high > medium > low)
+- Blast radius (how many modules affected)
+- Effort to fix (prefer quick wins)
+- Risk if left unaddressed

package/bundled/team/prizm-dev-team.json

@@ -0,0 +1,47 @@
+{
+  "name": "prizm-dev-team",
+  "team_name": "prizm-dev-team",
+  "description": "PrizmKit-integrated Multi-Agent software development team. 4 specialized agents (Coordinator, PM, Dev, Reviewer) following PrizmKit spec-driven workflow with 7-phase pipeline and 4 checkpoints.",
+  "lead": "team-lead",
+  "communication": {
+    "protocol": "SendMessage",
+    "routing": "mesh",
+    "note": "Teammates 间通过 SendMessage 直接通信，关键消息同时通知 Coordinator"
+  },
+  "members": [
+    {
+      "name": "team-lead",
+      "role": "lead",
+      "agentDefinition": "prizm-dev-team-coordinator",
+      "subscriptions": []
+    },
+    {
+      "name": "coordinator",
+      "role": "coordinator",
+      "agentDefinition": "prizm-dev-team-coordinator",
+      "prompt": "You are the Coordinator Agent of the prizm-dev-team. Orchestrate the 7-phase pipeline (init → specify+plan+tasks → analyze → implement → review → summarize → commit). Manage checkpoints CP-0 through CP-3, coordinate PM/Dev/Reviewer agents. Follow PrizmKit workflow.",
+      "subscriptions": ["*"]
+    },
+    {
+      "name": "pm",
+      "role": "pm",
+      "agentDefinition": "prizm-dev-team-pm",
+      "prompt": "You are the PM Agent of the prizm-dev-team. In a single session, use prizmkit.specify/clarify/plan/tasks to create spec.md, plan.md, and tasks.md. All artifacts go under .prizmkit/specs/###-feature-name/.",
+      "subscriptions": ["*"]
+    },
+    {
+      "name": "dev",
+      "role": "developer",
+      "agentDefinition": "prizm-dev-team-dev",
+      "prompt": "You are a Dev Agent of the prizm-dev-team. Follow prizmkit.implement workflow with TDD. Read tasks.md/plan.md/spec.md, implement task-by-task, mark completed tasks [x]. Check .prizm-docs/ TRAPS before implementing.",
+      "subscriptions": ["*"]
+    },
+    {
+      "name": "reviewer",
+      "role": "reviewer",
+      "agentDefinition": "prizm-dev-team-reviewer",
+      "prompt": "You are the Reviewer Agent of the prizm-dev-team. In Phase 4: run prizmkit.analyze for cross-document consistency. In Phase 6: run prizmkit.code-review for spec compliance and code quality, write and execute integration tests.",
+      "subscriptions": ["*"]
+    }
+  ]
+}

package/bundled/templates/claude-md-template.md

@@ -0,0 +1,38 @@
+## PrizmKit Documentation Framework
+
+This project uses PrizmKit with the Prizm documentation system for AI-optimized progressive context loading.
+
+### Progressive Loading Protocol
+- ON SESSION START: Always read `.prizm-docs/root.prizm` first (L0 — project map)
+- ON TASK: Read L1 (`.prizm-docs/<module>.prizm`) for relevant modules referenced in MODULE_INDEX
+- ON FILE EDIT: Read L2 (`.prizm-docs/<module>/<submodule>.prizm`) before modifying files. Pay attention to TRAPS and DECISIONS.
+- NEVER load all .prizm docs at once. Load only what is needed for the current task.
+
+### Auto-Update Protocol
+- BEFORE EVERY COMMIT: Update affected `.prizm-docs/` files
+- The `.claude/rules/` files will enforce this automatically
+- Use `/prizmkit-committer` command for the complete commit workflow
+
+### Doc Format Rules
+- All `.prizm` files use KEY: value format, not prose
+- Size limits: L0 = 4KB, L1 = 3KB, L2 = 5KB
+- Arrow notation (->) indicates load pointers to other .prizm docs
+- DECISIONS and CHANGELOG are append-only (never delete entries)
+
+### Creating New L2 Docs
+- When you first modify files in a sub-module that has no L2 doc:
+  1. Read the source files in that sub-module
+  2. Generate a new L2 `.prizm` file following Prizm specification
+  3. Add a pointer in the parent L1 doc's SUBDIRS section
+
+### Available Commands
+Run `/prizm-kit` to see all available PrizmKit commands.
+
+### Fast Path for Simple Changes
+Not every change needs the full spec -> plan -> tasks workflow. Use fast path for:
+- Bug fixes with clear root cause, config tweaks, typo fixes, simple refactors
+- Documentation-only changes, test additions for existing code
+- Directly use `/prizmkit-implement` with inline task description, then `/prizmkit-committer`
+
+Use the full workflow (/prizmkit-specify -> /prizmkit-plan -> /prizmkit-tasks -> /prizmkit-analyze -> /prizmkit-implement) for:
+- New features, multi-file coordinated changes, architectural decisions, data model or API changes