prizmkit 1.1.148 → 1.1.149
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bundled/VERSION.json +3 -3
- package/bundled/skills/_metadata.json +1 -1
- package/bundled/skills/app-planner/SKILL.md +27 -27
- package/bundled/skills/app-planner/references/architecture-decisions.md +5 -11
- package/bundled/skills/app-planner/references/frontend-design-guide.md +1 -1
- package/bundled/skills/app-planner/references/generated-plan-review.md +2 -2
- package/bundled/skills/app-planner/references/infrastructure-convention-discovery.md +2 -2
- package/bundled/skills/app-planner/references/project-conventions-discovery.md +1 -1
- package/package.json +1 -1
package/bundled/VERSION.json
CHANGED
|
@@ -36,18 +36,18 @@ If you believe the task is better suited for a different workflow, you MUST:
|
|
|
36
36
|
**Your ONLY writable outputs are:**
|
|
37
37
|
1. `.prizmkit/plans/project-brief.md` (`.prizmkit/plans/` — accumulated project context brief)
|
|
38
38
|
2. `.prizmkit/plans/project-brief.draft.md` — working source during planning and saved draft when the user exits before completion
|
|
39
|
-
3.
|
|
40
|
-
4.
|
|
41
|
-
5. `.prizmkit/
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
-
|
|
49
|
-
- `
|
|
50
|
-
-
|
|
39
|
+
3. The resolved project instruction target for the current AI host (with user consent) — only project conventions, infrastructure configuration (database conventions, deployment config, **cloud services**), frontend design direction, and architecture decisions
|
|
40
|
+
4. `.prizmkit/rules/<layer>-rules.md` — per-layer development rules generated by Rules Configuration
|
|
41
|
+
5. `.prizmkit/prizm-docs/root.prizm` — `RULES:` pointer line only (not other root.prizm content; created minimally if absent)
|
|
42
|
+
|
|
43
|
+
**Current-host project instruction target resolution**:
|
|
44
|
+
- Identify the current AI host from direct runtime/session evidence and the host's own project conventions. Installed project resources, existing project files, and `.prizmkit/manifest.json` are supporting evidence only; they are not a platform identity or path allowlist and must not override stronger current-session evidence.
|
|
45
|
+
- Resolve the host's conventional main project-level AI instruction/context file: a project-local, durable file that the current host loads or reads to guide AI work in this project.
|
|
46
|
+
- Named paths such as `AGENTS.md`, `CLAUDE.md`, `CODEBUDDY.md`, and `.pi/APPEND_SYSTEM.md` are non-exhaustive examples only. They do not define a platform-to-path mapping or a compliance condition.
|
|
47
|
+
- The target must stay inside the project, represent the current host's main user-facing project instruction context, and must not be a private or framework-protocol-only import file.
|
|
48
|
+
- If the conventional target is absent, create it only when current-host evidence establishes one unambiguous conventional project path and the user consents to the write.
|
|
49
|
+
- If no target can be identified confidently or multiple plausible targets remain, use `AskUserQuestion` to confirm the intended project instruction file before writing. Never guess, and never treat semantic detection as permission to write an arbitrary file.
|
|
50
|
+
- Resolve the target once before project-convention discovery and reuse the same resolved target for conventions, infrastructure, frontend design direction, architecture decisions, prerequisites, checkpoints, generated-plan review, and completion reporting. Do not mirror content to every installed host merely because multiple platform resources exist.
|
|
51
51
|
|
|
52
52
|
**After planning is complete**, you MUST:
|
|
53
53
|
1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
|
|
@@ -130,7 +130,7 @@ Do NOT use this skill when:
|
|
|
130
130
|
- During brainstorm Phase C → also read `${SKILL_DIR}/references/red-team-checklist.md`
|
|
131
131
|
|
|
132
132
|
3. **Project conventions discovery** — after Intent Confirmation, before brainstorm or vision work:
|
|
133
|
-
→
|
|
133
|
+
→ Resolve the current host's project instruction target through **Current-host project instruction target resolution**, then read that exact target and check for a `### Project Conventions` section
|
|
134
134
|
→ If section exists and covers the project well → skip silently
|
|
135
135
|
→ If section is missing or incomplete → run the **AI-driven convention discovery** below:
|
|
136
136
|
|
|
@@ -138,14 +138,14 @@ Do NOT use this skill when:
|
|
|
138
138
|
|
|
139
139
|
→ Read `${SKILL_DIR}/references/project-conventions-discovery.md` for the full AI-driven discovery procedure (Analyze → Reason → Present via AskUserQuestion).
|
|
140
140
|
|
|
141
|
-
→ Normalize each proposed convention into a standalone domain rule, run the Pre-Generation Headless Context Completeness Gate, then save only passing convention meanings to
|
|
141
|
+
→ Normalize each proposed convention into a standalone domain rule, run the Pre-Generation Headless Context Completeness Gate, then save only passing convention meanings to the resolved project instruction target under `### Project Conventions` (one bullet per convention; no raw answers or planning provenance)
|
|
142
142
|
→ Output format will naturally vary per project — that is the intended behavior
|
|
143
143
|
|
|
144
144
|
**Infrastructure Convention Discovery (Database + Deployment)**
|
|
145
145
|
|
|
146
|
-
After project conventions are captured, check the project instruction
|
|
146
|
+
After project conventions are captured, check the resolved project instruction target 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.
|
|
147
147
|
|
|
148
|
-
After inquiry, run the Pre-Generation Headless Context Completeness Gate on every proposed infrastructure decision, then update the `### Infrastructure` section in the project instruction
|
|
148
|
+
After inquiry, run the Pre-Generation Headless Context Completeness Gate on every proposed infrastructure decision, then update the `### Infrastructure` section in the resolved project instruction target with passing content (see reference file for full output format). Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` for `prizmkit-deploy` to pick up later.
|
|
149
149
|
|
|
150
150
|
4. **Project brief accumulation** — throughout all interactive phases:
|
|
151
151
|
→ Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
|
|
@@ -168,8 +168,8 @@ Proceed to Prerequisites and continue the app-planner workflow.
|
|
|
168
168
|
Before questions, check optional context files (never block if absent):
|
|
169
169
|
- `.prizmkit/prizm-docs/root.prizm` (architecture/project context)
|
|
170
170
|
- `.prizmkit/config.json` (existing stack preferences and detected tech stack)
|
|
171
|
-
-
|
|
172
|
-
-
|
|
171
|
+
- Resolved project instruction target `### Project Conventions` section (previously answered project conventions)
|
|
172
|
+
- Resolved project instruction target `### Infrastructure` section (database and deployment config from prizmkit-init or previous app-planner run)
|
|
173
173
|
|
|
174
174
|
**Tech stack auto-population from config.json:**
|
|
175
175
|
- If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill tech assumptions.
|
|
@@ -287,8 +287,8 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
|
|
|
287
287
|
| Checkpoint | Artifact/State | Criteria | Phase |
|
|
288
288
|
|-----------|----------------|----------|-------|
|
|
289
289
|
| **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
|
|
290
|
-
| **CP-AP-1** | Conventions Checked |
|
|
291
|
-
| **CP-AP-1.5** | Infrastructure Checked |
|
|
290
|
+
| **CP-AP-1** | Conventions Checked | Current-host project instruction target resolved; its `### Project Conventions` section is loaded or asked and up to date | 1 |
|
|
291
|
+
| **CP-AP-1.5** | Infrastructure Checked | Resolved project instruction target `### Infrastructure` section addressed — database, deployment **and cloud services** each configured or explicitly deferred | 1-2 |
|
|
292
292
|
| **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 |
|
|
293
293
|
| **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user. For brownfield: existing purpose confirmed or refined. | 1-2 |
|
|
294
294
|
| **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 |
|
|
@@ -302,10 +302,10 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
|
|
|
302
302
|
Run this gate before any final handoff whenever the current `app-planner` session wrote or rewrote final app-level planning content. In full produce mode this runs after CP-AP-5.5 and the passing content's final writes; in Quick Context Mode it runs after the confirmed `.prizmkit/plans/project-brief.md` write; in conventions, infrastructure, architecture-decision, or rules-only final-write flows it runs after those writes and before the completion summary. This gate reviews generated planning artifacts directly, not implementation diffs.
|
|
303
303
|
|
|
304
304
|
1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for app-planner generated content review.
|
|
305
|
-
2. **Read actual planning artifacts directly**: inspect current-session final outputs such as `.prizmkit/plans/project-brief.md`,
|
|
305
|
+
2. **Read actual planning artifacts directly**: inspect current-session final outputs such as `.prizmkit/plans/project-brief.md`, changed sections in the resolved project instruction target, `.prizmkit/rules/<layer>-rules.md`, and `.prizmkit/prizm-docs/root.prizm` `RULES:` pointer line. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
|
|
306
306
|
3. **Scope to new/changed app-planning content**: compare against pre-session snapshots or in-memory drafts when available. Preserve unchanged historical brief items, instruction-file sections, rules files, and Prizm doc content. For explore-only sessions, draft-save exits, or flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
|
|
307
307
|
4. **Run the local checklist and fresh-session simulation** from the reference: project brief completeness, consistency of conventions/infrastructure/architecture decisions, rules pointer consistency, normalization of selected decisions, purpose-tagged references, app-planner writable-boundary compliance, and downstream `feature-planner` readiness to produce `.prizmkit/plans/feature-list.json` without guessing or seeing the original conversation.
|
|
308
|
-
5. **Apply accepted fixes through the source/writer path**: project brief fixes go through the draft/checklist source, instruction-file section fixes go through the
|
|
308
|
+
5. **Apply accepted fixes through the source/writer path**: project brief fixes go through the draft/checklist source, instruction-file section fixes go through the resolved project instruction target's section source with user confirmation when changing approved wording, rules fixes re-render from rules configuration answers/templates when available, and `root.prizm` fixes are limited to the `RULES:` pointer line.
|
|
309
309
|
6. **Recheck changed sections directly** after every accepted fix batch.
|
|
310
310
|
7. **Report CP-AP-6** in the completion summary: include local generated-plan review verdict, reviewed app-planning artifacts/sections, accepted fixes (or "none"), and final writer/validation result.
|
|
311
311
|
|
|
@@ -314,8 +314,8 @@ Run this gate before any final handoff whenever the current `app-planner` sessio
|
|
|
314
314
|
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.
|
|
315
315
|
|
|
316
316
|
**How it works**:
|
|
317
|
-
1. If decisions are captured → run the Pre-Generation Headless Context Completeness Gate on each decision, then append passing decisions to
|
|
318
|
-
2. Downstream skills (feature-planner, prizmkit-plan, etc.) read
|
|
317
|
+
1. If decisions are captured → run the Pre-Generation Headless Context Completeness Gate on each decision, then append passing decisions to the resolved project instruction target under `### Architecture Decisions`
|
|
318
|
+
2. Downstream skills (feature-planner, prizmkit-plan, etc.) read the current host's project instruction context, so they automatically receive these decisions
|
|
319
319
|
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.
|
|
320
320
|
|
|
321
321
|
## Project Brief Accumulation
|
|
@@ -348,10 +348,10 @@ When the session appears to be ending:
|
|
|
348
348
|
After CP-AP-6 passes or is reported not applicable, present a summary and end the session:
|
|
349
349
|
|
|
350
350
|
1. **Summary** (as text): List all project-level artifacts produced:
|
|
351
|
-
- Project conventions →
|
|
352
|
-
- Infrastructure config →
|
|
351
|
+
- Project conventions → resolved project instruction target `### Project Conventions`
|
|
352
|
+
- Infrastructure config → resolved project instruction target `### Infrastructure` (database conventions + deployment config)
|
|
353
353
|
- Tech stack assumptions → captured in `.prizmkit/plans/project-brief.md` and reused from `.prizmkit/config.json` when it already exists
|
|
354
|
-
- Architecture decisions (if any) →
|
|
354
|
+
- Architecture decisions (if any) → resolved project instruction target `### Architecture Decisions`
|
|
355
355
|
- Dev rules (if configured) → `.prizmkit/rules/<layer>-rules.md` (with `root.prizm` `RULES:` pointer)
|
|
356
356
|
- Project brief → `.prizmkit/plans/project-brief.md`
|
|
357
357
|
- Local generated-plan review → verdict, reviewed app-planning artifacts/sections, accepted fixes (or "none"), and final writer/validation result
|
|
@@ -24,15 +24,9 @@ After Phase 2 (Confirm constraints and tech assumptions), before Phase 3 (Captur
|
|
|
24
24
|
|
|
25
25
|
## How to Capture
|
|
26
26
|
|
|
27
|
-
1. **
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
- `claude` → append to `CLAUDE.md`
|
|
31
|
-
- `codebuddy` → append to `CODEBUDDY.md`
|
|
32
|
-
- `all` → append to all three files.
|
|
33
|
-
- If no platform can be determined, skip (no project instruction file).
|
|
34
|
-
|
|
35
|
-
2. **Check for existing section** — read the target file and look for `### Architecture Decisions` heading:
|
|
27
|
+
1. **Use the resolved project instruction target** — consume the exact current-host target already selected by `SKILL.md` before project-convention discovery. Do not redetect the host, reinterpret manifest identity, or choose from named platform files inside this reference. If the target was not resolved, return to the parent Skill's current-host resolution rule; ask the user when evidence is missing or ambiguous rather than guessing or silently skipping.
|
|
28
|
+
|
|
29
|
+
2. **Check for existing section** — read the resolved target and look for `### Architecture Decisions` heading:
|
|
36
30
|
- If heading exists → append new entries below it (avoid duplicates with existing entries)
|
|
37
31
|
- If heading does not exist → create it at the end of the file
|
|
38
32
|
|
|
@@ -44,7 +38,7 @@ After Phase 2 (Confirm constraints and tech assumptions), before Phase 3 (Captur
|
|
|
44
38
|
- Monorepo structure: shared types between frontend and backend
|
|
45
39
|
```
|
|
46
40
|
|
|
47
|
-
4. **User confirmation** — before writing, show the collected decisions and ask:
|
|
48
|
-
> "These architecture decisions were identified during planning. Record them
|
|
41
|
+
4. **User confirmation** — before writing, show the collected decisions and the exact resolved target path, then ask:
|
|
42
|
+
> "These architecture decisions were identified during planning. Record them in `<resolved-project-instruction-target>`? (Y/n)"
|
|
49
43
|
|
|
50
44
|
If user declines, skip without further prompting.
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
> Create distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics.
|
|
4
4
|
|
|
5
|
-
**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
|
|
5
|
+
**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 in the current session's resolved project instruction target selected by `SKILL.md`. Do not redetect a platform or choose a named file in this reference. Downstream implementation skills will consume these decisions when building features.
|
|
6
6
|
|
|
7
7
|
Load this guide **only when the feature involves frontend/UI work**. Skip for backend-only or infrastructure features.
|
|
8
8
|
|
|
@@ -14,7 +14,7 @@ Planning artifacts may be gitignored, untracked, or absent from staged and unsta
|
|
|
14
14
|
|
|
15
15
|
- Project brief: `.prizmkit/plans/project-brief.md`
|
|
16
16
|
- Draft brief when present: `.prizmkit/plans/project-brief.draft.md`
|
|
17
|
-
-
|
|
17
|
+
- The exact project instruction target selected for the current session, limited to sections written or changed by app-planner
|
|
18
18
|
- Generated rule files: `.prizmkit/rules/<layer>-rules.md`
|
|
19
19
|
- Prizm docs root pointer: `.prizmkit/prizm-docs/root.prizm` `RULES:` line only
|
|
20
20
|
- In-memory answers, draft brief data, rules configuration answers, or section snapshots captured before writes
|
|
@@ -32,7 +32,7 @@ Do not rely on `git status`, `git diff`, or `git diff --cached` to decide whethe
|
|
|
32
32
|
## Source-of-Truth Map
|
|
33
33
|
|
|
34
34
|
- `project-brief.md` fixes go through the draft/checklist project brief source representation described in `project-brief-guide.md`, then rewrite the final brief through the existing project brief writer path.
|
|
35
|
-
- Project conventions, infrastructure, and architecture decisions are source sections in
|
|
35
|
+
- Project conventions, infrastructure, frontend design direction, and architecture decisions are source sections in the exact project instruction target selected for the current session. If a fix changes user-approved wording or meaning, ask for user confirmation before rewriting.
|
|
36
36
|
- `.prizmkit/rules/<layer>-rules.md` fixes should re-render from the rules configuration answers and template inputs when available. If no structured source remains, update the source rule section explicitly and report that source path.
|
|
37
37
|
- `root.prizm` fixes are limited to correcting or adding the `RULES:` pointer line; do not rewrite unrelated root content.
|
|
38
38
|
|
|
@@ -4,7 +4,7 @@ Detailed Q&A flows for database, deployment, and cloud services conventions duri
|
|
|
4
4
|
|
|
5
5
|
## Infrastructure Section Check
|
|
6
6
|
|
|
7
|
-
Check
|
|
7
|
+
Check the current session's resolved project instruction target for a `### Infrastructure` section. Consume the exact target selected by `SKILL.md`; do not redetect a platform or choose a named file in this reference:
|
|
8
8
|
|
|
9
9
|
- 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.
|
|
10
10
|
- 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")
|
|
@@ -105,4 +105,4 @@ After infrastructure inquiry, update the `### Infrastructure` section in the pro
|
|
|
105
105
|
<!-- If user picked "None" in Round 1, replace this block with: cloud-services: none -->
|
|
106
106
|
```
|
|
107
107
|
|
|
108
|
-
Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in the
|
|
108
|
+
Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in the resolved project instruction target for `prizmkit-deploy` to pick up later.
|
|
@@ -55,5 +55,5 @@ Then ask in text: "Anything I missed that you'd like to standardize?" — if the
|
|
|
55
55
|
|
|
56
56
|
## After Discovery
|
|
57
57
|
|
|
58
|
-
→ Save resolved convention meanings to
|
|
58
|
+
→ Save resolved convention meanings to the current session's resolved project instruction target under `### Project Conventions` (one standalone domain rule per bullet). Consume the target selected by `SKILL.md`; do not redetect a platform or choose a named file in this reference. Do not copy raw answers, option labels, recommendation markers, question IDs, or dialogue provenance.
|
|
59
59
|
→ Output format will naturally vary per project — that is the intended behavior
|