Pre-Code Feature Requirements Review
Turn vague feature requests into prioritized questions, explicit assumptions, and a testable spec before coding.
Before & after
Same prompt, same agent — the only difference is the skill.
I can build a real-time notification system for your app. Here's what I'm thinking: we could use WebSockets for the persistent connection, store notifications in a database, and push them to the client when they arrive. I'd suggest setting up a notification service on the backend that listens for events and broadcasts to connected clients. We could also add a UI component to show notifications as toasts. Should I start with the backend service first, or would you prefer the frontend components? I could also suggest using Socket.io if you're already using Node.js.
GRILL: REAL-TIME NOTIFICATION SYSTEM Hold on—before I write a single line of code, I need clarity on these questions. Each one changes the architecture dramatically. ===== TECHNICAL REQUIREMENTS ===== 1. Transport layer: Do you need persistent WebSocket connections, or is HTTP polling + periodic refresh acceptable? (WebSocket = complex, polling = simpler, higher latency) 2. Notification volume: How many notifications per user per day? (10 = database query fine; 10,000 = need message queue) 3. Failure tolerance: If a notification is lost mid-delivery, is retry required or fire-and-forget okay? (Retry = complex state machine) 4. Persistence: Should users see past notifications after logout, or only live notifications while connected? 5. Distribution: Do you need to notify 1 user, 1000 users simultaneously, or broadcast to everyone? (1000 users = need fan-out queue) ===== PRODUCT REQUIREMENTS ===== 6. Types of notifications: Which use cases matter most? Examples: • Transactional (order shipped, payment confirmed) • System alerts (maintenance, new feature) • Social (friend request, mention) → Architecture changes based on this 7. User experience: Should notifications: • Persist in an in-app notification center? (Log all) • Auto-dismiss after 5 seconds? (Ephemeral) • Require user acknowledgment? 8. Mobile support: Does this need to work on iOS/Android, or web only? (Push notifications = whole different system) ===== DATA & INTEGRATION ===== 9. Data model: Who triggers notifications? • Backend cronjob (batch)? • Real user action in another service? • External API (payment processor, email service)? → Determines what systems need to connect 10. Delivery timing: Can notifications be delayed 30 seconds, or do they need to be instant (< 100ms)? ===== OPERATIONAL ===== 11. Monitoring: How will you know if notifications are silently dropped? Do you need audit logs of every notification sent? 12. Scale limit: At what user count do you expect this to break? (10K users = Redis fine; 1M users = message broker required) ===== YOUR ANSWERS WILL DETERMINE ===== • Tech choice: WebSocket vs polling vs Server-Sent Events • Database: SQL polling vs dedicated queue (RabbitMQ, Kafka) • Deployment: Single server vs distributed system • Testing strategy: Mock clock vs integration test environment Which of these are hardest to answer right now? Let's lock those in first.
About this skill
“Just add team invites” can hide decisions about permissions, existing accounts, expired links, and who gets access to whose data. This review exposes the decisions that would change the implementation, asks the most consequential questions first, and turns the answers into a testable feature spec before coding starts.
What it does
- Separates confirmed requirements, proposed defaults, contradictions, and unresolved decisions.
- Distinguishes product choices from technical questions that existing code or documentation can answer.
- Prioritizes blockers by their effect on access, data integrity, architecture, and user behavior.
- Asks up to three focused questions per round, with concrete alternatives and their consequences.
- Converts vague goals into observable acceptance criteria, including failure paths and permission boundaries.
- Stops the interview once implementation can proceed without silently deciding unresolved requirements.
What you get
A provisional feature outline and a short set of blocking questions, followed by an agreed spec with acceptance criteria, exclusions, and explicitly deferred decisions. Small requests receive a compact review rather than a full discovery document.
Best for
Technical founders, solo developers, and engineering teams starting ambiguous features or reviewing incomplete tickets before implementation.
SKILL.md preview
---
name: pre-code-feature-requirements-review
description: Review feature requests before coding by separating evidence from assumptions, prioritizing unresolved product and technical decisions, and converting answers into testable acceptance criteria. Use when the user says "grill me before coding", "what am I missing in this feature?", "help me nail down the requirements", "review this ticket before we build", "don't let me skip the hard questions", "we keep rebuilding because requirements change", or "this sounds simple but the edge cases keep growing".
---
# Pre-Code Feature Requirements Review
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.