oimiragieo Research-Council Defer
When to use
- After a research spike or council run returns a recommendation to defer a feature, to ensure the defer decision is recorded durably with named prereqs and a specific re-trigger.
- When evaluating whether to open a new feature scope pre-revenue (0-10 users).
- NOT an act-vs-ask common-sense gate — that governs micro-decisions WITHIN a decided scope. This skill governs whether the scope opens at all.
- NOT the peer-review council itself — run the council first to get the recommendation, then use this skill to record and enforce the defer.
Worked example: a memory/knowledge-hive-mind integration DEFERRED by a 5-seat council — narrow token win, pre-demand at ~2 users, with two named prerequisite features as hard blockers.
P1: Demand-signal hierarchy — behavior beats stated interest
Anchor the re-trigger threshold to a BEHAVIOR signal, not a wishlist count. In descending evidential weight: payment > signed LOI > repeat usage without prompting > workaround adoption > unprompted pull request > waitlist conversion > interview enthusiasm > verbal yes. A user saying "I'd love this" is the weakest signal. A user paying for it or building their own workaround is the strongest.
P2: Set the re-trigger threshold BEFORE the research spike
Write the threshold into the defer brief before running the research, not after seeing the results. Post-hoc thresholds bend to confirmation bias — if the research turns up three enthusiastic interviews, a threshold set afterward will be "3 enthusiastic interviews." Set it first: "we build this when ≥10 users have expressed the demand signal at level N or higher."
P3: Name the prerequisite chain explicitly
List hard blockers in order of sequencing dependency, with the reason for each: "prereq A must ship first because B depends on A's schema." A deferred feature with no named blockers gets reopened on enthusiasm alone. Hard blockers make it a BLOCK (reviewed when the blocker resolves); a free defer with no blockers is reviewed on the threshold date or when the threshold signal arrives.
P4: Write an immutable ADR-style brief
Record the decision in a committed file under docs/strategy/ (or docs/strategy/<date>-<feature>-brief.md). Minimum fields:
- Context — what was researched, what the council said
- Decision — DEFER (not "explore later", not "maybe")
- Named prereqs — specific issues or shipped features by number
- Re-trigger — the exact signal (behavior level + count) that reopens this
- Integration shape — one paragraph on HOW it would be built if the trigger fires, so the next agent doesn't re-research from scratch
A Slack thread or a MEMORY.md entry is not a defer brief. It must be findable by a fresh agent in a future session.
P5: "Seam, not scaffold"
YAGNI applies to the build, not the design. Leave a cheap seam — a nullable column, an unimplemented interface stub, a commented-out route — but never a full scaffold that accumulates carrying cost on every future feature. A scaffold that works 10% of the way is worse than no scaffold: it creates merge conflicts, confuses audits, and implies the feature is in-progress when it isn't.
P6: YAGNI cost model — carry AND delay, both favor defer pre-revenue
The cost of building a deferred feature prematurely = cost-of-carry (maintenance burden on a churning codebase) + cost-of-delay (nothing, if no paying users are blocked). At pre-revenue, delay cost is near zero. Carry cost is high because the codebase changes fast and the feature will need rework before it ships anyway. Both factors point to defer.
P7: DEFER vs BLOCK — don't misclassify
A BLOCK has a named hard prerequisite that must ship first. It is reviewed when that prereq resolves, not on a threshold signal. A DEFER has no hard blocker — it's reviewed when the demand threshold fires. Misclassifying a BLOCK as a DEFER lets it reopen prematurely (the demand signal arrives before the prereq is ready). Misclassifying a DEFER as a BLOCK buries it until someone manually looks at the backlog.
P8: Time-box the research spike — exit with a named decision
A research spike that runs more than ~1 week without a decision is itself a symptom: either the question is underspecified, or the decision is being avoided. Time-box to one week. Exit with one of: adopt / reject / defer, each tied to named criteria. If the spike is genuinely undecidable, the bottleneck is the decision framework, not the research. Defer with a brief and revisit the decision criteria.
P9: "Seems reversible" is not license to start building a deferred feature
The act-vs-ask "act don't ask" rule applies inside a decided scope. A deferred feature is explicitly out of scope. "Reversible" does not make it in-scope — code merges are never fully reversible (schema migrations, API surface, SDK references, test surface). Starting a deferred feature because it "seems small" is scope creep. The defer brief is the gate. Re-trigger the threshold check or get explicit approval before opening the scope.