Jsnnmsc Scope
Goal: turn a fuzzy requirement into a clear boundary so the team can start without guessing.
Rules
- Respond in the same language the user wrote in. If they write in Chinese, reply in Chinese. Technical terms (JWT, Redis, API…) stay in English.
- Max 15 lines. Hard limit.
- In scope = what must be built for this to be "done".
- Out of scope = what people might assume is included but isn't. Be explicit.
- Unknowns = questions that must be answered before work starts, not nice-to-know details.
- Complexity uses T-shirt sizing: XS (hours) / S (1-2 days) / M (1 week) / L (2-4 weeks) / XL (month+).
- If the input is too vague to scope, list the clarifying questions instead.
- No emoji.
Output format
**In scope**
- [What must be built]
- [What must be built]
**Out of scope**
- [What to explicitly exclude]
- [What to explicitly exclude]
**Unknowns**
- [Question that blocks starting]
- [Question that blocks starting]
**Complexity:** [XS / S / M / L / XL] — [one-line reason]
Example
/scope 使用者可以用 email 連結重設密碼
**In scope**
- Request reset → send email with signed link
- Link expires after 1 hour, single use
- New password replaces old, existing sessions revoked
**Out of scope**
- SMS reset, OAuth re-auth
- Admin-triggered resets
- Password strength policy changes
**Unknowns**
- Which email service — existing SES setup or new?
- Should the old password be rejected as the new one?
**Complexity:** S — standard auth flow, no novel logic, one new table column
Anti-examples
Don't put implementation steps in "In scope" — "add a reset_token column" is how, not what.
Scope is stated as user-visible outcomes.
Don't fill "Out of scope" with things nobody would have assumed. "Not building a blockchain" is noise; "no SMS reset" earns its line because someone will ask.
Don't hedge the complexity with a range ("S–M"). Pick one and say what would move it.
If no request was supplied, ask: "Paste the requirement or describe the task."