feat(skills): product fold-ins for pricing, forms, signup, activation, listing, and IA

.claude/skills/spgr-scope-mvp/SKILL.md

@@ -17,12 +17,13 @@ Define the minimum viable product scope by cutting everything that is not requir
 | `value-proposition` | One-line statement of the core value the product delivers. |
 | `target-icp` | Ideal Customer Profile the MVP must serve. |
 | `capacity-estimate` | Available development capacity for the MVP window. |
+| `activation-event` | The PRD `activation_event` on `saas` and `mobile`, the action that proves the value proposition reached the user. Read from the PRD via spgr-read-artifact. |
 
 ## Outputs
 
 | Artifact | Description |
 |----------|-------------|
-| `mvp-scope` | MVP definition statement (one paragraph on what the MVP is and is not), in-scope feature list with a rationale per inclusion, out-of-scope feature list with a rationale and a planned deferral phase per item, the end-to-end core user journey the MVP must support, and success criteria stating the user behavior or metric that confirms the value proposition is validated. |
+| `mvp-scope` | MVP definition statement (one paragraph on what the MVP is and is not), in-scope feature list with a rationale per inclusion, out-of-scope feature list with a rationale and a planned deferral phase per item, the end-to-end core user journey the MVP must support, the minimum path to value from signup to the activation event, and success criteria stating the user behavior or metric that confirms the value proposition is validated. |
 
 ## Procedure
 
@@ -32,9 +33,10 @@ Define the minimum viable product scope by cutting everything that is not requir
 4. Test each backlog item against the journey. Ask: if we remove this, does the core user journey break? If yes, mark it in-scope and write the rationale. If no, mark it a deferral candidate.
 5. Apply the standing priors. Authentication is almost always in scope, since users need an identity. Billing is frequently out of scope, since you validate before monetizing. Record any departure from these priors as a decision with spgr-log-decision.
 6. Assign each out-of-scope item a planned deferral phase and a rationale. Defer, do not reject. A user who definitely wants a feature will still want it in a later sprint.
-7. Write the success criteria. State the observable user behavior or metric that confirms the core value proposition is validated.
-8. When a deferral or inclusion touches a vertical domain (for example deferring billing, or scoping auth), consult the owning vertical with spgr-tag-vertical-agent and fold the recommendation in before finalizing.
-9. Write the mvp-scope artifact with spgr-write-artifact. If a downstream go/no-go gate or scope change requires human judgment, route it with spgr-notify-human.
+7. Write the minimum path to value on `saas` and `mobile`. Inventory every step between signup and the activation event, including each screen, each form field, each confirmation, and each wait, because teams undercount their own steps. Mark each step essential or removable, where essential means the activation event cannot fire without it. Remove or defer the removable steps, reorder what remains so the user reaches value before any setup that can wait, and move deferred setup behind the activation event with progressive disclosure. Name the analytics event each remaining step emits, so the funnel from signup to activation is measurable from the first release. The step list is a section of the artifact, and the step count before and after is recorded with spgr-log-decision.
+8. Write the success criteria. State the observable user behavior or metric that confirms the core value proposition is validated.
+9. When a deferral or inclusion touches a vertical domain (for example deferring billing, or scoping auth), consult the owning vertical with spgr-tag-vertical-agent and fold the recommendation in before finalizing.
+10. Write the mvp-scope artifact with spgr-write-artifact. If a downstream go/no-go gate or scope change requires human judgment, route it with spgr-notify-human.
 
 ## Notes
 

.claude/skills/spgr-write-app-store-listing/SKILL.md

@@ -28,17 +28,18 @@ Write the store-facing listing content for both iOS App Store and Google Play as
 ## Procedure
 
 1. Read each input with spgr-read-file. If a target-keyword list, a value proposition, or screenshots at the required sizes are missing, stop and raise spgr-escalate rather than inventing them. The keyword and screenshot inputs drive ASO ranking and conversion and cannot be assumed.
-2. Write the App Store app name and subtitle first, since these carry the most keyword weight in App Store search. Place the primary keyword in the app name when the brand name does not already contain it. Keep the app name and subtitle each within 30 characters.
-3. Write the iOS keywords field as a comma-separated, case-insensitive list within 100 characters. Exclude the app name and any word already in the app name, since the algorithm indexes those. Do not pad with spaces after commas, which waste the character budget.
-4. Write the App Store description (<=4000 chars) and promotional text (<=170 chars). Note in the artifact that promotional text updates without app review, so reserve it for time-sensitive messaging.
-5. Write the Google Play title (<=30 chars), short description (<=80 chars), and full description (<=4000 chars). Map the same value proposition and keywords to Play's fields, since Play indexes the full description text.
-6. Plan the screenshots as an ordered story rather than a UI tour. Mark the first screenshot as the highest-priority asset, since most users decide to install or skip before scrolling past it. Specify the required device sizes per platform and the feature graphic for Play.
-7. Specify the App Preview video (iOS) and promotional video (Play): orientation, length, and the user flow each shows.
-8. Set the localization scope: list which markets require a localized listing and which inherit the default-language listing.
-9. Write a product-page A/B test plan: App Store Connect product page optimization and Google Play Console store listing experiments both support testing screenshots and descriptions. Name the elements under test, the variant hypotheses, and the conversion metric each test reads.
-10. Screen every element against store content policy before writing the artifact. Reject and rewrite any screenshot that shows a competitor app, is a mockup rather than an actual app screen, or any description that makes an unsubstantiated superlative claim such as "best app ever". If an input forces a policy violation that cannot be rewritten away, raise spgr-escalate with the conflicting input named.
-11. Write the artifact with spgr-write-artifact and validate inline with spgr-validate-artifact. Record the keyword strategy and any policy-driven rewrites in the decision log with spgr-log-decision. Version with spgr-version-artifact on revision.
-12. Route any recommendation to the design agent (for example a screenshot recapture) or the PM agent through spgr-tag-vertical-agent as a consultation. Do not edit another agent's artifact directly.
+2. Fix the indexed surface per store before writing a word, because each store ranks on different fields. App Store search indexes the app name (30 characters), the subtitle (30 characters), and the keywords field (100 bytes), and does not index the description. Google Play indexes the title (30 characters), the short description (80 characters), and the full description (4000 characters). Spend the primary keywords on the indexed fields of each store and treat the App Store description as conversion copy only.
+3. Write the App Store app name and subtitle first, since these carry the most keyword weight in App Store search. Place the primary keyword in the app name when the brand name does not already contain it. Keep the app name and subtitle each within 30 characters.
+4. Write the iOS keywords field as a comma-separated, case-insensitive list within 100 characters. Exclude the app name and any word already in the app name, since the algorithm indexes those. Do not pad with spaces after commas, which waste the character budget.
+5. Write the App Store description (<=4000 chars) and promotional text (<=170 chars). Note in the artifact that promotional text updates without app review, so reserve it for time-sensitive messaging.
+6. Write the Google Play title (<=30 chars), short description (<=80 chars), and full description (<=4000 chars). Map the same value proposition and keywords to Play's fields, since Play indexes the full description text. Keep the Play title free of emoji, all-caps words, superlatives such as best, and calls to action such as download now, which Play's metadata policy rejects.
+7. Plan the screenshots as an ordered story rather than a UI tour. The first three screenshots are the set shown in search results on both stores, and their caption text is indexed, so the first three carry the value proposition in order and their captions carry keywords. Mark the first screenshot as the highest-priority asset, since most users decide to install or skip before scrolling past it. Specify the required device sizes per platform and the feature graphic for Play.
+8. Specify the App Preview video (iOS) and promotional video (Play): orientation, length, and the user flow each shows. The App Store autoplays the preview in search results and on the product page, so its first seconds show the core action with no title card. Play shows the video behind a play control on the listing, so its first frame is the poster.
+9. Set the localization scope: list which markets require a localized listing and which inherit the default-language listing.
+10. Write a product-page A/B test plan: App Store Connect product page optimization and Google Play Console store listing experiments both support testing screenshots and descriptions. Name the elements under test, the variant hypotheses, and the conversion metric each test reads.
+11. Screen every element against store content policy before writing the artifact. Reject and rewrite any screenshot that shows a competitor app, is a mockup rather than an actual app screen, or any description that makes an unsubstantiated superlative claim such as "best app ever". If an input forces a policy violation that cannot be rewritten away, raise spgr-escalate with the conflicting input named.
+12. Write the artifact with spgr-write-artifact and validate inline with spgr-validate-artifact. Record the keyword strategy and any policy-driven rewrites in the decision log with spgr-log-decision. Version with spgr-version-artifact on revision.
+13. Route any recommendation to the design agent (for example a screenshot recapture) or the PM agent through spgr-tag-vertical-agent as a consultation. Do not edit another agent's artifact directly.
 
 ## Notes
 

.claude/skills/spgr-write-auth-flow/SKILL.md

@@ -39,11 +39,13 @@ Write the sequence-level specification for each authentication flow so a develop
    - Password reset: request, email delivery, token validation, token expiry. Reset tokens carry an explicit expiry of 15 to 60 minutes and are single-use. Document the invalidation mechanism so a used or expired token cannot be replayed.
    - MFA: enrollment, challenge, and recovery code flow.
 
-5. Generate one Mermaid sequence diagram per flow from the written steps so the diagram and text share a single source. Include both the happy path and the failure branches in the diagram via alt and opt blocks. Verify each diagram parses as valid Mermaid before write.
+5. Specify the signup flow's field set and friction rules alongside its security paths, because the signup form is where an auth flow loses most of its users. Hold the first step to three fields or fewer, and when the requirements need more, split into steps with a progress indicator and the easy questions first. Defer every field that can be inferred or asked later: company from the email domain, role, phone, and team size are collected after the activation event, not at signup. Order social sign-in by audience: Google, Apple, then Facebook for a consumer product, and Google, Microsoft, then SSO for a business product, and omit any provider the auth model does not name. Offer a magic-link alternative to the password where the auth model allows it. Defer email verification until the user takes an action that needs a verified address, and let them into the product first. Reject these in the flow: a confirm-email field, paste disabled on the password field, a placeholder standing in for a label, a CAPTCHA shown to every user by default rather than after a risk signal, and phone verification required by default. The form's visual and accessibility rules live in spgr-write-component and spgr-write-accessibility-annotations.
 
-6. Tag the Auth vertical for review with spgr-tag-vertical-agent on any flow that deviates from the auth model or the provider's documented sequence, and record the recommendation. Use spgr-log-decision to capture consequential choices (lockout thresholds, token lifetimes, account-linking rules) with their rationale and rejected alternatives.
+6. Generate one Mermaid sequence diagram per flow from the written steps so the diagram and text share a single source. Include both the happy path and the failure branches in the diagram via alt and opt blocks. Verify each diagram parses as valid Mermaid before write.
 
-7. Write the artifact with spgr-write-artifact. Because auth-flow is not yet a registered schema type, the envelope header, confidence map, and decision log still apply, and the content is validated against the auth-flow schema once it is registered in a later build increment.
+7. Tag the Auth vertical for review with spgr-tag-vertical-agent on any flow that deviates from the auth model or the provider's documented sequence, and record the recommendation. Use spgr-log-decision to capture consequential choices (lockout thresholds, token lifetimes, account-linking rules) with their rationale and rejected alternatives.
+
+8. Write the artifact with spgr-write-artifact. Because auth-flow is not yet a registered schema type, the envelope header, confidence map, and decision log still apply, and the content is validated against the auth-flow schema once it is registered in a later build increment.
 
 ## Notes
 

.claude/skills/spgr-write-component/SKILL.md

@@ -37,13 +37,15 @@ Produce one UI component that is visually identical to the approved design spec,
 5. Implement each state. Resolve every style value to a design token reference. Do not write a hardcoded hex value, pixel value, or font size into the component styles. A raw style value is a token violation and fails this skill.
 6. Implement the accessibility annotations exactly as written: ARIA roles, focus behavior, keyboard interactions, and screen reader announcements. Do not paraphrase or omit an annotation.
 7. Apply YAGNI. Build only the states and props the spec and contract specify. Do not add states, variants, or props the spec does not list.
-8. Write one Storybook story per state so design QA can review every state in isolation.
-9. Run the component and visual regression suite via spgr-run-tests. Confirm every state renders as the spec describes and every regression case passes. Then capture the stories or the screen with `.claude/skills/spgr-render-design-comps/scripts/capture-comps.py` when the Playwright CLI is installed, read the captures, and self-critique against the craft floor, the motion standards, and the interface rules in `.claude/references/design-quality.md`. Fix a calibration-cluster hit or a floor miss before the PR opens.
-10. Lint and format the component, stories, and contract clean before commit. For TypeScript or JavaScript, conform to `.claude/references/typescript-standards.md` and pass `tsc --noEmit`. Keep the component to one logical change per commit.
-11. Write the files via spgr-write-file. Record any consequential implementation choice, such as a token chosen where the spec was ambiguous, via spgr-log-decision.
+8. When the component is a form or a form field, hold it to the form rules. Count the fields: three is the baseline for a signup or lead form, four to six costs completions, and seven or more needs a written reason in the spec. Every field has a visible label, never a placeholder standing in for one. Lay fields out in a single column. Set the input type and keyboard that match the data (email, tel, number, url) and leave autofill on with the matching autocomplete attribute. On mobile keep the submit control reachable without scrolling back, sticky at the bottom when the form is longer than the viewport. Write the button copy as the action plus what the user gets, never Submit or Learn more. Build the loading state on the submit control so a double tap cannot send twice. Touch target size, label association, and error association are accessibility annotations and come from spgr-write-accessibility-annotations, so implement them as written rather than re-deriving them here.
+9. When the component has an empty state, make it an entry point rather than a notice. Show the exact next action and offer it as one click or one field. Show the action the user can take, not a description of the capability. Where the product allows it, let the user try the feature with sample data before any setup. Empty-state copy comes from the screen spec, and a missing empty-state action is an escalation to the Design agent, not an invention.
+10. Write one Storybook story per state so design QA can review every state in isolation.
+11. Run the component and visual regression suite via spgr-run-tests. Confirm every state renders as the spec describes and every regression case passes. Then capture the stories or the screen with `.claude/skills/spgr-render-design-comps/scripts/capture-comps.py` when the Playwright CLI is installed, read the captures, and self-critique against the craft floor, the motion standards, and the interface rules in `.claude/references/design-quality.md`. Fix a calibration-cluster hit or a floor miss before the PR opens.
+12. Lint and format the component, stories, and contract clean before commit. For TypeScript or JavaScript, conform to `.claude/references/typescript-standards.md` and pass `tsc --noEmit`. Keep the component to one logical change per commit.
+13. Write the files via spgr-write-file. Record any consequential implementation choice, such as a token chosen where the spec was ambiguous, via spgr-log-decision.
 
 ## Notes
 
-- This skill produces source code. Verification is by spgr-run-tests, the visual regression suite, CI, and the self-critique in step 9, not by an envelope schema. The design bar the Code Reviewer holds the PR to is `.claude/references/design-quality.md`, so clear it here first. For full accessibility conformance against a WCAG target, the component is later audited by spgr-run-accessibility-audit.
+- This skill produces source code. Verification is by spgr-run-tests, the visual regression suite, CI, and the self-critique in step 11, not by an envelope schema. The design bar the Code Reviewer holds the PR to is `.claude/references/design-quality.md`, so clear it here first. For full accessibility conformance against a WCAG target, the component is later audited by spgr-run-accessibility-audit.
 - Escalate via spgr-escalate when the spec does not define a required state's appearance or behavior, when a style value the spec calls for has no matching design token, when the accessibility annotations are missing or contradict the component contract, or when the spec and the component contract disagree on props or events. Return the precise list of what is missing rather than guessing.
 - When the component touches a vertical concern such as accessibility conformance or an auth-gated state, consult the specialist via spgr-tag-vertical-agent before finalizing.