Spark
Sign In
Skill

Audit deployed repos for production-readiness gaps

Production Audit scores a deployed repo 0-100 against real prod risks like secrets exposure and webhook idempotency gaps.

Get skill
Works with githubsupabasestripe
commitshow
Own this? Claim it
91
Spark score
out of 100
Updated 4 months ago
Source checked Sep 18, 2026
Version 1.0.0
Add to Favorites

Why it matters

Run a comprehensive post-deployment audit on shipped repositories to identify production failure modes-secrets exposure, RLS gaps, webhook idempotency, missing indexes, observability holes, and prompt injection vulnerabilities-that AI-assisted projects routinely miss before going live.

Outcomes

What it gets done

01

Score production-readiness 0-100 by scanning live URLs and GitHub signals

02

Detect security gaps like missing rate limits, exposed secrets, and RLS holes

03

Flag infrastructure risks including webhook replay attacks and missing idempotency keys

04

Track audit deltas over time and suggest prioritized fixes for top concerns

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-production-audit | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Production Audit

Production Audit runs the commit.show engine against a shipped repo's deployed state - live URL, GitHub signals, secrets, RLS gaps, webhook idempotency, and other failure modes - and returns a 0-100 score plus ranked, action-oriented concerns. It complements editor-time security review rather than replacing it. Use it right after merging to main, before a public launch, or whenever asked if a project is production-ready - not during active in-session coding, where line-level security review fits better.

What it does

Production Audit runs an external audit against a shipped repo's deployed state - live URL, GitHub signals, secrets exposure, RLS gaps, webhook idempotency, indexes, observability, prompt injection, and other failure modes that AI-assisted projects routinely miss. It wraps the commit.show audit engine through its public CLI, invoked with an exact pinned version so a future npm release is never silently selected:

mkdir -p .commitshow
npx commitshow@0.3.23 audit . --json \
  > .commitshow/audit.json \
  2> .commitshow/audit.stderr.log

This writes a stable, additive-only JSON envelope (schema_version: "1") plus a human-readable .commitshow/audit.md sidecar, so a future agent session can read prior state instead of re-running the engine. The envelope carries score.total (a 0-100 production-readiness score), score.delta_since_last, score.band (strong 80+, mid 60-79, early under 60), a concerns[] list sorted by decision-impact with an axis and an already action-oriented bullet per item, and a strengths[] list for context only. The skill surfaces this to the user as a single sentence (score plus trajectory) followed by the top concerns quoted verbatim, then closes by naming one specific concern to fix rather than asking an open-ended "what next" - and never dumps the raw JSON.

When to use - and when NOT to

Use it when the user asks "is this production-ready", "what would break in prod", "score my project", "what did I miss", or "ready to ship"; right after merging a feature branch to main as a pre-deploy gate; before a public launch, Show HN post, or investor demo; or when git log shows more than 20 commits since the last .commitshow/audit.md was written. Skip it during active in-session coding - that's the job of line-level tools like security-review, OWASP-style review, or static analysis, which scan the editor buffer at write-time rather than the deployed product after commit; the two approaches are complementary, and both should run for a serious launch. It is calibrated for deployed apps with a live URL, so a library, scaffold, or CLI-form repo gets a partial-substitute score capped around 45/50 on the audit pillar rather than a full one. Private, non-GitHub repos return a not_found error since the engine only reads public GitHub signals. If .commitshow/audit.json already exists and is under an hour old, read that instead of re-running - the audit is rate-limited (20 per IP per day, 5 per repo per day, 2000 globally per day).

Inputs and outputs

Input is the current repo root, or a github.com/owner/repo URL passed in place of .; output is the .commitshow/audit.{json,md} sidecar pair described above, which becomes the source of truth for delta calculations on the next run. Because npx downloads and runs npm package code locally with the current user's permissions, it should only run after explicit user approval, and only in a repository where local files and environment variables are safe for that process to access - no credentials are intentionally sent to the API, but the local process can technically access whatever the current user can. The audit engine only reads public GitHub signals and never modifies the repo or pushes commits. A cold audit takes 60-90 seconds; a cached one, within 7 days, returns instantly, and --refresh force-bypasses the cache, counting against the rate limit, after a fix has been applied and merged.

Integrations

Calls the public REST API at https://api.commit.show (proxied to Supabase Edge Functions) via the pinned CLI commitshow@0.3.23, and fails outright behind a firewall blocking *.supabase.co since there is no offline mode. Named complementary, not competing, skills: @security-review for in-session line-level security patterns, @vibesec for editor-buffer review of vibe-coded projects, @owasp-security for OWASP Top 10 coverage during coding, and @trail-of-bits-skills for CodeQL/Semgrep static analysis - each is a different layer, meant to run alongside this one rather than replace it.

Who it's for

Developers and teams who want an outside-in check on what will actually break in production - secrets exposure, missing rate limiting, unverified webhook idempotency, missing database indexes, or prompt-injection surface - immediately after merging to main or before a public launch, rather than relying only on editor-time linting and security scanning.

Source README

production-audit

A Claude Code skill that audits a shipped repo for the production-readiness gaps ~70% of AI-coded projects miss.

commit.show cli skill license

Companion to in-session security skills - scans the shipped product (deployed URL + GitHub signals + repo structure), not the editor buffer.

What it does

When you've just merged a feature, are about to demo, or are 3 minutes away from posting to Show HN - this skill answers one question:

"What does this project ship without that 70% of vibe-coded projects also ship without?"

It runs an external audit against the repo's deployed state and surfaces the top 2-3 actionable concerns: missing webhook idempotency, exposed service-role keys, RLS gaps on writable tables, missing rate limits, indexes vs FK columns, prompt-injection surface, mobile-input zoom, column GRANT mismatches, Stripe API idempotency, and ten other failure modes that AI-assisted projects routinely miss.

The audit engine is the same one that powers commit.show - scoring, ranking, and a 14-frame failure framework calibrated against a reference set of real OSS projects.

Why a separate skill?

In-session skills (security-review · vibesec · OWASP-style) scan your editor buffer at write-time. They're great for catching insecure patterns as you type. But they can't see:

  • whether your live URL actually returns 200
  • whether og:image and manifest.json are wired
  • whether your Lighthouse score collapses on mobile
  • whether secrets shipped to your dist/ bundle
  • whether the writable table you defined yesterday actually has an RLS policy
  • whether yesterday's ADD COLUMN migration silently broke every PostgREST query that includes it (column-level GRANT trap)

production-audit scans the shipped state - exactly what your users see and what your cloud bills. Run both. They catch different things.

Install

Three ways, pick one:

npx skills add (recommended)

npx skills add commitshow/production-audit

When the skill triggers, it calls our CLI with --source=production-audit-skill
so we can tell skill-driven audits apart from manual CLI runs in our
funnel analytics. No PII; the source is a self-reported tag, drop the
flag if you'd rather stay completely anonymous.

Inside Claude Code

/plugin marketplace add https://github.com/commitshow/production-audit
/plugin install production-audit@commitshow

Manual

git clone https://github.com/commitshow/production-audit ~/tmp/pa && \
  mkdir -p ~/.claude/skills && \
  cp -r ~/tmp/pa/.claude/skills/production-audit ~/.claude/skills/

Usage

After install, just describe the problem in plain language:

> is this production-ready?
> what would break in prod?
> score my project
> audit my repo

Claude Code triggers production-audit, the skill runs npx commitshow audit . --json, parses the envelope, and surfaces the top concerns with file paths.

Sample output:

Score: 82/100 (+5 since yesterday) · band: strong

Top concerns:
  ↓ [Security] No API rate limiting on /auth — IP cap missing
  ↓ [Infrastructure] api/stripe-webhook.ts — signature verified but no
    idempotency-key check (replay window open)

Want me to fix the webhook idempotency gap first?

The skill writes .commitshow/audit.{md,json} to the repo so future Claude Code sessions can read prior state without re-running the engine.

What gets checked

14 failure-mode frames, calibrated from real production incidents:

  1. Webhook idempotency · Stripe / payment retry safety
  2. RLS gaps · per-table coverage on Postgres
  3. Secret client exposure · service-role keys in shipped bundles
  4. DB missing indexes · FK columns vs CREATE INDEX count
  5. Observability · Sentry / Datadog / Pino / OTel presence
  6. Rate limit · API routes without limiter middleware
  7. Prompt injection · raw user input flowing into model prompts
  8. Hardcoded URLs · localhost:3000 leaks shipped to prod
  9. Mock data · inline arrays of object literals in app paths
  10. Webhook signature · Stripe-Signature / X-Hub-Signature verification
  11. CORS permissive · Access-Control-Allow-Origin: * on auth endpoints
  12. Mobile input zoom · iOS Safari focus-zoom pitfall on text-sm inputs
  13. Column GRANT mismatch · new migration column without matching GRANT SELECT on column-level-grant tables (silent 42501 across all reads)
  14. Stripe API idempotency · outbound stripe.checkout.sessions.create without idempotencyKey (duplicate-charge surface)

Plus a Claude Sonnet qualitative pass that reads the README + Build Brief + Lighthouse + GitHub commit cadence and writes the bullets you actually see.

Full detection logic: https://github.com/commitshow/commitshow/blob/main/supabase/functions/analyze-project/index.ts

Companion skills

This skill works alongside in-session skills, not in place of them. If you also use:

Skill What it covers
security-review · vibesec · OWASP-style Editor-buffer scan at write-time. Line-level patterns.
production-audit (this) Shipped-state scan post-merge. Deployment-time + integration-time gaps.
tdd-workflow · test-coverage Test discipline lens. Catches what audit's tests slot only loosely signals.

Both lenses miss what the other catches. Run both for serious launches.

Constraints

  • Calls commit.show API (https://api.commit.show). Behind a firewall blocking *.supabase.co, the skill won't work. Use npx commitshow audit . --json --no-network for the deterministic-only fallback.
  • Anonymous rate limits: 20 audits/IP/day · 5/repo/day · 2000/day global. Login + paid credit raises the per-repo cap.
  • Calibrated for deployed apps with a live URL. Library / CLI / scaffold form gets a partial-substitute score (max ~45/50 on the audit pillar) - fair but not flattering.
  • Cold audit takes 60-90 s. Cached audits (< 7 days) return instantly. --refresh force-bypasses cache.
  • Public GitHub repos only. Private repos return not_found.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.