checkmyvibe 1.0.1 → 1.1.0

package/README.md

@@ -1,8 +1,8 @@
 # checkmyvibe
 
-A structured, zero-dependency, local security-audit workflow packaged as an Agent Skill for AI coding assistants (such as Claude Code, Cursor, Codex, and Gemini CLI).
+A structured, zero-dependency, local production readiness and code quality workflow packaged as an Agent Skill for AI coding assistants (such as Claude Code, Cursor, Codex, and Gemini CLI).
 
-AI-generated ("vibe-coded") applications built on modern AI tools frequently ship with serious, well-documented security flaws—such as exposed API keys, fake authentication stubs, permissive default database rules, and client-side pricing logic. **checkmyvibe** solves this by packaging security checks directly into an Agent Skill. When you ask your coding agent to "run a security audit," the agent uses checkmyvibe's local helper scripts and its own reasoning capabilities to analyze your codebase, producing a prioritized report detailing what's wrong, why it matters, and how to fix it.
+AI-generated ("vibe-coded") applications built on modern AI tools frequently ship with serious, well-documented configuration and quality issues—such as exposed API keys, fake authentication stubs, permissive default database rules, and client-side pricing logic. **checkmyvibe** solves this by packaging readiness and verification checks directly into an Agent Skill. When you ask your coding agent to "run checkmyvibe" or "perform a readiness check", the agent uses checkmyvibe's local helper scripts and its own reasoning capabilities to analyze your codebase, producing a prioritized report detailing what configuration issues or gaps exist, why they matter, and how to fix them.
 
 ---
 
@@ -20,8 +20,8 @@ AI-generated ("vibe-coded") applications built on modern AI tools frequently shi
 ## What This Does NOT Check For (Disclaimer)
 
 > [!WARNING]
-> **checkmyvibe is not a substitute for a full professional security audit.**
-> This tool is a first-pass heuristic scanner meant to highlight common mistakes made by AI coding models during rapid scaffolding. It does not perform dynamic runtime analysis, penetration testing, deep static analysis, dependency vulnerability checks, or comprehensive logic auditing. Do not rely solely on checkmyvibe to declare your application secure for production.
+> **checkmyvibe is not a substitute for a full professional external security audit.**
+> This tool is a first-pass quality and readiness checklist meant to highlight common mistakes and temporary scaffolding shortcuts made by AI coding models during rapid prototyping. It does not perform dynamic runtime analysis, penetration testing, deep static analysis, dependency vulnerability checks, or comprehensive logic auditing. Do not rely solely on checkmyvibe to declare your application hardened for production.
 
 ---
 
@@ -42,23 +42,31 @@ If you prefer not to use `npx`, copy the files manually:
 1. Create a `checkmyvibe` directory inside your agent's skills path:
    * **Project-level (Claude Code):** `.claude/skills/checkmyvibe/`
    * **Global/Personal (Claude Code):** `~/.claude/skills/checkmyvibe/`
-2. Copy `SKILL.md`, the `scripts/` folder, and the `references/` folder into that directory.
+2. Copy `SKILL.md`, the `scripts/` folder, `references/` folder, and `commands/` folder into that directory.
+3. (Optional for slash command support) Copy the files from `commands/` directly into `.claude/commands/` (or `~/.claude/commands/`).
 
 ---
 
 ## Usage
 
-Once installed, your AI coding agent will automatically recognize the `checkmyvibe` skill when relevant. You can trigger the workflow explicitly:
+### Full Production Readiness Audit
+Run a complete audit across all categories before deploying or shipping:
+* Command: `/checkmyvibe`
+* Or prompt: *"Run checkmyvibe on this project"*
 
-### Claude Code
-Open your terminal in the workspace and type:
-```bash
-/bug run a security audit
-```
-*Or simply ask Claude in the chat:*
-> "Run a security audit on this project using checkmyvibe"
+### Focused / Scoped Scanning
+When actively developing a specific feature, run focused scans for fast, targeted feedback without running the entire test suite:
+
+| Slash Command | Scope / Keyword | Included Checks | Use Case |
+| :--- | :--- | :--- | :--- |
+| `/checkmyvibe-secrets` | `/checkmyvibe secrets` | Check 1 + Check 2 | Exposed API keys, hardcoded credentials, and `.gitignore` hygiene |
+| `/checkmyvibe-auth` | `/checkmyvibe auth` | Check 3 | Missing, mock, stubbed, or bypassed authentication guards |
+| `/checkmyvibe-db` | `/checkmyvibe db` | Check 4 | Database & BaaS rules, Supabase RLS policies, Firebase permissions |
+| `/checkmyvibe-backend` | `/checkmyvibe backend` | Checks 3, 4, 5, 6 (server), 7 | All server-side logic: auth, DB/RLS, IDOR/BOLA, SQLi/input validation, pricing |
+| `/checkmyvibe-frontend` | `/checkmyvibe frontend` | Checks 1 (client), 3 (client), 7 (client) | Client bundle key leaks, UI-only auth hiding, client-side pricing overrides |
+| `/checkmyvibe-payment` | `/checkmyvibe payment` | Check 7 | Client-side payment tampering, price overrides, and checkout integrity |
 
-The agent will walk through the checks, execute the local python validation scripts, and print a prioritized markdown report (Critical / Should Fix / Worth Reviewing) with instructions on how to correct the issues.
+The agent will walk through the scoped checks, execute relevant local helper scripts, and print a prioritized markdown report (Critical / Should Fix / Worth Reviewing) with concrete remediation steps.
 
 ---
 

package/SKILL.md

@@ -1,14 +1,13 @@
 ---
 name: checkmyvibe
 description: >
-  Use this skill when the user asks for a security review, security audit, penetration test, or "is this safe to ship / safe to launch" check. Also trigger proactively when the agent is about to help deploy, publish, or push an application live, or when the codebase shows signs of AI-scaffolded patterns (Supabase/Firebase config, recently generated boilerplate, auth stubs, no existing security review) and the user has not had one done yet. Covers the specific, documented vulnerability patterns common in AI-generated and vibe-coded applications: exposed secrets, missing or fake authentication, permissive database rules, broken object-level authorization, unvalidated inputs, and client-side payment or pricing logic.
+  Use this skill when the user asks to "check my vibe", run a production readiness check, review code quality, do a sanity check, check for exposed environment variables, or check if the app is ready to launch/ship, or runs a scoped check like `/checkmyvibe db`, `/checkmyvibe auth`, `/checkmyvibe secrets`, `/checkmyvibe payment`, `/checkmyvibe backend`, or `/checkmyvibe frontend`. Also trigger proactively when the agent is about to help deploy, publish, or push an application live, or when the codebase shows signs of AI-scaffolded patterns (Supabase/Firebase config, recently generated boilerplate, auth stubs, no existing verification) and the user has not had one done yet.
 ---
-
-# checkmyvibe — Security Audit for Vibe-Coded Apps
+# checkmyvibe — Production Readiness & Code Quality Check for Vibe-Coded Apps
 
 ## Why this skill exists
 
-AI coding tools optimize for "it works," not "it's safe." A feature can pass every
+AI coding tools optimize for "it works," not "it's production-ready." A feature can pass every
 manual test a non-technical founder runs — sign up, log in, place an order — and
 still leak every other user's data to a stranger who changes one number in a URL.
 This happens because AI-generated code frequently ships with scaffolding shortcuts
@@ -16,26 +15,44 @@ that were meant to be temporary (a stub auth check, a permissive default databas
 rule) and never get hardened before launch, precisely because the person building
 the app doesn't know those shortcuts exist or what to look for.
 
-Your job when this skill is active: think like a security engineer doing a
-pre-launch review for a client who has never heard the words "IDOR" or "row-level
-security." Find the real, exploitable issues. Explain them in plain language. Give
-exact fixes. Do not pad the report with theoretical concerns that don't apply to
-this specific codebase, and do not skip a check because the codebase "looks
-simple" — simple codebases are exactly where stubbed auth and hardcoded secrets
-hide, because nobody expected them to hold real user data yet.
+Your job when this skill is active: think like an experienced software engineer doing a
+pre-launch quality review for a client who has never heard the words "IDOR" or "row-level
+security." Find the real, addressable configuration and logic issues. Explain them in plain
+language. Give exact fixes. Do not pad the report with theoretical concerns that don't apply
+to this specific codebase, and do not skip a check because the codebase "looks simple" —
+simple codebases are exactly where stubbed auth and hardcoded secrets hide, because nobody
+expected them to hold real user data yet.
 
 ## Scope and honesty (read this before writing any report)
 
-This is a first-pass audit for known, documented failure patterns. It is not a
-full penetration test, it does not cover infrastructure security, dependency
-vulnerabilities, or novel/business-logic-specific flaws outside the six categories
-below. Never tell the user their app is "secure" or "safe" in an unqualified way.
+This is a first-pass review for known, documented scaffolding failure patterns. It is not a
+comprehensive external validation, and it does not cover infrastructure hosting, third-party package
+issues, or novel/business-logic-specific flaws outside the categories below. Never tell the user their app is completely "secure" or "safe" in an unqualified way.
 The correct language is "no issues found in this pass" or "ready to ship as far as
 these checks go" — always paired with the scope reminder in the Final Summary
 section. If the app appears to handle payments, health data, or other regulated
-data, say explicitly that a professional audit is strongly recommended regardless
+data, say explicitly that a professional verification is strongly recommended regardless
 of what this pass finds.
 
+## Scope selection
+
+checkmyvibe supports targeted/scoped scanning for rapid iteration during development, as well as full audits before release. When a specific scope or slash command is specified, execute only the mapped checks:
+
+| Scope / Command Keyword | Included Checks | Description / Focus Area |
+| :--- | :--- | :--- |
+| **`secrets`** | **Check 1 + Check 2** | Exposed credentials, API keys, tokens, and `.gitignore` file protection |
+| **`auth`** | **Check 3** | Missing, mock, stubbed, or bypassed authentication guards |
+| **`db`** | **Check 4** | Database & BaaS rules, Supabase RLS policies, Firebase/storage permissions |
+| **`backend`** | **Check 3 + Check 4 + Check 5 + Check 6 (server-side) + Check 7** | All server-side logic: auth guards, database configs, IDOR/BOLA, SQLi/input validation, and payment processing |
+| **`frontend`** | **Check 1 (client-exposed) + Check 3 (client-only auth) + Check 7 (client pricing)** | Client-side bundle leaks, UI-only auth hiding, and client-controlled payment/pricing logic |
+| **`payment`** | **Check 7** | Client-side payment amount tampering, price overrides, and checkout integrity |
+| *(no argument / `full`)* | **All Checks (1–7)** | Full production readiness and code quality audit |
+
+### Rules for Scoped Runs:
+- **Execute only the selected checks:** Do not run unselected check scripts or inspect code outside the chosen scope.
+- **Explicit scope transparency:** At the start and in the final summary of the report, clearly state which checks were run and which checks were skipped.
+- **No false safety claims:** A clean scoped scan does **not** mean the app is ready for production. State clearly: *"This was a [scope]-only check. Run a full `/checkmyvibe` audit across all categories prior to launch."*
+
 ## Before you start
 
 1. **Analyze and understand the whole project first:** Walk the directory tree and analyze the repository configuration files before running any checks, generating findings, or providing instructions. Establish a solid high-level understanding of the architecture, components, and data flow.
@@ -51,7 +68,6 @@ of what this pass finds.
 
 ---
 
-
 ## Supported stacks to recognize
 
 Common stacks this skill should expect include: Next.js, Express, FastAPI, Supabase, Firebase, Prisma, Postgres, MongoDB, Clerk, NextAuth, Stripe, and common app patterns built around them.
@@ -80,6 +96,7 @@ strings, and variable assignments where a name like `key`, `secret`, `token`, or
 `password` is set to a literal string instead of `process.env.X` or equivalent.
 
 **What counts as a finding:**
+
 - A real credential committed directly in source, e.g.:
   `const stripeKey = "sk_live_51H8x..."` — Critical
 - A secret present only in `.env` but `.env` is not gitignored (see Check 2) —
@@ -90,6 +107,7 @@ strings, and variable assignments where a name like `key`, `secret`, `token`, or
   Critical, this is directly shippable to every visitor's browser
 
 **What is NOT a finding (avoid false positives):**
+
 - Public/anon/publishable keys that are designed to be exposed client-side
   (Stripe publishable keys starting `pk_`, Supabase anon keys) — these are safe
   by design as long as server-side authorization (RLS, API checks) is correctly
@@ -105,10 +123,10 @@ them (not just whether a `.gitignore` file exists — many AI-generated `.gitign
 files exist but miss the actual secret file).
 
 **What counts as a finding:**
+
 - `.env` present in the working directory and not listed in `.gitignore` —
   Critical, regardless of current contents
-- `.env` already committed to git history (check with a quick `git log --all
-  --full-history -- .env` if git is available) — Critical, and note in the
+- `.env` already committed to git history (check with a quick `git log --all --full-history -- .env` if git is available) — Critical, and note in the
   fix that removing it from `.gitignore` going forward is not enough; the
   secrets in git history must be rotated, since they're recoverable even after
   deletion
@@ -119,17 +137,18 @@ files exist but miss the actual secret file).
 checks) for these patterns:
 
 **What counts as a finding:**
+
 - A function that always returns true/success regardless of input, e.g.:
   ```js
   function isAuthenticated(req) {
     return true; // TODO: implement real auth
   }
   ```
+
   Critical — this is a placeholder someone forgot to replace.
 - Naming that signals a stub: `mockAuth`, `fakeLogin`, `tempAuth`, `bypassAuth`,
   `skipAuth`, `devAuth` still present in a codebase with no clear dev-only guard
-  around it. If it IS properly guarded (e.g. `if (process.env.NODE_ENV ===
-  'development')`), verify the guard is airtight and note it as Should Fix
+  around it. If it IS properly guarded (e.g. `if (process.env.NODE_ENV === 'development')`), verify the guard is airtight and note it as Should Fix
   rather than Critical, since misconfigured environment variables in production
   are a common way these leak through anyway.
 - A protected route or API endpoint with no auth check at all — compare route
@@ -153,6 +172,7 @@ If the project uses **Supabase**: check for row-level security (RLS) policies on
 every table that holds user-specific data. A table with RLS disabled, or enabled
 with a policy like `USING (true)` for `SELECT`/`UPDATE`/`DELETE`, means any
 authenticated (or even anonymous) user can read or modify every row.
+
 ```sql
 -- Finding example: this policy applies to ALL rows for ALL users
 CREATE POLICY "allow all" ON orders FOR SELECT USING (true);
@@ -204,6 +224,7 @@ common and DELETE is often the most damaging.
 ## Check 6: Unvalidated inputs
 
 Spot-check forms and API endpoints for:
+
 - No type or length validation on inputs before they're stored or used
 - User input passed into a database query via string concatenation rather than
   parameterized queries/an ORM (SQL injection risk)
@@ -261,6 +282,7 @@ For every finding, use exactly this structure:
 - Include a `Generated fix:` line when a direct code snippet or precise implementation step would help the agent patch the issue immediately.
 
 **[SEVERITY] Short title**
+
 - **What's wrong:** plain-English description, no jargon. If a technical term is
   unavoidable (e.g. "IDOR"), define it in one clause the first time it's used.
 - **Why it matters:** a concrete, real-world consequence a non-technical person
@@ -271,10 +293,10 @@ For every finding, use exactly this structure:
   suggestion like "add proper validation."
 - **File(s):** exact path and line number(s).
 
-
 ## After the checks
 
-Once the checks are complete, create a security audit/report. **The report must be written in clear, plain English, completely free of dense security jargon, so that it is easily understandable by non-technical stakeholders (such as founders, clients, or project managers).** The report must include:
+Once the checks are complete, create a readiness review report. **The report must be written in clear, plain English, completely free of dense technical jargon, so that it is easily understandable by non-technical stakeholders (such as founders, clients, or project managers).** The report must include:
+
 - what was found
 - what is fixed already
 - how each fix was applied
@@ -283,12 +305,12 @@ Once the checks are complete, create a security audit/report. **The report must
 
 If no issues are found, still produce a short report that says no blocking issues were found in this pass, which categories were checked, and what the remaining scope limits are.
 
-
 ## Example report style
 
 Use clear, direct wording like:
 
 **[Critical] Missing object-level authorization**
+
 - **What's wrong:** Any logged-in user can read another user's order by changing the order ID.
 - **Why it matters:** A stranger could see someone else's orders and personal details.
 - **The fix:** Add a user ownership check in the query and return 404 when the record does not belong to the current user.
@@ -296,22 +318,21 @@ Use clear, direct wording like:
 
 ## Final summary
 
-End every audit with, in this order:
+End every review with, in this order:
+
 1. Stack and data-sensitivity context noted at the start (one line)
 2. Total findings by severity, e.g. "2 Critical, 3 Should Fix, 1 Worth Reviewing"
 3. A one-line verdict: "Not ready to ship — fix the Critical items first" or "No
    blocking issues found in this pass — review the Should Fix items when you can"
-4. The scope reminder: "This covers common patterns seen in AI-generated code —
-   exposed secrets, auth stubs, database misconfiguration, IDOR, input validation,
-   and client-side payment logic. It is not a full penetration test. If this app
-   handles payment, health, or other regulated data, get a professional security
-   review before launch regardless of these results."
+4. The scope reminder:
+   - **For Full Audit:** "This review covers common configuration patterns seen in AI-generated code — exposed secrets, auth stubs, database rules, object-level authorization, input validation, and client-side payment logic. It is not a comprehensive third-party safety audit or pentest. If this app handles payment, health, or other regulated data, get a professional external review before launch regardless of these results."
+   - **For Scoped Scan:** "This was a focused [SCOPE]-only check ([LIST OF RUN CHECKS]). Skipped checks: [LIST OF SKIPPED CHECKS]. A clean scoped check does not mean the application is production-ready. Always run a full `/checkmyvibe` audit prior to release, and obtain a professional external security review if handling sensitive or regulated data."
 
 ## Notes for the agent
 
-- Always produce an audit/report after the scan; do not stop at raw findings.
+- Always produce a review report after the check; do not stop at raw findings.
 - Write the entire report in clear, accessible language. Frame findings around concrete, real-world user consequences rather than abstract technical concepts. A non-technical stakeholder must be able to read the report and immediately understand the real-world danger.
-- The audit should clearly separate what was found, what was fixed, how it was fixed, and what remains.
+- The review should clearly separate what was found, what was fixed, how it was fixed, and what remains.
 - Always run the available scripts (located in the `scripts/` directory relative to this `SKILL.md` file) before relying on reasoning alone for Checks 1-4 — they exist so those specific checks are reliable and repeatable rather than dependent on re-deriving the logic every time.
 - If a script is missing, fails to run, or the language/stack isn't supported by
   it, say so explicitly in the report ("automated secret scan could not run;
@@ -323,4 +344,4 @@ End every audit with, in this order:
   categories — pick the most relevant category and reference it once.
 - If the codebase is large, prioritize routes and files that touch
   authentication, payments, and any endpoint returning data tied to a specific
-  user ID — these are where real damage concentrates.
+  user ID — these are where real damage concentrates.

package/commands/checkmyvibe-auth.md

@@ -0,0 +1,3 @@
+Read the checkmyvibe `SKILL.md`. Run only **Check 3 (missing or fake authentication)** from that skill.
+
+Use the same report format, severity rubric, and final summary structure defined in `SKILL.md`, but scope the final summary to note that this was an authentication-only check (Checks 1, 2, 4, 5, 6, and 7 were skipped), not a full audit, and suggest running the full `/checkmyvibe` audit before launch.

package/commands/checkmyvibe-backend.md

@@ -0,0 +1,8 @@
+Read the checkmyvibe `SKILL.md`. Run only the server-side / backend checks from that skill:
+- **Check 3 (missing or fake authentication)**
+- **Check 4 (database and backend-as-a-service misconfiguration)**
+- **Check 5 (broken object-level authorization / IDOR)**
+- **Check 6 (unvalidated inputs, server-side / query portion)**
+- **Check 7 (payment and pricing logic)**
+
+Use the same report format, severity rubric, and final summary structure defined in `SKILL.md`, but scope the final summary to note that this was a backend-only check (Check 1 client bundle secrets and Check 2 .gitignore hygiene were skipped), not a full audit, and suggest running the full `/checkmyvibe` audit before launch.

package/commands/checkmyvibe-db.md

@@ -0,0 +1,3 @@
+Read the checkmyvibe `SKILL.md`. Run only **Check 4 (database and backend-as-a-service misconfiguration)** from that skill.
+
+Use the same report format, severity rubric, and final summary structure defined there, but scope the final summary to note that this was a database-only check (Checks 1, 2, 3, 5, 6, and 7 were skipped), not a full audit, and suggest running the full `/checkmyvibe` audit before launch.

package/commands/checkmyvibe-frontend.md

@@ -0,0 +1,6 @@
+Read the checkmyvibe `SKILL.md`. Run only the frontend / client-side checks from that skill:
+- **Check 1 (client-exposed secrets in frontend bundles and environment configurations)**
+- **Check 3 (client-side-only auth checks / UI hiding without server enforcement)**
+- **Check 7 (client-side payment or pricing logic)**
+
+Use the same report format, severity rubric, and final summary structure defined in `SKILL.md`, but scope the final summary to note that this was a frontend-only check (Check 2 .gitignore hygiene, Check 4 database rules, Check 5 IDOR, Check 6 server input validation, and full server auth checks were skipped), not a full audit, and suggest running the full `/checkmyvibe` audit before launch.

package/commands/checkmyvibe-payment.md

@@ -0,0 +1,3 @@
+Read the checkmyvibe `SKILL.md`. Run only **Check 7 (client-side payment or pricing logic)** from that skill.
+
+Use the same report format, severity rubric, and final summary structure defined in `SKILL.md`, but scope the final summary to note that this was a payment/pricing-only check (Checks 1, 2, 3, 4, 5, and 6 were skipped), not a full audit, and suggest running the full `/checkmyvibe` audit before launch.

package/commands/checkmyvibe-secrets.md

@@ -0,0 +1,3 @@
+Read the checkmyvibe `SKILL.md`. Run only **Check 1 (exposed secrets and credentials)** and **Check 2 (.gitignore hygiene)** from that skill.
+
+Use the same report format, severity rubric, and final summary structure defined in `SKILL.md`, but scope the final summary to note that this was a secrets-only check (Checks 3, 4, 5, 6, and 7 were skipped), not a full audit, and suggest running the full `/checkmyvibe` audit before launch.

package/commands/checkmyvibe.md

@@ -0,0 +1,3 @@
+Read the checkmyvibe `SKILL.md`. Run a full production readiness and code quality audit across all checks (Checks 1 through 7: exposed secrets, .gitignore hygiene, missing/fake auth, database misconfigurations, IDOR/BOLA, unvalidated inputs, and client-side payment logic).
+
+Use the report format, severity rubric, and final summary structure defined in `SKILL.md`.

package/install.js

@@ -9,13 +9,17 @@ const readline = require('readline');
 const srcSkill = path.join(__dirname, 'SKILL.md');
 const srcScripts = path.join(__dirname, 'scripts');
 const srcReferences = path.join(__dirname, 'references');
+const srcCommands = path.join(__dirname, 'commands');
 
 // Destination selection
 const cwd = process.cwd();
 const hasLocalClaude = fs.existsSync(path.join(cwd, '.claude'));
 
-const localDest = path.join(cwd, '.claude', 'skills', 'checkmyvibe');
-const globalDest = path.join(os.homedir(), '.claude', 'skills', 'checkmyvibe');
+const localSkillDest = path.join(cwd, '.claude', 'skills', 'checkmyvibe');
+const localCommandsDest = path.join(cwd, '.claude', 'commands');
+
+const globalSkillDest = path.join(os.homedir(), '.claude', 'skills', 'checkmyvibe');
+const globalCommandsDest = path.join(os.homedir(), '.claude', 'commands');
 
 function copyRecursiveSync(src, dest) {
   if (fs.statSync(src).isDirectory()) {
@@ -28,34 +32,54 @@ function copyRecursiveSync(src, dest) {
   }
 }
 
-function performInstall(destPath) {
+function performInstall(skillDest, commandsDest) {
   try {
-    console.log(`\nInstalling checkmyvibe to: ${destPath}...`);
+    console.log(`\nInstalling checkmyvibe skill to: ${skillDest}...`);
     
-    // Clear destination if it already exists (overwrite mode)
-    if (fs.existsSync(destPath)) {
+    // Clear skill destination if it already exists (overwrite mode)
+    if (fs.existsSync(skillDest)) {
       if (fs.rmSync) {
-        fs.rmSync(destPath, { recursive: true, force: true });
+        fs.rmSync(skillDest, { recursive: true, force: true });
       } else {
-        fs.rmdirSync(destPath, { recursive: true });
+        fs.rmdirSync(skillDest, { recursive: true });
       }
     }
-    fs.mkdirSync(destPath, { recursive: true });
+    fs.mkdirSync(skillDest, { recursive: true });
 
     // Copy SKILL.md
-    fs.copyFileSync(srcSkill, path.join(destPath, 'SKILL.md'));
+    fs.copyFileSync(srcSkill, path.join(skillDest, 'SKILL.md'));
     
-    // Copy folders
-    copyRecursiveSync(srcScripts, path.join(destPath, 'scripts'));
-    copyRecursiveSync(srcReferences, path.join(destPath, 'references'));
+    // Copy folders into skill destination
+    copyRecursiveSync(srcScripts, path.join(skillDest, 'scripts'));
+    copyRecursiveSync(srcReferences, path.join(skillDest, 'references'));
+    if (fs.existsSync(srcCommands)) {
+      copyRecursiveSync(srcCommands, path.join(skillDest, 'commands'));
+    }
+
+    // Install slash commands into agent commands directory
+    if (fs.existsSync(srcCommands)) {
+      console.log(`Installing slash commands to: ${commandsDest}...`);
+      fs.mkdirSync(commandsDest, { recursive: true });
+      fs.readdirSync(srcCommands).forEach((cmdFile) => {
+        if (cmdFile.endsWith('.md')) {
+          fs.copyFileSync(path.join(srcCommands, cmdFile), path.join(commandsDest, cmdFile));
+        }
+      });
+    }
 
     console.log('\n=========================================');
-    console.log('🎉 checkmyvibe Agent Skill installed!');
+    console.log('🎉 checkmyvibe Agent Skill & Commands installed!');
     console.log('=========================================');
-    console.log('\nHow to run a security audit:');
-    console.log('1. Open your terminal in the target repository.');
-    console.log('2. Ask your coding agent: "run a security audit"');
-    console.log('3. The agent will execute checkmyvibe\'s checks and output a prioritized report!');
+    console.log('\nHow to run checkmyvibe:');
+    console.log('• Full Audit:');
+    console.log('  /checkmyvibe  or  "run checkmyvibe"');
+    console.log('\n• Focused / Scoped Scans:');
+    console.log('  /checkmyvibe secrets   (or /checkmyvibe-secrets)   -> Exposed secrets & .gitignore');
+    console.log('  /checkmyvibe auth      (or /checkmyvibe-auth)      -> Authentication checks');
+    console.log('  /checkmyvibe db        (or /checkmyvibe-db)        -> Database & BaaS rules / RLS');
+    console.log('  /checkmyvibe backend   (or /checkmyvibe-backend)   -> Server-side (auth, db, IDOR, input, payment)');
+    console.log('  /checkmyvibe frontend  (or /checkmyvibe-frontend)  -> Client-side (bundle leaks, client auth, pricing)');
+    console.log('  /checkmyvibe payment   (or /checkmyvibe-payment)   -> Payment & pricing integrity');
     console.log('=========================================\n');
   } catch (err) {
     console.error('Error installing skill:', err.message);
@@ -65,7 +89,7 @@ function performInstall(destPath) {
 
 if (hasLocalClaude) {
   // If .claude folder exists in the project root, install at project level directly
-  performInstall(localDest);
+  performInstall(localSkillDest, localCommandsDest);
 } else {
   // Prompt user for local vs global/personal installation
   const rl = readline.createInterface({
@@ -74,16 +98,16 @@ if (hasLocalClaude) {
   });
 
   console.log('No local .claude/ directory detected in the current working directory.');
-  console.log(`1. Install locally to current directory: ${path.join('.claude', 'skills', 'checkmyvibe')}`);
-  console.log(`2. Install globally/personally: ${globalDest.replace(os.homedir(), '~')}`);
+  console.log(`1. Install locally to current directory: ${path.join('.claude', 'skills', 'checkmyvibe')} & ${path.join('.claude', 'commands')}`);
+  console.log(`2. Install globally/personally: ${globalSkillDest.replace(os.homedir(), '~')} & ${globalCommandsDest.replace(os.homedir(), '~')}`);
   
   rl.question('\nSelect installation destination (1 or 2, default 2): ', (answer) => {
     rl.close();
     const selection = answer.trim();
     if (selection === '1') {
-      performInstall(localDest);
+      performInstall(localSkillDest, localCommandsDest);
     } else {
-      performInstall(globalDest);
+      performInstall(globalSkillDest, globalCommandsDest);
     }
   });
 }

package/package.json

@@ -1,14 +1,15 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "checkmyvibe",
-  "version": "1.0.1",
-  "description": "A structured security-audit workflow Agent Skill for AI coding assistants to catch common vibe-coded vulnerabilities.",
+  "version": "1.1.0",
+  "description": "A structured production readiness and code quality workflow Agent Skill for AI coding assistants to catch common vibe-coded configuration issues.",
   "main": "install.js",
   "bin": {
     "checkmyvibe": "install.js"
   },
   "files": [
     "SKILL.md",
+    "commands/",
     "scripts/",
     "references/",
     "install.js",
@@ -20,7 +21,8 @@
   },
   "keywords": [
     "ai-agent",
-    "security-audit",
+    "code-quality",
+    "production-readiness",
     "claude-code",
     "cursor",
     "vibe-coding",

package/references/{vibe_vulnerability_patterns.md → vibe_risk_patterns.md}

@@ -1,6 +1,6 @@
-# Vibe Vulnerability Patterns
+# Vibe Readiness Risk Patterns
 
-This document serves as a reference for common vulnerability patterns identified in AI-generated ("vibe-coded") applications. AI coding assistants frequently introduce these security flaws because they prioritize speed, feature completion, and standalone component demonstration over robust security configurations.
+This document serves as a reference for common readiness risk patterns identified in AI-generated ("vibe-coded") applications. AI coding assistants frequently introduce these configuration and design flaws because they prioritize speed, feature completion, and standalone component demonstration over robust production-ready setups.
 
 ---