Brainstorm, Preplan, Build

Tenkr has a planning pipeline that takes you from a vague idea to executed code. The pipeline has four stages: brainstorming, pre-planning, plan-with-team, and build. You do not always need all four. The key skill is knowing which stages to skip.

The Full Pipeline

The four stages form a funnel. Each one narrows uncertainty.

Stage 1: Brainstorm. You have an idea but the requirements are unclear. Brainstorming is a structured conversation — Tenkr asks targeted questions to extract what you actually need, identifies ambiguities and contradictions, and produces a document with clarified requirements. This stage is about the problem, not the solution.

Stage 2: Pre-Plan. Requirements are clear but implementation is not. Tenkr spawns multiple expert agents in parallel to investigate your codebase, database schema, existing tools, and patterns. Round 1 explores the landscape. You review findings and approve Round 2 experts who make specific technical decisions. Tenkr synthesizes everything into an implementation plan with design decisions resolved, acceptance criteria defined, and phases laid out.

Stage 3: Plan With Team. The implementation plan exists but needs to become an executable task breakdown. This stage converts the pre-plan output into a spec with task IDs, dependencies, team member assignments, agent primers, and per-task acceptance criteria. This is where parallelism is designed — which tasks can run simultaneously, which must wait for dependencies.

Stage 4: Build. The spec exists. Tenkr reads it, creates the task list, and deploys agents to execute each task. Builders do the work. Validators verify it. Tenkr orchestrates the sequence, handles failures, and enforces acceptance criteria at phase boundaries. You get a built thing at the end.

When to Use Each Stage

The decision is about uncertainty. Where does your uncertainty live?

Start at Brainstorm when...

You have a vague idea and cannot articulate requirements. “I want something that helps the team track their commitments” is brainstorm territory. You do not know the users, the scope, or what success looks like. Brainstorming forces those answers out before anyone writes code.

You also start here when you have multiple conflicting documents or stakeholder inputs. Brainstorming resolves contradictions and produces a single source of requirements truth.

Start at Pre-Plan when...

You know what you want but not how to build it. The requirement is clear, but the implementation involves understanding existing code, system routing, and integration mechanisms. Pre-plan sends investigators into the codebase and synthesizes their findings into architectural decisions.

Start at Plan With Team when...

You already have a solid implementation plan (maybe you wrote it yourself, maybe it came from a previous pre-plan run) and need Tenkr to break it into tasks and assign agents. Plan-with-team trusts the plan's research and design decisions — it does not re-explore the codebase.

Start at Build when...

You have a complete spec with task breakdowns, acceptance criteria, and team assignments. Build reads the spec and executes. No planning, no research.

The Decision Heuristic

Ask yourself one question: What do I not know yet?

• What the problem is, who the users are, what scope is reasonable → Start at Brainstorm
• What the solution looks like, what components exist, how they interact → Start at Pre-Plan
• How to break the work into tasks and assign agents → Start at Plan With Team
• Nothing — you have a spec and want it executed → Start at Build

If you are unsure, start earlier in the pipeline. Skipping a stage you needed means the downstream stages produce lower-quality output. A shallow pre-plan creates generic tasks. Generic tasks create weak agent primers. Weak primers produce poor results.

How the Stages Connect

Each stage produces an artifact that the next stage consumes.

1. Brainstorm → Clarified requirements document
2. Pre-Plan → Implementation plan
3. Plan With Team → Execution spec with task breakdowns
4. Build → Executed work (code, integrations, whatever the spec describes)

The handoff between stages is explicit. You control the pace. You can review and edit artifacts between stages.

What Happens Inside Pre-Plan

Pre-plan is the most complex stage and worth understanding in detail. It runs in two rounds of parallel investigation.

Round 1: Landscape exploration. Tenkr picks 2–4 investigator personas based on your task — a database schema analyst, an existing tool auditor, a capability scout, an architecture reviewer. Each persona gets a rich prompt describing who they are, what questions to answer, and what to check. They run in parallel and write their findings.

User checkpoint. Tenkr presents consolidated findings and proposes Round 2 experts based on what was discovered. You vet the expert selection. If the task is simple enough, you can skip Round 2 entirely.

Round 2: Expert technical decisions. These experts make the actual design decisions. A data model architect deciding whether to normalize or add views. An integration strategist designing a sync pipeline. The experts emerge from the findings — they are not predetermined.

Synthesis. Tenkr reads all findings and synthesizes them into a plan with motivation, current state, design decisions (with rationale), implementation phases, and acceptance criteria. Every design decision has a resolution. No open questions remain.

The quality of the pre-plan determines everything downstream. A pre-plan that resolves all architectural decisions produces a spec where builders know exactly what to do. A pre-plan full of “TBD” produces specs where builders improvise.

When to Skip Stages

Not every task needs the full pipeline.

Skip brainstorm when requirements are already clear. You know the users, the scope, and the success criteria. Jump to pre-plan or plan-with-team.

Skip pre-plan when the implementation path is obvious. You know which files to change, which patterns to follow, and what the acceptance criteria are.

Skip everything when the task is a single-file change you can describe in one sentence. No pipeline needed.

The pipeline exists for tasks with enough complexity that ad-hoc execution produces poor results. Use it when the cost of investigation and planning is lower than the cost of rework from a bad implementation.

Common Mistakes

Skipping pre-plan for tasks that need it. The symptom: the spec produces tasks with vague acceptance criteria. The cause: nobody investigated the codebase, so the plan is guessing at architecture. If the spec seems shallow, you probably needed pre-plan.

Not reviewing between stages. Each artifact is editable. You can modify the pre-plan output before feeding it to the next stage. The pipeline is not a fire-and-forget sequence — the checkpoints exist for your judgment.

Over-planning simple tasks. If the task takes less time than the planning pipeline would, skip the pipeline. Brainstorming a one-line config change is overhead, not methodology. Match the planning investment to the task complexity.