prizmkit 1.1.13 → 1.1.15
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
CHANGED
|
@@ -70,25 +70,58 @@ Do NOT use this skill when:
|
|
|
70
70
|
- User wants to explore ideas before committing → read `${SKILL_DIR}/references/brainstorm-guide.md`
|
|
71
71
|
- During brainstorm Phase C → also read `${SKILL_DIR}/references/red-team-checklist.md`
|
|
72
72
|
|
|
73
|
-
3. **Project conventions
|
|
73
|
+
3. **Project conventions discovery** — after Intent Confirmation, before brainstorm or vision work:
|
|
74
74
|
→ Read `CLAUDE.md` / `CODEBUDDY.md` and check for `### Project Conventions` section
|
|
75
|
-
→ If section exists and
|
|
76
|
-
→ If section is missing or incomplete →
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
75
|
+
→ If section exists and covers the project well → skip silently
|
|
76
|
+
→ If section is missing or incomplete → run the **AI-driven convention discovery** below:
|
|
77
|
+
|
|
78
|
+
**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.
|
|
79
|
+
|
|
80
|
+
**Step 1: Analyze the project**
|
|
81
|
+
- Read tech stack, dependencies, existing code, config files, README, any existing style guides or linter configs
|
|
82
|
+
- For brownfield: also read actual source code patterns (naming, file structure, error handling, etc.)
|
|
83
|
+
- For greenfield: use the user's stated goals and intended tech stack
|
|
84
|
+
|
|
85
|
+
**Step 2: Reason about what conventions matter for THIS project**
|
|
86
|
+
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):
|
|
87
|
+
- Language and localization choices
|
|
88
|
+
- Code style and naming patterns
|
|
89
|
+
- Architecture and communication patterns
|
|
90
|
+
- Data format and storage decisions
|
|
91
|
+
- Security and auth approaches
|
|
92
|
+
- UI/UX patterns
|
|
93
|
+
- Testing strategies
|
|
94
|
+
- Deployment and environment patterns
|
|
95
|
+
- ...anything else you observe that needs a project-level decision
|
|
96
|
+
|
|
97
|
+
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.
|
|
98
|
+
|
|
99
|
+
**Step 3: Present findings via `AskUserQuestion`**
|
|
100
|
+
|
|
101
|
+
First, show "Already decided" conventions as text:
|
|
102
|
+
> **Already decided** (detected from your codebase):
|
|
103
|
+
> - [convention]: [value] (source: [where you found it])
|
|
104
|
+
> - [convention]: [value] (source: [where you found it])
|
|
105
|
+
|
|
106
|
+
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:
|
|
107
|
+
- Question text includes the convention name AND why it matters for this project
|
|
108
|
+
- Options are the reasonable choices (2-4 per question)
|
|
109
|
+
- Mark the recommended option first with "(Recommended)" in its label
|
|
110
|
+
- Use `description` field to explain trade-offs
|
|
111
|
+
|
|
112
|
+
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.
|
|
113
|
+
|
|
114
|
+
Then ask in text: "Anything I missed that you'd like to standardize?" — if the user adds more, continue the discovery loop.
|
|
115
|
+
|
|
116
|
+
**Rules:**
|
|
117
|
+
- **No interaction limit** — keep asking until every project-level convention is covered. Do NOT stop early or batch-skip to save rounds.
|
|
118
|
+
- Every proposed convention must be justified by something you observed in the project — explain WHY it matters
|
|
119
|
+
- Auto-confirm anything already evident from the codebase (show as "detected", let user override)
|
|
120
|
+
- Propose as many conventions as the project genuinely needs, but don't pad with irrelevant ones
|
|
121
|
+
- The "Anything I missed?" question is NOT the end — if the user adds items, ask follow-up `AskUserQuestion` calls to clarify those too
|
|
122
|
+
|
|
81
123
|
→ Save answers to `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
|
|
82
|
-
→
|
|
83
|
-
```markdown
|
|
84
|
-
### Project Conventions
|
|
85
|
-
- UI language: 中文
|
|
86
|
-
- i18n: disabled
|
|
87
|
-
- Date format: YYYY-MM-DD, timezone: UTC storage + local display
|
|
88
|
-
- Currency: CNY ¥
|
|
89
|
-
- Code comments: English
|
|
90
|
-
- Git commits: English
|
|
91
|
-
```
|
|
124
|
+
→ Output format will naturally vary per project — that is the intended behavior
|
|
92
125
|
|
|
93
126
|
4. **Project brief accumulation** — throughout all interactive phases:
|
|
94
127
|
→ Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
|
|
@@ -112,25 +145,57 @@ Note:
|
|
|
112
145
|
- This skill does **not** create `.prizmkit/config.json` directly.
|
|
113
146
|
- Creation/update is handled by bootstrap/init flows (e.g., `prizmkit-init`, `dev-pipeline/scripts/init-dev-team.py`).
|
|
114
147
|
|
|
115
|
-
##
|
|
148
|
+
## Interaction Style (Hard Rule)
|
|
149
|
+
|
|
150
|
+
**ALL decision points MUST use the `AskUserQuestion` tool** to present interactive, selectable options. Do NOT render options as plain text (e.g., `[A] option [B] option`) — the user must be able to click/select, not type a letter.
|
|
116
151
|
|
|
117
|
-
|
|
152
|
+
This applies to:
|
|
153
|
+
- Intent confirmation
|
|
154
|
+
- Project conventions
|
|
155
|
+
- Tech stack selection
|
|
156
|
+
- Architecture decisions
|
|
157
|
+
- Handoff recommendations
|
|
158
|
+
- Session exit gates
|
|
159
|
+
- Brownfield prerequisite check
|
|
160
|
+
- Any other decision point
|
|
118
161
|
|
|
119
|
-
|
|
120
|
-
|
|
162
|
+
**How to use `AskUserQuestion`:**
|
|
163
|
+
- Each decision point → one `AskUserQuestion` call with 1-4 questions. Use multiple calls as needed — there is NO limit on total rounds for project-level convention discovery. Keep going until everything is covered.
|
|
164
|
+
- Each question has 2-4 selectable options (the tool auto-adds "Other" for custom input)
|
|
165
|
+
- Use `multiSelect: true` when the user can pick more than one
|
|
166
|
+
- Mark the recommended option first and append "(Recommended)" to its label
|
|
167
|
+
- Use the `description` field to explain trade-offs or implications
|
|
121
168
|
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
- Run project conventions check first
|
|
126
|
-
- Load `${SKILL_DIR}/references/brainstorm-guide.md` and follow its structured ideation process (Phases A-D)
|
|
127
|
-
- Brainstorm Phase D output serves as the Vision Summary (CP-AP-2)
|
|
128
|
-
- After brainstorm completes, ask: "Ideas are taking shape. Ready to hand off to `feature-planner` for feature decomposition, or continue refining?"
|
|
129
|
-
- If ready → proceed to Phase 2 (constraints + frontend design check if applicable) then handoff
|
|
130
|
-
- If not ready → continue exploring, or save draft to `.prizmkit/planning/` and exit
|
|
131
|
-
- **Checkpoints in explore mode**: CP-AP-0 (required), CP-AP-1 (required), CP-AP-2 (from brainstorm output), CP-AP-3 (only if user proceeds to Phase 2), CP-AP-4 and CP-AP-5 (only if user transitions to produce mode)
|
|
169
|
+
**When gathering open-ended information** (e.g., "describe your app idea"), use regular text questions — but follow up with `AskUserQuestion`-based clarifications wherever possible.
|
|
170
|
+
|
|
171
|
+
## Intent Confirmation (Mandatory First Step)
|
|
132
172
|
|
|
133
|
-
|
|
173
|
+
After initial greeting, use `AskUserQuestion` to confirm intent:
|
|
174
|
+
|
|
175
|
+
**Question**: "What would you like to do?"
|
|
176
|
+
- **Produce a project plan (Recommended)** — define vision, tech stack, and constraints → generates project-brief.md for pipeline use
|
|
177
|
+
- **Explore ideas first** — brainstorm and refine ideas before committing to a plan
|
|
178
|
+
- **Generate project context only** — for an existing project that needs a project brief without full planning
|
|
179
|
+
|
|
180
|
+
Route by answer:
|
|
181
|
+
- **Produce a project plan** → Continue to Core Workflow. Set session goal = `produce`.
|
|
182
|
+
- **Explore ideas first** → Enter **Exploration Mode**:
|
|
183
|
+
- Run project conventions check first
|
|
184
|
+
- Load `${SKILL_DIR}/references/brainstorm-guide.md` and follow its structured ideation process (Phases A-D)
|
|
185
|
+
- Brainstorm Phase D output serves as the Vision Summary (CP-AP-2)
|
|
186
|
+
- After brainstorm completes, use `AskUserQuestion`: "Ideas are taking shape. What's next?"
|
|
187
|
+
- **Proceed to feature decomposition (Recommended)** — hand off to feature-planner
|
|
188
|
+
- **Continue refining** — keep brainstorming
|
|
189
|
+
- **Save draft & exit** — save progress to .prizmkit/planning/
|
|
190
|
+
- **Checkpoints in explore mode**: CP-AP-0 (required), CP-AP-1 (required), CP-AP-2 (from brainstorm output), CP-AP-3 (only if user proceeds to Phase 2), CP-AP-4 and CP-AP-5 (only if user transitions to produce mode)
|
|
191
|
+
- **Generate project context only** → Enter **Quick Context Mode** (brownfield only):
|
|
192
|
+
- Run Project State Detection → if greenfield, redirect to produce mode
|
|
193
|
+
- Proactively scan the project (same as brownfield behavior)
|
|
194
|
+
- Generate project-brief.md from inferred context
|
|
195
|
+
- Skip extensive brainstorming and constraint phases
|
|
196
|
+
- Present brief for user confirmation → write → done
|
|
197
|
+
|
|
198
|
+
Session goal tracking: Track the intent (`produce`, `explore`, or `quick_context`) throughout the session. If `explore`, always re-prompt before ending.
|
|
134
199
|
|
|
135
200
|
## Project State Detection (after Intent Confirmation)
|
|
136
201
|
|
|
@@ -153,6 +218,31 @@ Proceed with the standard Core Workflow — ask all questions from scratch.
|
|
|
153
218
|
|
|
154
219
|
When an existing project is detected:
|
|
155
220
|
|
|
221
|
+
**Step 1: Prerequisite Check (Mandatory)**
|
|
222
|
+
|
|
223
|
+
Before ANY planning work, check if AI-essential project context files exist:
|
|
224
|
+
|
|
225
|
+
| File | Purpose | Status |
|
|
226
|
+
|------|---------|--------|
|
|
227
|
+
| `.prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
|
|
228
|
+
| `.prizmkit/config.json` | Tech stack + runtime config | exists / missing |
|
|
229
|
+
| `.prizmkit/plans/project-brief.md` | Product vision checklist | exists / missing |
|
|
230
|
+
|
|
231
|
+
**If ANY are missing**, show the status table, then use `AskUserQuestion`:
|
|
232
|
+
|
|
233
|
+
**Question**: "Some AI context files are missing. These help AI understand your project — making planning much more effective. How would you like to proceed?"
|
|
234
|
+
- **Run project init first (Recommended)** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
|
|
235
|
+
- **Continue without init** — I'll scan the project manually during this session (less thorough)
|
|
236
|
+
- **Skip, I'll set these up later** — proceed with planning using only what's available
|
|
237
|
+
|
|
238
|
+
- **Run project init first** → Invoke `prizmkit-init`, then resume app-planner from where it left off
|
|
239
|
+
- **Continue without init** → Continue with Step 2 below (manual scan)
|
|
240
|
+
- **Skip** → Continue with Step 3, skip scanning
|
|
241
|
+
|
|
242
|
+
**Step 2: Proactive Project Scanning**
|
|
243
|
+
|
|
244
|
+
Do NOT ask the user to describe their project — read it yourself first:
|
|
245
|
+
|
|
156
246
|
1. **Scan project structure** to understand the codebase layout:
|
|
157
247
|
```bash
|
|
158
248
|
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'
|
|
@@ -166,19 +256,35 @@ When an existing project is detected:
|
|
|
166
256
|
- `.prizmkit/config.json` → previously detected tech stack
|
|
167
257
|
- `.prizm-docs/root.prizm` → existing architecture context
|
|
168
258
|
|
|
169
|
-
3. **
|
|
170
|
-
|
|
259
|
+
3. **Read key source files** (entry points, main routes, core models) to understand what the project actually does — don't rely solely on metadata.
|
|
260
|
+
|
|
261
|
+
**Step 3: Present inferred summary with confirmation**
|
|
262
|
+
|
|
263
|
+
Show the summary as text, then use `AskUserQuestion`:
|
|
264
|
+
|
|
265
|
+
> Based on my analysis of your codebase:
|
|
266
|
+
>
|
|
267
|
+
> **Project**: [name] — [inferred description]
|
|
268
|
+
> **Tech Stack**: [framework] + [language] + [key dependencies]
|
|
269
|
+
> **Key Features Found**: [list 3-5 detected capabilities]
|
|
270
|
+
> **Architecture**: [e.g., monolithic, microservices, serverless]
|
|
271
|
+
|
|
272
|
+
**Question**: "Does this look correct?"
|
|
273
|
+
- **Yes, looks correct (Recommended)** — proceed with planning
|
|
274
|
+
- **Mostly correct, with changes** — I'll note corrections
|
|
275
|
+
- **This is off** — let me describe the project
|
|
276
|
+
|
|
277
|
+
**Step 4: Pre-fill and focus**
|
|
171
278
|
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
- Existing features → note them as `[x]` items in project brief
|
|
279
|
+
- Phase 2 tech stack selection → largely pre-filled from dependencies
|
|
280
|
+
- Vision/problem statement → inferred from README or package description (user confirms)
|
|
281
|
+
- Existing features → note them as `[x]` items in project brief
|
|
176
282
|
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
283
|
+
**Focus remaining questions** (as options where possible) on what CANNOT be inferred:
|
|
284
|
+
- Target users and core value proposition
|
|
285
|
+
- Future direction and planned capabilities
|
|
286
|
+
- Non-functional requirements (performance, scale, security)
|
|
287
|
+
- Design direction (for frontend projects)
|
|
182
288
|
|
|
183
289
|
## Core Workflow
|
|
184
290
|
|
|
@@ -186,11 +292,13 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
|
|
|
186
292
|
|
|
187
293
|
### Interactive Phases
|
|
188
294
|
1. Clarify business goal and scope
|
|
189
|
-
1.1 Confirm deliverable intent (→ Intent Confirmation)
|
|
190
|
-
1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope,
|
|
295
|
+
1.1 Confirm deliverable intent (→ Intent Confirmation — option-based)
|
|
296
|
+
1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, use option-based questions where possible. When common patterns exist, present them as choices. Only use open-ended questions for truly unique input (e.g., "describe your app idea"). Follow up with option-based clarifications.
|
|
191
297
|
2. Confirm constraints and tech assumptions
|
|
192
|
-
2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix
|
|
193
|
-
2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found,
|
|
298
|
+
2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix. Use `AskUserQuestion` for each major tech decision (framework, database, styling, etc.)
|
|
299
|
+
2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, use `AskUserQuestion`:
|
|
300
|
+
- Question: "No UI/UX design docs found. Would you like to establish design direction?"
|
|
301
|
+
- Options: "Establish design direction now (Recommended)", "Skip for now", "I have external designs"
|
|
194
302
|
3. Capture architecture decisions and finalize project brief
|
|
195
303
|
4. Hand off to `feature-planner` for feature decomposition
|
|
196
304
|
|
|
@@ -236,16 +344,18 @@ Activate when ALL true:
|
|
|
236
344
|
|
|
237
345
|
When the session appears to be ending:
|
|
238
346
|
1. **Remind**: "You set out to produce a project plan but `.prizmkit/plans/project-brief.md` isn't complete yet."
|
|
239
|
-
2.
|
|
240
|
-
- **
|
|
241
|
-
- **
|
|
242
|
-
- **
|
|
347
|
+
2. Use `AskUserQuestion`: "How would you like to proceed?"
|
|
348
|
+
- **Continue to completion (Recommended)** — finish the project brief
|
|
349
|
+
- **Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
|
|
350
|
+
- **Abandon** — exit without saving
|
|
243
351
|
|
|
244
352
|
## Handoff to feature-planner
|
|
245
353
|
|
|
246
|
-
After all checkpoints pass, present a summary and
|
|
354
|
+
After all checkpoints pass, present a summary and use `AskUserQuestion` for next steps:
|
|
247
355
|
|
|
248
|
-
1. **Summary
|
|
249
|
-
2.
|
|
250
|
-
|
|
251
|
-
|
|
356
|
+
1. **Summary** (as text): List captured vision, tech stack, constraints, architecture decisions, and project brief status
|
|
357
|
+
2. Use `AskUserQuestion`: "Planning complete! What's next?"
|
|
358
|
+
- **Proceed to feature decomposition (Recommended)** — invoke `feature-planner` to break down features into `.prizmkit/plans/feature-list.json`
|
|
359
|
+
- **Continue refining** — stay in app-planner to adjust vision or constraints
|
|
360
|
+
- **Done for now** — exit with artifacts saved
|
|
361
|
+
3. **Artifacts produced**: List files written (`.prizmkit/plans/project-brief.md`, project conventions and architecture decisions in `CLAUDE.md` / `CODEBUDDY.md`)
|