prizmkit 1.1.100 → 1.1.102

package/bundled/skills-windows/app-planner/assets/app-design-guide.md

@@ -1,101 +0,0 @@
-# App Design Reference Guide
-
-This guide provides structured templates, decision matrices, and decomposition patterns for new application planning. Use during the vision and architecture phases of app-planner sessions.
-
----
-
-## 1. App Vision Template
-
-Use this template to capture the app vision during the initial planning phase.
-
-```markdown
-# App Vision: [APP_NAME]
-
-## Problem Statement
-[What problem does this app solve?]
-
-## Target Users
-- Primary: [Who are the main users?]
-- Secondary: [Any secondary user types?]
-
-## Core Value Proposition
-[What makes this app valuable? What's the "elevator pitch"?]
-
-## Key Differentiators
-[What sets this apart from existing solutions?]
-```
-
-### Guidance
-
-- **Problem Statement**: Should describe a real pain point in 1-3 sentences. Avoid vague statements like "improve productivity." Be specific about who suffers and why.
-- **Target Users**: Identify at least one primary user persona. Secondary users are optional but useful for prioritization decisions later.
-- **Core Value Proposition**: Should be expressible in one sentence. If it takes a paragraph, the scope is likely too broad.
-- **Key Differentiators**: List 1-3 concrete differentiators. If none exist, reconsider whether the app needs to be built.
-
----
-
-## 2. Tech Stack Decision Matrix
-
-Use these tables to guide tech stack selection based on project requirements.
-
-### Frontend Frameworks
-
-| Framework | Best For | Ecosystem |
-|-----------|----------|-----------|
-| Next.js | Full-stack React, SSR, API routes | React ecosystem, Vercel |
-| Nuxt 3 | Full-stack Vue, SSR | Vue ecosystem |
-| SvelteKit | Performance-focused, smaller teams | Svelte ecosystem |
-| Remix | Nested routes, data loading | React ecosystem |
-
-### Backend Frameworks
-
-| Framework | Best For | Language |
-|-----------|----------|----------|
-| Express.js | Flexible, minimal | Node.js/TS |
-| FastAPI | High-perf APIs, Python ML | Python |
-| NestJS | Enterprise, structured | Node.js/TS |
-| Django | Batteries-included, admin | Python |
-| Go (Gin/Echo) | High concurrency | Go |
-
-### Databases
-
-| Database | Best For | Type |
-|----------|----------|------|
-| PostgreSQL | Complex queries, ACID | Relational |
-| MySQL | Read-heavy, simple | Relational |
-| MongoDB | Flexible schema, documents | Document |
-| SQLite | Embedded, prototyping | Relational |
-| Redis | Caching, sessions, pub/sub | Key-Value |
-
-### Design Systems
-
-| System | Best For | Framework |
-|--------|----------|-----------|
-| shadcn/ui | Modern, customizable | React/Next.js |
-| Ant Design | Enterprise, data-heavy | React |
-| Material UI | Google-style, full-featured | React |
-| Vuetify | Material Design for Vue | Vue |
-| Tailwind CSS | Utility-first, any framework | Any |
-
-### Common Service Patterns
-
-| Need | Options |
-|------|---------|
-| Auth | NextAuth.js, Auth0, Clerk, Supabase Auth, custom JWT |
-| Real-time | WebSocket, Socket.io, SSE, Supabase Realtime |
-| File Storage | S3, Cloudflare R2, Supabase Storage |
-| Email | SendGrid, Resend, Postmark |
-| Payments | Stripe, LemonSqueezy |
-| Search | Algolia, Meilisearch, Elasticsearch |
-
-### Selection Heuristics
-
-- If the user has no strong preference, default to **Next.js + PostgreSQL + shadcn/ui + Tailwind CSS** as a general-purpose stack.
-- If the project involves ML/AI backends, prefer **FastAPI** on the backend.
-- If the project requires high concurrency with minimal resource usage, consider **Go**.
-- If rapid prototyping is the goal, consider **SQLite** initially with a migration path to PostgreSQL.
-- Always ask about deployment preferences (Vercel, AWS, self-hosted) as this influences framework choice.
-
-
-
-> **Note**: Feature decomposition patterns (CRUD, SaaS, Social, E-commerce) have been moved to `feature-planner/references/decomposition-patterns.md`. Load that reference during feature decomposition phase.

package/bundled/skills-windows/app-planner/references/architecture-decisions.md

@@ -1,52 +0,0 @@
-# Architecture Decision Capture
-
-During planning, key **framework-level** architectural decisions may emerge. When they do, capture them in the project instruction file so all future AI sessions have this context.
-
-## What Qualifies (ALL must apply)
-
-Only capture decisions that are **framework-shaping** — NOT individual feature details. Qualifying categories:
-
-| Category | Examples |
-|----------|----------|
-| Tech stack choices | PostgreSQL over MongoDB, React over Vue, Node.js runtime |
-| Communication patterns | REST vs GraphQL, WebSocket vs SSE vs polling |
-| Architectural patterns | Monorepo, microservices, monolith, event-driven |
-| Data model strategies | Relational vs document, event sourcing, CQRS |
-| Security architecture | JWT vs session, OAuth provider, RBAC model |
-
-**Do NOT capture**: individual feature implementation details, UI component choices, specific API endpoint designs, or anything scoped to a single feature.
-
-**This is conditional** — most planning sessions will NOT produce architecture decisions. Only capture when genuinely impactful decisions are made during the discussion.
-
-## When to Capture
-
-After Phase 2 (Confirm constraints and tech assumptions), before Phase 3 (Capture architecture decisions and finalize project brief). At this point decisions are settled.
-
-## How to Capture
-
-1. **Detect platform** — determine which project instruction file to update:
-   - If `.prizmkit/manifest.json` exists, read `platform` and use it as the source of truth.
-   - `codex` → append to `AGENTS.md`
-   - `claude` → append to `CLAUDE.md`
-   - `codebuddy` → append to `CODEBUDDY.md`
-   - `all` → append to all three files. Legacy manifests may contain `both`; treat it as read-only compatibility and append to `CLAUDE.md` and `CODEBUDDY.md` only when encountered.
-   - Only when the manifest is missing, fall back to PrizmKit-owned install artifacts: `.codex/agents/*.toml`, `.claude/commands/prizm-kit.md`, `.codebuddy/skills/prizm-kit/SKILL.md`.
-   - Do not treat a generic `.agents/` directory as Codex; it may contain unrelated third-party skills.
-   - If no platform can be determined, skip (no project instruction file).
-
-2. **Check for existing section** — read the target file and look for `### Architecture Decisions` heading:
-   - If heading exists → append new entries below it (avoid duplicates with existing entries)
-   - If heading does not exist → create it at the end of the file
-
-3. **Format** — one line per decision, no feature IDs:
-   ```markdown
-   ### Architecture Decisions
-   - WebSocket for real-time: sub-second latency required for collaboration features
-   - PostgreSQL: relational data model with complex queries, ACID compliance needed
-   - Monorepo structure: shared types between frontend and backend
-   ```
-
-4. **User confirmation** — before writing, show the collected decisions and ask:
-   > "These architecture decisions were identified during planning. Record them to [AGENTS.md / CLAUDE.md / CODEBUDDY.md]? (Y/n)"
-
-   If user declines, skip without further prompting.

package/bundled/skills-windows/app-planner/references/brainstorm-guide.md

@@ -1,101 +0,0 @@
-# Brainstorm Guide — Structured Ideation Before Implementation
-
-> Separate WHAT from HOW. Explore the problem space before committing to a solution.
-
-This guide provides the structured brainstorming framework used in Phase 1 of the workflow.
-The AI facilitates this process as a **design collaborator**, not a builder.
-
-## Four Phases
-
-### Phase A: Assess Clarity
-
-Evaluate the user's initial goal statement:
-
-- **Clear** — Specific and actionable (e.g., "add JWT auth to the API")
-- **Vague** — Direction exists but needs narrowing (e.g., "improve security")
-- **Exploring** — No firm goal yet, just a direction (e.g., "something with auth")
-
-If **vague** or **exploring**, ask follow-up questions to sharpen the goal.
-Do NOT proceed until there is a concrete, testable problem statement (one sentence).
-
-### Phase B: Understand the Idea
-
-Answer these questions (use codebase exploration as needed):
-
-1. **What problem does this solve?** — State the pain point in concrete terms.
-2. **Who benefits?** — End users, developers, operators?
-3. **What exists today?** — Current state, prior art in the codebase, adjacent systems.
-4. **What constraints matter?** — Performance, compatibility, security, timeline.
-
-Non-functional requirements to explicitly clarify or propose defaults for:
-- Performance expectations
-- Scale (users, data, traffic)
-- Security or privacy constraints
-- Reliability / availability needs
-- Maintenance and ownership expectations
-
-If the user is unsure on any point, propose reasonable defaults and clearly mark them as **assumptions**.
-
-Summarize findings before moving on. If anything is unclear, ask.
-
-### Phase C: Explore Approaches
-
-Generate **2-3 distinct approaches**. For each:
-
-- **Name** — Short label (e.g., "JWT middleware", "OAuth proxy")
-- **How it works** — 2-3 sentences
-- **Pros** — What it gets right
-- **Cons** — What it gets wrong or defers
-- **Effort** — Rough scope (small / medium / large)
-
-#### Adversarial Critique (Red Team)
-
-Before asking the user to choose, stress-test each approach using the red team checklist
-(`references/red-team-checklist.md`):
-
-1. What breaks first?
-2. What's the hidden cost?
-3. What assumption is wrong?
-4. Who disagrees?
-
-Mark any approach that fails 2+ red team questions as **HIGH RISK**.
-If all approaches fail, generate a hybrid addressing the weaknesses.
-
-Present the comparison and let the user pick an approach or request a hybrid.
-
-### Phase D: Capture Design
-
-Produce a structured summary:
-
-```markdown
-## Problem Statement
-[One sentence, testable]
-
-## Approaches Considered
-[2-3 approaches with pros/cons/effort]
-
-## Selected Approach
-[User's choice + rationale]
-
-## Assumptions
-[All assumptions explicitly listed]
-
-## Open Questions
-[Unresolved items, if any]
-
-## Key Decisions
-[What was decided and why — alternatives and rationale]
-```
-
-This summary becomes the input for the next phase (specification or planning).
-
----
-
-## Rules
-
-- Ask as many questions as needed — no rushing
-- One topic at a time for complex clarifications
-- Prefer multiple-choice questions when possible
-- Assumptions must be explicit, never silent
-- YAGNI ruthlessly — avoid premature complexity
-- Do NOT implement, code, or modify behavior during brainstorming

package/bundled/skills-windows/app-planner/references/frontend-design-guide.md

@@ -1,71 +0,0 @@
-# Frontend Design Guide — High-Quality UI Implementation
-
-> Create distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics.
-
-**app-planner context**: In the planning phase, use this guide to establish **design direction decisions** (aesthetic tone, typography approach, color strategy, layout philosophy). Do NOT produce CSS, code, or implementation artifacts — capture the design direction as decisions in the project instruction file (`AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md`). Downstream implementation skills will consume these decisions when building features.
-
-Load this guide **only when the feature involves frontend/UI work**. Skip for backend-only or infrastructure features.
-
-## Context Gathering (Required Before Design)
-
-Before any UI design work, gather:
-- **Target audience**: Who uses this product and in what context?
-- **Use cases**: What jobs are they trying to get done?
-- **Brand personality/tone**: How should the interface feel?
-
-You cannot infer this from codebase alone — ask the user.
-
-## Design Direction
-
-Commit to a **bold** aesthetic direction:
-- **Purpose**: What problem does this interface solve? Who uses it?
-- **Tone**: Pick an intentional aesthetic — minimalist, editorial, brutalist, organic, luxury, playful, retro-futuristic, industrial, art deco, etc.
-- **Differentiation**: What makes this unforgettable?
-
-## Typography
-
-- Choose distinctive fonts. Pair a display font with a refined body font.
-- Use a modular type scale with fluid sizing (`clamp()`)
-- Vary font weights and sizes for clear visual hierarchy
-- Avoid overused fonts: Inter, Roboto, Arial, Open Sans, system defaults
-- Avoid monospace as lazy shorthand for "technical" vibes
-
-## Color & Theme
-
-- Use modern CSS color functions (oklch, color-mix, light-dark)
-- Tint neutrals toward brand hue for subconscious cohesion
-- Avoid: pure black (#000) or pure white (#fff) — always tint
-- Avoid: the AI palette (cyan-on-dark, purple-to-blue gradients, neon accents on dark)
-- Avoid: gradient text for "impact", default dark mode with glowing accents
-
-## Layout & Space
-
-- Create visual rhythm through varied spacing — not uniform padding
-- Use fluid spacing with `clamp()` that breathes on larger screens
-- Embrace asymmetry and unexpected compositions
-- Avoid: wrapping everything in cards, nesting cards, identical card grids
-- Avoid: centering everything, uniform spacing
-
-## Motion
-
-- Focus on high-impact moments: one well-orchestrated page load > scattered micro-interactions
-- Use exponential easing for natural deceleration
-- Use `transform` and `opacity` only — avoid animating layout properties
-- Avoid: bounce/elastic easing, excessive animations
-
-## Interaction
-
-- Use progressive disclosure — start simple, reveal complexity through interaction
-- Design empty states that teach the interface
-- Use optimistic UI — update immediately, sync later
-- Avoid: making every button primary, redundant headers
-
-## Responsive
-
-- Use container queries (`@container`) for component-level responsiveness
-- Adapt the interface for different contexts, don't just shrink it
-- Never hide critical functionality on mobile
-
-## The AI Slop Test
-
-If you showed this interface to someone and said "AI made this", would they believe you immediately? If yes, redesign. A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

package/bundled/skills-windows/app-planner/references/infrastructure-convention-discovery.md

@@ -1,108 +0,0 @@
-# Infrastructure Convention Discovery
-
-Detailed Q&A flows for database, deployment, and cloud services conventions during app planning.
-
-## Infrastructure Section Check
-
-Check `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` for `### Infrastructure` section:
-
-- If `### Infrastructure` section does not exist → this project was not initialized with prizmkit-init's Phase 4.6. Treat as if both database and deployment are undecided — run full inquiry below.
-- If `<!-- infrastructure: deferred -->` → user explicitly skipped at init time. Ask: "During project init you deferred infrastructure decisions. Would you like to configure them now?" (options: "Yes — configure now (Recommended)", "Skip — decide later")
-- If `<!-- database: deferred -->` → only database was deferred, run database inquiry only
-- If `<!-- deployment: deferred -->` or deployment section is missing → run deployment inquiry only
-- If both sections exist with real values → read existing config, present as "Already decided", ask: "Anything to change?" If no → skip to next phase.
-
-## Database Convention Deep Inquiry
-
-AI-driven, context-aware — select from pool based on project. AI analyzes the detected database type, ORM, and tech stack, then selects relevant questions from this pool. Do NOT ask all questions — only those that matter for THIS project:
-
-1. **Table naming convention**: snake_case / camelCase / PascalCase; prefix convention (e.g., `t_`, `tbl_`, none). For brownfield: detect from existing migration files or schema and present as "Already decided" with override option.
-2. **Field naming convention**: snake_case / camelCase; common fields convention — are `created_at`, `updated_at`, `deleted_at` (soft delete) required on all tables? What about `id` vs `uuid` column naming?
-3. **Migration conventions**:
-   - File storage directory (e.g., `db/migrations/`, `prisma/migrations/`, `alembic/versions/`)
-   - Naming rule (timestamp prefix `20240101_create_users`, sequence prefix `001_create_users`, ORM auto-generated)
-   - Migration tool (ORM built-in / Flyway / Liquibase / golang-migrate / manual SQL)
-   - For brownfield: detect existing migration directory and naming pattern, present as "Already decided"
-4. **Primary key strategy**: Auto-increment integer / UUID v4 / ULID / Snowflake ID / Other
-5. **Index naming convention**: e.g., `idx_{table}_{column}`, `ix_{table}_{column}`, or ORM default
-6. **Environment separation**: dev/test/prod database separation strategy; connection config management (env vars / config files / secret manager)
-
-Use `AskUserQuestion` for each batch (up to 4 questions per call). For brownfield projects, show detected patterns as recommended options. Each question MUST include a "Skip — decide later" option.
-
-## Deployment Configuration Deep Inquiry
-
-AI-driven, context-aware. Read the existing `### Infrastructure` → `#### Deployment` section for the deployment target, then ask relevant follow-up questions:
-
-1. **Deployment target refinement**:
-   - Own server: SSH access method (key-based / password), OS (Ubuntu / CentOS / other), Docker installed?
-   - SaaS platform: specific platform confirmation, existing account and project? Already deployed before?
-   - Container: orchestration method (Docker Compose / K8s / ECS / Cloud Run)
-2. **Existing infrastructure**:
-   - Remote machine availability — IP/domain? Existing server configuration?
-   - Existing CI/CD pipeline — GitHub Actions / GitLab CI / Jenkins / other? Already configured?
-   - Domain name and SSL — already owned? DNS provider? SSL management (Let's Encrypt / platform-managed / other)?
-3. **AI-assisted deployment**:
-   - Whether AI should help execute deploy commands (via SaaS CLI like `vercel deploy`, `fly deploy`, `railway up`, `docker push`, or SSH remote commands)
-   - If yes: collect necessary info — API token storage method (env var name, e.g., `VERCEL_TOKEN`), project name/ID on the platform, target environment (production / staging)
-   - Explicitly inform: "AI will show each command and wait for your confirmation before executing"
-4. **Environment variable management**: production env var strategy (SaaS platform dashboard / `.env.production` committed to repo / secret manager like AWS Secrets Manager, Vault / CI/CD secrets)
-
-Use `AskUserQuestion` for each batch. Each question MUST include a "Skip — decide later" option.
-
-## Cloud Services Deep Inquiry
-
-Two-round AskUserQuestion.
-
-*Round 1 — Cloud Vendors* (multi-select via `AskUserQuestion`):
-- "Which cloud vendors will this project integrate with?"
-- Options: `AWS`, `Aliyun`, `Tencent Cloud`, `Cloudflare`, `Vercel`, `Other` (free text), `None — skip`
-- If `None — skip`, write `<!-- cloud-services: none -->` to the `#### Cloud Services` subsection and exit this inquiry.
-
-*Round 2 — Service Types* (multi-select, only if Round 1 returned any vendor):
-- "Which types of cloud services will you use?"
-- Options: `Object Storage (COS/S3/OSS)`, `CDN`, `Managed Database`, `Functions/Serverless`, `Auth (OAuth/JWT/IDaaS)`, `Domain & DNS`, `Email`, `SMS`, `Payment`, `AI API (OpenAI/Anthropic/...)`, `Other`
-- The list is multi-select. Skip the question entirely if user picks "None" in Round 1.
-
-*After both rounds, write to `#### Cloud Services`*:
-- For each chosen (vendor x service) pair, append a row to the subsection
-- **Do NOT** prompt for env var names, credentials, region, or SDK details — those belong to `prizmkit-deploy`'s scope, not planning
-- If the user is unsure of the mapping, store the vendors and service types separately; deploy skill can refine later
-
-## Output Format
-
-After infrastructure inquiry, update the `### Infrastructure` section in the project instruction file:
-
-```markdown
-### Infrastructure
-
-#### Database
-- **Type**: [database type]
-- **ORM**: [ORM name]
-- **Table naming**: [convention, e.g., snake_case, no prefix]
-- **Field naming**: [convention]; common fields: [list]
-- **Primary key**: [strategy]
-- **Migration directory**: [path]
-- **Migration naming**: [rule]
-- **Index naming**: [convention]
-- **Environment separation**: [strategy]
-
-#### Deployment
-- **Target**: [platform/method]
-- **AI-assisted deploy**: [yes/no]
-- **Domain**: [domain or "not configured"]
-- **SSL**: [management method]
-- **CI/CD**: [tool or "not configured"]
-- **Env var management**: [strategy]
-
-#### Deployment Credentials Reference
-- [platform]: [token/auth method description]
-
-#### Cloud Services
-- **Vendors**: [comma-separated list, e.g., "AWS, Cloudflare" or "none"]
-- **Services**:
-  - [vendor]: [service type] — [optional one-line note, e.g., "user-upload images"]
-  - [vendor]: [service type]
-<!-- If user picked "None" in Round 1, replace this block with: cloud-services: none -->
-```
-
-Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in the selected project instruction file for `prizmkit-deploy` to pick up later.

package/bundled/skills-windows/app-planner/references/project-brief-guide.md

@@ -1,82 +0,0 @@
-# Project Brief Template
-
-> Capture the user's key product ideas as a simple checklist. Each line is one idea. This file is referenced by `root.prizm` (`PROJECT_BRIEF:`) so every new AI session automatically knows the project's goals.
-
-## File Location
-
-`.prizmkit/plans/project-brief.md`
-
-## Format
-
-```markdown
-# Project Brief
-
-[ ] Core product idea or constraint
-[ ] Another product idea
-[ ] Third idea — one sentence, no sub-bullets
-[x] Already implemented feature -> src/feature/, src/utils/helper.ts
-```
-
-## Rules
-
-1. **First line**: `# Project Brief`
-2. **Remaining lines**: One idea per line, prefixed with `[ ]` (pending) or `[x]` (done)
-3. Each line is **one sentence** — no paragraphs, no sub-bullets, no grouping headers
-4. Language: match the user's language (Chinese or English)
-5. **Size limit**: 500 words max (this file is injected into every session's context window)
-6. **Completion marking** (mandatory): When a brief item is implemented:
-   - Change `[ ]` to `[x]`
-   - Append `->` followed by the **key file or directory paths** that implement it
-   - List the most important 1-3 paths only (entry point, core module, or directory) — not every touched file
-   - Example: `[x] User authentication with OAuth -> src/auth/, src/middleware/auth.ts`
-   - This lets future AI sessions instantly locate the implementation without re-scanning
-
-## Brownfield Init
-
-When initializing an existing project, AI infers the brief from:
-- Generated `root.prizm` (tech stack, module structure)
-- `README.md` (if exists)
-- Package metadata (`package.json` description, `pyproject.toml`, etc.)
-
-Then presents the draft to the user for confirmation and editing.
-
-## Greenfield Init
-
-When initializing a new/empty project, use **progressive questioning** to fully understand the user's intent before generating the brief. Do NOT dump all questions at once — ask in rounds, adapting based on answers.
-
-### Round 1: Problem & Vision (required)
-- What problem does this project solve? (or: what's the core idea?)
-- Who is the target user / audience?
-
-### Round 2: Scope & Features (required)
-- What are the 3-5 core features or capabilities? (ask user to list them)
-- What is the MVP scope? (what's the minimum version that delivers value?)
-- Are there any explicit non-goals? (things this project deliberately does NOT do)
-
-### Round 3: Technical Constraints (if user has preferences)
-- Any preferred tech stack / language / framework?
-- Any integration requirements? (third-party APIs, databases, auth providers)
-- Deployment target? (web app, mobile, CLI, library, self-hosted, cloud)
-
-### Round 4: Clarification (adaptive — only if gaps remain)
-If previous answers are vague or incomplete, probe deeper:
-- "You mentioned X — can you give a concrete example of how a user would use it?"
-- "Are there existing tools that do something similar? How is yours different?"
-- "What does success look like for V1?"
-
-### Completion Criteria
-Stop asking when ALL of these are clear:
-1. **Problem** — what pain point or opportunity this addresses
-2. **Users** — who will use it and in what context
-3. **Core features** — at least 3 concrete capabilities (not vague aspirations)
-4. **Boundaries** — what's in scope vs. out of scope for V1
-5. **Technical direction** — enough to populate `config.json` tech_stack (or explicitly deferred)
-
-If the user gives short/vague answers, don't accept them — rephrase and ask again. A weak brief leads to weak specs downstream.
-
-### Generate & Confirm
-Once all criteria are met:
-1. Generate brief in checklist format (see Format section above)
-2. Present to user with: "Here's what I captured — anything to add, remove, or change?"
-3. Apply edits and write to `.prizmkit/plans/project-brief.md`
-

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

@@ -1,59 +0,0 @@
-# Project Conventions Discovery
-
-AI-driven procedure for discovering and capturing project-level conventions. SKILL.md retains the trigger condition and entry point; this file contains the full Analyze → Reason → Present workflow.
-
-## Principle
-
-**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.
-
-## Step 1: Analyze the project
-
-- Read tech stack, dependencies, existing code, config files, README, any existing style guides or linter configs
-- For brownfield: also read actual source code patterns (naming, file structure, error handling, etc.)
-- For greenfield: use the user's stated goals and intended tech stack
-
-## Step 2: Reason about what conventions matter for THIS project
-
-Think about what decisions, if left unstandardized, would cause inconsistency as the project grows. Consider all dimensions relevant to the project — these might include (but are NOT limited to):
-
-- Language and localization choices
-- Code style and naming patterns
-- Architecture and communication patterns
-- Data format and storage decisions
-- Security and auth approaches
-- UI/UX patterns
-- Testing strategies
-- Deployment and environment patterns
-- ...anything else you observe that needs a project-level decision
-
-The point is: YOU decide what's relevant based on what you see. A Next.js SaaS app needs completely different conventions than a Python data pipeline or a Go microservice.
-
-## Step 3: Present findings via `AskUserQuestion`
-
-First, show "Already decided" conventions as text:
-> **Already decided** (detected from your codebase):
-> - [convention]: [value] (source: [where you found it])
-> - [convention]: [value] (source: [where you found it])
-
-Then use `AskUserQuestion` for conventions that need user input (up to 4 questions per call, use multiple calls as needed — no limit on total rounds). Each question:
-- Question text includes the convention name AND why it matters for this project
-- Options are the reasonable choices (2-4 per question)
-- Mark the recommended option first with "(Recommended)" in its label
-- Use `description` field to explain trade-offs
-
-After each batch of `AskUserQuestion` calls, reassess: are there more project-level conventions to cover? If yes, continue with more `AskUserQuestion` calls. Keep going until ALL project-level conventions are fully addressed.
-
-Then ask in text: "Anything I missed that you'd like to standardize?" — if the user adds more, continue the discovery loop.
-
-## Rules
-
-- **No interaction limit** — keep asking until every project-level convention is covered. Do NOT stop early or batch-skip to save rounds.
-- Every proposed convention must be justified by something you observed in the project — explain WHY it matters
-- Auto-confirm anything already evident from the codebase (show as "detected", let user override)
-- Propose as many conventions as the project genuinely needs, but don't pad with irrelevant ones
-- The "Anything I missed?" question is NOT the end — if the user adds items, ask follow-up `AskUserQuestion` calls to clarify those too
-
-## After Discovery
-
-→ 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

package/bundled/skills-windows/app-planner/references/project-state-detection.md

@@ -1,90 +0,0 @@
-# Project State Detection — Brownfield Behavior
-
-Detailed procedures for detecting and handling existing (brownfield) projects during app planning.
-
-## 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:
-
-### Step 1: Prerequisite Check (Mandatory)
-
-Before ANY planning work, check if AI-essential project context files exist:
-
-| File | Purpose | Status |
-|------|---------|--------|
-| `.prizmkit/prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
-| `.prizmkit/config.json` | Tech stack + runtime config | exists / missing |
-| `.prizmkit/plans/project-brief.md` | Product vision checklist | exists / missing |
-
-**If ANY are missing**, show the status table, then use `AskUserQuestion`:
-
-**Question**: "Some AI context files are missing. These help AI understand your project — making planning much more effective. How would you like to proceed?"
-- **Run project init first (Recommended)** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
-- **Continue without init** — I'll scan the project manually during this session (less thorough)
-- **Skip, I'll set these up later** — proceed with planning using only what's available
-
-- **Run project init first** -> Invoke `prizmkit-init`, then resume app-planner from where it left off
-- **Continue without init** -> Continue with Step 2 below (manual scan)
-- **Skip** -> Continue with Step 3, skip scanning
-
-### Step 2: Proactive Project Scanning
-
-Do NOT ask the user to describe their project — read it yourself first:
-
-1. **Scan project structure** to understand the codebase layout:
-   ```powershell
-   Get-ChildItem -Path . -Directory -Recurse -Depth 2 |
-     Where-Object { $_.FullName -notmatch '\\(node_modules|\.git|dist|build|__pycache__|vendor)(\\|$)' } |
-     ForEach-Object { $_.FullName -replace '[^\\]*\\', '|____' -replace '____\|', ' |' }
-   ```
-
-2. **Read existing project metadata** to infer tech stack and purpose:
-   - `package.json` -> name, description, dependencies, scripts
-   - `pyproject.toml` / `requirements.txt` -> Python dependencies
-   - `go.mod` -> Go module info
-   - `README.md` -> project description and goals
-   - `.prizmkit/config.json` -> previously detected tech stack
-   - `.prizmkit/prizm-docs/root.prizm` -> existing architecture context
-
-3. **Read key source files** (entry points, main routes, core models) to understand what the project actually does — don't rely solely on metadata.
-
-### Step 3: Present Inferred Summary with Confirmation
-
-Show the summary as text, then use `AskUserQuestion`:
-
-> Based on my analysis of your codebase:
->
-> **Project**: [name] — [inferred description]
-> **Tech Stack**: [framework] + [language] + [key dependencies]
-> **Key Features Found**: [list 3-5 detected capabilities]
-> **Architecture**: [e.g., monolithic, microservices, serverless]
-
-**Question**: "Does this look correct?"
-- **Yes, looks correct (Recommended)** — proceed with planning
-- **Mostly correct, with changes** — I'll note corrections
-- **This is off** — let me describe the project
-
-### Step 4: Pre-fill and Focus
-
-- Phase 2 tech stack selection -> largely pre-filled from dependencies
-- Vision/problem statement -> inferred from README or package description (user confirms)
-- Existing features -> note them as `[x]` items in project brief
-
-**Focus remaining questions** (as options where possible) on what CANNOT be inferred:
-- Target users and core value proposition
-- Future direction and planned capabilities
-- Non-functional requirements (performance, scale, security)
-- Design direction (for frontend projects)