prizmkit 1.1.99 → 1.1.101

package/bundled/dev-pipeline-windows/templates/sections/phase0-init.md

@@ -1,13 +0,0 @@
-### Phase 0: Project Bootstrap
-- Run `/prizmkit-init` (invoke the prizmkit-init skill)
-- Run `Invoke-PrizmPython {{INIT_SCRIPT_PATH}} --project-root {{PROJECT_ROOT}} --feature-id {{FEATURE_ID}} --feature-slug {{FEATURE_SLUG}}`
-- **CP-0**: Verify `.prizmkit/prizm-docs/root.prizm`, `.prizmkit/config.json` exist
-
-
-**Checkpoint update**: Run the update script to set step `prizmkit-init` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-init `
-  --status completed
-```

package/bundled/dev-pipeline-windows/templates/sections/phase0-test-baseline.md

@@ -1,21 +0,0 @@
-### Phase 0: Record Test Baseline & Detect Test Commands
-
-**Step 1 — Detect test commands**: You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS`.
-
-**Step 2 — Record pre-existing failure baseline**:
-```powershell
-# Run each test command, capture output
-& { {{TEST_CMD}} } 2>&1 | Tee-Object (Join-Path $env:TEMP "test-baseline.txt") | Select-Object -Last 20
-```
-Save the list of **pre-existing failing tests** (if any) as `BASELINE_FAILURES`. These are known failures that existed before this session — Dev must NOT be blamed for them, but must list them in COMPLETION_SIGNAL.
-
-> **Test Output Rule**: Always capture test output to a temp file (`Tee-Object (Join-Path $env:TEMP "test-out.txt")`). Then use Select-String on the file instead of re-running the suite.
-
-
-**Checkpoint update**: Run the update script to set step `test-baseline` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step test-baseline `
-  --status completed
-```

package/bundled/dev-pipeline-windows/templates/sections/session-context.md

@@ -1,5 +0,0 @@
-## Session Context
-
-- **Feature ID**: {{FEATURE_ID}} | **Session**: {{SESSION_ID}} | **Run**: {{RUN_ID}}
-- **Complexity**: {{COMPLEXITY}}
-- **Init**: {{INIT_DONE}} | Artifacts: spec={{HAS_SPEC}} plan={{HAS_PLAN}}

package/bundled/dev-pipeline-windows/templates/sections/subagent-timeout-recovery.md

@@ -1,6 +0,0 @@
-## Subagent Timeout Recovery
-
-If any agent times out:
-1. `Get-ChildItem -LiteralPath ".prizmkit/specs/{{FEATURE_SLUG}}/" -ErrorAction SilentlyContinue` — check what exists
-2. If `context-snapshot.md` exists: open recovery prompt with `"Read .prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md for project context and any Implementation Log/Review Notes from previous agents. Run git diff HEAD to see actual code changes already made. Do NOT re-read individual source files unless the File Manifest directs you to."` + only remaining steps + `model: "lite"`
-3. Max 2 retries per phase. After 2 failures, orchestrator completes the work directly and appends a Recovery Note to context-snapshot.md.

package/bundled/dev-pipeline-windows/templates/sections/task-contract.md

@@ -1,34 +0,0 @@
-## Task Contract
-
-This section defines the only work that belongs to this session.
-
-### Objective
-
-Implement {{FEATURE_ID}}: "{{FEATURE_TITLE}}".
-
-{{FEATURE_DESCRIPTION}}
-
-### Scope Rule
-
-Current scope is limited to the intersection of:
-
-1. The Objective above
-2. The Verification Gates below
-3. Dependencies required to complete those gates
-
-Raw user context, project brief, and completed dependency notes are authoritative context, but they do not expand scope by themselves.
-
-### Non-Scope Rule
-
-Do NOT implement unrelated backlog items, already completed features, or adjacent modules unless they are required by the Objective or a Verification Gate.
-
-### Verification Gates
-
-These gates are generated from `feature.acceptance_criteria` and are the only acceptance requirements for this session.
-
-{{AC_CHECKLIST}}
-
-Gate rule:
-- `[x]` means verified with implementation or test evidence.
-- Any remaining `[ ]` means the feature is incomplete.
-- If a gate is blocked, document the reason in `failure-log.md`; blocked is not success.

package/bundled/dev-pipeline-windows/templates/sections/test-failure-recovery-agent.md

@@ -1,48 +0,0 @@
-## Test Failure Recovery Protocol
-
-Use this protocol whenever implementation or review tests fail. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
-
-### Failure Classes
-
-| Class | Meaning | Required Action | May Continue? |
-|-------|---------|-----------------|---------------|
-| Baseline failure | Existed before this session | Document in Implementation Log or review notes | Yes |
-| New regression | Introduced by this session | Fix before reporting success | No |
-| Brittle test | Test expectation/setup is wrong for the intended behavior | Fix the test or environment setup, then rerun | Only after fixed or documented as blocked |
-| Environment/tooling failure | External tool, network, install, or local environment prevents verification | Document in `failure-log.md` with impact on gates | Only if no Verification Gate is blocked |
-
-### Recovery Loop
-
-1. Run tests and record: failing test names, failure count, and class for each failure.
-2. Compare with `BASELINE_FAILURES`; never blame baseline failures on this feature.
-3. Fix new regressions and brittle tests while progress is being made.
-4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
-5. If failures decrease, reset the plateau counter.
-
-### Success Rule
-
-Proceed to review only when:
-
-1. all new regressions are fixed;
-2. baseline failures are documented;
-3. every Verification Gate is verified.
-
-Blocked gates are not success. If any gate cannot be verified, follow the Blocked Rule.
-
-### Blocked Rule
-
-If a remaining failure prevents any Verification Gate from being verified, the feature is incomplete. Write `failure-log.md` and do not report success.
-
-### Failure Capture Format
-
-```markdown
-## Test Failures Encountered
-
-- **Test**: [test name/path]
-  - Root Cause: [explanation]
-  - Category: [baseline failure | new regression | brittle test | environment/tooling]
-  - Rounds Attempted: [N rounds, plateau at round M]
-  - Status: [fixed | still failing | blocked]
-
-- **Impact on Verification Gates**: [verified | not affected | blocked + reason]
-```

package/bundled/dev-pipeline-windows/templates/sections/test-failure-recovery-lite.md

@@ -1,48 +0,0 @@
-## Test Failure Recovery Protocol
-
-Use this protocol whenever implementation tests fail. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
-
-### Failure Classes
-
-| Class | Meaning | Required Action | May Continue? |
-|-------|---------|-----------------|---------------|
-| Baseline failure | Existed before this session | Document in Implementation Log | Yes |
-| New regression | Introduced by this session | Fix before reporting success | No |
-| Brittle test | Test expectation/setup is wrong for the intended behavior | Fix the test or environment setup, then rerun | Only after fixed or documented as blocked |
-| Environment/tooling failure | External tool, network, install, or local environment prevents verification | Document in `failure-log.md` with impact on gates | Only if no Verification Gate is blocked |
-
-### Recovery Loop
-
-1. Run tests and record: failing test names, failure count, and class for each failure.
-2. Compare with `BASELINE_FAILURES`; never blame baseline failures on this feature.
-3. Fix new regressions and brittle tests while progress is being made.
-4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
-5. If failures decrease, reset the plateau counter.
-
-### Success Rule
-
-Proceed only when:
-
-1. all new regressions are fixed;
-2. baseline failures are documented;
-3. every Verification Gate is verified.
-
-Blocked gates are not success. If any gate cannot be verified, follow the Blocked Rule.
-
-### Blocked Rule
-
-If a remaining failure prevents any Verification Gate from being verified, the feature is incomplete. Write `failure-log.md` and do not report success.
-
-### Failure Capture Format
-
-```markdown
-## Test Failures Encountered
-
-- **Test**: [test name/path]
-  - Root Cause: [explanation]
-  - Category: [baseline failure | new regression | brittle test | environment/tooling]
-  - Rounds Attempted: [N rounds, plateau at round M]
-  - Status: [fixed | still failing | blocked]
-
-- **Impact on Verification Gates**: [verified | not affected | blocked + reason]
-```

package/bundled/dev-pipeline-windows/templates/session-status-schema.json

@@ -1,83 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Dev-Pipeline Session Status",
-  "description": "Schema for session-status.json written by agent at session end",
-  "type": "object",
-  "required": ["session_id", "feature_id", "status", "timestamp"],
-  "properties": {
-    "session_id": {
-      "type": "string",
-      "minLength": 1
-    },
-    "feature_id": {
-      "type": "string",
-      "pattern": "^F-\\d{3}(-[A-Z])?$"
-    },
-    "status": {
-      "type": "string",
-      "enum": ["success", "partial", "failed", "commit_missing", "docs_missing", "merge_conflict"]
-    },
-    "completed_phases": {
-      "type": "array",
-      "items": {
-        "type": "integer",
-        "minimum": 0,
-        "maximum": 7
-      }
-    },
-    "current_phase": {
-      "type": "integer",
-      "minimum": 0,
-      "maximum": 7
-    },
-    "checkpoint_reached": {
-      "type": "string",
-      "pattern": "^CP-[0-3]$"
-    },
-    "tasks_completed": {
-      "type": "integer",
-      "minimum": 0
-    },
-    "tasks_total": {
-      "type": "integer",
-      "minimum": 0
-    },
-    "errors": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["message"],
-        "properties": {
-          "phase": { "type": "integer" },
-          "type": { "type": "string" },
-          "message": { "type": "string" },
-          "recoverable": { "type": "boolean" }
-        }
-      }
-    },
-    "can_resume": {
-      "type": "boolean"
-    },
-    "docs_maintained": {
-      "type": "boolean"
-    },
-    "retrospective_done": {
-      "type": "boolean"
-    },
-    "resume_from_phase": {
-      "type": ["integer", "null"]
-    },
-    "artifacts": {
-      "type": "object",
-      "properties": {
-        "spec_path": { "type": "string" },
-        "plan_path": { "type": "string" },
-        "context_snapshot_path": { "type": "string" }
-      }
-    },
-    "timestamp": {
-      "type": "string",
-      "format": "date-time"
-    }
-  }
-}

package/bundled/skills-windows/app-planner/SKILL.md

@@ -1,296 +0,0 @@
----
-name: "app-planner"
-description: "Plan an application through interactive conversation — capture vision, tech stack, constraints, dev rules, and project brief. Works for both new (greenfield) and existing (brownfield) projects that need app-level planning. Also use for configuring per-layer development rules (frontend/backend/database/mobile) that AI coding assistants should follow. Use this skill when users say 'plan an app', 'design a new project', 'start from scratch', 'build a new application', 'set up dev rules', 'configure frontend rules', 'configure backend rules', or discuss app-level architecture and design. Also use for existing projects that need a project brief or app-level context. For adding features to existing projects that already have a project brief, use feature-planner instead."
----
-
-# app planner
-
-Plan an application from idea to actionable project context through interactive conversation. Works for both **greenfield** (new) and **brownfield** (existing) projects:
-- Vision and problem statement
-- Tech stack selection (or confirmation of existing stack)
-- Constraints and design direction
-- Architecture decision capture
-- Project brief accumulation (`.prizmkit/plans/project-brief.md`)
-
-This skill captures **project-level context only**: vision, tech stack, conventions, architecture decisions, and project brief. It does not do feature decomposition. (See **Scope Boundary** for the authoritative output rules.)
-
-For adding features to an **existing** project that already has a project brief, use `feature-planner` directly.
-
-## Invocation Commitment (Hard Rule)
- You must NEVER:
-- Bypass the interactive phases because you judge the task to be "simple"
-
-If you believe the task is better suited for a different workflow, you MUST:
-1. **Explain why** you think a different path is more appropriate
-2. **Ask the user explicitly** whether they want to switch
-3. **Only switch if the user confirms**
-
-## Scope Boundary (Hard Rule)
-
-**This skill is PLANNING ONLY.** You must NEVER:
-- Create, modify, or delete source code files (*.js, *.ts, *.py, *.go, *.html, *.css, etc.)
-- Create project scaffolding, directories, or boilerplate (exception: `.prizmkit/rules/` and `.prizmkit/prizm-docs/` directories may be created for dev rules and root.prizm output)
-- Run build/install/test commands (npm init, pip install, etc.)
-- Execute any implementation action beyond writing planning artifacts
-
-**Your ONLY writable outputs are:**
-1. `.prizmkit/plans/project-brief.md` (`.prizmkit/plans/` — accumulated project context brief)
-2. Project conventions and architecture decisions appended to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
-3. Infrastructure configuration (database conventions, deployment config, **cloud services**) appended to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section
-4. `.prizmkit/rules/<layer>-rules.md` — per-layer development rules generated by Rules Configuration
-5. `.prizmkit/prizm-docs/root.prizm` — `RULES:` pointer line only (not other root.prizm content; created minimally if absent)
-
-**Project instruction file selection**:
-- If `.prizmkit/manifest.json` exists, use its `platform` field as the source of truth.
-- Codex → `AGENTS.md`
-- Claude Code → `CLAUDE.md`
-- CodeBuddy → `CODEBUDDY.md`
-- `all` → all three files. Legacy manifests may contain `both`; treat it as read-only compatibility and update `CLAUDE.md` and `CODEBUDDY.md` only when encountered.
-- Only when the manifest is missing, fall back to installed PrizmKit-owned platform files such as `.codex/agents/*.toml`, `.claude/commands/prizm-kit.md`, or `.codebuddy/skills/prizm-kit/SKILL.md`. Do not treat a generic `.agents/` directory as Codex.
-
-**After planning is complete**, you MUST:
-1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
-2. List the artifacts produced and suggest possible next steps (e.g., `feature-planner`, `prizmkit-plan`, etc.) — but do NOT auto-invoke any of them
-3. **NEVER auto-execute** the pipeline, feature-planner, or any implementation step
-4. **NEVER generate `feature-list.json`** — that is exclusively `feature-planner`'s responsibility
-
-## When to Use
-
-The skill `description` lists the trigger phrases. Beyond those, use this section to disambiguate from `feature-planner` and other workflows.
-
-Do NOT use this skill when:
-- The user already has a project brief and wants to add features → use `feature-planner`
-- The user wants to run the pipeline → use `feature-pipeline-launcher`
-- The user is debugging/refactoring or wants to write source code directly
-
-## Resource Loading Rules (Mandatory)
-
-1. **App design reference** — always load at session start:
-   - Read `${SKILL_DIR}/assets/app-design-guide.md` for vision templates and tech stack matrix
-
-2. **Load on-demand references when triggered**:
-   - Architecture decisions emerged → read `${SKILL_DIR}/references/architecture-decisions.md`
-   - Frontend/UI project detected → read `${SKILL_DIR}/references/frontend-design-guide.md`
-   - User wants to explore ideas before committing → read `${SKILL_DIR}/references/brainstorm-guide.md`
-   - During brainstorm Phase C → also read `${SKILL_DIR}/references/red-team-checklist.md`
-
-3. **Project conventions discovery** — after Intent Confirmation, before brainstorm or vision work:
-   → Read `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` and check for `### Project Conventions` section
-   → If section exists and covers the project well → skip silently
-   → If section is missing or incomplete → run the **AI-driven convention discovery** below:
-
-   **Do NOT follow any fixed checklist.** Every project is different. You must analyze the project first, then reason about what system-level conventions this specific project needs.
-
-   → Read `${SKILL_DIR}/references/project-conventions-discovery.md` for the full AI-driven discovery procedure (Analyze → Reason → Present via AskUserQuestion).
-
-   → Save answers to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
-   → Output format will naturally vary per project — that is the intended behavior
-
-   **Infrastructure Convention Discovery (Database + Deployment)**
-
-   After project conventions are captured, check the project instruction file for `### Infrastructure` section status. Read `${SKILL_DIR}/references/infrastructure-convention-discovery.md` for the full database (6 topics — table naming, field naming, migrations, primary keys, indexes, environment separation), deployment (4 topics — target refinement, existing infrastructure, AI-assisted deploy, env var management), and cloud services (2-round AskUserQuestion) inquiry procedures. Follow the inquiry flow there — use `AskUserQuestion` for each batch. Each question MUST include a "Skip — decide later" option.
-
-   After inquiry, update the `### Infrastructure` section in the project instruction file with all collected information (see reference file for full output format). Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` for `prizmkit-deploy` to pick up later.
-
-4. **Project brief accumulation** — throughout all interactive phases:
-   → Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
-   → Update after each meaningful user response containing business intent, constraints, or design decisions
-
-## Rules Configuration (after Infrastructure)
-
-After Infrastructure configuration is complete (CP-AP-1.5), check whether the project's development layers have custom rules configured. Rules are per-layer documents (frontend-rules.md, backend-rules.md, database-rules.md, mobile-rules.md) that tell AI coding assistants how to generate code for that layer — UI framework, state management, naming conventions, etc.
-
-Rules are optional. If the user skips, AI uses general best practices freely — no reminders, no blocking.
-
-→ Read `${SKILL_DIR}/references/rules-configuration.md` for the full procedure: layer detection, configuration mode selection, interactive Q&A per layer, template rendering, and root.prizm RULES pointer update.
-
-### After rules configuration
-
-Proceed to Prerequisites and continue the app-planner workflow.
-
-## Prerequisites
-
-Before questions, check optional context files (never block if absent):
-- `.prizmkit/prizm-docs/root.prizm` (architecture/project context)
-- `.prizmkit/config.json` (existing stack preferences and detected tech stack)
-- `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions` section (previously answered project conventions)
-- `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section (database and deployment config from prizmkit-init or previous app-planner run)
-
-**Tech stack auto-population from config.json:**
-- If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill tech assumptions.
-- Map config fields: `language`, `runtime`, `frontend_framework`, `frontend_styling`, `backend_framework`, `database`, `orm`, `testing`, `bundler`, `project_type`.
-- Do NOT re-ask for tech stack info already in config.json. Show the detected stack and ask: "Is this correct? Any changes?"
-- If config.json has no `tech_stack`, fall back to asking during Phase 2.
-
-Note:
-- This skill **reads** `.prizmkit/config.json` if present.
-- This skill does **not** create `.prizmkit/config.json` directly.
-- Creation/update is handled by bootstrap/init flows (e.g., `prizmkit-init`, `.prizmkit/dev-pipeline/scripts/init-dev-team.py`).
-
-## Interaction Style (Hard Rule)
-
-**ALL decision points MUST use the `AskUserQuestion` tool** to present interactive, selectable options. Do NOT render options as plain text (e.g., `[A] option [B] option`) — the user must be able to click/select, not type a letter.
-
-This applies to:
-- Intent confirmation
-- Project conventions
-- Tech stack selection
-- Architecture decisions
-- Session exit gates
-- Brownfield prerequisite check
-- Any other decision point
-
-**How to use `AskUserQuestion`:**
-- Each decision point → one `AskUserQuestion` call with 1-4 questions. Use multiple calls as needed — there is NO limit on total rounds for project-level convention discovery. Keep going until everything is covered.
-- Each question has 2-4 selectable options (the tool auto-adds "Other" for custom input)
-- Use `multiSelect: true` when the user can pick more than one
-- Mark the recommended option first and append "(Recommended)" to its label
-- Use the `description` field to explain trade-offs or implications
-- **Every non-essential question MUST include a "Skip" option** (e.g., "Skip — decide later"). Users should never be forced to answer something they want to defer. Skipped items are simply not written to conventions — they can be added in a future session.
-
-**What can be skipped vs. what cannot:**
-- **Cannot skip**: Intent confirmation (must know the session goal)
-- **Everything else can be skipped**: conventions, tech stack choices, architecture decisions, design direction, etc. If the user skips, move on — do not re-ask or block progress.
-
-**When gathering open-ended information** (e.g., "describe your app idea"), use regular text questions — but follow up with `AskUserQuestion`-based clarifications wherever possible.
-
-## Intent Confirmation (Mandatory First Step)
-
-After initial greeting, use `AskUserQuestion` to confirm intent:
-
-**Question**: "What would you like to do?"
-- **Explore ideas first (Recommended)** — brainstorm and refine ideas before committing to a plan
-- **Produce a project plan** — define vision, tech stack, and constraints → generates project-brief.md for pipeline use
-- **Generate project context only** — for an existing project that needs a project brief without full planning
-
-Route by answer:
-- **Produce a project plan** → Continue to Core Workflow. Set session goal = `produce`.
-- **Explore ideas first** → Enter **Exploration Mode**:
-  - Run project conventions check first
-  - Load `${SKILL_DIR}/references/brainstorm-guide.md` and follow its structured ideation process (Phases A-D)
-  - Brainstorm Phase D output serves as the Vision Summary (CP-AP-2)
-  - After brainstorm completes, use `AskUserQuestion`: "Ideas are taking shape. What's next?"
-    - **Continue to project planning (Recommended)** — capture tech stack, conventions, and architecture decisions
-    - **Continue refining** — keep brainstorming
-    - **Save draft & exit** — save progress to .prizmkit/planning/
-  - **Checkpoints in explore mode**: CP-AP-0 (required), CP-AP-1 (required), CP-AP-2 (from brainstorm output), CP-AP-3 (only if user proceeds to Phase 2), CP-AP-4 and CP-AP-5 (only if user transitions to produce mode)
-- **Generate project context only** → Enter **Quick Context Mode** (brownfield only):
-  - Run Project State Detection → if greenfield, redirect to produce mode
-  - Proactively scan the project (same as brownfield behavior)
-  - Generate project-brief.md from inferred context
-  - Skip extensive brainstorming and constraint phases
-  - Present brief for user confirmation → write → done
-
-Session goal tracking: Track the intent (`produce`, `explore`, or `quick_context`) throughout the session. If `explore`, always re-prompt before ending.
-
-## Project State Detection (after Intent Confirmation)
-
-Detect whether this is a **greenfield** (new) or **brownfield** (existing) project and adapt the workflow accordingly.
-
-### Detection Signals
-
-| Signal | Greenfield | Brownfield |
-|--------|-----------|------------|
-| `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / `pom.xml` | absent | present |
-| `src/` or `app/` directory with source files | absent | present |
-| `.git` with commit history | absent or initial commit only | present with history |
-| Empty or near-empty directory | yes | no |
-
-### Greenfield Behavior (default)
-
-Proceed with the standard Core Workflow — ask all questions from scratch.
-
-### Brownfield Behavior
-
-When an existing project is detected, read `${SKILL_DIR}/references/project-state-detection.md` for the full 4-step brownfield procedure:
-
-- **Step 1**: Prerequisite check — verify `.prizmkit/prizm-docs/root.prizm`, `.prizmkit/config.json`, `.prizmkit/plans/project-brief.md` exist. If missing, offer to run `prizmkit-init` first.
-- **Step 2**: Proactive scanning — read codebase structure, metadata files, and key source files yourself
-- **Step 3**: Present inferred summary and confirm with `AskUserQuestion`
-- **Step 4**: Pre-fill known information, focus questions on what cannot be inferred
-
-## Core Workflow
-
-Execute the planning workflow in conversation mode with mandatory checkpoints:
-
-### Interactive Phases
-1. Clarify business goal and scope
-   1.1 Confirm deliverable intent (→ Intent Confirmation — option-based)
-   1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, use option-based questions where possible. When common patterns exist, present them as choices. Only use open-ended questions for truly unique input (e.g., "describe your app idea"). Follow up with option-based clarifications.
-2. Confirm constraints and tech assumptions
-   2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix. Use `AskUserQuestion` for each major tech decision (framework, database, styling, etc.)
-   2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, use `AskUserQuestion`:
-       - Question: "No UI/UX design docs found. Would you like to establish design direction?"
-       - Options: "Establish design direction now (Recommended)", "Skip for now", "I have external designs"
-3. Capture architecture decisions and finalize project brief
-4. Present completion summary with artifacts produced and possible next steps
-
-### Checkpoints (Mandatory Gates)
-
-Checkpoints catch cascading errors early — skipping one means the next phase builds on unvalidated assumptions.
-
-| Checkpoint | Artifact/State | Criteria | Phase |
-|-----------|----------------|----------|-------|
-| **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
-| **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `### Project Conventions` section in `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` up to date | 1 |
-| **CP-AP-1.5** | Infrastructure Checked | Infrastructure config loaded or asked; `### Infrastructure` section in `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` addressed — database, deployment **and cloud services** each configured or explicitly deferred | 1-2 |
-| **CP-AP-1.6** | Rules Configured | For each detected layer (from config.json or self-detection), rules file exists in `.prizmkit/rules/` or user explicitly skipped. `root.prizm` `RULES:` pointer up-to-date. | 2 |
-| **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user. For brownfield: existing purpose confirmed or refined. | 1-2 |
-| **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing. **Auto-pass** for backend-only or non-UI projects. | 2 |
-| **CP-AP-4** | Project Brief Accumulated | `.prizmkit/plans/project-brief.md` exists at `.prizmkit/plans/` with at least 3 ideas listed. For brownfield: already-implemented items marked `[x]` count toward this total. | 3 |
-| **CP-AP-5** | Planning Complete | All project-level context captured: conventions, infrastructure config, tech stack, architecture decisions, project brief finalized | 4 |
-
-## Architecture Decision Capture
-
-After Phase 2, if framework-shaping architecture decisions emerged during planning (tech stack, communication patterns, data model strategies — not individual feature details), read `${SKILL_DIR}/references/architecture-decisions.md` and follow the capture flow. Most sessions will NOT produce architecture decisions — only capture when genuinely impactful.
-
-**How it works**:
-1. If decisions are captured → append to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` under `### Architecture Decisions` section
-2. Downstream skills (feature-planner, prizmkit-plan, etc.) read `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` as standard context, so they automatically receive these decisions
-3. Do NOT write architecture decision content directly to `.prizmkit/prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. (The `RULES:` pointer line is managed by Rules Configuration, not by this section.) If the project needs `.prizmkit/prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
-
-## Project Brief Accumulation
-
-During interactive planning, maintain a `.prizmkit/plans/project-brief.md` at `.prizmkit/plans/` as a simple checklist of product ideas.
-
-→ Read `${SKILL_DIR}/references/project-brief-guide.md` for full format and rules.
-
-## Session Exit Gate
-
-Prevent accidental session exit without completing the planning artifacts.
-
-### Trigger Conditions
-
-Activate when ALL true:
-- Session goal = `produce`
-- `.prizmkit/plans/project-brief.md` has not been written or is incomplete (fewer than 3 ideas listed)
-
-### Gate Behavior
-
-When the session appears to be ending:
-1. **Remind**: "You set out to produce a project plan but `.prizmkit/plans/project-brief.md` isn't complete yet."
-2. Use `AskUserQuestion`: "How would you like to proceed?"
-   - **Continue to completion (Recommended)** — finish the project brief
-   - **Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
-   - **Abandon** — exit without saving
-
-## Completion Summary
-
-After all checkpoints pass, present a summary and end the session:
-
-1. **Summary** (as text): List all project-level artifacts produced:
-   - Project conventions → `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions`
-   - Infrastructure config → `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` (database conventions + deployment config)
-   - Tech stack → `.prizmkit/config.json`
-   - Architecture decisions (if any) → `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Architecture Decisions`
-   - Dev rules (if configured) → `.prizmkit/rules/<layer>-rules.md` (with `root.prizm` `RULES:` pointer)
-   - Project brief → `.prizmkit/plans/project-brief.md`
-
-2. **Suggest possible next steps** (as text, NOT auto-invoked):
-   > Project-level planning is complete. When you're ready, here are some possible next steps:
-   > - `feature-planner` — decompose the project into features and generate `feature-list.json`
-   > - `prizmkit-plan` — start working on a specific feature directly
-   > - `prizmkit-prizm-docs` — initialize or update project documentation
-   > - `prizmkit-deploy` — supplement infrastructure config or execute deployment (if AI-assisted deploy was configured)
-
-   **Do NOT invoke any of these.** The user decides what to do next, in their own time.