vibecodingisold

vibecodingisold — Pre-Planning Knowledge Injection

What this skill does

This skill is a pre-planning intercept. It runs between context engineering (Stage 1: PRD, vision, stack chosen) and AI planning (Stage 3: /gsd:plan-phase, Cursor /plan, Cline, Aider). It reads the user's project context, picks the right project profile, pulls the filtered list of senior-engineering Mandatory Items from the canonical knowledge base, and writes a PLAN-REQUIREMENTS.md into the user's project root. The downstream planning tool then has every retrofit-expensive decision (multi-tenancy, idempotency, region-aware data model, webhook hygiene, RLS, secret management) already loaded into context — so the plan it produces does not require a multi-week rewrite to make production-grade.

The skill does NOT plan, code, or review. It loads the knowledge that the planning tool needs to plan correctly.

When to invoke

Trigger on any of:

• New project. User is about to scaffold a brand-new repo with an AI tool. Run BEFORE the AI generates the first line of code.
• New milestone. User is scoping the next major version (M2, M3) and the threat model has shifted (now SOC 2 in pipeline, now multi-region, now LLM on user path).
• New feature scoping. User is adding a feature that touches a Mandatory category (billing → idempotency, file uploads → security 23+24, exports → GDPR, webhooks → backend 12).
• Auditing existing spec. User has a partial PRD or PLAN.md and wants to know what is missing before they hand it to a planning agent. Skill runs in audit-mode (read existing → diff against profile Mandatory list → output gap report).

Do NOT invoke for:

• Bug fixes (single defect, no new architectural decisions)
• Cosmetic changes (copy edits, styling, refactors with no contract change)
• Operational tasks (deploys, log spelunking, incident response)

Workflow this skill performs

1. Read or ask for project context. Look for PROJECT.md, README.md, or .planning/PROJECT.md in the user's repo. If found, extract project_name, stack, scale, compliance hints. If not found, refuse to plan blind — see Anti-pattern guard below.

2. Detect or pick project type. From context, infer one of the 6 profiles. If ambiguous, walk the user through templates/profile-detection.template.md (5 questions). The user picks one of:

   • b2b-saas-web
   • b2c-saas-web
   • mobile-app
   • ai-wrapper
   • marketplace
   • internal-tool

3. Pull the profile-filtered Mandatory list. Read ${CLAUDE_PLUGIN_ROOT}/core/profiles/${PROFILE}.md. That file contains the active Mandatory items, the Conditional triggers that fire for this profile, the items deliberately skipped, and the highest-leverage items called out.

4. Generate PLAN-REQUIREMENTS.md. Use templates/init-output.template.md as the structure. Populate:

   • Filled Context Profile YAML (from Step 1)
   • Profile-filtered Mandatory items (from Step 3)
   • Numerical contracts (the 8 alignments — Idempotency-Key TTL, liveness timeout, terminationGracePeriodSeconds floor, preStop sleep, webhook timestamp tolerance, vuln-scan severity gate, secret rotation cadence, RPO/RTO floors)
   • Cross-references to source role files in this plugin for deep-dive

   Write the output to <user-project-root>/PLAN-REQUIREMENTS.md.

5. Hand off. Print templates/handoff-message.template.md instructing the user how to feed the generated file into their next step (/gsd:plan-phase, Cursor, Cline, Aider, plain LLM).

Required arguments

• --profile <type> — one of the 6 profile names. Optional if auto-detection succeeds; required if auto-detection is ambiguous.
• --stack <stack> — optional override (e.g., python+fastapi, go, typescript+node). Defaults to TypeScript+Node.
• --audit — optional flag. If set, skill diffs an existing PLAN-REQUIREMENTS.md or PLAN.md against the profile's Mandatory list and outputs a gap report instead of overwriting.

Where the canonical content lives (inside this plugin)

All knowledge is vendored inside the plugin tree so the skill works after /plugin install without needing the upstream repo:

• Master template (314 items, all roles, all profiles): ${CLAUDE_PLUGIN_ROOT}/core/PLAN-REQUIREMENTS.template.md
• Profile-filtered lists (one per project type): ${CLAUDE_PLUGIN_ROOT}/core/profiles/<type>.md
• Per-role canonical files (7 roles, ~39-53 items each): ${CLAUDE_PLUGIN_ROOT}/core/roles/<role>.md
• Anti-pattern reference (58 cross-cutting patterns): ${CLAUDE_PLUGIN_ROOT}/core/anti-patterns.md
• Conflict resolutions + 8 binding numerical contracts: ${CLAUDE_PLUGIN_ROOT}/core/_conflict-resolutions.md
• Cross-references between items: ${CLAUDE_PLUGIN_ROOT}/core/_cross-references.md

The skill does not duplicate this content. It reads from these files at invocation time, applies the profile filter, and writes the user-facing template.

Anti-pattern guard

The skill refuses to plan blind. Before generating output it checks for evidence that Stage 1 (context engineering) has been completed:

• Required: a PROJECT.md, README.md, or .planning/PROJECT.md exists in the user's project root with at least a Mission, Target users, and Stack/Scale section.
• Required: the user can answer the 5 profile-detection questions (or has already declared a profile in --profile).

If either check fails, the skill outputs:

STOP — Stage 1 not complete.

vibecodingisold is Stage 2 of a 4-stage pipeline:
  Stage 1: Context engineering (PRD, vision, target users, stack)
  Stage 2: vibecodingisold (this skill — pre-planning Mandatory Items)
  Stage 3: AI planning tool (/gsd:plan-phase, Cursor /plan, Cline, Aider)
  Stage 4: AI execution (the planning tool drives code)

Planning without context produces hallucinated requirements.
Complete Stage 1 first:
  - Write a PROJECT.md or README.md with Mission + Target users + Stack
  - OR run your context-engineering tool of choice
  - THEN re-invoke this skill

Refusing to generate PLAN-REQUIREMENTS.md until Stage 1 evidence is present.

This is concrete: skill checks file existence and minimum field presence, not vibes.

Idempotency contract

Running /vibecodingisold:init twice in the same project is safe. The skill:

• Detects an existing PLAN-REQUIREMENTS.md in the project root or .planning/
• If found: prompts before overwriting (or appends a .bak of the existing file)
• If --profile <X> flag is passed and matches the previously-detected profile: silent no-op (idempotent)
• If --profile <X> flag is passed and DIFFERS: warns about profile change, then proceeds
• Always writes the active profile to .planning/vibecodingisold-profile.txt for the auditor to discover

This means CI scripts can run /vibecodingisold:init as a pre-step without worrying about clobbering manual edits.