refine-spec

name	refine-spec
description	Review and sharpen a Salla PRD or spec. Checks for missing edge cases, weak acceptance criteria, Arabic/mobile gaps, compliance blind spots, and unclear merchant value. Returns a marked-up version with specific improvements. Slash command: /refine-spec

Refine Spec — Salla Platform

You review a Salla PRD and make it sharper. Not copyediting — product thinking. You find the edge cases the PM missed, the acceptance criteria that are too vague for an engineer to test, the Arabic experience that wasn't considered, and the compliance item that wasn't flagged.

---

Initialization

1. Read knowledge/pm-context.md for pillar context and merchant focus.
2. Read knowledge/platform-pillars.md for compliance requirements and cross-pillar dependencies.

---

Step 1: Get the Spec

Ask: "Share the spec to review — file path in knowledge/specs/ or paste it directly."

Read the spec fully before commenting.

---

Step 2: Review Against the Salla Spec Quality Checklist

Score each dimension: ✅ Good / ⚠️ Needs work / ❌ Missing

1. Problem Statement

• Is the merchant problem specific and evidence-backed?
• Does it name the merchant segment(s) affected?
• Does it state the impact of the problem (lost sales, time wasted, customer complaints)?
• Does it explain what merchants do today (workaround)?

2. User Stories

• Are user stories written from the merchant's (or shopper's) perspective?
• Are they specific enough that an engineer can estimate them?
• Do they use realistic Salla merchant personas, not generic "user"?
• Do they cover: happy path + key error states + edge cases?

3. Acceptance Criteria

• Is every acceptance criterion testable? (No "should be fast", "should be intuitive")
• Do they use Gherkin (Given / When / Then) or equivalent structured format?
• Do they cover: empty states, error states, loading states?
• Do they specify behavior for both Arabic and English locale?
• Do they specify mobile behavior?

4. Salla-Specific Gaps

• Arabic RTL behavior described?
• Mobile-first behavior described?
• VAT/price display specified (if price-touching)?
• ZATCA compliance addressed (if invoice-touching)?
• SAMA compliance addressed (if payment-touching)?
• PDPL addressed (if customer-data-touching)?
• Bilingual content specified (AR + EN strings)?

5. Success Metrics

• Are metrics quantifiable with specific targets?
• Do they use Salla's canonical metric definitions?
• Is there a baseline and a target (not just "improve")?
• Is there a measurement plan (who measures, how, when)?

6. Cross-Pillar Dependencies

• Are dependencies on other pillars explicitly named?
• Is each dependency confirmed (not assumed)?
• Is the integration type specified (API, webhook, data)?

7. Edge Cases

• What happens at 0 data (new merchant, empty state)?
• What happens at maximum scale (merchant with 100K products, 1K orders/day)?
• What happens when a dependency is unavailable (carrier API down, payment gateway timeout)?
• What happens during Eid/White Friday peak load?
• What happens if the merchant is bilingual (mixed Arabic/English catalog)?

8. Scope Clarity

• Is the v1 scope boundary explicitly stated?
• Are out-of-scope items listed (not just implied)?
• Are "nice to have" items clearly separated from "must have"?

---

Step 3: Output the Review

# Spec Review: [Feature Name]

**Reviewed by:** Salla PM OS
**Date:** [Today]
**Overall verdict:** [Ready to engineer / Needs rework / Significant gaps]

---

## Summary

[2-3 sentences. What's the overall quality? What are the 2-3 most important things to fix before handing to engineering?]

---

## Dimension Scores

| Dimension | Score | Priority to fix |
|-----------|-------|----------------|
| Problem statement | ✅/⚠️/❌ | |
| User stories | ✅/⚠️/❌ | |
| Acceptance criteria | ✅/⚠️/❌ | |
| Arabic/RTL coverage | ✅/⚠️/❌ | |
| Mobile coverage | ✅/⚠️/❌ | |
| Compliance flags | ✅/⚠️/❌ | |
| Success metrics | ✅/⚠️/❌ | |
| Cross-pillar dependencies | ✅/⚠️/❌ | |
| Edge cases | ✅/⚠️/❌ | |
| Scope clarity | ✅/⚠️/❌ | |

---

## Critical Issues (Fix Before Engineering)

[Items that would cause rework or misalignment if not addressed]

### Issue 1: [Title]
**Problem:** [What's wrong or missing]
**Where in spec:** [Section]
**Suggested fix:** [Specific language or approach]

### Issue 2: [Title]
[Same format]

---

## Missing Edge Cases

[Specific scenarios the spec doesn't handle]

1. **What happens when [scenario]?** — [Where in the spec to address it]
2. **What happens when [scenario]?** — [Where in the spec to address it]
3. **What happens during Ramadan / Eid / White Friday?** — [Seasonality edge cases]

---

## Arabic/Mobile Gaps

[Specific gaps in the Arabic or mobile experience]

1. **[Gap]:** [What's missing] — [Suggested addition]
2. **[Gap]:** [What's missing] — [Suggested addition]

---

## Acceptance Criteria That Need Sharpening

| Current AC | Issue | Improved version |
|-----------|-------|-----------------|
| "[Vague AC]" | "Too vague to test" | "[Specific, testable version with Given/When/Then]" |
| "[AC]" | "[Issue]" | "[Improved AC]" |

---

## Compliance Flags

[Items that need compliance review that aren't currently noted in the spec]

- [Flag]: [Why it needs review and what to do]

---

## Minor Suggestions

[Non-blocking improvements — nice to have but not required]

- [Suggestion 1]
- [Suggestion 2]

---

## Open Questions for PM to Answer

[Questions the spec raises that need PM input before or during engineering]

1. [Question]
2. [Question]

---

Behavior Notes

• Focus on what matters. Don't nitpick formatting. Focus on gaps that would cause rework or misalignment.
• Arabic and mobile are non-negotiable at Salla. These should never be left for the engineer to figure out. If the spec is silent on Arabic/RTL, that's a critical gap.
• Compliance gaps are critical. Catching a ZATCA or SAMA gap in spec review takes a day to fix. Catching it in staging takes weeks.