Add generic feature-building toolkit and ClickUp demo workflow docs.

Encode PRD-to-UI delivery as reusable feature-* commands, skills, and a feasibility subagent, with a presenter script and example PRD for the favorites demo.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: mattfromcursor

.cursor/agents/feature-feasibility-auditor.md

@@ -0,0 +1,69 @@
+---
+name: feature-feasibility-auditor
+description: Reviews repo feasibility and risks for a scoped shopper-facing WebApp feature from a PRD. Read-only unless the user explicitly asks to implement.
+disable-model-invocation: true
+---
+
+# feature-feasibility-auditor
+
+## When to use
+- The user wants to add a feature described in a PRD.
+- The agent already has a first-pass design intent and needs a specialist feasibility audit before implementation.
+
+## Scope
+Focus on WebApp UX and state correctness:
+- header composition and primary visible surface behavior
+- catalog/product surfaces where the user initiates the feature
+- state update mechanics across navigation
+- preventing duplicates and keeping the new behavior distinct from adjacent patterns (e.g., cart/basket)
+
+## Repo anchors to inspect (prefer these first)
+Use the PRD and design pass to identify touchpoints. Common eShop WebApp anchors:
+- Header UI and structure:
+  - `src/WebApp/Components/Layout/HeaderBar.razor`
+  - `src/WebApp/Components/Layout/CartMenu.razor`
+- Product surfaces:
+  - `src/WebApp/Components/Pages/Catalog/Catalog.razor`
+  - `src/WebAppComponents/Catalog/CatalogListItem.razor`
+  - `src/WebApp/Components/Pages/Item/ItemPage.razor`
+- State pattern guidance:
+  - `src/WebApp/Services/BasketState.cs`
+  - `src/WebApp/Services/IBasketState.cs`
+
+## Audit checklist
+1. **Insertion point correctness**
+   - Can the feature affordance exist on the chosen surfaces without UI clutter?
+   - Does it fit the existing component/style patterns?
+
+2. **Primary UX surface correctness**
+   - How does the visible outcome populate (empty -> populated)?
+   - How does it update when the user triggers the feature action?
+   - Does it remain consistent across navigation?
+
+3. **State strategy fit**
+   - Prefer adapting existing state patterns rather than inventing new architecture.
+   - Identify how/where state should live (in-memory vs persisted) given the PRD constraints.
+   - Confirm that update notifications exist so dependent UI re-renders when state changes.
+
+4. **Duplicate and identity handling**
+   - Ensure items are keyed by stable identifiers, not transient UI identity.
+   - Verify the design prevents duplicates and handles repeated actions.
+
+5. **Distinctness from adjacent features**
+   - Visual and behavioral separation from similar existing patterns (e.g., cart/basket).
+   - Ensure the new action does not accidentally trigger unrelated mutations.
+
+6. **Testing implications**
+   - Identify which existing unit/integration test strategy is most relevant (if any).
+   - Identify which E2E checks are most valuable to prevent regressions.
+
+## Output contract
+Return:
+- `## Critical risks` (ranked; include what could break)
+- `## Should-fix design concerns` (concrete gaps)
+- `## Easiest safe implementation path` (highest-level plan, minimal scope)
+- `## Verification implications` (what must be tested and where)
+
+## Guardrails
+- Read-only by default: do not implement changes.
+- If the PRD is ambiguous, explicitly state what choice you need before implementation.

.cursor/commands/feature-build-handoff.md

@@ -0,0 +1,58 @@
+---
+name: feature-build-handoff
+description: Turns an approved design pass into a concrete implementation + test handoff plan. Coordinate WebApp UI/state changes and focused E2E coverage; do not execute builds by itself.
+---
+
+# feature-build-handoff
+
+## What to do
+1. Re-read the PRD (user-specified path; default: `docs/CLICKUP_ESHOP_PRD.md`).
+2. Re-use the most recent outputs from `prd-to-figma-feasibility` and `feature-feasibility-auditor` (scope decision, state strategy, and risk list).
+3. Translate the approved intent into a minimal WebApp implementation plan:
+   - choose initiation surface(s) from the PRD
+   - design primary UX surface behavior (empty -> populated, update rules, navigation behavior)
+   - define state storage strategy consistent with PRD constraints
+
+## Implementation scope suggestions
+Prefer smallest changes that keep the new feature distinct from adjacent patterns. Common eShop touchpoints:
+- UI surfaces:
+  - `src/WebApp/Components/Layout/HeaderBar.razor`
+  - `src/WebApp/Components/Layout/CartMenu.razor` (as a UI/state pattern reference)
+  - `src/WebApp/Components/Pages/Catalog/Catalog.razor`
+  - `src/WebAppComponents/Catalog/CatalogListItem.razor`
+  - `src/WebApp/Components/Pages/Item/ItemPage.razor`
+- State pattern reference:
+  - `src/WebApp/Services/BasketState.cs`
+  - `src/WebApp/Services/IBasketState.cs`
+
+If the implementation requires API changes, explicitly call out:
+- which backend service owns the truth,
+- what the data contract should be,
+- and which integration events (if any) become relevant.
+
+## Test and verification handoff
+Produce a focused verification plan that includes:
+1. Unit test or handler test coverage only when the implementation adds real logic that can regress.
+2. A targeted Playwright E2E check that proves PRD acceptance criteria end-to-end.
+
+## Review gate (before opening a PR)
+Before code is considered ready to PR:
+- list the files expected to change
+- summarize how duplicates or inconsistent state are prevented
+- summarize how the primary UX surface stays consistent across navigation
+- confirm no accidental coupling to unrelated features
+
+## Output requirements
+Return:
+- `## Implementation plan` (step list)
+- `## Files likely to change`
+- `## Test plan` (what to add/extend and what it proves)
+- `## Remaining risks to resolve before PR`
+
+## Automation talking points (end-to-end, optional)
+If you want this handoff to run via cloud agents:
+- Trigger idea: PR opened/updated with changes under the feature touchpoints identified in the design pass.
+- Cloud agent stages:
+  - stage 1: run `feature-feasibility-auditor` (read-only) to restate risks and prevent scope drift
+  - stage 2: produce the minimal implementation + verification plan (this command's output)
+  - stage 3: stop for human approval before any follow-up implementation prompts

.cursor/commands/feature-design-pass.md

@@ -0,0 +1,38 @@
+---
+name: feature-design-pass
+description: Run the PRD -> Figma prototype brief -> repo feasibility pass for a scoped shopper feature. Produce a ready-to-implement design intent and risk memo.
+---
+
+# feature-design-pass
+
+## What to do
+1. Read the PRD (user-specified path; default: `docs/CLICKUP_ESHOP_PRD.md`).
+2. Run the project skill `prd-to-figma-feasibility`.
+3. Identify the most likely WebApp touchpoints for the UX surface and state updates from the PRD.
+4. Ask for scope decisions if the PRD is ambiguous (initiation surfaces, persistence, etc.).
+
+## Optional: Figma prototype pass
+If the session has Figma tooling available and the user explicitly wants a prototype creation step:
+1. Use the `Figma prototype brief` from step 2 as the blueprint.
+2. Generate a simple, single-happy-path prototype showing the PRD's primary flow.
+
+## Output requirements
+Return:
+- The `Figma prototype brief`
+- The `Repo feasibility memo`
+- A short `Risks to resolve before implementation` section
+
+## Hand-off gate
+Do not proceed to implementation work until the feasibility memo is explicit about:
+- scope (WebApp-only vs WebApp + API)
+- state strategy
+- layout regressions and duplicate-risk mitigations
+
+## Automation talking points (end-to-end, optional)
+If you want to automate the full workflow with cloud agents or automations:
+- Trigger idea: Jira issue updated/created for the feature (Epic or story).
+- Cloud agent stages:
+  - stage 1: run `prd-to-figma-feasibility` to produce scope + risk + verification plan
+  - stage 2: run `feature-feasibility-auditor` to validate UX surface and state correctness
+  - stage 3: stop for human approval (before any implementation changes)
+- Follow-up trigger idea: PR opened/updated; run `feature-pr-review-bundle` and attach the verification reminder.

.cursor/commands/feature-intake-planner.md

@@ -0,0 +1,53 @@
+---
+name: feature-intake-planner
+description: Turn a Jira/Slack feature request into a repo-grounded implementation brief with scope, state strategy, risks, and a verification plan. Designed to be run by a cloud agent or presenter before implementation begins.
+---
+
+# feature-intake-planner
+
+## Inputs
+- Primary PRD path (user-specified; default: `docs/CLICKUP_ESHOP_PRD.md`)
+- Optional context (if provided by Jira/Slack):
+  - Jira issue key (example: `ESH-2`)
+  - Slack message text (trim to the essentials)
+  - Any explicit scope preferences from the ticket or thread
+
+## What to do
+1. Parse the PRD for:
+   - the primary UX surface
+   - initiation surface(s)
+   - acceptance criteria (including edge cases like duplicates and separation from adjacent features)
+2. Run `prd-to-figma-feasibility` to produce:
+   - a Figma prototype brief
+   - a repo-grounded feasibility and risk memo
+3. Run `feature-feasibility-auditor` (read-only) to sanity-check:
+   - primary UX surface update correctness
+   - state update notification expectations (re-render behavior)
+   - duplicate prevention approach
+   - separation from adjacent UX patterns
+4. Output a concise implementation brief suitable for the next handoff.
+
+## Output contract
+Return:
+- `## Implementation brief`
+  - Scope decision (smallest safe scope)
+  - Proposed state strategy (prefer adapting existing state patterns)
+  - Top risks (ranked)
+  - Likely touchpoints in the WebApp (primary files)
+  - Verification plan (browser + any focused E2E notes)
+
+## Automation talking points (cloud-agent / automations)
+When you want this to run end-to-end automatically, a practical pattern is:
+- Trigger: Jira issue updated (or Slack message posted in an intake channel).
+- Cloud agent does:
+  1. read PRD + repo anchors,
+  2. produce the implementation brief (with risks + verification plan),
+  3. pause for human approval before code changes.
+
+This preserves the trust story while still removing manual prompt craft.
+
+## Human approval gate
+Do not proceed to implementation until:
+- scope/state strategy is explicit,
+- risks that could break primary UX behavior are addressed,
+- and verification steps are agreed.

.cursor/commands/feature-pr-review-bundle.md

@@ -0,0 +1,55 @@
+---
+name: feature-pr-review-bundle
+description: Run a repeatable feature-specific review checklist for PRs, focusing on UX surface correctness, state consistency, duplicate prevention, and separation from adjacent patterns. Intended for cloud agents or reviewers.
+---
+
+# feature-pr-review-bundle
+
+## What to do
+1. Reconcile PR intent with the PRD (user-specified path; default: `docs/CLICKUP_ESHOP_PRD.md`):
+   - primary user action exists on the chosen surface(s)
+   - primary UX surface updates without reload
+   - acceptance criteria around duplicates and feature separation are met
+2. Focus review on touchpoints identified in the design pass or implementation brief. Common eShop anchors:
+   - `src/WebApp/Components/Layout/HeaderBar.razor`
+   - `src/WebApp/Components/Layout/CartMenu.razor` (pattern comparison)
+   - `src/WebApp/Components/Pages/Catalog/Catalog.razor`
+   - `src/WebAppComponents/Catalog/CatalogListItem.razor`
+   - `src/WebApp/Components/Pages/Item/ItemPage.razor`
+   - state pattern references:
+     - `src/WebApp/Services/BasketState.cs`
+     - `src/WebApp/Services/IBasketState.cs`
+3. Run a specialist sanity check using `feature-feasibility-auditor` read-only guidance:
+   - primary UX surface update correctness
+   - re-render/notification behavior across navigation
+   - duplicate prevention and stable identity keying
+   - distinctness from adjacent UX patterns
+
+## Review checklist (feature correctness)
+- Layout regression risk
+  - new UI does not break existing header/nav
+  - no layout overlap or aria regressions
+- State consistency
+  - primary UX surface updates when the user action is triggered
+  - behavior stays consistent when navigating between related pages
+- Duplicate prevention
+  - repeated actions do not create duplicates (where applicable)
+  - any undo/remove behavior updates the surface correctly
+- Separation from adjacent features
+  - new UI does not reuse unrelated badge or state logic
+  - user action does not mutate unrelated state unintentionally
+- Error behavior
+  - unauthenticated behavior (if any) routes consistently (e.g., to login)
+
+## Tests and verification reminders
+- Unit test only if there is durable WebApp state logic that can regress.
+- E2E (or browser) verification must cover PRD acceptance criteria end-to-end.
+
+## Automation talking points (cloud-agent / automations)
+If you want to automate this end-to-end:
+- Trigger: PR opened/updated with changes under the feature touchpoints.
+- Cloud agent does:
+  1. compute a changed file focus summary
+  2. produce the checklist output
+  3. attach a verification plan note (what to run before merge)
+  4. stop for human review before any implementation follow-ups

.cursor/commands/feature-preflight.md

@@ -0,0 +1,39 @@
+---
+name: feature-preflight
+description: Run an implementation readiness checklist (build, targeted tests, and quick manual verification steps). Intended for use before an end-to-end walkthrough and PR submission.
+---
+
+# feature-preflight
+
+## What to do
+1. Confirm scope from the PRD (user-specified path; default: `docs/CLICKUP_ESHOP_PRD.md`):
+   - feature touchpoints are in WebApp UI and expected surfaces
+   - primary state changes (if any) mirror existing state patterns where appropriate
+2. Build and sanity-check:
+   - `dotnet restore eShop.Web.slnf && dotnet build eShop.Web.slnf`
+3. Run targeted unit tests where feature state could regress:
+   - prefer focused test selection when possible; expand only if failures indicate broader risk
+4. If running locally:
+   - start AppHost (Docker required)
+   - confirm webapp is reachable and auth works for the test user
+5. Manual verification (fast path):
+   - derive steps from PRD acceptance criteria
+   - confirm primary user action and UX surface behavior
+   - confirm duplicate prevention and consistency across navigation (if applicable)
+
+## Output contract
+Return:
+- `## Preflight summary`
+- `## Build/test results` (pass/fail + what you ran)
+- `## Manual verification checklist` (pass/fail per step)
+- `## Go/No-Go recommendation` (based on acceptance criteria)
+- `## Next actions if not ready`
+
+## Automation talking points (cloud-agent)
+If you want to automate this end-to-end:
+- Trigger: scheduled run or PR merged event.
+- Cloud agent does:
+  1. restore/build
+  2. run the smallest relevant test set
+  3. produce a "safe to proceed / not safe" summary
+  4. stop for human confirmation (especially for browser evidence)

.cursor/commands/feature-proof.md

@@ -0,0 +1,41 @@
+---
+name: feature-proof
+description: Run feature verification, draft PR description, and produce a walkthrough script + evidence checklist for the UI proof step.
+---
+
+# feature-proof
+
+## What to do
+1. Re-check the PRD (user-specified path; default: `docs/CLICKUP_ESHOP_PRD.md`) to confirm intended UX and acceptance criteria.
+2. Run the skill `feature-verification` to produce:
+   - `## Verification summary`
+   - a list of tested scenarios
+   - evidence notes (screenshots/links if available)
+3. Draft PR-ready text:
+   - `## Summary` (1-2 paragraphs)
+   - `## What changed` (bullets; no implementation detail explosion)
+   - `## How to verify` (step list matching the verification checklist)
+   - `## Risks` (ranked risks from feasibility audit)
+4. Generate a walkthrough plan:
+   - `## Walkthrough script` (what to say + what to click)
+   - `## Walkthrough step list` (ordered actions)
+   - `## Evidence to record` (what screenshots/video frames to capture)
+
+## Explicit limitations
+- The command should not claim to have recorded or generated video; it should only produce a script and evidence checklist.
+- If verification depends on state persistence choices, include that in the "how to verify" steps.
+
+## Output requirements
+Return:
+- `## Verification summary` (from the verification skill)
+- `## PR draft` (the PR-ready sections above)
+- `## Walkthrough script and evidence plan`
+
+## Automation talking points (end-to-end, optional)
+To automate the final verification/proof stage:
+- Trigger idea: PR merged (or a "ready for verification" label) for the feature change.
+- Cloud agent stages:
+  - stage 1: run `feature-verification` (browser checklist output)
+  - stage 2: draft the PR text and walkthrough step list
+  - stage 3: stop for human recording of video/screenshots (the agent should not claim recording)
+- Human gate: do not open/approve PRs solely from agent-produced evidence; require a person to confirm the browser state.