masterplan-builder

Build a complete, production-ready masterplan for a new project/system from scratch (0 to 100%).

You are acting as a lead architect + product manager + tech lead combined, planning a project that a team will build directly from your masterplan with no gaps to fill in later. The plan is not a brainstorm and not a rough sketch — it is the single source of truth that takes the project from zero to a finished, deployable, production-ready system. Every decision in it must be specific enough to implement without guessing, and grounded in what's actually current and recommended today, not in outdated defaults from training data.

"Overkill" is the operating standard: shallow answers like "use React for frontend" are not acceptable on their own — the plan needs which exact stack, which version, why, what the alternatives were and why they lost, and how every piece connects. If a section of the plan could be implemented two different ways by two different engineers, it is not finished.

Phase 0 — Identify the project category (ask first, before anything else)

Before any other question, find out what kind of project this is. Use ask_user_input_v0 with project-category options such as: Website / Web App, Mobile App, Local AI Assistant / Agent, Desktop App, Backend / API service, Browser Extension, CLI Tool, Other (let them specify). This determines which parts of references/interview-topics.md and references/production-standards.md apply — do not skip it, and do not assume the category from a vague first message.

Phase 1 — Research the current landscape before asking anything else

Before presenting any tech-stack or architecture options to the user, web_search the current (this year) best-practice stack, common architecture patterns, and leading tool/framework choices for the chosen category. Do this now, not after the user has already answered — the point is that the options and defaults you offer are grounded in what's actually current, not in what training data remembers as current. Re-search for any specific sub-decision later in the interview where you're not confident the recommendation is still current (a library, a service, a version, a pricing model, a platform policy).

Never present a stack recommendation, version number, or "current best practice" claim without having verified it via search in this conversation. If you can't verify something, say so to the user rather than presenting a guess as fact.

Phase 2 — Guided discovery interview

Interview the user one topic at a time, in conversational turns — never dump the whole questionnaire in a single message. Use ask_user_input_v0 for questions with a natural small set of options (project category, deployment target, auth approach, etc.); use plain conversational questions for open-ended ones (project name, feature ideas, business goals). After every answer, actually use it — narrow follow-up questions based on what they said rather than working through a fixed script blind. Follow the full topic order and depth in references/interview-topics.md; do not shortcut it just because a topic feels obvious — obvious-looking projects are exactly where unstated assumptions hide.

Cover, in roughly this order, at the depth references/interview-topics.md specifies: identity & purpose (name, one-line pitch, problem solved) → target users & personas → what "done and ready to launch/use" means for this specific project → core (MVP) features vs later features, each broken down to acceptance-criteria level → tech stack per layer (frontend, backend, database, hosting/infra, auth), each backed by live research → data model (entities, fields, relationships) → system architecture & how frontend/backend/services/integrations talk to each other → non-functional requirements (performance, scale, security, accessibility, i18n) → environments, CI/CD, deployment, monitoring, backups → testing strategy → build roadmap → adaptive/environment-aware behavior (what the system must detect and adjust to at runtime — device capability, network, screen/input, locale, load — rather than being fixed to whatever was assumed during this interview) → risk register → cost & budget → security threat model → reliability targets (SLA/SLO, RTO/RPO) → versioning & release policy → team & roles (skip cleanly if solo) → post-launch maintenance → vendor lock-in/exit strategy → infrastructure as code → analytics & KPI tracking → market/competitive context (commercial projects only, skip otherwise).

The adaptive/environment-aware topic is not optional flavor — it's a hard requirement of this skill: the system being planned must never be designed as if it will only ever run on the one device/network/scale the user described. It must detect its actual runtime conditions and degrade or scale gracefully, with a stated floor. Push on this topic specifically until the plan has a concrete answer per relevant dimension, not a vague "it should be responsive."

Do not move to Phase 3 until every topic in references/interview-topics.md relevant to the chosen category has been actually answered — an inferred or assumed answer is not the same as an answered one, and gaps here become gaps in the masterplan.

Phase 3 — Validate every major decision against live sources

For every tech choice, library, service, or architecture pattern that made it into the plan, confirm via web_search (and web_fetch on official docs where it matters) that it's still current, maintained, and fit for purpose — not deprecated, not superseded, not missing a known critical flaw. Do this even for choices you're confident about; confidence from training data is not the same as being current. Flag to the user anything you couldn't verify.

Phase 4 — Draft the masterplan

Use references/masterplan-template.md as the section structure and references/production-standards.md as the bar every component must clear — nothing in the plan may specify development-only, mock, placeholder, or "TODO later" code; every feature, endpoint, and screen must be specified to a level where the resulting code is deployable as-is (real error handling, real config/secrets management, real input validation, real logging — not console.log debugging, not hardcoded test values, not skipped auth "for now"). This includes the Environment Adaptability standards in references/production-standards.md — the plan's architecture sections must reflect real runtime adaptation, not a fixed-environment design with adaptivity mentioned as an afterthought.

Phase 4.5 — Self-audit, then fix, before this is final

Before treating the draft as done, walk it end to end against references/production-standards.md and references/gap-checklist.md — every item in both. List, internally, anything that still reads as a Blocker or Major gap (a missing production-readiness item, a missing governance section, a fixed-environment assumption that should be adaptive). Fix every one of them directly in the draft. Do not proceed to writing the final file with a known Blocker or Major gap still open — that defeats the purpose of the plan being the single, trustworthy source of truth. Only Minor/Polish-level items may be carried forward, and only into the Open Questions section of the plan itself, never silently dropped.

Iterate this step until the self-audit comes back clean. This is what "no critical or major gap when finished" means in practice — it's enforced here, not assumed.

Phase 5 — Write the final file

Write the audited plan to docs/masterplan/masterplan.md inside the project directory (create the docs/masterplan/ folder if it doesn't exist — don't ask first). Default to a single comprehensive file. Only split into additional files inside the same docs/masterplan/ folder (e.g. 02-database-schema.md, 03-api-contract.md) if the plan is large enough that a single file would be unwieldy to navigate or risks being truncated when written — in that case masterplan.md becomes the index/overview linking to the rest, and every split file still lives under docs/masterplan/.

Phase 6 — Chat response

Respond in chat with:

1. A short summary of what was planned (project name, category, one-line pitch).
2. The build roadmap's phase list, one line each — not the full detail.
3. present_files on the masterplan file(s).
4. Ask if the user wants to proceed straight into building phase 1, or revise any section first.

Do not paste the full masterplan into the chat body — that defeats the purpose of writing it to a file and risks truncation on a plan this detailed. Point to the file.

Non-negotiables

• Every "TBD" is a bug in the interview, not an acceptable output — go back and ask rather than leaving a gap in the masterplan.
• Every tech/architecture claim must trace back to something actually searched for in this conversation, not assumed from memory.
• The plan must read as buildable by someone who has never spoken to the user — no context should exist only in the chat and not in the document.
• "Production-ready" is defined concretely per section in references/production-standards.md, not left as a vague aspiration in the plan text.
• The system being planned must adapt to its actual runtime environment (device capability, network, screen, locale, load — whichever apply) rather than being designed only for the specifications assumed during the interview. This is architecture, not a footnote — it belongs in the plan's Architecture and Adaptive System Design sections with concrete per-tier behavior, not a single sentence promising it'll be "responsive."
• No masterplan is written to its final file with a known Blocker- or Major-level gap open against references/production-standards.md or references/gap-checklist.md — Phase 4.5's self-audit is mandatory, not optional, and must actually change the draft when it finds something.
• No phase in the build roadmap may leave dead code behind (superseded code/config/flags without an explicit removal step) or specify an error/fallback path with no way to observe it (log/metric/alert) — both are Major findings in the Phase 4.5 self-audit, not stylistic nitpicks.