wholestack 0.5.6 → 0.5.7

package/skills/fix-failing-build.md

@@ -0,0 +1,38 @@
+---
+name: fix-failing-build
+description: Diagnose a failing build or a NO_SHIP prove verdict, fix the root cause, and re-verify.
+when-to-use: When a build errors, tests fail, the prove gate returns NO_SHIP, or the app won't run. Use whenever you need to turn red into green before continuing.
+---
+
+# Fix a failing build (read errors → fix root cause → re-verify)
+
+Work from evidence, not guesses. Fix the ROOT cause, not the symptom, then prove the fix.
+
+## 1. Collect the real failure
+- Get the exact error text: prove `blockingReasons`, the build/run log, the failing test, or the compiler error.
+- Quote the precise message and the file:line it points at. Do not paraphrase a guess.
+
+## 2. Locate
+- Read the file(s) the error names. If the cause is unclear, grep for the failing symbol/string across the repo.
+- For breadth (several suspect areas at once), fan out read-only sub-agents, one per hypothesis.
+
+## 3. Identify the root cause
+- Map the message to a cause, e.g.:
+  - module-not-found / unresolved import → missing dep or wrong path.
+  - type mismatch → fix the type, never silence with `as any`.
+  - prove NO_SHIP → read which check failed; the `detail` tells you the invariant that broke.
+  - runtime crash on boot → missing env or a server/client boundary violation.
+- State the root cause in one sentence before editing.
+
+## 4. Apply the minimal fix
+- Make the smallest change that addresses the cause. Match the surrounding code's patterns and conventions.
+- Avoid scope creep — fix the failure, not unrelated nits.
+
+## 5. Re-verify (mandatory)
+- Re-run whatever was red: build, run, the failing test, AND the prove gate.
+- A fix is only done when the previously-red signal is now green. If still red, return to step 1 with the new error.
+
+## Done criteria
+- The original failing signal now passes.
+- If this was a NO_SHIP, the prove verdict is now SHIP.
+Report the root cause and the now-green verification.

package/skills/review-before-ship.md

@@ -0,0 +1,34 @@
+---
+name: review-before-ship
+description: A focused pre-ship review pass — correctness, security, and fake-success checks — before deploying.
+when-to-use: When the user asks for a review, a sanity check, or "is this ready to ship?" before deploy — or as the gate step inside ship-a-saas when extra scrutiny is wanted.
+---
+
+# Review before ship (correctness → security → fake-success)
+
+A quick, evidence-based pass to catch what an automated gate can miss. Report findings by severity; do not rubber-stamp.
+
+## 1. Scope the diff
+- Identify what actually changed (the files touched this session, or the generated app's entities/routes).
+- Skip unchanged code — review the delta.
+
+## 2. Correctness
+- Do the new/changed functions do what their name says? Check the obvious edge cases (empty input, error path).
+- Look for swallowed errors: empty catch blocks, try/catch that ignores, handlers that return 200 for everything.
+
+## 3. Security
+- Any endpoint touching sensitive data must enforce auth/ownership — flag unprotected ones.
+- No secrets in client code; server-only keys stay server-side.
+- DB access is parameterized (no string-interpolated queries).
+
+## 4. Fake-success
+- Functions that always return success regardless of input.
+- Loading states with no error state.
+- A "pass" that doesn't bind the real artifact (a proof that can't actually fail is no proof).
+
+## 5. Run the gate
+- Run the prove gate and read the verdict alongside your manual findings.
+
+## Done criteria
+- Findings listed by severity (critical / high / medium / low) with file:line and a concrete fix each.
+- A clear go / no-go recommendation, reconciled with the prove verdict.

package/skills/ship-a-saas.md

@@ -0,0 +1,39 @@
+---
+name: ship-a-saas
+description: End-to-end procedure to take an app idea to a deployed, proven SaaS.
+when-to-use: When the user wants to build AND ship a full SaaS — "ship this", "build and deploy", "get it live", or any request that spans generate → prove → deploy → launch.
+---
+
+# Ship a SaaS (build → prove → deploy → launch-kit)
+
+Follow these steps in order. After each step, report what happened before moving on. Do not skip the prove gate — a NO_SHIP verdict blocks deploy.
+
+## 1. Clarify the build
+- Restate the app in one sentence (what it does, who it's for).
+- If the idea is too vague to generate (no core entities/actions), ask ONE focused question, then proceed.
+
+## 2. Generate
+- Use the build tool to generate the full-stack app from the idea.
+- Capture the resulting `buildId` — every later step keys off the linked build.
+- If generation fails, switch to the `fix-failing-build` skill, then return here.
+
+## 3. Prove (ShipGate — the gate)
+- Run the prove gate on the generated repo.
+- Read the `verdict`:
+  - `SHIP` → continue to deploy.
+  - `NO_SHIP` → STOP. List the `blockingReasons` plainly. Fix the underlying issue (often via `fix-failing-build`), regenerate or edit, then re-prove. Never deploy a NO_SHIP build.
+
+## 4. Deploy
+- Only after a SHIP verdict, deploy the build (the linked `buildId`).
+- Report the live URL and the deploy status. If a database was provisioned, say so.
+
+## 5. Launch kit
+- Pull the launch kit for the build (brand, pricing, copy, social, email, pitch, analytics, checklist).
+- Summarize what's ready and what the founder still needs to fill in.
+- Offer the next concrete action (custom domain, payments, waitlist, first campaign).
+
+## Done criteria
+- A SHIP verdict was recorded.
+- A live URL was returned.
+- The launch kit was surfaced.
+Report all three back to the user.