prizmkit 1.1.8 → 1.1.10

package/bundled/skills/app-planner/references/project-conventions.md

@@ -1,93 +0,0 @@
-# Project Conventions — First-Run Setup Questions
-
-> Capture project-wide norms once, reuse across all planning sessions.
-
-These questions establish foundational conventions that affect every feature. They should be asked **once** during the first `app-planner` session and persisted to `.prizmkit/project-conventions.json` so subsequent sessions skip them.
-
-## Persistence
-
-- **File**: `.prizmkit/project-conventions.json`
-- **Read on startup**: If the file exists and a convention has a non-null value, skip that question.
-- **Write after asking**: Save answers immediately after the user responds.
-- **Shared**: Other skills (`prizmkit-init`, `dev-pipeline`) may also read this file.
-
-## Convention Questions
-
-Ask only unanswered conventions. Group related questions together in a single prompt when possible.
-
-### 1. UI Display Language
-
-**Key**: `ui_language`
-
-> "What is the primary language for the application's user interface? (e.g., English, 中文, 日本語, etc.)"
-
-**Follow-up if applicable**: If the user specifies a non-English language, confirm whether all UI text (buttons, labels, error messages, tooltips) should be in that language.
-
-### 2. Multi-Language Support (i18n)
-
-**Key**: `i18n_enabled`, `i18n_languages`
-
-> "Does the application need multi-language support (i18n)?"
-
-- If **yes** → ask: "Which languages should be supported? List all target languages."
-- If **no** → set `i18n_enabled: false`, skip `i18n_languages`.
-
-**Impact on planning**: If i18n is enabled, add an infrastructure feature for i18n setup (framework, translation file structure, language switcher) early in the dependency graph.
-
-### 3. Date, Time & Currency Formats
-
-**Key**: `date_format`, `timezone_strategy`, `currency`
-
-> "What are your preferences for date/time and currency display?"
-
-Sub-questions (ask as a group):
-- **Date format**: "Preferred date display format?" (e.g., `YYYY-MM-DD`, `MM/DD/YYYY`, `DD/MM/YYYY`, locale-auto)
-- **Timezone strategy**: "How should the app handle timezones?" (e.g., UTC storage + local display, user-selected timezone, server timezone only)
-- **Currency**: "If the app handles money, which currency format?" (e.g., USD `$1,234.56`, CNY `¥1,234.56`, EUR `€1.234,56`, or N/A if no monetary values)
-
-If the user says "not applicable" for currency, set `currency: null`.
-
-### 4. Code & Git Language Conventions
-
-**Key**: `code_comment_language`, `git_commit_language`
-
-> "What language should be used for code comments and git commit messages?"
-
-Options to present:
-- **Code comments**: English / Chinese / Match UI language / Mixed
-- **Git commit messages**: English / Chinese / Match code comments
-
-**Default suggestion**: English for both (widely accessible, compatible with open-source contribution).
-
-## JSON Schema
-
-```json
-{
-  "ui_language": "English",
-  "i18n_enabled": false,
-  "i18n_languages": [],
-  "date_format": "YYYY-MM-DD",
-  "timezone_strategy": "utc_storage_local_display",
-  "currency": null,
-  "code_comment_language": "English",
-  "git_commit_language": "English"
-}
-```
-
-## How Conventions Are Used
-
-Conventions are **AI context** — they inform your behavior during planning but are NOT written into `feature-list.json` `global_context` fields. Specifically:
-
-- `ui_language` → Write feature descriptions and acceptance criteria in a way that acknowledges the target UI language (e.g., mention CJK text handling if Chinese, RTL layout if Arabic)
-- `i18n_enabled` → If true, consider proposing an i18n infrastructure feature early in the dependency graph; ensure feature descriptions mention translation-ready patterns
-- `date_format`, `timezone_strategy` → When features involve date/time display or storage, reference the chosen convention in feature descriptions
-- `currency` → When features involve monetary values, reference the currency convention in descriptions
-- `code_comment_language` → Inform the language used in code-related examples within feature descriptions
-- `git_commit_language` → Inform pipeline and workflow language expectations
-
-## Rules
-
-- **Ask at most once per convention** — if answered, never re-ask unless user invokes a reset.
-- **No blocking** — if the user skips a question ("I'll decide later"), set value to `null` and move on. The question will be re-asked next session.
-- **Respect existing config** — if `.prizmkit/config.json` already has equivalent fields (e.g., `tech_stack.language`), do not duplicate. Only ask questions not covered by existing config.
-- **Minimal interruption** — batch all unanswered questions into a single interaction round, not one-by-one.

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

@@ -1,207 +0,0 @@
----
-name: "prizmkit-analyze"
-description: "Cross-document consistency analysis for spec.md and plan.md. Detects duplications, ambiguities, gaps, and rule conflicts. Read-only quality gate — use after /prizmkit-plan, before /prizmkit-implement. Trigger on: 'analyze', 'check consistency', 'validate spec', 'review plan', 'is the spec ready'. (project)"
----
-
-# PrizmKit Analyze
-
-### When to Use
-- After `/prizmkit-plan` to validate spec-plan-tasks alignment before implementation
-- User says "analyze", "check consistency", "validate spec", "review plan"
-- Before `/prizmkit-implement` as a quality gate
-
-**PRECONDITION:**
-
-| Required Artifact | Directory | Check | If Missing |
-|---|---|---|---|
-| `spec.md` | `.prizmkit/specs/###-feature-name/` | File exists | Run `/prizmkit-plan` |
-| `plan.md` (with Tasks section) | `.prizmkit/specs/###-feature-name/` | File exists + has Tasks section | Run `/prizmkit-plan` |
-
-## Operating Constraints
-
-**Read-only analysis**: Do not modify any files. The analysis output goes to conversation only, with an optional remediation plan the user must explicitly approve. This separation matters because the user needs to understand what's wrong before deciding what to change — auto-fixing consistency issues often introduces new ones.
-
-**Prizm Rules take precedence**: The project rules in `.prizm-docs/root.prizm` RULES section are the source of truth. If a spec or plan element conflicts with a MUST/NEVER directive, the spec/plan needs to change, not the rule. This prevents well-intentioned features from silently violating project-wide constraints. If a rule itself is wrong, that's a separate conversation via prizmkit-prizm-docs (Update operation).
-
-## Execution Steps
-
-### Step 1: Initialize Analysis Context
-
-Locate the current feature directory in `.prizmkit/specs/###-feature-name/` by checking the current Git branch name or scanning `.prizmkit/specs/` for the most recent feature directory.
-
-Derive absolute paths:
-- SPEC = `.prizmkit/specs/###-feature-name/spec.md`
-- PLAN = `.prizmkit/specs/###-feature-name/plan.md` (must include a Tasks section)
-
-Abort with an error message if spec.md or plan.md is missing — instruct the user to run `/prizmkit-plan`.
-
-### Step 2: Load Artifacts (Progressive Disclosure)
-
-Load only the minimal necessary context from each artifact:
-
-**From spec.md:**
-- Overview/Context
-- Functional Requirements
-- Non-Functional Requirements
-- User Stories and Acceptance Criteria
-- Scope Boundaries
-- Edge Cases (if present)
-
-**From plan.md:**
-- Architecture/stack choices
-- Component Design
-- Data Model references
-- API Contracts
-- Testing Strategy
-- Risk Assessment
-- Tasks section (task IDs, phase grouping, parallel markers, file paths)
-
-**From .prizm-docs/root.prizm:**
-- RULES section (MUST/NEVER/PREFER directives)
-- PATTERNS section (project-wide code patterns)
-- TECH_STACK section (for consistency checking)
-
-### Step 3: Build Semantic Models
-
-Create internal representations (do not include raw artifacts in output):
-
-- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug from imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`)
-- **User story/action inventory**: Discrete user actions with acceptance criteria
-- **Task coverage mapping**: Map each task (from plan.md Tasks section) to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
-- **Prizm rule set**: Extract MUST/NEVER/PREFER normative statements from root.prizm RULES
-
-### Step 4: Detection Passes
-
-Focus on high-signal findings. Limit to **50 findings total**; aggregate remainder in overflow summary.
-
-#### A. Duplication Detection
-- Identify near-duplicate requirements across spec.md sections
-- Mark lower-quality phrasing for consolidation
-
-#### B. Ambiguity Detection
-- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
-- Flag unresolved placeholders (TODO, TBD, ???, `<placeholder>`, `[NEEDS CLARIFICATION]`)
-
-#### C. Underspecification
-- Requirements with verbs but missing object or measurable outcome
-- User stories missing acceptance criteria alignment
-- Tasks referencing files or components not defined in spec/plan
-- Plan components with no corresponding spec requirement
-
-#### D. Prizm Rules Alignment
-- Any requirement or plan element conflicting with a MUST/NEVER directive
-- Missing mandated patterns from PATTERNS section
-- Tech stack inconsistencies between plan and root.prizm TECH_STACK
-
-#### E. Coverage Gaps
-- Requirements with zero associated tasks (from plan.md Tasks section)
-- Tasks with no mapped requirement/story ("orphan tasks")
-- Non-functional requirements not reflected in tasks (performance, security, etc.)
-- User stories without corresponding plan components
-
-#### F. Inconsistency
-- Terminology drift (same concept named differently across files)
-- Data entities referenced in plan but absent in spec (or vice versa)
-- Task ordering contradictions (e.g., integration tasks before foundational setup without dependency note)
-- Conflicting requirements (e.g., one requires REST while other specifies GraphQL)
-
-#### G. Database Design Consistency (when plan.md has Data Model section)
-- New entity/field naming inconsistent with existing schema conventions documented in "Existing Schema Audit"
-- Missing constraints (NOT NULL, UNIQUE, FK, INDEX) on fields where existing similar tables define them
-- Unresolved `[NEEDS CLARIFICATION]` in Data Model section → **CRITICAL** (must be resolved before implementation)
-- Style Conformance Checklist items unchecked → **HIGH** (design not verified against existing conventions)
-- New tables with no foreign key relationship to any existing table (orphan table warning — may indicate missing business logic)
-- Missing migration strategy for schema changes that affect existing data
-
-### Step 5: Severity Assignment
-
-Use this heuristic to prioritize findings:
-
-- **CRITICAL**: Violates Prizm RULES MUST/NEVER directive, missing core artifact section, or requirement with zero coverage that blocks baseline functionality
-- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
-- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
-- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
-
-### Step 6: Produce Compact Analysis Report
-
-Output a Markdown report (**no file writes**) with the following structure:
-
-```
-## Consistency Analysis Report
-
-| ID | Category | Severity | Location(s) | Summary | Recommendation |
-|----|----------|----------|-------------|---------|----------------|
-| A1 | Duplication | HIGH | spec.md §2.1, §3.4 | Two similar requirements... | Merge phrasing; keep clearer version |
-| D1 | Rules Alignment | CRITICAL | plan.md §Architecture | Conflicts with MUST rule... | Adjust plan to align with rule |
-
-**Coverage Summary:**
-
-| Requirement Key | Has Task? | Task IDs | Notes |
-|-----------------|-----------|----------|-------|
-
-**Prizm Rules Alignment Issues:** (if any)
-
-**Unmapped Tasks:** (if any)
-
-**Metrics:**
-- Total Requirements: N
-- Total Tasks: N
-- Coverage %: N% (requirements with >=1 task)
-- Ambiguity Count: N
-- Duplication Count: N
-- Critical Issues: N
-```
-
-### Step 7: Provide Next Actions
-
-At end of report, output a concise Next Actions block:
-
-- If CRITICAL issues exist: **Recommend resolving before `/prizmkit-implement`**
-- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
-- Provide explicit command suggestions:
-  - "Run `/prizmkit-plan` to refine requirements"
-  - "Run `/prizmkit-plan` to adjust architecture or tasks"
-  - "Edit plan.md Tasks section to add coverage for requirement X"
-  - "Proceed to `/prizmkit-implement`" (if clean)
-
-### Step 8: Offer Remediation
-
-Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
-
-## Operating Principles
-
-### Context Efficiency
-- Focus on actionable findings, not exhaustive documentation — the goal is to surface problems, not prove you read everything
-- Load artifacts incrementally; reading all content upfront wastes tokens on sections irrelevant to the feature
-- Cap findings at 50 rows to keep the report scannable; summarize overflow with counts
-- Rerunning without changes should produce consistent IDs and counts (deterministic)
-
-### Analysis Approach
-- If a section is absent, report it accurately rather than guessing what it might contain
-- Prizm Rules violations are always CRITICAL — they represent project-wide constraints that outrank individual feature decisions
-- Cite specific instances rather than generic patterns — "spec §2.1 says REST but plan §Architecture says GraphQL" is more useful than "terminology inconsistency found"
-- If zero issues found, report success with coverage statistics — a clean report is valuable confirmation
-
-## Example Finding
-
-```
-| ID | Category | Severity | Location(s) | Summary | Recommendation |
-|----|----------|----------|-------------|---------|----------------|
-| D1 | Rules Alignment | CRITICAL | plan.md §Architecture | Plan specifies SQLite but root.prizm RULES has "MUST: use PostgreSQL for all persistent storage" | Change plan to use PostgreSQL or request rule amendment via prizmkit-prizm-docs |
-| E1 | Coverage Gap | HIGH | spec.md §FR-3 | "User can export reports as PDF" has no corresponding task in plan.md Tasks section | Add export task to Phase 3 of plan.md |
-```
-
-**HANDOFF:** `/prizmkit-implement` (if clean) or `/prizmkit-plan` (if issues found)
-
-## Loop Protection
-
-In unattended pipeline mode, the analyze→fix→analyze cycle can loop indefinitely if issues keep reappearing. To prevent this:
-
-- Track an `analyze_iteration` counter starting at 1. Each re-run of this skill after remediation increments the counter.
-- **max_iterations = 5**: If `analyze_iteration >= 5`, you MUST proceed to `/prizmkit-implement` regardless of remaining findings. Log a warning: "Loop protection triggered — proceeding to implement with N unresolved findings (iterations: 5/5)."
-- Unresolved findings from the final iteration should be noted in the handoff so that `/prizmkit-code-review` can catch them downstream.
-- This guard exists because some findings oscillate (fixing one re-introduces another) and blocking forever is worse than proceeding with known issues.
-
-## Output
-
-Analysis report is output to conversation only.

package/bundled/skills/prizmkit-code-review/rules/dimensions-bugfix.md

@@ -1,25 +0,0 @@
-# Review Dimensions — Bugfix Mode
-
-Review code against `fix-plan.md` and the bug description. Minimal scope — the fix should change as little as possible.
-
-## Bugfix-Specific Dimensions
-
-### Bug Actually Fixed
-- The reproduction steps from fix-plan.md no longer trigger the bug
-- The root cause identified in fix-plan.md is addressed (not just symptoms)
-- A regression test exists that would catch this bug if reintroduced
-
-### No Regressions
-- All existing tests still pass
-- The fix does not change behavior for non-buggy inputs
-- Related code paths are not inadvertently affected
-
-### Minimal Change Scope
-- Only files directly related to the bug are modified
-- No "while I'm here" refactoring mixed with the fix
-- If scope creep is detected, flag it — those changes belong in a separate commit
-
-### Reproduction Test
-- A test exists that reproduces the exact bug scenario
-- The test would fail on the pre-fix code and pass on the post-fix code
-- The test covers the specific input/state that triggered the bug

package/bundled/skills/prizmkit-code-review/rules/dimensions-feature.md

@@ -1,43 +0,0 @@
-# Review Dimensions — Feature Mode
-
-Review code against `spec.md` and `plan.md` across 6 dimensions:
-
-## 1. Spec Compliance
-Does code implement all acceptance criteria? Missing criteria are the #1 source of "it works but it's wrong" bugs.
-- Check every acceptance criterion in spec.md has a corresponding implementation
-- Verify edge cases mentioned in spec are handled
-- Confirm scope boundaries are respected (no over-implementation, no under-implementation)
-
-## 2. Plan Adherence
-Does implementation follow architectural decisions in plan.md? Deviations may be improvements or may break assumptions other components depend on.
-- Check component structure matches plan's architecture approach
-- Verify data model matches plan's schema design
-- Confirm API contracts (endpoints, request/response) match plan
-
-## 3. Code Quality
-Naming, structure, complexity, DRY. Focus on maintainability — will someone understand this code in 6 months?
-- Function/variable names are descriptive and consistent with project conventions
-- No unnecessary complexity (cyclomatic complexity, deep nesting)
-- No copy-paste duplication that should be abstracted
-- Error messages are informative for debugging
-
-## 4. Security
-Injection (SQL, XSS, command), auth/authz gaps, sensitive data exposure, insecure defaults. Security issues are always HIGH+ because they're the hardest to catch later.
-- User input is validated and sanitized before use in queries, HTML, or commands
-- Authentication and authorization checks are present on protected routes
-- Sensitive data (passwords, tokens, PII) is not logged or exposed in responses
-- Cryptographic operations use established libraries, not custom implementations
-
-## 5. Consistency
-Follows project patterns from `.prizm-docs/` PATTERNS section. Inconsistent patterns increase cognitive load for every future reader.
-- Code style matches existing codebase conventions
-- Error handling follows established patterns
-- File organization follows project structure conventions
-- Naming conventions align with `.prizm-docs/` RULES
-
-## 6. Test Coverage
-Are critical paths tested? Focus on paths that handle user input, money, or state transitions.
-- Happy path tests exist for each user story
-- Error/edge case tests for critical paths
-- Tests are deterministic (no flaky timing dependencies)
-- Test names clearly describe what they verify

package/bundled/skills/prizmkit-code-review/rules/dimensions-refactor.md

@@ -1,25 +0,0 @@
-# Review Dimensions — Refactor Mode
-
-Review code against `refactor-analysis.md` goals. Standard dimensions (code quality, security, consistency, test coverage) still apply — load `${SKILL_DIR}/rules/dimensions-feature.md` §3–§6 for those.
-
-## Refactor-Specific Dimensions
-
-### Behavior Preservation (replaces Spec Compliance)
-Observable behavior must remain unchanged. This is the #1 refactor risk — "improving" code that subtly changes behavior.
-- All existing tests still pass without modification (test changes during refactor are a red flag)
-- Public API signatures are unchanged (parameter types, return types, error types)
-- Side effects (logging, metrics, events) are preserved unless explicitly scoped for removal
-- Edge case handling is preserved — refactors often silently drop edge case branches
-
-### Structural Improvement (replaces Plan Adherence)
-Is the code measurably better against the refactor goals?
-- Complexity metrics improved (fewer nested conditions, shorter functions)
-- Coupling reduced (fewer cross-module imports, clearer boundaries)
-- Duplication reduced (DRY violations eliminated per refactor-analysis.md scope)
-- Readability improved (naming, organization, documentation)
-
-### Test Integrity
-Refactors must not weaken the test suite.
-- No tests were deleted or skipped
-- Test coverage percentage is equal or higher
-- If tests were rewritten, they cover the same behavioral scenarios

package/bundled/skills/prizmkit-implement/references/deploy-guide-protocol.md

@@ -1,69 +0,0 @@
-# Deploy Guide Update Protocol
-
-When dependency manifests change during implementation, update `DEPLOY.md` at the project root.
-
-## Detection
-
-1. Check if any dependency manifests were modified in this session:
-   ```bash
-   git diff --name-only HEAD -- package.json requirements*.txt Pipfile pyproject.toml go.mod Cargo.toml pom.xml build.gradle Gemfile composer.json docker-compose*.yml Dockerfile .tool-versions 2>/dev/null
-   ```
-2. If no manifest files changed → skip this step entirely
-3. If manifest files changed, scan for **newly added** dependencies (not version bumps):
-   ```bash
-   git diff -U0 HEAD -- package.json requirements*.txt Pipfile pyproject.toml go.mod Cargo.toml pom.xml build.gradle Gemfile composer.json docker-compose*.yml Dockerfile .tool-versions 2>/dev/null | grep '^\+' | grep -v '^\+\+\+' | head -30
-   ```
-
-## Recording
-
-For each genuinely new framework/tool, record in `DEPLOY.md` at project root:
-
-| Field | Description | Source |
-|-------|-------------|--------|
-| **Name** | Framework/tool name | Package name from manifest |
-| **Version** | Installed version or constraint | Version spec from manifest |
-| **Purpose** | Why it was introduced | You just added it — you know why |
-| **Install Command** | How to install locally | Standard install command for the ecosystem |
-| **Key Config** | Config files or env vars needed | Config files you just created/modified |
-| **Notes** | Setup gotchas, required services | Docker services, manual steps, env vars |
-
-## Template for `DEPLOY.md`
-
-```markdown
-# Deploy Guide
-
-> Auto-maintained by PrizmKit. Manual edits are preserved.
-> Last updated: YYYY-MM-DD
-
-## Frameworks & Tools
-
-### <Framework Name>
-
-- **Version**: <version constraint>
-- **Purpose**: <why this framework is used>
-- **Install**:
-  ```bash
-  <install command>
-  ```
-- **Key Config**:
-  - `<config file or env var>`: <description>
-- **Notes**:
-  - <any setup gotchas, required external services, manual steps>
-```
-
-## Update Rules
-
-- Create file if absent; append new sections if file exists
-- Update version if framework already documented
-- Preserve manually added content
-- Keep entries sorted alphabetically
-
-## Filter Out
-
-- Patch version bumps of existing deps
-- Dev-only tools needing no setup (linters, formatters)
-- Transitive/lock-file-only changes
-
-## Final Step
-
-Stage the file: `git add DEPLOY.md`