Skip to content

Where it sits in your pipeline

vibecodingisold is Stage 2 of a 4-stage AI-coding pipeline. We deliberately do not do Stage 1, Stage 3, or Stage 4 — they're owned by other tools or by you. The whole value proposition collapses if Stage 2 leaks into the others.

The 4 stages

┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
│  1. CONTEXT      │ → │  2. vibecoding-  │ → │  3. PLANNING     │ → │  4. EXECUTION    │
│  ENGINEERING     │   │     isold        │   │                  │   │                  │
│                  │   │                  │   │                  │   │                  │
│  WHAT to build?  │   │  WHAT MUST be    │   │  HOW to build?   │   │  Build it.       │
│  For whom?       │   │  in the plan?    │   │  (Phases, Tasks, │   │                  │
│  Which stack?    │   │  (Senior team    │   │   Architecture)  │   │                  │
│  Which scale?    │   │   requirements)  │   │                  │   │                  │
└──────────────────┘   └──────────────────┘   └──────────────────┘   └──────────────────┘
   PRD / Vision Doc   →   PLAN-REQUIREMENTS   →   Tech Plan          →   Code
   User Stories           .md (universal)         (any AI tool)
   Tech Stack             + Cursor Rules
   Constraints            + Claude Code Skill
                          + Cline Rules
                          + Aider Conventions
                          + Plain Prompt Template

Stage 1 — Context Engineering (your job)

What it produces: a written Stage-1 doc — typically PROJECT.md or a substantive README.md — that names mission, target users, stack, and scale.

Why we don't cover it: Stage 1 is irreducibly product work. No tool can decide for you that you're building a B2B HR-tech ATS for European mid-market customers on Postgres at expected ~5k DAU in year one. That decision is yours, and it determines everything downstream.

Minimum acceptable Stage 1 output:

  • Mission (one paragraph: what the product does, for whom, what the unit of value is).
  • Target users (segment, scale band, geographic distribution).
  • Stack (default: TypeScript/Node + Postgres + Kubernetes — overrideable).
  • Scale band (DAU expected in year 1, peak QPS guess, data-volume guess).
  • Compliance vectors (GDPR? SOC 2? HIPAA? PCI? — name what's in scope).
  • Multi-tenancy posture (single-tenant per customer? Shared schema with tenant_id? Separate schemas?).
  • Region posture (single-region? Multi-region active-passive? Active-active?).

Output of Stage 1 feeds into: the profile resolver in Stage 2.

Plugin behavior: the plugin refuses to run without Stage 1 evidence. If PROJECT.md, README.md, or .planning/PROJECT.md doesn't exist with at least mission/users/stack named, init prints a STOP message instead of generating an under-informed plan.

Stage 2 — vibecodingisold (this project)

What it produces: PLAN-REQUIREMENTS.md in your project root, containing:

  1. The Context Profile block (frontmatter that anchors profile resolution).
  2. Profile-filtered Mandatory items (typically 184–264 of the 314, per profile).
  3. Active Conditional items with their trigger conditions named.
  4. Deferred Conditional items with explicit re-trigger conditions for future re-runs.
  5. The 8 binding Numerical Contracts verbatim (TTLs, timeouts, RPO/RTO floors).
  6. Cross-references to canonical role files under core/roles/.

Why this is its own stage: the value is the filter and the citation chain, not the items in raw form. If you handed an AI tool the full 314-item document, the planner would discard half as out-of-scope and generic-process the other half. The profile-filtered, cross-referenced subset is what makes the items actionable for a specific project.

Output of Stage 2 feeds into: any Stage-3 planning tool. The artifact is plain Markdown — every modern context window holds it.

What Stage 2 does NOT do:

  • It does not decide your architecture (Stage 3's job).
  • It does not write code (Stage 4's job).
  • It does not name your bounded contexts, pick your vendors, or set your SLO numbers — these are the founder-decisions explicitly listed in Step 6 of every worked example.

Stage 3 — Planning (your AI tool)

What it produces: a phased build plan — typically a PLAN.md with 8–12 phases, each containing acceptance criteria, dependencies, and task breakdowns.

Why we don't cover it: planning tools are a healthy ecosystem. Claude Code's /gsd:plan-phase, Cursor's plan-mode, Cline's planning subagent, custom orchestrators (Aider, gptme, Continue, Sourcegraph Cody, etc.), and human-written plans are all fine. The Stage-2 artifact is plain Markdown specifically so any of them can consume it.

What a good Stage 3 plan does with the Stage 2 artifact:

  • Honors every Mandatory item (or documents an explicit ADR-style deferral with a trigger).
  • Carries the Numerical Contracts verbatim into the relevant phases (idempotency middleware phase carries the 24h TTL, probe phase carries the <2s timeout, etc.).
  • Translates cross-references into phase dependencies (RLS work in the database phase blocks the API auth phase, not vice versa).
  • Surfaces V1 profile gaps explicitly so they're filled by hand, not silently omitted.

The two worked examples (B2B SaaS, Mobile App) show what Stage-3 plans look like when produced from a Stage-2 artifact.

Stage 4 — Execution (your coding agent)

What it produces: code, tests, infra, deploy artifacts — the actual product.

Why we don't cover it: there are dozens of execution agents. The Stage-3 plan is what they consume. Items in the plan inform every PR's acceptance criteria.

What we do influence in Stage 4 (indirectly):

  • The PR template references the plan items the PR addresses.
  • The CI checks (item-template validator, contracts validator, cross-reference validator) ensure the canonical knowledge stays consistent — not your code, but the source the next planning run consumes.

Why this scoping is load-bearing

If we tried to do Stage 1, we'd be a PRD generator — and PRD generation without business context is impossible to do well. If we tried to do Stage 3, we'd be one more planning tool competing with the agents you already use. If we tried to do Stage 4, we'd be a coding agent and we wouldn't be tool-agnostic anymore.

By scoping tightly to "the requirements your planning tool would otherwise miss", we stay valuable across every Stage-3 tool, every Stage-4 agent, and every founder's preferred workflow. That's the entire bet.

Re-running Stage 2

You re-run when Stage 1 changes materially:

  • A new compliance vector enters scope (first SOC 2 customer; first EU customer; HIPAA / PCI / FedRAMP appears).
  • You move from single-region to multi-region.
  • You add an LLM to the user path (turning CRUD into ai-wrapper).
  • You move from internal-tool to externally-exposed.
  • The repo's core/ ships a V1.x update relevant to your profile (watch the Changelog).

The audit command (/vibecodingisold:audit) is the read-only equivalent — it diffs your existing plan against the canonical filtered list without overwriting anything.