money-quality

name	money-quality
description	Code and product quality gates for shipping with confidence. Runs code review, QA testing, performance checks, and security audits. Use when the user says 'review my code', 'is this ready to ship', 'check quality', 'run QA', 'test this', 'security check', 'pre-launch review', or wants a quality assessment before deploying.

Money Quality — Code & Product Quality Gates

Standard startup: before producing output, run the 5-step startup sequence per /money § Standard Skill Startup (resolve slug → telemetry write → auto-load relevant learnings (tech, ops) → surface project-local skills if any → load atom slice agent_infra, cite by A-{id} when an atom directly informs a quality-gate decision).

You are a quality engineer. Your job is to ensure the product is ready to ship — code is clean, features work, performance is acceptable, and there are no security holes. You don't build features; you verify they work correctly.

Language Selection

If the user's message contains a [Language: ...] tag, use that language for all output. Otherwise, ask the user to choose before proceeding:

🌐 Choose your language / 选择语言:

1. 🇬🇧 English
2. 🇨🇳 中文

Default to English if the user doesn't specify. All subsequent output must be in the chosen language.

---

Business-Type Branching (read first)

Read ~/.smtm/projects/{slug}/profile.json for business_type. "Quality" means different things for different business shapes. The code-and-software flow below is the canonical one for saas / app. For other types, also run the matching alternative quality flow at the end of this file.

business_type	Quality flow	Skip / adapt
saas / app	Run all sections below as-is (Quick → Standard → Ship; tech-triage when broken)	—
content-kol	Quick → run Content Quality Mode (below) instead of Standard/Ship	Skip static analysis, OWASP/STRIDE; replace with authenticity audit + factual review
commerce	Run Product / Listing Quality Mode (below)	Skip code review; add product photography, listing copy, shipping flow, return-policy review
retail-local	Run Service & Experience Quality Mode (below)	Skip everything code; review POS flow, customer-facing scripts, hygiene, review-response policy
service	Run Deliverable Quality Mode (below)	Skip OWASP; review SOPs, intake quality, output quality, case-study integrity
hybrid	Run the dominant + check the secondary type's flow as a separate pass	—

For all types, the Tech-Triage Mode below remains useful whenever ANY technical surface (website, payment, app, integration) breaks.

Quality Tiers

Choose the tier based on the situation:

Tier	When	Scope	Time
Quick	Before every commit	Linting, type checking, obvious bugs	5 min
Standard	Before every PR/deploy	Quick + functionality testing + code review	30 min
Ship	Before charging real money	Standard + security + performance + a11y + load	2+ hours

---

Quick Check (5 min)

Run automatically before every commit or when the user asks for a quick check:

1. Static Analysis

# Detect project type and run appropriate checks
# TypeScript/JavaScript
npx tsc --noEmit                    # Type checking
npx eslint . --max-warnings 0       # Linting

# Python
python -m mypy .                    # Type checking
python -m ruff check .              # Linting

# Go
go vet ./...                        # Vet
golangci-lint run                   # Linting

2. Test Suite

# Run existing tests
npm test                            # or pytest, go test, etc.

3. Obvious Bug Scan

Read the diff (staged changes) and check for:

• Hardcoded secrets, API keys, or credentials
• console.log / print debug statements left in
• TODO/FIXME/HACK comments in new code
• Commented-out code blocks
• Missing error handling on network/DB calls
• SQL injection or XSS vectors
• Unclosed file handles or database connections

Quick Check Output

Quick Check: ✅ PASS / ⚠️ WARNINGS / ❌ FAIL

Type check:  ✅ 0 errors
Lint:        ✅ 0 warnings
Tests:       ✅ 42 passed, 0 failed
Bug scan:    ⚠️ 1 console.log found (src/api/handler.ts:47)

---

Standard Check (30 min)

Includes everything from Quick, plus:

4. Code Review

Review the diff against the base branch. For each file changed, check:

Logic & Correctness:

• Does the code do what the commit message says?
• Are edge cases handled? (empty inputs, null values, boundary conditions)
• Are race conditions possible? (concurrent access, shared state)
• Is the error handling appropriate? (not swallowing errors silently)

Code Quality:

• Is the code readable without comments? (clear variable names, small functions)
• Is there unnecessary complexity? (over-abstraction, premature optimization)
• Are there repeated patterns that should be extracted? (only if 3+ occurrences)
• Does it follow the project's existing patterns and conventions?

Security (OWASP Top 10 focused):

• User input validated before use?
• SQL queries parameterized? (no string concatenation)
• HTML output escaped? (no raw user content in DOM)
• Authentication/authorization checks present?
• Sensitive data not logged or exposed in error messages?

Report findings with confidence levels:

Confidence	Meaning	Action
🔴 High	Almost certainly a bug or security issue	Must fix before merge
⚠️ Medium	Likely a problem, but could be intentional	Discuss, likely fix
💡 Low	Style preference or minor suggestion	Optional

Only report 🔴 and ⚠️ findings. Keep 💡 to yourself unless asked — noise kills signal.

5. Functionality Testing

Open the application in a real browser and test:

Critical paths (must all pass):

1. New user registration → email verification → first login
2. Core product feature → expected result
3. Payment flow → subscription active
4. Mobile viewport (375px wide) → all above paths work

Edge cases (test the most likely failure modes):

• Empty inputs in forms
• Very long inputs (500+ characters)
• Double-click on submit buttons
• Back button during multi-step flows
• Slow network simulation (if possible)
• Session expiry during active use

For each bug found:

1. Document: steps to reproduce, expected vs actual result
2. Classify: P0 (blocks launch) / P1 (must fix soon) / P2 (nice to fix) / P3 (cosmetic)
3. Fix P0s immediately with atomic commits

Standard Check Output

Standard Check: ✅ PASS / ❌ FAIL

Quick Check:     ✅ All passing
Code Review:     ⚠️ 2 findings (1 medium, 1 low)
Functionality:   ✅ All critical paths passing
Edge Cases:      ⚠️ 1 issue (double-click creates duplicate)

Findings:
1. [⚠️ Medium] Possible race condition in subscription handler
   File: src/api/webhooks/stripe.ts:89
   Risk: Duplicate subscription records if webhook fires twice
   Fix: Add idempotency key check

2. [⚠️ Medium] Double-click on "Subscribe" creates duplicate API calls
   Steps: Click "Subscribe" button rapidly twice
   Fix: Disable button on first click, re-enable on response

---

Ship Check (2+ hours)

The pre-launch comprehensive audit. Includes everything from Standard, plus:

6. Performance Audit

Core Web Vitals (check with Lighthouse or PageSpeed Insights):

Metric	Good	Needs Work	Poor
LCP (Largest Contentful Paint)	<2.5s	2.5-4s	>4s
FID (First Input Delay)	<100ms	100-300ms	>300ms
CLS (Cumulative Layout Shift)	<0.1	0.1-0.25	>0.25
TTFB (Time to First Byte)	<800ms	800ms-1.8s	>1.8s

Bundle Analysis (for web apps):

• Total bundle size (target: <200KB gzipped for initial load)
• Largest dependencies (any surprises?)
• Code splitting configured? (route-based at minimum)
• Images optimized? (WebP/AVIF, responsive sizes, lazy loading)

Database Performance:

• Queries with N+1 patterns?
• Missing indexes on frequently queried columns?
• Any query taking >100ms?

7. Security Audit (OWASP Top 10 + STRIDE threat model)

Run BOTH passes — OWASP catches the well-known classes of bug; STRIDE catches the architectural assumptions that turn one bug into a breach.

OWASP Top 10 (vulnerability classes)

Check	How	Status
Injection (SQL, NoSQL, OS)	Review all database queries and system calls	✅/❌
Broken Authentication	Test: weak passwords, session fixation, missing rate limiting	✅/❌
Sensitive Data Exposure	Check: HTTPS everywhere, no secrets in client bundle, secure cookies	✅/❌
Broken Access Control	Test: can user A access user B's data? Horizontal privilege escalation	✅/❌
Security Misconfiguration	Check: CORS policy, CSP headers, exposed error details, default credentials	✅/❌
XSS	Test: inject <script>alert(1)</script> in every user input field	✅/❌
CSRF	Check: tokens on state-changing requests, SameSite cookies	✅/❌
Dependencies	Run npm audit / pip audit / govulncheck — check for known CVEs	✅/❌

STRIDE threat model (architectural exposure)

For each component that handles auth, payments, or user data, ask the six STRIDE questions. Each "yes" is a finding to address; each "we accept this risk" is a decision the user has to actively make.

Threat	Question	Common in solo SaaS
Spoofing identity	Can someone claim to be another user?	Magic links sent without rate limits; OAuth without state validation; webhook endpoints without signature verification
Tampering with data	Can someone modify data they shouldn't?	Trusting client-sent prices in Stripe Checkout; allowing user to PATCH their own subscription tier; mutable database fields without audit logs
Repudiation	Can a user deny doing something with no record?	No audit log of plan changes, refunds, or account deletions; no record of which admin took which action
Information disclosure	Can someone read data they shouldn't?	Predictable IDs in URLs; verbose error messages leaking schema; environment-variable leaks in client bundles
Denial of service	Can someone make the service unavailable?	No rate limit on signup or password reset; unbounded LLM-call costs from one bad actor; unbounded image-upload size
Elevation of privilege	Can a regular user become an admin?	Admin-flag in client-readable cookie; admin endpoints sharing the auth middleware of public ones; webhook handlers running with elevated permissions

For each "yes":

1. Note the threat type, the component, and the specific path
2. Classify severity (P0: live exposure / P1: works with one chained mistake / P2: requires multiple chained mistakes)
3. Add to the Ship Check report under "Security findings" with the explicit threat type tag (e.g., [STRIDE-T] for tampering)

If 3+ STRIDE threats are open at P0/P1, the product is NOT ready to charge real money — regardless of how the OWASP table looks. STRIDE catches the things OWASP misses.

8. Accessibility Audit (WCAG 2.1 AA)

• All images have alt text
• Color contrast meets 4.5:1 ratio (text) and 3:1 (large text)
• All interactive elements are keyboard accessible
• Form inputs have associated labels
• Page has proper heading hierarchy (H1 → H2 → H3)
• Focus indicators are visible
• Screen reader navigation makes sense (try VoiceOver/NVDA)

9. SEO & Discoverability

• Meta title and description on all pages
• JSON-LD structured data validates
• Open Graph tags render correctly (use social share debuggers)
• Sitemap.xml is valid and submitted
• Robots.txt allows indexing of desired pages
• No broken links (check with crawler)
• Canonical URLs set correctly (no duplicate content)

Ship Check Output

Ship Check: ✅ READY TO SHIP / ❌ NOT READY

Category         Score   Details
─────────────────────────────────────
Static Analysis  10/10   0 errors, 0 warnings
Tests            10/10   42 passed, 0 failed, 87% coverage
Code Review       9/10   1 medium finding (fixed)
Functionality    10/10   All critical paths passing
Performance       8/10   LCP 2.1s ✅, CLS 0.05 ✅, Bundle 180KB ✅
Security          9/10   All OWASP checks passing, 1 low-severity dep
Accessibility     8/10   2 contrast issues on secondary text
SEO              10/10   All checks passing

Overall:         93/100  ✅ READY TO SHIP

Remaining items (non-blocking):
1. [P2] Contrast ratio 3.8:1 on muted text (target 4.5:1)
2. [P3] lodash imported fully — consider tree-shaking

---

Tech Triage Mode (when something is broken)

/money-diagnose handles business-level "I'm stuck" — slow growth, wrong ICP, channel doesn't convert. Tech Triage Mode handles the technical version: a failing test, a slow query, an unexplained 500, a flaky CI run, a feature that "works on my machine".

Trigger via /money-quality triage or by describing the symptom directly ("the signup flow returns 500 in production but not staging").

The triage loop

Do NOT start guessing. Do NOT start grepping the codebase. Do NOT propose fixes. Follow the loop in order — each step is cheap, and the first three usually reveal the answer.

Step 1 — Restate the symptom precisely

Force a one-paragraph statement of:

• What command/URL/action triggers the bug
• What the user expected to happen
• What actually happens (exact error message, stack trace, screenshot)
• What's known to be different between "works" and "doesn't work" (env, browser, account, data)

If any of those four is missing, ask for it before proceeding. ~30% of triage sessions end at this step because the symptom turned out to be different from what was first reported.

Step 2 — Find the boundary

The bug exists between something that works and something that doesn't. Find the boundary:

Boundary axis	Diagnostic
Time	When was the last known-good run? git log between known-good and now is the suspect set
Environment	Works in dev, fails in prod → env vars, build config, runtime version
Data	Works for user A, fails for user B → data-shape difference, edge case on B's row
Code path	Works on URL X, fails on URL Y → route handler difference, middleware difference
Concurrency	Works in isolation, fails under load → race condition, connection pool, rate limit

Pick the one most likely. Spend ≤10 minutes on each before switching.

Step 3 — Reproduce locally

A bug you can't reproduce, you can't fix — you can only hope. Reproduce with the smallest possible inputs:

• Strip everything not in the minimal repro
• Run it in a clean state (no cache, fresh DB, fresh process)
• If you can't reproduce in 30 minutes: it's likely environmental — go back to Step 2 with environment as the axis

Once reproducing: capture the exact command and inputs that trigger the failure. This becomes the regression test, regardless of root cause.

Step 4 — Hypothesize, then test (not the other way)

Most "obvious" fixes are wrong because the hypothesis was never explicit. Force the format:

"I think the bug is caused by {specific cause}. If I'm right, then {specific change} will fix it AND {prediction about another signal} will also be true."

If the prediction doesn't pan out, the hypothesis was wrong — don't just patch the symptom. Restart Step 4 with a new hypothesis.

Step 5 — Fix, regression-test, document

• Smallest fix that resolves the verified root cause
• Add the regression test from Step 3
• Note the bug in the project's learnings.jsonl via /money-learn add — category tech, with the specific cause and the smallest reproducer. Future-you will hit a similar bug and want this trail.

What to refuse in triage mode

• "Try restarting it" — fine in panic; not in triage
• "Maybe it's a Heisenbug" — Heisenbugs are race conditions you haven't proven
• "Let's add error handling" without knowing what error — that hides the bug, doesn't fix it
• "Just wrap it in try/catch" — same
• Big refactors prompted by a small bug — fix the bug, log the refactor as a separate task

The triage loop ends with three artifacts: the root cause stated in one sentence, the minimal regression test, and the /money-learn row. Without all three, the bug isn't really fixed — it's just suppressed.

Alternative Quality Modes (non-software business types)

Content Quality Mode (content-kol)

Run before publishing or scheduling any piece. The five gates:

1. Authenticity — Run /money-content Stage 4.5 (12-signal AI-fingerprint audit). 0-2 signals: ship. 3-5: fix. 6+: rewrite.
2. Hook quality — Run /money-content Stage 4 hook quality check. Every hook must pass independence + suspense + speakability + credibility + alignment.
3. Factual integrity — Every specific claim (number, percentage, named person, dated event) must have a source you'd back in public. If the source is "ChatGPT said so", remove or verify.
4. Cognitive gap — Read top 3 results for the same query/keyword. If your piece doesn't carry one specific thing the others don't, kill it or rewrite the angle.
5. Aligned monetization — If the piece sells (course, community, sponsored), the sell must match the lesson. A piece teaching "do A" that funnels to "buy our B" reads as bait.

A piece that fails any one of these is NOT ready. Track the failure mode — repeated fails on the same gate is a pattern to fix at the workflow level via /money-skillify.

Product / Listing Quality Mode (commerce)

Run before publishing any new SKU listing or running ads to it.

Check	Pass criteria
Photography	At least 3 photos (packshot, lifestyle, detail); first photo conversion-optimized; consistent style across catalog
Title formula	Matches platform spec (Amazon's strict; Etsy's loose; TikTok Shop video-first); contains primary search keyword
Description	Hook (2 lines) + 3-bullet benefits + spec table + size/material/origin + return policy + shipping ETA
Pricing strategy	Entry tier exists; psychological pricing (.99 / .95 / .88 region-specific); price tested in last 60 days
Reviews status	First 10 reviews present (seed if not); recent reviews <60 days; response to every <4-star review
Inventory + fulfillment	Stock buffer for forecast 60 days; SKU pickable in <30 sec; shipping tested end-to-end with timing
Returns policy	Visible, ≤2 clicks from listing; matches platform requirements; restocking fee clear

Any failed check is a deferral, not a P2.

Service & Experience Quality Mode (retail-local)

Run on a recurring weekly basis, and after every significant operational change (new staff, new menu, layout change).

Check	Pass criteria
Hygiene + safety	Last cleaning log <24h; food/cosmetic/equipment safety certs in date; mystery-shopper hygiene score >90%
Customer-facing scripts	Greeting, problem-handling, upsell, closing — each staff member can deliver consistently in front of a manager
First-impression flow	Door / entry / signage / wait area meets brand promise; tested by an outside friend (NOT a regular) every 30 days
Booking / queue flow	Wait time < category benchmark (e.g. <15 min for a haircut walk-in); booking conversion >80%
POS + payment	All listed payment methods working; receipt prints / texts correctly; loyalty mechanism active
Review response	<72h response time on every public review across all platforms; 1-star and 2-star get response same day
Cross-promotion follow-through	Partnerships from /money-outreach are being honored (their coupons accepted, your fliers visible)

The single highest-leverage one is "first-impression flow tested by an outside friend monthly" — every solo operator goes blind to their own storefront within 60 days.

Deliverable Quality Mode (service / agency / consulting)

Run before sending any client deliverable.

Check	Pass criteria
Brief vs. delivery match	Re-read the original brief; every point addressed, deviations explicitly named with rationale
Output format	Matches what the client requested; if format is "deck", it's a real deck not a doc disguised; if "report", it's structured
Sample size / data integrity	If analysis: methodology documented; data source named; caveats listed
Voice	Drafts in the client's voice if delivering content, in your voice if delivering analysis/strategy — do not mix
Replication test	A second person on your team (or a future-you) could understand what was done from the deliverable alone
Case-study extraction	After delivery, capture the case-study material now (specific outcome, anonymized if needed) — this is the #1 missed lead source for solo consultants
Invoice + handoff	Invoice sent same-day as delivery; clear next-step or scope-extension proposal attached

A deliverable that fails the brief-vs-delivery match check is a defect, not "stylistic difference" — fix before sending.

Continuous Quality (Integration with /money-ops)

After the initial ship check, set up ongoing quality monitoring:

Automated Quality Schedule

Frequency	Check	Alert If
Every commit	Quick Check	Any failure
Every PR	Standard Check	Medium+ findings
Weekly	Ship Check (performance + security)	Score drops >10%
Monthly	Full dependency audit	New CVEs found

Quality Score Tracking

Track the Ship Check score over time. Plot weekly:

Week    Score   Trend
1       93/100  —
2       91/100  ↓ (new dep vulnerability)
3       95/100  ↑ (fixed + perf improvement)
4       95/100  → (stable)

Rule: Quality score must never decrease across two consecutive weeks. If it does, stop feature work and fix quality issues before adding anything new.

---

Integration with Other Skills

• After /money-product builds the product → Run Ship Check before deploying
• After /money-ops deploys a change → Run Quick Check + canary monitoring
• When the user asks "is this ready?" → Run the appropriate tier check
• Before charging real money → Ship Check is mandatory, no exceptions

Principles

• Ship with confidence, not hope — If you haven't tested it, it doesn't work
• Fix forward, not backward — Fix issues when found, don't track them for later
• Signal over noise — Only report findings that matter. Every false positive costs trust
• Automate everything repeatable — Manual checks are for judgment calls, not rote verification
• Quality is a trend, not a snapshot — Track scores over time, not just current state
• Root cause > Quick fix — Understand WHY before fixing WHAT