Expand init to capture positioning, conversion, and proof context

skill/reference/init.md

@@ -45,43 +45,58 @@ Note what you've learned and what remains unclear. Also note any rough edges wor
 
 ## Step 3: Ask strategic questions (for PRODUCT.md)
 
-{{ask_instruction}} Ask only about what you couldn't infer from the codebase.
+{{ask_instruction}} Ask about anything the codebase doesn't answer with strong, explicit evidence.
 
 ### Interview mode, not confirmation mode
 
 If the repo is empty or the user's brief is sparse, run a short interview before proposing PRODUCT.md. Do **not** turn a one-sentence request into a complete inferred PRODUCT.md and ask for blanket confirmation.
 
-- Use the harness's structured question tool when one exists. Otherwise, ask directly in chat and stop.
-- Ask **2-3 questions per round**, then wait for answers.
+- Use the harness's structured question tool when one exists. Otherwise, ask directly in chat and stop: one question at a time, with lettered options where the crawl suggests likely answers, waiting for each answer before the next.
+- Keep skill vocabulary (register, belief ladder, anti-references) out of question text; ask for the thing in words the user would use. For the brand register, ask like a magazine editor profiling the brand: curious and narrative, drawing out the story, the feel, and what a visitor should come to believe.
+- Ask in focused rounds and wait for answers between them. Keep **one topic per question**; add rounds rather than fold several topics into one either-or choice. Options obey the same rule: an option answers only the question asked; never write a compound option that bundles a feeling with a business outcome or names an additional audience.
 - Use inferred answers as hypotheses or options, not as finished facts.
 - Complete at least one real user-answer round before drafting PRODUCT.md, unless every required answer is directly discoverable from repo docs.
-- Round 1 should establish register, users/purpose, and desired outcome.
-- Round 2 should establish brand personality or references, anti-references, and accessibility needs.
+- Round 1 should establish register, users, purpose, positioning, and desired outcome.
+- Round 2 should establish brand personality or references, anti-references, and accessibility needs, plus conversion & proof for the brand register.
 
 ### Minimum viable interview
 
-Ask enough to complete PRODUCT.md. At minimum, cover register confirmation, users and purpose, brand personality, anti-references, and accessibility needs unless each answer is directly discoverable from repo context. After at least one interview round, you may propose inferred answers, but the user must confirm them before you write PRODUCT.md. Never synthesize PRODUCT.md from the original task prompt alone.
+Ask enough to complete PRODUCT.md. At minimum, cover register confirmation, users, purpose, positioning, brand personality, anti-references, and accessibility needs (plus conversion & proof for the brand register) unless each answer is directly discoverable from repo context. After at least one interview round, you may propose inferred answers, but the user must confirm them before you write PRODUCT.md. Never synthesize PRODUCT.md from the original task prompt alone.
 
 ### Register (ask first; it shapes everything below)
 
 Every design task is either **brand** (marketing, landing, campaign, long-form content, portfolio: design IS the product) or **product** (app UI, admin, dashboards, tools: design SERVES the product).
 
 If Step 2 produced a clear hypothesis, lead with it: *"From the codebase, this looks like a [brand / product] surface. Does that match your intent, or should we treat it differently?"*
 
-If the signal is genuinely split (e.g. a product with a big marketing landing), {{ask_instruction}} Ask which register describes the **primary** surface. The register can be overridden per task later, but PRODUCT.md carries one default.
+If the signal is genuinely split (e.g. a product with a big marketing landing), {{ask_instruction}} Ask which register describes the **primary** surface. The register can be overridden per task later, but PRODUCT.md carries one default. Settle the default before drafting any register-dependent questions; never batch brand-only questions (Conversion & proof) into the same round as the question that decides the register.
 
 ### Users & Purpose
 - Who uses this? What's their context when using it?
 - What job are they trying to get done?
-- For brand: what emotions should the interface evoke? (confidence, delight, calm, urgency)
+- What is this for? A purpose stated in README or docs is a hypothesis, not strong evidence; confirm it, don't transcribe it.
+- What does success look like?
+- If more than one kind of user is plausible, confirm a primary and secondary audience; don't manufacture a split that isn't there. An audience implied by another answer (a success metric, a CTA) is still unconfirmed; ask before writing it as secondary.
+- If the surface speaks to a different audience than the people who use the product, ask the user to name both.
+- For brand: what emotions should the interface evoke? (confidence, delight, calm, urgency) Ask this standalone; don't fold emotions into the success question.
 - For product: what workflow are they in? What's the primary task on any given screen?
 
+### Positioning
+- In one line, what does this do that nothing else does? The single strategic claim every screen reinforces.
+
 ### Brand & Personality
 - How would you describe the brand personality in 3 words?
 - Reference sites or apps that capture the right feel? What specifically about them?
   - Push for specific named references with the *specific* thing about them that fits this brand, not generic "modern" adjectives or category-bucket lanes.
 - What should this explicitly NOT look like? Any anti-references?
 
+### Conversion & proof (brand register only)
+- What's the primary CTA?
+- What's the secondary fallback, for visitors not ready for the primary?
+- The one line a visitor should remember after 10 seconds.
+- Belief ladder: what must the visitor believe, in order, before taking the primary CTA?
+- What proof is on hand? Ask the user to hand over any testimonials, case studies, press, or client/partner logos they already have. If you can receive files directly, collect them; otherwise create `.impeccable/assets/proof/` and ask the user to add files there. Reference supplied files by path; record text proof inline.
+
 ### Accessibility & Inclusion
 - Specific accessibility requirements? (WCAG level, known user needs)
 - Considerations for reduced motion, color blindness, or other accommodations?
@@ -90,7 +105,7 @@ Skip questions where the answer is already clear. **Do NOT ask about colors, fon
 
 ## Step 4: Write PRODUCT.md
 
-Write PRODUCT.md only after the user has confirmed the strategic answers from Step 3. If an inferred answer is uncertain or unconfirmed, ask before writing.
+Write PRODUCT.md only after the user has confirmed the strategic answers from Step 3. If an inferred answer is uncertain or unconfirmed, ask before writing. Confirmed means what the user actually said yes to; do not pad a confirmed answer with extras they never picked (additional anti-references, audiences, roadmap claims, a WCAG level), whether drawn from the crawl, another answer, or your own option text. If an extra belongs in the doc, ask about it first.
 
 Synthesize into a strategic document:
 
@@ -102,11 +117,21 @@ Synthesize into a strategic document:
 product
 
 ## Users
-[Who they are, their context, the job to be done]
+[Who they are, their context, the job to be done. Primary audience; a secondary audience or a surface-vs-user split only when they apply.]
 
 ## Product Purpose
 [What this product does, why it exists, what success looks like]
 
+## Positioning
+[The single strategic claim every screen reinforces. Not a visual rule, not an anti-reference.]
+
+## Conversion & proof
+[Brand register only. Product register: omit this section entirely, heading included.]
+- Primary and secondary CTA: [...]
+- The line a visitor remembers after 10 seconds: [...]
+- Belief ladder: [...]
+- Proof on hand: [testimonials, case studies, press, or logos, referenced by path]
+
 ## Brand Personality
 [Voice, tone, 3-word personality, emotional goals]
 
@@ -122,6 +147,8 @@ product
 
 Register is either `brand` or `product` as a bare value. No prose, no commentary.
 
+Write fields as prose, and use bold sparingly: only where a word carries a decision, never as a label lead-in on every line.
+
 Write to `PROJECT_ROOT/PRODUCT.md`. If `.impeccable.md` existed, the loader already renamed it; merge into that content rather than starting from scratch.
 
 ## Step 5: Decide on DESIGN.md