prizmkit 1.0.152 → 1.1.0

package/src/scaffold.js

@@ -57,7 +57,7 @@ async function loadSharedFrontmatter() {
 /**
  * 根据套件名称解析 Skill 列表
  */
-async function resolveSkillList(suite) {
+export async function resolveSkillList(suite) {
   const metadata = await loadMetadata();
 
   // 处理 recommended:<type> 格式
@@ -74,7 +74,7 @@ async function resolveSkillList(suite) {
     }
   }
 
-  const suiteDef = metadata.suites[suite] || metadata.suites.full;
+  const suiteDef = metadata.suites[suite] || metadata.suites.core;
   if (suiteDef.skills === '*') {
     return Object.keys(metadata.skills);
   }
@@ -92,11 +92,13 @@ export async function installSkills(platform, skills, projectRoot, dryRun) {
   const skillsDir = getSkillsDir();
   const { parseFrontmatter, buildMarkdown } = await loadSharedFrontmatter();
   
-  // Load metadata to get skill -> category mapping
+  // Load metadata to get skill -> category + subcategory mapping
   const metadata = await loadMetadata();
   const skillCategories = {};
+  const skillSubcategories = {};
   for (const [skillName, skillDef] of Object.entries(metadata.skills)) {
     skillCategories[skillName] = skillDef.category;
+    skillSubcategories[skillName] = skillDef.subcategory;
   }
 
   // Load Claude command adapter for skill conversion
@@ -107,22 +109,30 @@ export async function installSkills(platform, skills, projectRoot, dryRun) {
   }
 
   for (const skillName of skills) {
-    // Determine the category subdirectory (prizmkit-skill, prizmkit-tool-skill, Custom-skill)
+    // Determine the category subdirectory (prizmkit-skill, prizmkit-tool-skill, orchestration-skill)
     const category = skillCategories[skillName];
     if (!category) {
       console.warn(`  ⚠ Skill ${skillName} has no category mapping in metadata, skipping`);
       continue;
     }
 
-    // Security: validate category and skillName contain no path traversal sequences.
+    const subcategory = skillSubcategories[skillName];
+
+    // Security: validate category, subcategory, and skillName contain no path traversal sequences.
     if (category.includes('..') || category.includes('/') || skillName.includes('..') || skillName.includes('/')) {
       console.warn(`  ⚠ Skill ${skillName} has invalid category or name, skipping`);
       continue;
     }
+    if (subcategory && (subcategory.includes('..') || subcategory.includes('/'))) {
+      console.warn(`  ⚠ Skill ${skillName} has invalid subcategory, skipping`);
+      continue;
+    }
 
-    // Build path: prefer hierarchical layout (<skillsDir>/<category>/<skillName>),
+    // Build path: prefer hierarchical layout (<skillsDir>/<category>/[<subcategory>/]/<skillName>),
     // fallback to flat bundled layout (<skillsDir>/<skillName>) for npm package compatibility.
-    let corePath = path.resolve(skillsDir, category, skillName);
+    let corePath = subcategory
+      ? path.resolve(skillsDir, category, subcategory, skillName)
+      : path.resolve(skillsDir, category, skillName);
     // Ensure resolved path stays within skillsDir
     if (!corePath.startsWith(path.resolve(skillsDir))) {
       console.warn(`  ⚠ Skill ${skillName} path escapes skills directory, skipping`);
@@ -244,7 +254,7 @@ export async function installAgents(platform, projectRoot, dryRun) {
 /**
  * 安装 Team 配置
  */
-async function installTeamConfig(platform, projectRoot, dryRun) {
+export async function installTeamConfig(platform, projectRoot, dryRun) {
   const teamDir = getTeamDir();
   const teamDefPath = path.join(teamDir, 'prizm-dev-team.json');
 
@@ -766,7 +776,7 @@ export const EXTRAS_REGISTRY = {
  * 执行纯净安装
  * @param {Object} config
  * @param {string} config.platform - 'codebuddy' | 'claude' | 'both'
- * @param {string} config.skills - 'full' | 'core' | 'minimal' | 'recommended:<type>'
+ * @param {string} config.skills - 'core' | 'minimal' | 'recommended:<type>'
  * @param {boolean} config.team - 是否启用团队模式
  * @param {boolean} config.pipeline - 是否安装 dev-pipeline
  * @param {string} [config.rules] - Rules preset: 'recommended' | 'minimal' | 'none'
@@ -958,8 +968,7 @@ export async function scaffold(config) {
     console.log('');
 
     // 安装统计
-    const suiteLabel = skills === 'full' ? `全部 ${skillList.length} 个`
-      : skills === 'core' ? `核心 ${skillList.length} 个`
+    const suiteLabel = skills === 'core' ? `核心 ${skillList.length} 个`
       : skills === 'minimal' ? `最小 ${skillList.length} 个`
       : `推荐 ${skillList.length} 个`;
 

package/src/upgrade.js

@@ -30,42 +30,17 @@ import {
   installGitignore,
   installProjectMemory,
   resolvePipelineFileList,
+  resolveSkillList,
   EXTRAS_REGISTRY,
 } from './scaffold.js';
 
 const __dirname = dirname(fileURLToPath(import.meta.url));
 const pkg = JSON.parse(readFileSync(join(__dirname, '..', 'package.json'), 'utf-8'));
 
-/**
- * Resolve skill list from suite name (same logic as scaffold.js).
- */
-async function resolveSkillList(suite) {
-  const metadata = await loadMetadata();
-
-  if (suite && suite.startsWith('recommended:')) {
-    const projectType = suite.split(':')[1];
-    const rec = metadata.recommendations?.[projectType];
-    if (rec) {
-      const baseSkills = rec.base === '*'
-        ? Object.keys(metadata.skills)
-        : [...(metadata.suites[rec.base]?.skills || [])];
-      const includeSkills = rec.include || [];
-      const excludeSkills = new Set(rec.exclude || []);
-      return [...new Set([...baseSkills, ...includeSkills])].filter(s => !excludeSkills.has(s));
-    }
-  }
-
-  const suiteDef = metadata.suites[suite] || metadata.suites.full;
-  if (suiteDef.skills === '*') {
-    return Object.keys(metadata.skills);
-  }
-  return suiteDef.skills;
-}
-
 /**
  * Remove skill files for a specific platform.
  */
-async function removeSkillFiles(platform, projectRoot, skillNames, dryRun) {
+export async function removeSkillFiles(platform, projectRoot, skillNames, dryRun) {
   for (const skillName of skillNames) {
     if (platform === 'claude') {
       const commandFile = path.join(projectRoot, '.claude', 'commands', `${skillName}.md`);
@@ -103,7 +78,7 @@ async function removeSkillFiles(platform, projectRoot, skillNames, dryRun) {
 /**
  * Remove agent files for a specific platform.
  */
-async function removeAgentFiles(platform, projectRoot, agentFileNames, dryRun) {
+export async function removeAgentFiles(platform, projectRoot, agentFileNames, dryRun) {
   for (const fileName of agentFileNames) {
     const dir = platform === 'claude'
       ? path.join(projectRoot, '.claude', 'agents')
@@ -123,7 +98,7 @@ async function removeAgentFiles(platform, projectRoot, agentFileNames, dryRun) {
 /**
  * Remove rule files for a specific platform.
  */
-async function removeRuleFiles(platform, projectRoot, ruleFileNames, dryRun) {
+export async function removeRuleFiles(platform, projectRoot, ruleFileNames, dryRun) {
   for (const fileName of ruleFileNames) {
     const ext = platform === 'claude' ? '' : '';
     const dir = platform === 'claude'
@@ -148,7 +123,7 @@ async function removeRuleFiles(platform, projectRoot, ruleFileNames, dryRun) {
 /**
  * Remove pipeline files that are no longer in the new manifest.
  */
-async function removePipelineFiles(projectRoot, fileList, dryRun) {
+export async function removePipelineFiles(projectRoot, fileList, dryRun) {
   for (const relPath of fileList) {
     const filePath = path.join(projectRoot, 'dev-pipeline', relPath);
     if (await fs.pathExists(filePath)) {
@@ -217,7 +192,7 @@ export async function runUpgrade(directory, options = {}) {
 
   // 3. Resolve new skill list using old manifest's suite + platform (or defaults)
   const oldManifestPlatform = oldManifest?.platform || 'claude';
-  const suite = oldManifest?.suite || 'full';
+  const suite = oldManifest?.suite || 'core';
   const team = oldManifest?.options?.team ?? true;
   const pipeline = oldManifest?.options?.pipeline ?? true;
   const rulesPreset = oldManifest?.options?.rules || 'recommended';

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

@@ -1,93 +0,0 @@
----
-name: "prizmkit-clarify"
-description: "Interactive requirement clarification. Resolves ALL ambiguities in feature specs through unlimited rounds of questions until full understanding is reached. Use when spec has unclear parts, you're unsure about requirements, or before planning to ensure nothing is ambiguous. Trigger on: 'clarify', 'refine spec', 'resolve ambiguities', 'spec has questions', 'unsure about requirements', 'spec is unclear'. (project)"
----
-
-# PrizmKit Clarify
-
-Exhaustive interactive requirement clarification. Resolves **every** ambiguity in a feature specification by asking questions one at a time — no limit on rounds or number of questions. The goal is **complete understanding**: do not stop until every unclear aspect is resolved and you are fully confident about the requirements.
-
-### When to Use
-- After `/prizmkit-specify` when spec has `[NEEDS CLARIFICATION]` markers
-- User says "clarify", "resolve ambiguities", "refine spec"
-- Before `/prizmkit-plan` to ensure spec is unambiguous
-- Whenever you encounter any uncertainty about what the user wants — proactively ask rather than assume
-
-**PRECONDITION:**
-
-| Required Artifact | Directory | Check | If Missing |
-|---|---|---|---|
-| `spec.md` | `.prizmkit/specs/###-feature-name/` | File exists with `[NEEDS CLARIFICATION]` markers or underspecified areas | Run `/prizmkit-specify` first |
-
-## Execution Steps
-
-1. Read `spec.md` from `.prizmkit/specs/###-feature-name/`
-2. Scan for ALL ambiguities — not just `[NEEDS CLARIFICATION]` markers but also:
-   - Vague terms without measurable criteria (e.g., "fast", "user-friendly", "secure")
-   - Missing edge cases that would affect implementation
-   - Implicit assumptions not stated explicitly
-   - Scope boundaries that could be interpreted multiple ways
-   - Data model gaps (entities, relationships, constraints undefined)
-3. Categorize ambiguities by dimension and prioritize — address the ones that would most affect architecture and data model first, since those are hardest to change later:
-   - Data model (what entities, relationships, constraints?) — **highest priority when DB changes are involved**: field types, nullability, naming conventions, relationships, and constraint patterns must all be resolved before plan finalization. Unresolved DB design decisions during implementation lead to expensive rework.
-   - Functional scope (what does it do?)
-   - UX flow (what does the user see?)
-   - Error handling (what happens when things fail?)
-   - Non-functional requirements (performance, security)
-   - Edge cases, integration points, accessibility
-4. Ask questions **one at a time** — batch questions overwhelm users and produce lower-quality answers because they rush through without thinking deeply about each one
-5. For each question: provide a recommended answer with rationale. The recommendation gives users a concrete starting point to accept, modify, or reject — this is much faster than open-ended questions
-6. After each answer: immediately update `spec.md` (not batched at the end). Atomic updates mean the spec is always in a consistent state, even if the session is interrupted
-7. Remove resolved `[NEEDS CLARIFICATION]` markers as they are addressed
-8. **Continue asking** — after each answer, re-evaluate the spec for remaining ambiguities. Each user answer may reveal new questions. Keep going until:
-   - All `[NEEDS CLARIFICATION]` markers are removed, AND
-   - No vague or underspecified areas remain, AND
-   - You are fully confident about the requirements
-9. Support early termination: user says "done", "stop", or "enough" — end immediately and summarize what was resolved vs what remains unclear
-10. After all questions resolved or user terminates: output summary of all changes made
-
-## No Limits Policy
-
-**There is NO cap on the number of questions or rounds.** Ask as many questions as needed to achieve complete understanding. A half-understood spec leads to wrong implementations, which cost far more than thorough clarification upfront.
-
-- If you've asked 10 questions and there are still ambiguities — keep asking
-- If the user's answer raises new questions — ask those too
-- If you realize a previously-resolved item needs revisiting because of new context — go back and ask again
-- Only stop when you genuinely have no more uncertainties, or the user explicitly terminates
-
-## Example Session
-
-**Question 1:**
-> spec.md §3.2 says "User can upload files" but doesn't specify which file types or size limits.
->
-> **Recommended answer:** Accept JPEG, PNG, and PDF up to 10MB. These are the most common user upload types, and 10MB covers high-res photos without straining storage.
->
-> Do you agree, or would you like different constraints?
-
-**User:** "Also allow SVG, and make it 25MB"
-
-**Action:** Update spec.md §3.2:
-```
-File upload: accepts JPEG, PNG, PDF, SVG. Max size: 25MB per file.
-```
-Remove `[NEEDS CLARIFICATION]` marker from §3.2.
-
-**Question 2** (new question triggered by user's answer):
-> You mentioned SVG files. SVGs can contain embedded scripts which pose XSS risks. Should uploaded SVGs be sanitized (strip `<script>` tags and event handlers), or should SVG upload be restricted to trusted users only?
->
-> **Recommended answer:** Sanitize all SVG uploads by stripping scripts and event handlers. This allows all users to upload SVGs safely.
-
-*(Continue until all ambiguities are resolved...)*
-
-## Guidelines
-
-- Keep questions at the WHAT/WHY level — do not introduce implementation details (HOW). The spec describes the problem space; implementation choices belong in plan.md
-- If the user's answer contradicts an existing requirement, point out the conflict and ask which one should change
-- Group related follow-up questions naturally — if a user's answer opens 3 related sub-questions, ask the most impactful one first, then proceed to the others
-- If the user seems fatigued, acknowledge it: "I have N more questions. Want to continue now or come back later?" — but never silently stop with unresolved ambiguities
-
-**HANDOFF:** `/prizmkit-plan`
-
-## Output
-
-Updates are made directly to `.prizmkit/specs/###-feature-name/spec.md`. No new files are created.

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

@@ -1,118 +0,0 @@
----
-name: "prizmkit-specify"
-description: "Create structured feature specifications from natural language. Use this skill whenever the user wants to define a new feature, describe what to build, or write requirements. Trigger on: 'specify', 'define feature', 'write requirements', 'new feature', 'what should we build', 'I want to add...', 'I want to build...', 'let's add', 'let's build', 'feature idea', or when the user describes a feature they want. This is the first step in the full dev workflow — always use before /prizmkit-plan. Skip for bug fixes, config tweaks, or simple refactors (use fast path). (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.
-
-### When to Use
-- Starting a new feature — user says "specify", "define feature", "new feature", "I want to add..."
-- Before `/prizmkit-plan` — to define WHAT will be built before deciding HOW
-- When a feature idea needs to be formalized before implementation
-- When multiple stakeholders need to agree on scope before coding starts
-
-### When NOT to Use
-- Bug fixes with clear root cause → use fast path (`/prizmkit-plan` simplified → `/prizmkit-implement` → `/prizmkit-committer`)
-- Config tweaks, typo fixes, simple refactors → edit directly
-- Documentation-only changes → no spec needed
-- User already has a detailed spec → skip to /prizmkit-plan
-
-## Execution 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/`:
-   - List existing `###-*` directories and find the highest numeric prefix
-   - Next number = highest + 1 (zero-padded to 3 digits)
-   - Append a short timestamp suffix (`-MMDD`) to prevent collisions in concurrent sessions. Example: `004-user-avatar-0319/`
-   - If `.prizmkit/specs/` is empty or doesn't exist, start at `001`
-4. Create directory: `.prizmkit/specs/###-feature-name-MMDD/`
-5. Load project context (use first available source):
-   - If `.prizmkit/specs/###-feature-name/context-snapshot.md` exists → read Section 3 'Prizm Context' from it (do NOT re-read `.prizm-docs/` files)
-   - Otherwise → read `.prizm-docs/root.prizm`
-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 all ambiguous items
-7. **Database design detection**: If the feature involves data persistence (new entities, new fields, schema changes), add a `## Data Model` section to spec.md (see template):
-   - Scan for existing database schema files to understand current conventions:
-     ```bash
-     find . -maxdepth 4 -type f \( -name "*.prisma" -o -name "*.sql" -o -path "*/migrations/*" -o -path "*/models/*" -o -name "schema.*" -o -name "*.entity.*" \) -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/__pycache__/*' | head -20
-     ```
-   - Read existing schema/model files to extract conventions: naming style (snake_case vs camelCase), ID strategy (UUID vs auto-increment), timestamp patterns, soft-delete approach, constraint patterns, relationship patterns
-   - Document in spec.md Data Model section: existing schema reference, new entities needed, relationships to existing tables
-   - Mark uncertain fields or relationships with `[NEEDS CLARIFICATION]` — these MUST be resolved before planning
-   - **RULE**: Never design new tables in isolation — always reference existing schema to maintain style consistency
-8. Run internal quality validation loop (max 3 iterations):
-   - Check: All user stories have acceptance criteria?
-   - Check: Scope boundaries clearly defined?
-   - Check: All `[NEEDS CLARIFICATION]` markers have recommended defaults?
-   - Check: If Data Model section exists, are existing schema conventions documented?
-9. Output: `spec.md` path and summary
-
-## Writing Principles
-
-- **Focus on WHAT and WHY, never HOW** — the spec describes the problem space; implementation choices belong in plan.md. Mixing in tech stack details couples the spec to a specific solution and makes it harder to explore alternatives during planning.
-- **Every user story needs acceptance criteria** in Given/When/Then format — without them, the implementer has no way to verify the feature works correctly, and the code reviewer has no baseline to check against.
-- **Scope boundaries must be explicit** — without "Out of scope" boundaries, implementers tend to gold-plate features with capabilities nobody asked for, wasting time and adding complexity.
-- **Mark all unclear areas with `[NEEDS CLARIFICATION]`** — do not limit the number of markers. Every genuine ambiguity should be surfaced. After spec generation, suggest running `/prizmkit-clarify` to resolve them all interactively.
-- **Feature numbers are zero-padded to 3 digits** (e.g., `001`, `012`) with a `-MMDD` timestamp suffix — ensures consistent sorting and prevents collisions when multiple sessions run concurrently.
-
-## Handling Vague Inputs
-
-When the user's feature description is vague:
-1. Extract what IS clear and write that into the spec
-2. Mark genuinely ambiguous parts with `[NEEDS CLARIFICATION]` and include a recommended default
-3. Suggest running `/prizmkit-clarify` to resolve ambiguities interactively before proceeding to plan
-
-The goal is to never block progress — always produce a usable spec, even if it has open questions.
-
-## Example
-
-**Input:** "I want users to upload avatars"
-
-**Output:** `.prizmkit/specs/003-user-avatar/spec.md`
-```markdown
-# Feature: User Avatar Upload
-
-## Overview
-Allow users to upload and manage profile avatar images.
-
-## User Stories
-
-### US-1: Upload Avatar
-As a registered user, I want to upload a profile picture,
-so that other users can visually identify me.
-
-**Acceptance Criteria:**
-- Given I am on my profile page
-- When I select an image file and click upload
-- Then my avatar is updated and visible across the platform
-
-### US-2: Remove Avatar
-As a registered user, I want to remove my avatar,
-so that I can revert to a default placeholder.
-
-## Scope
-- **In scope:** Upload, display, remove avatar; image format validation
-- **Out of scope:** Image cropping/editing, avatar history
-
-## Open Questions
-- [NEEDS CLARIFICATION] Maximum file size limit? Recommended: 10MB
-```
-
-**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

@@ -1,56 +0,0 @@
-# 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]
-
-## Data Model (if feature involves database changes)
-
-### Existing Schema Reference
-<!-- Read existing schema/model files BEFORE designing new tables. Document observed conventions here. -->
-- Tables reviewed: [list existing tables related to this feature]
-- Naming convention: [snake_case/camelCase — match existing]
-- ID strategy: [UUID/auto-increment — match existing]
-- Timestamp pattern: [created_at/updated_at — match existing]
-- Soft delete: [yes/no, field name — match existing]
-
-### New/Modified Entities
-| Entity | Type (new/modify) | Key Fields | Relationships | Constraints |
-|--------|-------------------|------------|---------------|-------------|
-| [entity_name] | new | [field: type] | [FK to existing_table] | [NOT NULL, UNIQUE, etc.] |
-
-### Open Data Model Questions
-<!-- All questions here MUST be resolved before /prizmkit-plan generates Tasks -->
-- [NEEDS CLARIFICATION] [Any uncertain data model decisions — field types, nullability, relationships]
-
-## 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-tool-adr-manager/SKILL.md

@@ -1,67 +0,0 @@
----
-name: "prizmkit-tool-adr-manager"
-description: [Tier 1] Manage Architecture Decision Records. Create, list, and supersede ADRs with full context. AI excels at documentation tasks. (project)
----
-
-# PrizmKit ADR Manager
-
-Manage Architecture Decision Records (ADRs) to document and track architectural decisions with full context, alternatives, and consequences.
-
-## Commands
-
-### `/prizmkit-adr`.new \<title\>
-
-Create a new Architecture Decision Record.
-
-**STEPS:**
-
-1. Determine next ADR number from `docs/adr/` directory (scan existing files, increment highest number)
-2. Generate ADR from template (`${SKILL_DIR}/assets/adr-template.md`):
-   - **Title**: Provided by user
-   - **Date**: Current date
-   - **Status**: Proposed
-   - **Context**: Ask user what issue is motivating this decision
-   - **Decision**: Ask user what change is being proposed
-   - **Consequences**: Identify positive and negative consequences
-   - **Alternatives considered**: Ask user about alternatives and why they were rejected
-3. Write to `docs/adr/NNNN-title.md` (zero-padded number, kebab-case title)
-4. Record as a DECISION entry in the relevant `.prizm-docs/` L1/L2 file for the affected module
-
-### `/prizmkit-adr`.list
-
-Show all ADRs with their current status.
-
-**STEPS:**
-
-1. Scan `docs/adr/` directory for ADR files
-2. Parse each file for number, title, and status
-3. Display table:
-   - Number | Title | Status | Date
-   - Status values: Proposed, Accepted, Deprecated, Superseded
-4. Highlight any ADRs in Proposed status that may need review
-
-### `/prizmkit-adr`.supersede \<number\> \<new-title\>
-
-Mark an existing ADR as superseded and create a replacement.
-
-**STEPS:**
-
-1. Read the existing ADR with the given number from `docs/adr/`
-2. Update its status to "Superseded by [ADR-NNNN]" (the new ADR number)
-3. Create a new ADR using the ``/prizmkit-adr`.new` flow:
-   - Pre-populate context with reference to the superseded ADR
-   - Include "Supersedes [ADR-NNNN]" in the new ADR
-4. Write both updated files
-
-## Template
-
-The ADR template is located at `${SKILL_DIR}/assets/adr-template.md` and follows the standard ADR format with Context, Decision, Consequences, and Alternatives sections.
-
-## Path References
-
-All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
-
-## Output
-
-- ADR files in `docs/adr/` directory
-- Updated DECISIONS in relevant `.prizm-docs/` L1/L2 files

package/bundled/skills/prizmkit-tool-adr-manager/assets/adr-template.md

@@ -1,26 +0,0 @@
-# [NUMBER]. [TITLE]
-
-**Date**: YYYY-MM-DD
-**Status**: Proposed | Accepted | Deprecated | Superseded by [ADR-NNNN]
-
-## Context
-
-[What is the issue that we're seeing that is motivating this decision or change?]
-
-## Decision
-
-[What is the change that we're proposing and/or doing?]
-
-## Consequences
-
-### Positive
-- [Consequence 1]
-
-### Negative
-- [Consequence 1]
-
-## Alternatives Considered
-
-### [Alternative 1]
-- **Description**: [What it is]
-- **Reason rejected**: [Why not chosen]

package/bundled/skills/prizmkit-tool-api-doc-generator/SKILL.md

@@ -1,55 +0,0 @@
----
-name: "prizmkit-tool-api-doc-generator"
-description: [Tier 2] Extract API documentation from source code into OpenAPI/Markdown. May miss undocumented or dynamically generated endpoints. (project)
----
-
-# PrizmKit API Doc Generator
-
-Generate API documentation from source code by scanning routes, controllers, and handlers. Produces OpenAPI 3.0 specs or Markdown reference docs.
-
-## Commands
-
-### `/prizmkit-api`-docs [api-directory]
-
-Generate API documentation from source code.
-
-**STEPS:**
-
-1. Read `.prizm-docs/` for project tech stack (framework, language, API style: REST / GraphQL / gRPC)
-2. Scan API source files (routes, controllers, handlers):
-   - Detect routing patterns based on framework:
-     - Express/Fastify: `app.get()`, `router.post()`, etc.
-     - Django/Flask: `@app.route()`, `urlpatterns`
-     - Spring: `@GetMapping`, `@PostMapping`, etc.
-     - Go: `http.HandleFunc`, gorilla/mux, chi routes
-   - If `api-directory` is specified, limit scan to that directory
-3. Extract for each endpoint:
-   - **HTTP method and path**: GET /api/users/:id
-   - **Request parameters**:
-     - Path parameters (with types)
-     - Query parameters (with types and defaults)
-     - Request body schema (from types, validation decorators, or inline definitions)
-   - **Response body schemas**: Success and error response structures
-   - **Authentication requirements**: Which auth mechanism is required (JWT, API key, session, none)
-   - **Error responses**: Common error codes and their meanings (400, 401, 403, 404, 500)
-   - **Description**: From JSDoc comments, docstrings, or function/handler names
-4. Generate documentation in requested format:
-   - **OpenAPI 3.0 YAML** (default): Full spec with schemas, security definitions, and server info
-   - **Markdown API reference**: Human-readable endpoint documentation
-   - **Both**: Generate both formats
-5. Include examples for each endpoint:
-   - Sample request (curl command)
-   - Sample success response (JSON)
-   - Sample error response (JSON)
-6. Write to `docs/api/` directory:
-   - `docs/api/openapi.yaml` for OpenAPI spec
-   - `docs/api/API_REFERENCE.md` for Markdown docs
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-api-doc-generator` placeholder for cross-IDE compatibility.
-
-## Output
-
-- `docs/api/openapi.yaml`: OpenAPI 3.0 specification
-- `docs/api/API_REFERENCE.md`: Markdown API reference

package/bundled/skills/prizmkit-tool-bug-reproducer/SKILL.md

@@ -1,61 +0,0 @@
----
-name: "prizmkit-tool-bug-reproducer"
-description: [Tier 1] Generate minimal reproduction scripts and test cases from bug descriptions. AI strength in test/script generation. (project)
----
-
-# PrizmKit Bug Reproducer
-
-Generate minimal reproduction scripts and test cases from bug descriptions to isolate, confirm, and verify fixes.
-
-## Commands
-
-### `/prizmkit-bug`-reproduce \<bug-description\>
-
-Generate a minimal reproduction for a reported bug.
-
-**STEPS:**
-
-1. Parse bug description: extract expected vs actual behavior, steps to reproduce (if given), environment details
-2. Read `.prizm-docs/` for relevant module context, paying special attention to TRAPS sections that may document known pitfalls
-3. Identify affected code path from description:
-   - Map user-facing behavior to source code modules
-   - Identify entry points and data flow
-4. Generate minimal reproduction based on bug type:
-   a. **For API bugs**: Generate curl/HTTP request sequence
-      - Include headers, authentication, request body
-      - Show expected vs actual response
-      - Add assertions on status code and response body
-   b. **For UI bugs**: Generate step-by-step user interaction guide
-      - Numbered steps with specific UI elements to interact with
-      - Screenshot annotation points (where to look)
-      - Browser/device requirements if relevant
-   c. **For logic bugs**: Generate unit test that demonstrates the failure
-      - Minimal test case with clear arrange/act/assert
-      - Test name describes the expected behavior
-      - Comments explaining why this should pass
-   d. **For data bugs**: Generate seed data + query sequence
-      - Minimal dataset that triggers the issue
-      - Query or operation sequence to reproduce
-      - Expected vs actual result comparison
-5. Write reproduction script/test to a temporary file:
-   - Use project's existing test framework and conventions
-   - Include setup and teardown
-   - Make it self-contained and runnable
-6. Include assertions that:
-   - FAIL with current (buggy) behavior
-   - PASS with expected (correct) behavior
-   - Serve as regression test after fix is applied
-7. Output:
-   - Reproduction file path
-   - Minimal steps document describing how to run
-   - Suggested fix investigation starting points
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-bug-reproducer` placeholder for cross-IDE compatibility.
-
-## Output
-
-- Reproduction script or test file written to project's test directory
-- Minimal steps document printed to console
-- Investigation pointers for the fix