# Research Council Defer > Use when deciding whether to BUILD or DEFER a researched feature pre-revenue — the demand-signal-over-stated-interest, set-threshold-first, prereq-chain, written-defer-brief discipline (the build-now-vs-defer axis, distinct from an act-vs-ask common-sense-gate axis). - Skill: `oimiragieo/research-council-defer` (Agent Skill) - Install (CLI): `npx skillmds@latest add oimiragieo/research-council-defer` - Raw SKILL.md: https://api.skillmd.com/api/skills/oimiragieo/research-council-defer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: oimiragieo (https://skillmd.com/u/oimiragieo) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/oimiragieo/research-council-defer --- # 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/--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.