Skip to content

Plugin commands

The plugin exposes three slash commands. Use init first, audit after the project is underway, profile whenever you want to verify the resolution without generating output.

/vibecodingisold:init

Purpose: Generate PLAN-REQUIREMENTS.md in the project root, profile-filtered against the 314-item knowledge base. Run BEFORE any AI planning tool sees the repo.

Arguments: [--profile <type>] [--stack <stack>]

  • --profile <type> — explicit profile (one of b2b-saas-web, b2c-saas-web, marketplace, ai-wrapper, mobile-app, internal-tool). Skips auto-resolution.
  • --stack <stack> — override the default stack (TypeScript+Node+Postgres) for code snippets in items. Optional; most projects accept the default.

Total runtime: 2-5 minutes (depends on whether profile is auto-detected or asked).

Pre-flight (mandatory):

  1. Stage 1 evidence required. A PROJECT.md, README.md, or .planning/PROJECT.md MUST exist in the project root with at least Mission, Target users, and Stack. If missing, the command refuses with a STOP message.
  2. Profile must resolve. Either passed as --profile, auto-detected from project context, or interactively asked via the 5-question profile-detection flow. Refuses to write with an ambiguous profile.
  3. No existing PLAN-REQUIREMENTS.md overwrite, full stop. If the file exists, the command refuses to write and points at /vibecodingisold:audit instead. There is no overwrite flag in V1.0 — the user must rename or delete the existing file by hand if they really want a regeneration. Design rationale: silent overwrites of planning artifacts caused unrecoverable churn during methodology development.

Steps it executes:

  1. Invokes the vibecodingisold skill at ${CLAUDE_PLUGIN_ROOT}/skills/vibecodingisold/SKILL.md.
  2. Reads project context.
  3. Resolves profile (passed arg → context-inferred → interactive 5-question fallback).
  4. Reads core/profiles/<resolved-profile>.md for the filtered Mandatory list.
  5. Reads core/_conflict-resolutions.md for the 8 Numerical Contracts (BINDING — copies verbatim).
  6. Generates PLAN-REQUIREMENTS.md using the init-output template.
  7. Prints the handoff message (next-step command for your planning tool).

Quality gates after generation:

  • Output file exists at <project-root>/PLAN-REQUIREMENTS.md.
  • Frontmatter contains all 10 Context Profile fields (no unfilled ${VAR} placeholders).
  • All Numerical Contracts present and verbatim from core/_conflict-resolutions.md.
  • Profile-filtered Mandatory items count matches the count documented in core/profiles/<profile>.md header.
  • Cross-references to core/roles/<role>.md use plugin-relative paths.

If any check fails, init re-runs once with stricter prompting. If still failing: hard-fail with clear log entry — no silent proceed.

Anti-patterns the command refuses:

  • Generating without Stage 1 evidence (refuses, prints STOP).
  • Inferring profile from a single signal (ambiguous → asks 5 questions).
  • Modifying Numerical Contracts (binding across all 7 roles, must align verbatim).
  • Silently overwriting existing PLAN-REQUIREMENTS.md (confirms or suggests audit).
  • Dropping Conditional items (lists them with their trigger condition).

/vibecodingisold:audit

Purpose: Diff an existing PLAN.md or PLAN-REQUIREMENTS.md against the profile-filtered Mandatory list. Outputs a gap report. Does NOT overwrite the existing file. Designed for projects already underway that want to validate spec coverage before the next milestone.

Arguments: [--profile <type>] [--target <path>]

  • --profile <type> — same options as init.
  • --target <path> — override the auto-detected target. Default search order: PLAN-REQUIREMENTS.md, PLAN.md, .planning/PLAN.md, docs/PLAN.md.

Total runtime: 2-5 minutes.

Output: PLAN-REQUIREMENTS.audit.md in the project root with this structure:

# vibecodingisold Audit — <project-name>

Profile: <profile>
Target file: <path>
Audited: <ISO-date>

## Coverage summary
- Total Mandatory items in profile: NNN
- Present and aligned: NNN
- Present but misaligned: NNN  ← REVIEW
- Missing: NNN                  ← BLOCKERS
- Deferred with trigger: NNN

## Numerical Contracts compliance
| Contract | Canonical | In plan | Status |
|---|---|---|---|
... 8 rows ...

## Misaligned items (review needed)
... item ID | role | canonical value | plan value | impact ...

## Missing items (blockers before next milestone)
... grouped by role, ordered by retrofit cost (high → low) ...

## Deferred items (acceptable if trigger documented)
... list with trigger condition ...

Per-item classification:

  • Present and aligned — item appears in plan with consistent values.
  • Present but misaligned — item appears but contradicts canonical (e.g., webhook tolerance set to 600s instead of 300s).
  • Missing — item not addressed in plan.
  • Out-of-scope deferral — item explicitly deferred with documented trigger condition.

Quality gates:

  • Output file PLAN-REQUIREMENTS.audit.md exists in project root.
  • All 8 Numerical Contracts present in the compliance table.
  • Misaligned and Missing sections each cite the canonical source file (core/roles/<role>.md Item N).
  • No silent overwrites — verify target file mtime is unchanged after audit.

Anti-patterns the command refuses:

  • Overwriting the target file under any circumstances. Audit is read-only on the source plan.
  • Reporting "all good" if Numerical Contracts are misaligned — they are binding.
  • Classifying Missing items as "low priority" without checking the role file's "Estimated time to retrofit" field.

/vibecodingisold:profile

Purpose: Resolve which project profile fits this repo. No file output — just prints the resolved profile, the trigger evidence, and the next-step command.

Arguments: [--explain]

  • --explain — also print the path to the canonical profile file (core/profiles/<profile>.md) so you can read the full Mandatory list without writing the artifact yet.

Total runtime: 1-2 minutes.

When to use:

  • The user wants to confirm which profile applies before committing to init.
  • The user is debugging a PLAN-REQUIREMENTS.md they suspect was generated against the wrong profile.

Steps it executes:

  1. Reads project context (PROJECT.md, README.md, .planning/PROJECT.md).
  2. Tries to auto-resolve a profile from the context. Tracks which signals fired (e.g., "B2B" keyword, "Postgres" stack, "EU customers" → GDPR, "mobile" mentioned, "internal" mentioned).
  3. If auto-resolve produces a single confident match: prints it with the trigger evidence.
  4. If ambiguous or no match: walks through the 5-question profile-detection flow interactively.
  5. Prints the resolved profile, mandatory item count, and the init command to run next.

Output format (no file written):

Profile resolution for <project-name>
─────────────────────────────────────
Resolved profile: <profile>
Confidence: <auto | interactive>
Mandatory items in scope: NNN
Conditional items active: NN
Conditional items deferred: NN

Triggering signals:
  - <signal 1>: <evidence>
  - <signal 2>: <evidence>
  ...

Next step:
  /vibecodingisold:init --profile <profile>

Anti-patterns the command refuses:

  • Writing any file. This command is diagnostic only.
  • Printing profile choice without listing triggering signals — the user needs to be able to challenge the resolution.
  • Auto-resolving with low confidence. Ambiguous → falls through to interactive.

Choosing between commands

Situation Command
New project, ready to generate the artifact init
Existing project with a plan, want to check coverage audit
Want to verify the profile choice before generating profile
Want to understand which signals dominated resolution profile --explain
Generated artifact looks wrong (wrong items present) profile to confirm, then init --profile <correct>
Major Stage 1 change (compliance vector added, multi-region entered scope) init again