prizmkit 1.1.79 → 1.1.81

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.79",
-  "bundledAt": "2026-06-28T02:05:10.521Z",
-  "bundledFrom": "bba9d87"
+  "frameworkVersion": "1.1.81",
+  "bundledAt": "2026-06-29T17:31:12.809Z",
+  "bundledFrom": "65df08d"
 }

package/bundled/dev-pipeline/scripts/init-pipeline.py

@@ -294,6 +294,8 @@ def create_state_directory(state_dir, feature_list_path, features):
             "updated_at": now,
         }
         status_path = os.path.join(feature_dir, "status.json")
+        if os.path.exists(status_path):
+            continue
         with open(status_path, "w", encoding="utf-8") as f:
             json.dump(feature_status, f, indent=2, ensure_ascii=False)
             f.write("\n")

package/bundled/dev-pipeline-windows/scripts/init-pipeline.py

@@ -294,6 +294,8 @@ def create_state_directory(state_dir, feature_list_path, features):
             "updated_at": now,
         }
         status_path = os.path.join(feature_dir, "status.json")
+        if os.path.exists(status_path):
+            continue
         with open(status_path, "w", encoding="utf-8") as f:
             json.dump(feature_status, f, indent=2, ensure_ascii=False)
             f.write("\n")

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.79",
+  "version": "1.1.81",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

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

@@ -12,7 +12,7 @@ Plan an application from idea to actionable project context through interactive
 - 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 or generate `feature-list.json` — that is `feature-planner`'s job.
+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.
 
@@ -56,14 +56,7 @@ If you believe the task is better suited for a different workflow, you MUST:
 
 ## When to Use
 
-Trigger this skill for requests like:
-- "Plan an app", "Design a project", "Design a new application"
-- "Start from scratch", "Build something new", "Create a new product"
-- "Help me figure out what to build", "Brainstorm an app idea"
-- "What tech stack should I use?", "Help me choose frameworks"
-- "Create a project brief for my existing project"
-- "Help me document what this project is about"
-- "I have a codebase but no project plan yet"
+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`
@@ -88,155 +81,16 @@ Do NOT use this skill when:
 
    **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
+   → 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 `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):
-
-   Many projects depend on third-party cloud services (object storage, CDN, managed DB, auth, domain, email, SMS, payment, AI APIs). Capture them now so feature-planner and prizmkit-deploy can reference them later.
-
-   *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 × service) pair, append a row to the subsection (see template below)
-   - **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
-
-   Use `AskUserQuestion` for both rounds. Each question MUST include a "Skip — decide later" option.
-
-   **After infrastructure inquiry**:
-   - Update `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section with all collected information. Replace `<!-- deferred -->` markers with real values. Preserve any existing values that were confirmed unchanged. Full format:
-     ```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.
+   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
@@ -248,142 +102,7 @@ After Infrastructure configuration is complete (CP-AP-1.5), check whether the pr
 
 Rules are optional. If the user skips, AI uses general best practices freely — no reminders, no blocking.
 
-### Step 1: Detect which layers need rules
-
-1. Read `.prizmkit/config.json` to get `detected_layers` (written by `prizmkit-init` Phase 4.5).
-   - If `detected_layers` is present and non-empty → use it directly, jump to step 3.
-   - If `detected_layers` is absent or empty → run self-detection (step 2). Do NOT skip rules configuration just because this field is missing — the project may still have layers that need rules.
-
-2. **Self-detection** (only when `detected_layers` is absent/empty from config.json):
-
-   Scan the project to determine which development layers exist. Combine signal matching with your own judgment — the signals below are a guide, not exhaustive.
-
-   | Layer | Where to Look | Signals |
-   |-------|---------------|---------|
-   | **frontend** | `package.json` deps | `react`, `vue`, `angular`, `next`, `nuxt`, `svelte`, `solid-js`, `preact`, `remix`, `astro`, `qwik` |
-   | **frontend** | `package.json` devDeps | `vite`, `webpack`, `parcel`, `turbo` |
-   | **frontend** | Directory | `src/components/`, `pages/`, `app/` with `.tsx`/`.jsx`/`.vue` files |
-   | **backend** | `package.json` deps | `express`, `fastify`, `koa`, `hono`, `nest` |
-   | **backend** | `pyproject.toml`/`requirements.txt` | `fastapi`, `django`, `flask`, `sanic`, `litestar` |
-   | **backend** | `go.mod` | `gin-gonic`, `echo`, `fiber`, `chi` |
-   | **backend** | `pom.xml`/`build.gradle` | `spring-boot`, `quarkus`, `micronaut`, `ktor` |
-   | **backend** | Directory | `routes/`, `controllers/`, `handlers/`, `api/` with server code |
-   | **database** | `package.json` deps | `prisma`, `typeorm`, `sequelize`, `mongoose`, `knex`, `drizzle-orm`, `kysely` |
-   | **database** | `pyproject.toml`/`requirements.txt` | `sqlalchemy`, `pony`, `peewee`, `tortoise-orm` |
-   | **database** | `go.mod` | `gorm`, `sqlx`, `sqlc`, `ent`, `bun` |
-   | **database** | Directory/Env | `migrations/`, `prisma/`, `alembic/`; `.env*` with `DATABASE_URL`, `DB_HOST`, `MONGO_URI` |
-   | **mobile** | File | `pubspec.yaml` (Flutter) |
-   | **mobile** | `package.json` deps | `react-native`, `expo` |
-   | **mobile** | Directory | Both `ios/*.xcodeproj` + `android/build.gradle` simultaneously |
-
-   **Apply your own judgment**: if you see clear evidence of a layer not covered above, include it. If a signal matches but context suggests it's misleading (e.g., a dependency present but not used as the primary tech), downgrade or ignore it.
-
-   After scanning, present findings via `AskUserQuestion`:
-
-   **Question**: "I detected these development layers: [list with brief evidence]. Is this correct?"
-   - **Yes, looks correct (Recommended)** — use detected layers
-   - **Mostly correct, adjust** — I'll note changes
-   - **No layers apply** — skip rules configuration (library/CLI project)
-
-   If user picks "No layers apply" → skip this entire section, proceed to Prerequisites.
-   If user picks "Mostly correct, adjust" → ask what to add, remove, or change, then reassemble `detected_layers`. Continue to step 3.
-   If user confirms → assemble `detected_layers` array and continue to step 3.
-
-3. For each layer in `detected_layers`, check if `.prizmkit/rules/<layer>-rules.md` exists:
-   - `frontend` → `.prizmkit/rules/frontend-rules.md`
-   - `backend` → `.prizmkit/rules/backend-rules.md`
-   - `database` → `.prizmkit/rules/database-rules.md`
-   - `mobile` → `.prizmkit/rules/mobile-rules.md`
-
-4. Display status:
-
-   ```
-   Rules Status Check:
-     [missing] frontend-rules.md — frontend code detected, no rules configured
-     [exists]  backend-rules.md  — already configured
-     [missing] database-rules.md — database interaction detected, no rules configured
-   ```
-
-5. If all detected layers already have rules → skip to Prerequisites.
-6. If missing rules found, proceed to Step 2.
-
-### Step 2: Ask configuration mode
-
-Use `AskUserQuestion`:
-
-**Question**: "{N} layer(s) without custom dev rules. How would you like to configure?"
-- **Quick setup (only core decisions, rest use recommended defaults)** — covers essential architecture, core technology decisions, and testing questions specific to each layer. Detailed configuration topics (design-system, i18n, performance tuning, deployment details, AI constraints) adopt recommended defaults. See Step 4 for exact per-layer coverage.
-- **Full setup (customize every detail)** — 15-25 questions per layer
-- **Skip — no custom rules needed**
-
-If user picks "Skip" → proceed to Prerequisites.
-
-### Step 3: Select layers to configure
-
-Use `AskUserQuestion` (multiSelect):
-
-**Question**: "Which layers do you want to configure?"
-- Options: the missing layers from Step 1, each with a brief description
-- All pre-selected by default
-
-### Step 4: Configure each selected layer
-
-For each selected layer, run the rules Q&A workflow. This follows the 4-phase rule generation pattern:
-
-**Phase A — Load layer resources:**
-- Read `${SKILL_DIR}/references/rules/<layer>/fixed-rules.md` — industry-consensus rules injected without asking
-- Read `${SKILL_DIR}/references/rules/<layer>/question-bank.md` — interactive questions organized in groups (G1→G10): authoritative source for question text, options, "Recommended" markers, and Notes
-- Read `${SKILL_DIR}/references/rules/<layer>/question-manifest.json` — machine-readable structure for this layer. **This is your asking checklist.** It lists, per question: `group`, `required`, `maps_to` (which template placeholders the answer fills), and conditional fields (`required_if`, `auto_derived_when`, `options_vary_by`). Its `groups[]` carries each group's `quick_mode` flag, and `template_placeholders` is the expected-set for the Phase D self-check. Use the manifest to track coverage; use question-bank.md for the actual wording you present to the user. If a question id in one file is absent from the other, trust question-bank.md for content and note the drift.
-
-**Phase B — Interactive Q&A:**
-- Ask questions one group at a time (max 3 questions per message), as defined in question-bank.md
-- Each question shows a "Recommended" option to reduce decision cost
-- **Quick mode**: ask only the groups whose `quick_mode` is `true` in `question-manifest.json`. All other groups adopt recommended defaults silently. (The manifest is the single source of truth for quick-mode membership — do not hardcode group lists here.)
-- **Full mode**: ask all groups in manifest order (`groups[]`).
-- **Conditional questions** (driven by the manifest's per-question fields):
-  - `required_if: "<expr>"` — ask this question only when the expression over prior answers holds (e.g. Q14 `required_if: Q13 != D`). If the condition is false, the question is legitimately skipped — not a coverage gap.
-  - `auto_derived_when: "<expr>"` — when this holds, fill the mapped placeholder(s) from the prior answer without asking (e.g. backend Q6 `auto_derived_when: Q5 in [GraphQL, gRPC]`). Count as satisfied, not skipped.
-  - `options_vary_by: "<Qid>"` — the question is still asked; only its option list depends on that prior answer (e.g. framework/ORM options vary by language). Never affects whether the question is required.
-- Shortcut commands work at any point:
-  - `recommended` / `default` → adopt all recommended for current group
-  - `all recommended` → adopt all recommended for all remaining groups
-  - `skip` → mark current group as "Not required at this stage"
-- Record answers in memory after each group. Track which manifest questions are answered, auto-derived, or conditionally skipped so Phase D can verify coverage.
-
-**Phase C — Auto-derivation:**
-- Read `${SKILL_DIR}/references/rules/<layer>/derivation-rules.md`
-- Match user answers against the trigger map using keyword matching
-- Derive platform-specific rules without asking the user (e.g., choosing Flutter → auto-inject Flutter widget/persistence/navigation rules)
-
-**Phase D — Render and write:**
-- Read `${SKILL_DIR}/references/rules/<layer>/template.md`
-- Fill all template placeholders with accumulated content from Phases A+B+C
-- **Post-render self-check** (driven by `question-manifest.json` → `template_placeholders`):
-  1. **Coverage pass** — for every placeholder in `from_questions`, confirm it traces to an answered question OR an `auto_derived_when` path OR a conditionally-skipped question (`required_if` false). If a `from_questions` placeholder has no source, you skipped a required question — go back and ask it before writing.
-  2. **Residual pass** — scan the rendered document for any residual `{{ ` or ` }}`; count must be 0. Placeholders in `from_fixed_rules` / `auto_generated` / `metadata` are filled from fixed-rules.md, Phase D generation, and project metadata respectively — they are NOT expected to come from Q&A, but they MUST still be rendered (no residual braces).
-- Generate Appendix A (Deny List) and Appendix B (Recommended Tools) per template instructions — these fill the `auto_generated` placeholders
-- Create `.prizmkit/rules/` directory if it doesn't exist
-- Write `.prizmkit/rules/<layer>-rules.md`
-
-### Step 5: Update root.prizm
-
-After all selected layers are configured:
-1. Check if `.prizmkit/prizm-docs/root.prizm` exists.
-2. **If root.prizm exists**:
-   - Read the file.
-   - Check if `RULES:` line exists:
-     - If present: append new rules file paths to the existing line (check for duplicates first — skip paths already on the line).
-     - If absent: add `RULES: .prizmkit/rules/<layer>-rules.md, ...` at the end (after PROJECT_BRIEF line).
-3. **If root.prizm does not exist** (e.g., project without prizm-docs init):
-   - Create a minimal `root.prizm` with:
-     ```
-     PRIZM_VERSION: 2
-     PROJECT: <name>  — from package.json name, directory name, or git repo name
-     MODULE_INDEX:
-     RULES: .prizmkit/rules/<layer>-rules.md, ...
-     ```
-   - The file will be expanded when the project later runs `prizmkit-prizm-docs init`.
-4. The RULES pointer tells every AI session where to find custom dev rules — AI reads rules via this pointer on session start
+→ 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
 
@@ -483,75 +202,12 @@ 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:
-   ```bash
-   find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
-   ```
-
-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
+When an existing project is detected, read `${SKILL_DIR}/references/project-state-detection.md` for the full 4-step brownfield procedure:
 
-**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)
+- **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
 

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

@@ -0,0 +1,108 @@
+# 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/app-planner/references/project-conventions-discovery.md

@@ -0,0 +1,59 @@
+# 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