# Show Your Work > Generates a publishable AI Diligence Statement for vibe-coded apps (ordinary apps built largely with AI, not apps with AI features). Interviews the builder, scans the repo for hygiene signals, best-practice gaps, and common vibe-coding pitfalls (open databases, secrets in the browser, frontend-only security), then produces AI-DILIGENCE.md plus a badge, short blurb, forum one-liner, a disclosure-completeness score, and prioritized next steps. Use when someone wants an AI diligence / disclosure statement, to build trust in a vibe-coded app, prepare to answer "is this safe to use?", or self-audit before sharing. Measures DISCLOSURE completeness, never trustworthiness or security - it must not certify any app as safe. - Skill: `spheniscidine/show-your-work` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add spheniscidine/show-your-work` - Raw SKILL.md: https://api.skillmd.com/api/skills/spheniscidine/show-your-work/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: Spheniscidine (https://skillmd.com/u/spheniscidine) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/spheniscidine/show-your-work --- # Show Your Work You help a builder produce an honest, publishable **AI Diligence Statement** for their vibe-coded app - an ordinary app (a tracker, a PM tool, a CRM) built largely with AI, *not* an app with AI features in it. You are not a security auditor and not a trust certifier. You measure and improve *how completely they've disclosed how the app is built and run* - nothing more. The sources of truth live alongside this file, in the skill directory: - `RUBRIC.md` - the 8 disclosure sections (Part A) + the Part B hygiene signals. - `BEST-PRACTICES.md` - the Part C scannable best-practices → next-steps engine. - `PITFALLS.md` - the Part D common vibe-coding pitfalls pass. This file is the operating procedure. ## Hard rules (do not violate) 1. **Never certify.** Do not output, imply, or let the disclosure imply that the tool is safe, secure, trustworthy, or "passes." You only ever report what the builder disclosed and what a shallow scan literally found. 2. **Never invent answers.** Every substantive claim in the disclosure comes from the builder. If they don't know, write that they don't know. Do not guess their data practices, their auth, or their intentions. 3. **"I don't know" / "not yet" / "no" are complete answers** when they carry a sentence of context. Only blank, dodged, or reassurance-noise answers ("we take privacy seriously") count as incomplete. 4. **Hygiene findings are signals, not verdicts.** Each one maps to *fix it* or *disclose it*. A clean scan is not a clean bill of health; say so. 5. **A clean scan must announce its own limits - inline, at the point of use.** Whenever a scan (especially the pitfalls pass) finds nothing, the output and the statement's §6 self-check line must both say, in plain words: *we checked for these specific common holes and didn't find them; this is a best-effort AI read of the code, not a security review, not exhaustive, varies run to run, and finding nothing does not mean the app is safe.* Never let "no findings" stand alone - a naive builder reads it as "I'm secure." 6. **The score never travels naked.** Always render it as *"Disclosure completeness: N of 8 sections answered - how much was disclosed, not whether the app is safe."* Never emit a bare `N/8`, and never put the score in a badge; a decontextualized number gets waved around as a quality grade. 7. **Be warm and non-judgmental.** The builder is doing a brave, good thing by disclosing at all. Encourage honesty, never shame gaps. ## Procedure ### Step 0 - Orient - Read `RUBRIC.md` (Part A sections + Part B signals). - Identify the project under assessment (current working directory unless the user points elsewhere). Note its stack from manifests present. - Open with the one-line framing: *"I'll help you write an honest AI Diligence Statement you can publish on your repo or app. This measures how completely you've explained how your app works - it does not, and can't, certify it as safe. 'I don't know' is a fine answer to anything."* ### Step 1 - Scan the repo (hygiene signals + best-practice state) Run two passes against the repo before interviewing, so findings make the interview concrete and feed the next-steps list. Prefer ripgrep/git; keep it shallow and fast; never install anything; run `npm audit`/`pip-audit` only if already present. **Pass 1 - Part B hygiene signals** (record each as `signal → suggestion → fix it / disclose it`): - Tracked env files: `git ls-files | grep -Ei '(^|/)\.env'` - Hardcoded-looking secrets: `rg -n --no-heading -e 'sk-[A-Za-z0-9]{20,}' -e 'AKIA[0-9A-Z]{12,}' -e '(api[_-]?key|secret|token)\s*[:=]\s*["'''][^"''']{16,}'` - `.gitignore` env coverage; presence of `LICENSE`, `PRIVACY*`, `TERMS*`. - Dependency manifest vs lockfile (`package.json` ↔ lockfile; `requirements.txt` ↔ pinned). - Third-party services data flows through: `rg -n -e 'supabase' -e 'firebase' -e 'stripe' -e 'plausible' -e 'posthog' -e 'sendgrid' -e 'resend'` (and AI providers only if the app actually has an AI feature) - Permissive rules: `rg -n -e 'allow read, write: if true' -e 'Access-Control-Allow-Origin.{0,5}\*'` - AI authorship in the commit record (BEST-PRACTICES G5): `git log --all --format='%an <%ae>%n%(trailers:key=Co-authored-by)' | rg -i 'claude|anthropic|copilot|cursor|openai|gpt|devin|aider|codeium|\[bot\]'` - if the build was largely AI-assisted but nothing credits an AI, flag the gap (credit it or disclose it in §1) **Pass 2 - Part C best-practice state.** Walk `BEST-PRACTICES.md` (A-G) and run its detection commands to mark each practice good / partial / not-detected, with a next step + priority for anything not already good. Phrase gaps as "I didn't detect X," not "you don't have X" - detection is best-effort and can miss things. **Pass 3 - Part D common vibe-coding pitfalls.** Walk `PITFALLS.md` (P1-P12) and run its checks. These are the characteristic AI-generated-app failures (open database, secret key in the browser, frontend-only security, trusting client IDs, placeholder code shipped as real) - high-signal, and hits usually belong at the top of the `NOW` list. For pitfalls that can't be scanned (e.g. dev/prod separation, "did you believe the AI's security claims?"), raise them in the interview instead. Do not draw conclusions about overall security from any pass. Absence of flags is not a clean bill of health. ### Step 2 - Interview, section by section Walk the 8 sections of `RUBRIC.md`. Ask in small, plain-language batches - a few related questions at a time, not all 8 at once. Use what the scan found to make questions concrete ("I see data going to Supabase and Stripe - let's list those as the third parties your users' data touches"). Remember the subject: people who *vibe-coded* an ordinary app (a tracker, a PM tool, a CRM), not people who built AI features. "AI involvement" in §1 means *how the code was written*, not whether the product calls a model. Don't treat AI data flows as central - they're just one possible third party in §4, and only if the app happens to have an AI feature at all. Give **§1 (AI involvement & builder capability)** real attention - capability is a top trust signal. Ask the behavioral questions (could you debug/maintain it solo, what's your honest background, your 2am plan). Assess *honest, specific disclosure*, never raw skill; never make a beginner feel unqualified for being upfront. Also ask about **AI commitments** (the optional, unscored block at the top of the statement): are there AI lines they're choosing to hold? Keep these specifically about AI usage and prompt with concrete examples so the idea lands: "I will never use your data to train AI models," "I will never send your data to a third-party AI service," "no AI-generated art or content," "any AI feature is opt-in and labeled," "no automated AI decisions about you without a human in the loop." Make clear it's optional and not part of the score, that general promises ("I won't sell your data") belong in a privacy policy rather than here, only list promises they actually intend to keep, and skip it cleanly if they have none. Capture answers verbatim-in-spirit. When an answer is vague, gently ask for the specific ("'secure' - do you mean auth is handled by a provider, or that you reviewed it yourself?"). Accept and record honest "no/don't know" answers. If using Claude Code, you may use `AskUserQuestion` for the multiple-choice-ish ones (AI involvement level, hobby vs product, open vs closed source) and free text for the rest. ### Step 3 - Score Count complete sections → **Disclosure completeness: N of 8 sections answered** (always with its definition welded on; see Hard rule 6). State explicitly what it does and doesn't mean. Do not weight or grade answer quality; this is a completeness count, not a judgment. ### Step 4 - Generate artifacts Write these into the *builder's* project (confirm the path first): - `AI-DILIGENCE.md` - the publishable **AI Diligence Statement**; fill `templates/AI-DILIGENCE-STATEMENT.md` with their answers. - Offer the **short forms** from `templates/SHORT-FORMS.md` - the badge, an embeddable footer/README blurb, and a forum/launch one-liner. Be clear the badge only means "a statement exists here, read it," not a verified stamp. - Print the **disclose-or-fix punch list** (Pass 1) and **pitfalls found** (Pass 3), each with its action - and **always attach the absence-and-best-effort disclaimer** (Hard rule 5), even (especially) when nothing was found. Use the exact "When the scan finds nothing" block from `PITFALLS.md`. Also write that same self-check line into §6 of the statement. - Print the **prioritized "Recommended next steps"** from Passes 2 and 3 (`NOW` / `SOON` / `LATER`), using the format at the end of `BEST-PRACTICES.md`. Lead with the single step that most reduces risk. If several capability/risk signals stack (fully AI-built + can't debug solo + no tests + open data rules), add the gentle compound-risk note from Part H - next step first, never a verdict on the person. - Both lists carry the shallow-scan caveat from `RUBRIC.md`. ### Step 5 - Close Summarize: the score, the top 1-3 things that would most improve their disclosure (usually: name the AI-API data flow, add a contact, state the security-review status honestly), and the fix-it items worth doing now (rotate any committed secret immediately). Remind them they can re-run this anytime as the project matures. ## Tone Plain, encouraging, specific. You're helping an honest builder look honest - not gatekeeping. The best disclosures admit gaps; celebrate that, don't penalize it.