Feature Design Tree and Decision Spec
Resolve hidden feature decisions through a code-grounded interview, then get a dependency tree and an implementation-ready spec.
Before & after
Same prompt, same agent — the only difference is the skill.
That sounds like a complex feature to build. Real-time collaboration involves a lot of moving parts — socket management, conflict resolution, persistence, permissions — and you'll want to think carefully about the architecture. I'd recommend mapping out the design dependencies and asking yourself some tough questions about how different components interact. You'll need to decide on communication protocol, handle edge cases like offline users and permission boundaries, and think about data consistency. Before diving into code, it might be worth having a detailed design conversation. Do you want me to help brainstorm the architecture or identify the key design questions you should answer first?
DESIGN INTERVIEW TRANSCRIPT 20 GROUNDED QUESTIONS: 1. Transport layer: WebSocket bidirectional or HTTP polling fallback? 2. Consistency model: Operational transformation (OT) or CRDT? 3. Conflict example: User A renames layer X while User B deletes it — expected outcome? 4. Persistence: every keystroke or batched every 5 seconds? 5. Offline user: edits queue locally, then sync on reconnect? 6. Permission scope: document-level, page-level, or object-level lock? 7. Undo/redo: per-user history or shared history? 8. Notification: toast on every collaborator action or quiet in background? 9. Cursor presence: show live cursors and selections of other users? 10-20. [Codebase-grounded questions: DB schema, auth token refresh, WebSocket reconnect backoff, stale connection cleanup, bandwidth estimate for 10 concurrent users, test strategy...] UNRESOLVED BRANCHES: 3 - Conflict resolution specifics under rapid simultaneous edits - Offline sync strategy for large batch operations - Performance ceiling at 20+ concurrent editors READY TO SPEC.
About this skill
“We agreed on the feature, but implementation keeps uncovering decisions nobody made.” This skill turns a fuzzy feature or refactor into a focused interview that follows design dependencies, checks available code for existing answers, and records each decision before moving on.
What it does
- Builds a numbered design tree with parent decisions, dependent branches, and clear unresolved states.
- Checks available repository evidence before asking questions the code can answer.
- Asks one consequential question at a time, with concrete options and their tradeoffs.
- Pushes vague answers into observable behavior while accepting explicitly delegated design choices.
- Revisits only the branches affected when an earlier decision changes.
- Converts the resolved tree into a scoped spec with acceptance scenarios, exclusions, and remaining blockers.
What you get
A running decision ledger and a final design handoff grounded in the evidence actually available. The handoff distinguishes confirmed decisions, proposed defaults, implementation blockers, and deliberately deferred work.
Best for
Engineers, technical leads, and product managers preparing a substantial feature or refactor, especially when a simple request hides permission, lifecycle, concurrency, or compatibility decisions.
SKILL.md preview
---
name: feature-design-tree-and-decision-spec
description: Resolve a feature's hidden design decisions through a dependency-ordered interview, using available code evidence before asking questions and recording decisions in a traceable handoff spec. Use when the user says "grill me on this feature", "walk every design branch", "help me spec this before coding", "what decisions are we missing?", "my requirements keep changing during implementation", "we keep finding edge cases in review", or "challenge this design before we build it".
---
# Feature Design Tree and Decision Spec
… (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.