fix: apply skill-reviewer feedback and preserve prototype to durable path

- Move preserved prototypes from .context/ to prototypes/<topic>/ at
  repo root since .context/ is ephemeral scratch space
- Add trigger phrases: 'feasibility check', 'experiment with this',
  'will this actually work'
- Mark origin field as optional in template to match schema
- Add example validation report in examples/ for LLM quality reference
- Update prototype_path description in schema

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: rodrigohaertel-ctrl

plugins/compound-engineering/skills/ce-prototype/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ce:prototype
-description: "Build a throwaway prototype to validate assumptions before committing to an implementation plan. Use when the user says 'prototype this', 'let me test this idea first', 'spike on this', 'validate this before planning', 'build a quick prototype', 'I want to test if this works', 'try this out before we plan', 'proof of concept', 'quick test', 'throwaway prototype', or 'validate assumptions'. Also use when a brainstorm or requirements document contains untested assumptions about APIs, data sources, UX patterns, or integrations, or when the user wants to de-risk before planning."
+description: "Build a throwaway prototype to validate assumptions before committing to an implementation plan. Use when the user says 'prototype this', 'let me test this idea first', 'spike on this', 'validate this before planning', 'build a quick prototype', 'I want to test if this works', 'try this out before we plan', 'proof of concept', 'quick test', 'throwaway prototype', 'validate assumptions', 'feasibility check', 'experiment with this', or 'will this actually work'. Also use when a brainstorm or requirements document contains untested assumptions about APIs, data sources, UX patterns, or integrations, or when the user wants to de-risk before planning."
 argument-hint: "[optional: feature description, requirements doc path, or specific assumptions to validate]"
 ---
 
@@ -194,7 +194,7 @@ If anything is found, flag it to the user with a brief explanation. Let them dec
 
 Delete the prototype directory under `.context/compound-engineering/ce-prototype/`. The validation report in `docs/prototypes/` persists.
 
-If the user explicitly asks to keep the prototype, respect that — but note in the validation report that the prototype code still exists and where.
+If the user explicitly asks to keep the prototype, move it out of `.context/` (which is ephemeral scratch space subject to cleanup) to a durable location: `prototypes/<topic-slug>/` at the repo root. Note the preserved path in the validation report.
 
 #### 4.3 Recommend Next Step
 
@@ -238,7 +238,7 @@ If this prototype was triggered manually (not from a brainstorm recommendation):
 - `docs/prototypes/<topic-slug>-validation-<date>.md` — Validation report
 
 **Temporary output (deleted after report):**
-- `.context/compound-engineering/ce-prototype/<topic-slug>-<YYYYMMDD-HHMMSS>/` — Throwaway prototype code
+- `.context/compound-engineering/ce-prototype/<topic-slug>-<YYYYMMDD-HHMMSS>/` — Throwaway prototype code (moved to `prototypes/<topic-slug>/` if user chooses to keep it)
 
 ## Success Output
 

plugins/compound-engineering/skills/ce-prototype/assets/validation-report-template.md

@@ -7,7 +7,7 @@ Use this template when writing prototype validation reports to `docs/prototypes/
 title: [Topic] Prototype Validation
 date: YYYY-MM-DD
 topic: <kebab-case-topic>
-origin: <path to requirements doc, if any>
+origin: <path to requirements doc, if any> # optional
 status: complete | partial
 goals_proved: <count>
 goals_disproved: <count>
@@ -67,6 +67,6 @@ tags: [prototype, validation, keyword-one, keyword-two]
 
 **Tech used:** [e.g., Static HTML + fetch API, Python script, curl commands]
 **Time spent:** [Actual effort, e.g., "~25 minutes"]
-**Prototype location:** [Deleted / Preserved at <path>]
+**Prototype location:** [Deleted / Preserved at prototypes/<topic-slug>/]
 **Artifacts preserved:** [List any files moved out of prototype before deletion, or "none"]
 ```

plugins/compound-engineering/skills/ce-prototype/examples/stripe-refund-webhooks-validation.md

@@ -0,0 +1,73 @@
+---
+title: Stripe Refund Webhooks Prototype Validation
+date: 2026-04-04
+topic: stripe-refund-webhooks
+origin: docs/brainstorms/2026-04-01-stripe-refund-webhooks-requirements.md
+status: complete
+goals_proved: 2
+goals_disproved: 1
+goals_inconclusive: 1
+tags: [prototype, validation, stripe, webhooks, refunds]
+effort_minutes: 30
+iterations: 2
+---
+
+# Stripe Refund Webhooks Prototype Validation
+
+## Summary
+
+Prototyped Stripe webhook handling for refund events to validate payload structure, delivery latency, and rate limit viability before planning the refund notification system. Payload and latency validated well; free tier rate limits are insufficient for peak traffic.
+
+## Origin
+
+**Requirements document:** `docs/brainstorms/2026-04-01-stripe-refund-webhooks-requirements.md`
+**Prototype trigger:** Requirements assumed webhook payload includes refund metadata -- needed verification against real API behavior.
+
+## Validation Goals and Results
+
+### Goal 1: Stripe webhook payload includes refund metadata fields
+
+- **Status:** Proved
+- **Evidence:** Triggered test refund events via Stripe CLI. The `charge.refund.updated` event payload includes `reason`, `receipt_number`, `amount`, `currency`, and `metadata` object. All fields needed for the notification system are present.
+- **Detail:** Metadata is nested under `data.object.metadata`, not at the top level. The plan should reference this path explicitly.
+
+### Goal 2: Webhook delivery latency is under 2s for test events
+
+- **Status:** Proved
+- **Evidence:** Measured 50 test webhook deliveries. Mean latency: 340ms. P95: 890ms. Max: 1.4s. All within the 2s threshold.
+
+### Goal 3: Free tier webhook rate limit is sufficient for peak traffic
+
+- **Status:** Disproved
+- **Evidence:** Free tier allows 500 webhooks/hour. Peak traffic estimate from requirements: 1,200 refund events/hour during holiday sales. Free tier covers ~42% of peak demand.
+- **Detail:** Paid tier ($0.01/event beyond free tier) or a queuing strategy needed. Estimated monthly cost at peak: ~$168.
+
+### Goal 4: Retry logic handles partial failures gracefully
+
+- **Status:** Inconclusive
+- **Evidence:** Stripe retries failed deliveries up to 3 times with exponential backoff. Simulated partial failures (returning 500 on first attempt, 200 on retry) worked correctly. However, the test only covered single-event retries -- behavior under concurrent retry storms during an outage recovery was not tested.
+
+## Surprises
+
+- Webhook signature verification requires access to the raw request body. Express middleware that parses JSON before signature verification will break it. The implementation must use `express.raw()` on the webhook endpoint.
+
+## Constraints Discovered
+
+| Constraint | Impact | Mitigation |
+|-----------|--------|------------|
+| Free tier: 500 webhooks/hour | Insufficient for peak traffic (1,200/hr) | Implement queuing strategy or upgrade to paid tier |
+| Refund metadata format changed in Stripe API v2024-12 | Field paths differ between API versions | Pin API version in webhook endpoint configuration |
+| Signature verification needs raw body | Standard JSON parsing middleware breaks verification | Use `express.raw()` middleware on webhook route |
+
+## Recommendations
+
+- **For planning:** Pin Stripe API version, use `express.raw()` on webhook endpoint, implement a queue for peak traffic buffering.
+- **For requirements:** Update rate limit assumption -- free tier is insufficient. Decision needed: paid tier vs. queuing.
+- **For further prototyping:** Retry behavior under concurrent storm conditions (Goal 4) should be validated once the queue architecture is designed.
+
+## Prototype Details
+
+**Tech used:** Node.js script, Stripe CLI for webhook forwarding, manual event triggers
+**Time spent:** ~30 minutes
+**Prototype location:** Deleted
+**Artifacts preserved:** None

plugins/compound-engineering/skills/ce-prototype/references/validation-report-schema.md

@@ -21,7 +21,7 @@ Canonical frontmatter fields for prototype validation reports in `docs/prototype
 | `origin` | string (repo-relative path) | Path to the upstream requirements document, if any |
 | `tags` | array[string] | Search keywords, lowercase and hyphen-separated. Always include `prototype` and `validation`. Max 8 tags. |
 | `prototype_preserved` | boolean | Whether the prototype code was kept (default: false) |
-| `prototype_path` | string | Path to preserved prototype, if `prototype_preserved: true` |
+| `prototype_path` | string | Path to preserved prototype (e.g., `prototypes/<topic-slug>/`), if `prototype_preserved: true` |
 | `effort_minutes` | integer | Approximate time spent on the prototype |
 | `iterations` | integer | Number of build-feedback iterations before final validation (typically 1-3) |