Skip to content

Quick Start

You will need: an AI-coding tool you already use (Claude Code, Cursor, Cline, Aider, or any chat LLM) and a project that has at least a README.md or PROJECT.md describing what you're building. Total time: 5 minutes from clone to first PLAN-REQUIREMENTS.md.

Step 0 — Make sure you have Stage 1 evidence

vibecodingisold is Stage 2 of a 4-stage pipeline. If you don't have Stage 1 done — a written description of what you're building, for whom, on which stack, at what scale — stop and write that first. The plugin and the skill both refuse to run without it. See Where it sits in your pipeline.

Minimum Stage 1 evidence: one Markdown file in your project root that names mission, target users, stack, and scale band. The plugin checks for PROJECT.md, README.md, or .planning/PROJECT.md in that order.

Pick your tool

The plugin is the lowest-friction path. One install command, three slash commands.

/plugin marketplace add 0zoriginals/vibecodingisold
/plugin install vibecodingisold@vibecodingisold

Then in any Claude Code session inside your project:

/vibecodingisold:profile          # diagnostic — resolve profile without writing
/vibecodingisold:init             # auto-detect profile, write PLAN-REQUIREMENTS.md
/vibecodingisold:audit            # gap-report on existing plan (read-only)

Detail: Plugin install · Plugin commands

Claude Code — Skill only (legacy)

If you don't want the plugin, the standalone skill still works. Symlink the skill folder into your ~/.claude/skills/:

ln -s /path/to/vibecodingisold/integrations/claude-code-skill ~/.claude/skills/vibecodingisold

Then invoke /skill vibecodingisold in any Claude Code session.

Cursor

cp -r integrations/cursor/.cursor /path/to/your/project/
cp integrations/cursor/.cursorrules /path/to/your/project/

Cursor auto-applies the rules during plan and code mode. See integrations/cursor/README.md in the repo for the per-rule frontmatter conventions.

Cline (VS Code)

cp integrations/cline/.clinerules /path/to/your/project/

Or paste integrations/cline/custom-instructions.md into Cline's settings pane for cross-project defaults.

Aider

cp integrations/aider/CONVENTIONS.md /path/to/your/project/

Aider auto-loads CONVENTIONS.md from the project root on every session. No further config.

Plain prompt (any LLM)

Copy integrations/prompt-templates/init-requirements-compact.md (~5k tokens, fits anywhere) or init-requirements-full.md (full surface) into ChatGPT, Claude.ai, Gemini, Perplexity, or any chat UI as system context. Profile-filtered slices for each project type live in the same directory.

Just Markdown

Read core/PLAN-REQUIREMENTS.template.md directly. Fill in the Context Profile block at the top. Paste into your planning tool of choice. The 118 KB master template fits in any modern context window.

What you get back

A PLAN-REQUIREMENTS.md in your project root with:

  1. Context Profile block — the YAML frontmatter that anchors profile resolution.
  2. Profile-filtered Mandatory items — typically 184–264 of the 314, depending on your project type.
  3. Active Conditional items — the Conditionals that fire for your profile, with their trigger conditions named.
  4. Deferred items with triggers — Conditionals that don't apply yet but might later, with the explicit trigger to re-run init.
  5. The 8 binding Numerical Contracts verbatim — idempotency TTL, liveness timeout, terminationGracePeriodSeconds floor, webhook timestamp tolerance, vuln-scan gate, secret rotation cadence, RPO/RTO floors. See Numerical Contracts.
  6. Cross-references to canonical role files under core/roles/ for any item you want to dig into.

Then what

Hand PLAN-REQUIREMENTS.md to your planning tool. The plan that comes back will cover the items the senior team would have demanded, not just the ones you remembered to ask for.

A worked example end-to-end: B2B SaaS Example. It shows the Context Profile fill, the resolved profile (264 active items), the 11-phase plan Claude Code produced from it, and the ~110-item delta vs a vanilla "build me a SaaS" prompt.

When to re-run

Re-run vibecodingisold:init when one of these happens:

  • A new compliance vector enters scope (first enterprise customer asks for SOC 2; first EU customer triggers GDPR; HIPAA / PCI / FedRAMP appears).
  • You move from single-region to multi-region.
  • You add an LLM to the user path (turning a CRUD product into an ai-wrapper profile).
  • You move from internal-tool to externally-exposed (your "dashboard" is now sold as a customer portal).
  • A profile's V2 fills a gap relevant to your project (watch the Changelog).

The audit command (/vibecodingisold:audit) is the read-only equivalent — diff your existing plan against the canonical filtered list without touching the file.

Troubleshooting

  • "Profile cannot be resolved" — Stage 1 evidence is too thin. Add mission, users, stack, scale to your PROJECT.md or README.md.
  • "PLAN-REQUIREMENTS.md already exists" — the plugin refuses to overwrite to protect your existing planning artifact. Run /vibecodingisold:audit against the existing file instead (read-only gap-report), or rename / delete the existing file manually before re-running /vibecodingisold:init. There is no --overwrite flag in V1.0 by design — silent overwrites of planning docs caused too much pain in the design phase.
  • Wrong profile resolved — pass --profile <type> explicitly, or run /vibecodingisold:profile --explain to see which signals fired.
  • Item count looks wrong — compare against the documented count in core/profiles/<your-profile>.md header. If they disagree, file a bug.