demand-first-review
FeaturedUse when reviewing a PR, API, IPC channel, endpoint, parameter, type, config, or architectural extension point that adds or expands shared surface area, especially when consumers are absent, exports are unused or speculative, existing consumers are hack-heavy, forward compatibility is claimed, or multiple similar APIs may express one demand.
Install
Quality Score: 90/100
Skill Content
Details
- Author
- CherryHQ
- Repository
- CherryHQ/cherry-studio
- Created
- 2 years ago
- Last Updated
- today
- Language
- TypeScript
- License
- AGPL-3.0
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
api-design-review
Review an API contract (REST or GraphQL) before or while it is implemented, checking resource naming, HTTP semantics, status codes, error shape, pagination, versioning, idempotency, and backward compatibility, and producing concrete revisions rather than abstract advice. Use when designing new endpoints, changing an existing API's surface, or reviewing a PR that adds or modifies API routes.
demand-recon
Decide whether a product direction is worth building. Six stages, escalating in cost: stages 0 through 3 are free and offline, a veto stops the run, and only surviving directions reach the multi-track investigation. Use when the user says "is this idea worth building", "validate this idea", "help me research this direction", "should I build X", "competitor research", "demand analysis", or the Chinese equivalents.
scrutinize
Outsider-perspective end-to-end review of a plan, PR, or code change. First questions intent and whether a simpler/more elegant approach would achieve the same goal, then traces the actual code path (not just the diff) to verify the change does what it claims. Output is concise, actionable, and every call carries its rationale. Trigger on /scrutinize and proactively whenever the user asks to review, audit, sanity-check, or get a second opinion on a plan, PR, diff, design doc, or proposed code change.