@kensaurus/skills 0.0.0-stage → 2.1.0

package/skills/workflow-merge-conflicts/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: workflow-merge-conflicts
+description: >
+  Resolve an in-progress merge or rebase conflict by tracing each side back to
+  its intent. Use when "resolve the conflicts", "fix this merge", "the rebase
+  is stuck", or a pull has left conflict markers in the tree.
+license: MIT
+---
+
+# Resolving Merge Conflicts
+
+**Degree of freedom: MIXED.** Which intent wins `[HIGH freedom]`; inspect,
+never `--abort` unasked, and run real checks `[LOW freedom — run exactly]`.
+
+> Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT).
+
+## How to reason
+
+1. **Identify** — operation (merge/rebase/cherry-pick) and conflicted files
+2. **Intent** — why each side changed, from commits/PRs — not the markers
+3. **Preserve** — both intents if possible; else the merge's stated goal
+4. **Verify** — typecheck + tests + lint; then finish the operation
+
+## Worked example
+
+> **Identify:** rebase of `fix/cart-sku` onto `main`; conflict in `src/lib/cart.ts`.
+> **Intent:** this branch treats missing SKU as invalid; main extracted `quoteCart` to a new file.
+> **Preserve:** keep the extraction and the missing-SKU branch — move the guard into `quoteCart`.
+> **Verify:** `pnpm typecheck && pnpm test` green; `git rebase --continue`; tree clean.
+
+## Self-critique before reporting
+
+- **Intent, not text** — no "ours/theirs" from appearance alone
+- **No invented behavior** — resolution does not add a third design
+- **Checks run** — semantic conflicts caught after a clean text merge
+- **Right owner** — message after resolve → `workflow-git-commit`; open PR lifecycle → `workflow-pr`
+
+1. **See the current state.** `[LOW freedom — run exactly]` `git status` for the operation in progress
+   (merge/rebase/cherry-pick) and the conflicting files; `git log --oneline
+   --left-right HEAD...MERGE_HEAD` (or the rebase equivalent) for what each side
+   contains.
+
+2. **Find the primary sources for each conflict.** `[HIGH freedom]` Understand why each
+   change was made and what the original intent was: read the commit messages,
+   check the PRs, check the original issues or tickets. Never resolve a hunk on
+   textual appearance alone.
+
+3. **Resolve each hunk.** `[HIGH freedom]` Preserve both intents where possible. Where they are
+   incompatible, pick the one matching the merge's stated goal and note the
+   trade-off. Do **not** invent new behavior. Always resolve; never `--abort`
+   without the user's explicit instruction.
+
+4. **Run the project's automated checks** `[LOW freedom — run exactly]` — typecheck, then tests, then
+   format/lint, using the repo's real scripts. Fix anything the merge broke;
+   conflicts that merge cleanly at the text level can still conflict
+   semantically.
+
+5. **Finish the operation.** `[LOW freedom — run exactly]` Stage everything and commit (or `git rebase
+   --continue` until all commits are replayed). Confirm the tree is clean and
+   checks are green before reporting done.
+
+**Related:** `workflow-git-commit`, `workflow-pr`, `verification-before-completion`.

package/skills/workflow-onboard/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: workflow-onboard
+description: >
+  First-contact orientation for an unfamiliar codebase. Use when "I'm new to this repo",
+  "orient me", "explain this codebase", "what does this do?", "onboard me", "first day on
+  this project", or "catch me up on the codebase".
+license: MIT
+context: fork
+agent: Explore
+---
+
+# workflow-onboard — Codebase Orientation
+
+**Degree of freedom: MIXED.** Briefing synthesis `[HIGH freedom]`; which files
+to read and never printing env values `[LOW freedom — run exactly]`.
+
+Orient to any repo in under 5 minutes. Read first, explain second.
+
+## How to reason
+
+1. **Read** — manifests, routes, schema, auth — don't guess
+2. **Map** — stack, features, data, how-to-run
+3. **Gap** — missing README/schema said out loud
+4. **Brief** — scannable; top-3 complexity called out
+
+## Worked example
+
+> **Read:** `package.json` is Next.js 16 + Supabase; `src/app/(app)/*` has dashboard, billing, settings; latest migration adds `organizations`.
+> **Map:** B2B dashboard; session via middleware + `getUser()`; run `pnpm dev`.
+> **Gap:** no README scripts section; `.env.example` lists `STRIPE_SECRET_KEY`.
+> **Brief:** purpose + stack + route map + 4 tables + auth + `pnpm dev` + env names + "start in `src/lib/billing`".
+
+## Self-critique before reporting
+
+- **Files read** — briefing cites files, not folklore
+- **Secrets safe** — env names only, never values
+- **Gaps explicit** — missing schema/README is stated, not invented
+- **Right owner** — preflight commands/services → `workflow-environment-ready`; parked work → `housekeep-backlog`
+
+---
+
+## Step 1: Stack & entry points  [LOW freedom — run exactly]
+
+Read these (grep finds fragments; the briefing needs the whole file). The table is the floor, not the ceiling: when the repo does not match it (monorepo, unusual framework, no `src/app`), follow what the manifest and top-level tree point to before writing anything:
+
+| File | What to extract |
+|------|-----------------|
+| `package.json` / `pyproject.toml` / `Cargo.toml` | Runtime, framework, key deps, scripts |
+| `README.md` | Stated purpose, setup steps, architecture notes |
+| `src/app/layout.tsx` / `pages/_app.tsx` / `App.tsx` | Root component, providers, global context |
+| `src/app/**/page.tsx` / `src/routes/**` / `app/routes/**` | Route tree → feature map |
+| `capacitor.config.*` / `app.json` / `app.config.*` | Mobile targets (Expo/RN/Capacitor) |
+| `android/` / `ios/` presence | Native targets |
+
+---
+
+## Step 2: Data & auth layer  [LOW freedom — run exactly]
+
+| File | What to extract |
+|------|-----------------|
+| `supabase/migrations/*.sql` (latest 3) | Schema, tables, relationships |
+| `prisma/schema.prisma` / `drizzle/*.ts` | ORM model |
+| `src/lib/supabase.*` / `src/lib/db.*` | Client init, auth helper |
+| `.env.example` / `.env.local` (names only, never values) | Required env vars |
+| `middleware.ts` / `auth.ts` / `src/lib/auth.*` | Auth guard pattern |
+
+---
+
+## Step 3: Recent context  [LOW freedom — run exactly]
+
+```bash
+git log --oneline -15          # recent work direction
+git diff HEAD~5 --stat         # files changed recently
+```
+
+---
+
+## Step 4: Orientation briefing  [HIGH freedom]
+
+Produce a structured briefing covering:
+
+1. **What it is** — one sentence on the product's purpose
+2. **Tech stack** — framework + DB + auth + mobile targets
+3. **Feature map** — top-level routes grouped by capability
+4. **Data model** — the entities and relationships the feature map depends on, not the whole schema
+5. **Auth pattern** — how sessions work and who the roles are
+6. **How to run** — exact commands from `package.json` scripts
+7. **Environment** — required env vars (names only) and where to find values
+8. **Top 3 to understand first** — the areas with the most business logic or complexity
+
+Format as a scannable briefing, not a wall of text. Use short tables where helpful.
+
+---
+
+## Guardrails  [LOW freedom — do not skip]
+
+- Never print `.env` values — names only
+- If the codebase is a monorepo, scope the briefing to the specific app/package the user is working in (ask if unclear)
+- If critical files are missing (no README, no schema), say so explicitly rather than guessing

package/skills/workflow-parallel-agents/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: workflow-parallel-agents
+description: Run multiple agents in parallel via git worktrees, cloud agents, or multi-model comparison. Use for "run agents in parallel", "best-of-N", "compare approaches", "multi-model", "parallel worktrees".
+license: MIT
+---
+
+# Parallel Agents & Worktrees
+
+**Degree of freedom: MIXED.** What to split, how to brief, and which model or effort `[HIGH freedom]`;
+isolated worktrees and no shared-file writes `[LOW freedom — run exactly]`.
+
+## How to reason
+
+1. **Observe** — independent tasks vs one shared file
+2. **Interpret** — worktree / cloud / best-of-N
+3. **Classify** — parallel-safe / must-serialize
+4. **Severity** — two agents editing one path is a conflict, not speed
+
+## Worked example
+
+> **Observe:** "fix tests" and "write the README" touch different trees.
+> **Interpret:** two worktrees, two agents.
+> **Classify:** parallel-safe; do not also give both `package.json`.
+> **Merge:** integrate one result at a time; compare best-of-N on the same prompt.
+
+## Self-critique before reporting
+
+- **Isolation** — no two agents owned the same files
+- **Prompt named** — each delegate had a concrete done-check
+- **Compared if best-of-N** — a winner was picked with a reason
+- **Right owner** — one sequential feature → `workflow-build-feature`
+
+## Why Run Agents in Parallel?  [HIGH freedom]
+- **Compare approaches**: same brief to several agents (Cursor: different models; Claude Code: subagents, optionally at different `effort`) → pick the best result
+- **Isolate work**: Each agent edits its own files without conflicts
+- **Delegate background tasks**: Offload bug fixes, tests, docs while you work on something else
+- **Speed**: Multiple independent tasks done simultaneously
+
+## When delegation pays  [HIGH freedom]
+
+Delegate when a track is independent, sizeable, and can run beside the others, or when its output is verbose and you do not need it in the main context (log reads, wide exploration, a full test run). A handful of tool calls is cheaper to do yourself than to brief.
+
+Brief each delegate once and precisely — goal, files, constraints, the done-check, and what to report back — then commit to the delegation: do not redo its work in parallel. Launch independent agents in one message so they run at the same time; integrate results one at a time.
+
+Claude Code: each delegate is a subagent (built-in `Explore` for read-only work; a general agent or one from `agents/` for edits). A subagent that writes files gets `isolation: worktree` in its agent frontmatter, or its own `git worktree add`, so two delegates never own the same path. Cursor: the worktree and cloud options below.
+
+## Git Worktrees (Local Parallel Agents)  [LOW freedom — run exactly]
+
+### How It Works
+Cursor creates an isolated git worktree per agent from the agent dropdown; in Claude Code the equivalent is `isolation: worktree` on the subagent (see above). Each has its own:
+- File system (changes don't affect other agents)
+- Build/test environment
+- Branch
+
+When an agent finishes, click **Apply** to merge changes back.
+
+### Starting a Worktree Agent
+1. Open the agent dropdown
+2. Select the **worktree** option
+3. Submit your prompt
+4. While it runs, start another agent in a different worktree
+
+### Best Use Cases
+- Running the same hard problem across 3 models simultaneously
+- Implementing 2 independent features at once
+- Having one agent write tests while another writes implementation
+- Trying 2 different architectural approaches before choosing
+
+### After Agents Finish
+- Review diffs side-by-side
+- Cursor suggests which solution it recommends (multi-agent judging)
+- Click **Apply** on the winner
+- Discard the others
+
+## Cloud Agents (Background Delegation)  [HIGH freedom]
+
+### When to Use
+Delegate tasks you'd otherwise put on a todo list:
+- Bug fixes that came up while working on something else
+- Writing tests for existing code
+- Documentation updates
+- Refactoring recent changes
+- Dependency updates
+
+### Starting a Cloud Agent
+- From Cursor editor: agent dropdown → cloud option
+- From web: [cursor.com/agents](https://cursor.com/agents)
+- From phone: Cursor mobile app
+- From Slack: `@Cursor <task description>`
+
+### How Cloud Agents Work
+1. Describe the task + relevant context
+2. Agent clones your repo, creates a branch
+3. Works autonomously (you can close your laptop)
+4. Opens a PR when finished
+5. You get notified (Slack, email, or web)
+6. Review and merge
+
+### Writing Good Delegation Prompts
+```markdown
+# Good delegation prompt
+Fix the bug where users see a 500 error when they submit the onboarding form
+with a duplicate email. The error should show an inline message "Email already
+in use" instead of crashing. See `app/onboarding/actions.ts` for the server
+action and `app/onboarding/page.tsx` for the form.
+
+# Bad delegation prompt
+Fix the email bug
+```
+
+Include:
+- Exact behaviour (current vs expected)
+- File paths if known
+- Acceptance criteria
+- Any constraints ("don't change the API contract")
+- A time signal when the run is clocked: "Time matters here: do not spend time that can be avoided." Delegates weight it.
+
+## Running Multiple Models on the Same Prompt  [LOW freedom — run exactly]
+1. Open agent dropdown
+2. Select multiple models
+3. Submit prompt once
+4. Cursor runs all models in parallel
+5. Compare results; Cursor recommends the best
+
+Claude Code: send the same brief to N subagents in one message (different `effort` levels, or a different approach named in each brief); compare the candidates yourself or hand them to a fresh-context reviewer that flags only correctness and requirement gaps.
+
+Best for:
+- Architecturally significant decisions
+- Hard bugs where different models take different approaches
+- When you want to verify the solution is correct
+
+## Notifications  [LOW freedom — run exactly]
+When running many agents, configure:
+- Settings → notifications → agent completion
+- Sounds for agent completion (hear it finish across the room)
+- Slack integration for cloud agents
+
+## Patterns  [HIGH freedom]
+
+### The Parallel Spike
+Run 2-3 agents with different approaches to a hard problem:
+- Agent A: "Use optimistic updates with TanStack Query"
+- Agent B: "Use server-sent events for real-time sync"
+- Agent C: "Use Supabase Realtime subscriptions"
+Compare all three, pick the cleanest.
+
+### The Background Test Writer
+While implementing feature X locally:
+- Cloud agent: "Write tests for the auth flow in `features/auth/`"
+- You: implement feature X
+- Merge both when done
+
+### The Parallel Review
+One agent reviews for security, another for performance:
+- Agent A: "Review `app/api/` for security issues (auth, input validation, RLS)"
+- Agent B: "Review `app/api/` for performance (N+1s, missing indexes, large payloads)"
+
+Each reviewer reports only findings in its lane, with file:line evidence — not style or general cleanups.
+
+## Worktree Tips  [LOW freedom — run exactly]
+- Each worktree needs its own `node_modules` if deps differ
+- Share `.env` by symlinking or copying to each worktree
+- Worktrees share git history — easy to cherry-pick between them
+- Clean up finished worktrees: `git worktree remove <path>`

package/skills/workflow-pr/SKILL.md

@@ -0,0 +1,197 @@
+---
+name: workflow-pr
+description: >
+  Manage an existing PR lifecycle — review, bot feedback, conflicts,
+  merge. Use when opening a PR from an already-committed branch,
+  addressing review, or merging. Uncommitted working tree to
+  merge-ready → workflow-release-prep.
+license: MIT
+---
+
+# PR Workflow Skill
+
+**Degree of freedom: MIXED.** Feedback judgment `[HIGH freedom]`; validations,
+poll loop, and merge-only-if-asked `[LOW freedom — run exactly]`.
+
+Full checklist for an already-committed branch or an open PR.
+
+Uncommitted / staged / untracked working tree that still needs review,
+commit, and a merge-ready PR is **`workflow-release-prep`**. This skill
+does not own that sequence.
+
+## How to reason
+
+1. **Validate** — repo commands green; no secrets in the branch
+2. **Open** — template + complete description
+3. **Drive** — poll checks; address every thread
+4. **Gate** — mergeable_state clean AND threads 0; merge only if asked
+
+## Worked example
+
+> **Validate:** `pnpm typecheck && pnpm test` green; no `.env` in the diff.
+> **Open:** PR uses the repo template; title `fix(checkout): handle deleted SKU`.
+> **Drive:** CI red on lint → fix, push, re-poll; reply + resolve the bot thread.
+> **Gate:** `mergeable_state=clean`, 0 threads; user did not ask to merge → report merge-ready and stop.
+
+## Self-critique before reporting
+
+- **Already committed** — dirty tree was routed to `workflow-release-prep`
+- **Both gates** — never treat `mergeable: true` as approval
+- **Merge gated** — no merge unless the user explicitly asked
+- **Right owner** — uncommitted pile → `workflow-release-prep`; keep-green loop after open → `babysit`
+
+## Invocation boundary
+
+- **Standalone:** open or manage the PR. Merge only when the user explicitly
+  asked to merge.
+- **Called by `workflow-release-prep`:** open the PR and return its URL.
+  `babysit` owns the green loop; the caller stops before merge.
+
+## Phase 1: Before Creating PR  [LOW freedom — run exactly]
+
+### 1. Run Validations
+
+**JavaScript/TypeScript:**
+```bash
+pnpm typecheck && pnpm build && pnpm test
+# or: npm run typecheck && npm run build && npm test
+```
+
+**Python:**
+```bash
+mypy . && python -m pytest && ruff check .
+```
+
+**With Makefile:**
+```bash
+make typecheck && make build && make test
+```
+
+### 2. Security Scan
+
+Before committing, verify:
+- [ ] No hardcoded paths (`/Users/username/...`)
+- [ ] No secrets, API keys, or tokens
+- [ ] No machine-specific values
+- [ ] Environment variables for sensitive data
+
+### 3. Create PR
+
+1. Search for `pull_request_template.md` in repo
+2. Use template structure for PR description
+3. Create PR with clear title and description
+
+---
+
+## Phase 2: Monitor PR  [LOW freedom — run exactly]
+
+### 4. Poll Status
+
+Check every 60-90 seconds until checks complete:
+
+**Understanding Check Status:**
+- `mergeable: true` → Only means no git conflicts
+- `mergeable_state: "clean"` → ALL checks passed, safe to merge
+
+**Mergeable State Values:**
+| State | Meaning | Action |
+|-------|---------|--------|
+| `"clean"` | ✅ All passed | Safe to merge |
+| `"unstable"` | ⚠️ Pending/failing | Wait, poll again |
+| `"blocked"` | ❌ Protection rules | Check requirements |
+| `"behind"` | ⚠️ Needs update | Update branch |
+
+### 5. Address Bot Feedback
+
+When reviews complete:
+
+1. **Read every comment** - Track unresolved threads
+2. **For each issue:**
+ - Analyze feedback
+ - Implement fix
+ - Commit and push
+ - Reply confirming fix
+ - **Mark thread resolved**
+
+3. Address every comment — an unresolved thread fails Gate 2
+
+### 6. Wait for Re-validation
+
+After pushing fixes:
+1. Poll status again
+2. All checks must show `SUCCESS`
+3. Re-fetch comments for NEW feedback
+4. Repeat until clean
+
+---
+
+## Phase 3: Merge Criteria  [LOW freedom — run exactly]
+
+### 7. Final Checklist
+
+**Two gates must pass:**
+
+| Gate | Check |
+|------|-------|
+| Gate 1 | `mergeable_state == "clean"` |
+| Gate 2 | `unresolved_thread_count == 0` |
+
+**Both must be TRUE to merge.**
+
+### 8. Execute Merge
+
+Only after both gates pass **and the user explicitly asked to merge**:
+```bash
+gh pr merge --merge
+```
+
+Otherwise report that the PR is merge-ready and stop.
+
+### 9. Verify Success
+
+Confirm merge was successful and report status.
+
+---
+
+## Error Handling
+
+| Situation | Action |
+|-----------|--------|
+| Checks fail 3x | Pause, ask for guidance |
+| Unclear feedback | Ask clarifying questions |
+| Merge blocked | Check protection rules, report |
+| Checks stuck | Run local validation, ask permission |
+
+---
+
+## Common Mistakes
+
+### ❌ Merging when `mergeable_state` is "unstable"
+**Fix:** Always check `mergeable_state`, poll again if unstable
+
+### ❌ Treating `mergeable: true` as approval
+**Fix:** `mergeable` ≠ `mergeable_state`. Check the latter.
+
+### ❌ Not re-checking comments after push
+**Fix:** After every push, re-fetch comments for new threads
+
+### ❌ Not marking threads resolved
+**Fix:** After addressing each comment, mark thread resolved
+
+---
+
+## Quick Reference
+
+```bash
+# Check PR status
+gh pr status
+
+# View checks
+gh pr checks <number>
+
+# View comments
+gh pr view <number> --comments
+
+# Merge (only when both gates pass)
+gh pr merge <number> --merge
+```

package/skills/workflow-quality-gate/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: workflow-quality-gate
+description: >
+  Pre-release quality gate across red-team, security, bundle size,
+  performance, and unit tests. Use when "is this ready to ship?", "quality
+  gate", or "pre-release checklist". Working tree to a PR →
+  workflow-release-prep.
+license: MIT
+effort: high
+---
+
+# workflow-quality-gate — Pre-Release Go/No-Go
+
+**Degree of freedom: MIXED.** Verdict and severity `[HIGH freedom]`; gate
+order, Critical pause, and report table `[LOW freedom — run exactly]`.
+
+Run before any production release. Each skill contributes a specific defect
+class. The combined result is a single verdict.
+
+## How to reason
+
+1. **Observe** — what did each gate actually return?
+2. **Interpret** — blocker vs recommended; plan-only fork vs apply-now
+3. **Classify** — GO / GO WITH CONDITIONS / NO-GO
+4. **Severity** — any Critical, or 2+ High without a named mitigation, is NO-GO
+
+## Worked example
+
+> **Observe:** red-team finds unauthenticated `/api/export` dump; bundle 180 KB; LCP 2.1s; tests green.
+> **Interpret:** export is Critical (data leak); later gates cannot make this a GO.
+> **Classify:** NO-GO — pause after Gate 1 and ask fix-now vs continue-and-report.
+> **Severity:** Critical outranks a clean bundle; do not paper it as GO WITH CONDITIONS.
+
+## Self-critique before reporting
+
+- **Gates in order** — an earlier Critical paused the remaining sweep or was explicitly continued
+- **Verdict matches rubric** — Critical ⇒ NO-GO; 2+ High without owner+deadline ⇒ not GO
+- **Plan-only honored** — user said plan-only ⇒ `plan-security-audit`, not `audit-security` fixes
+- **Right owner** — dirty tree to a PR → `workflow-release-prep`; silent-bypass of CI → `audit-gate-logic`
+
+---
+
+## Gate sequence  [LOW freedom — run exactly]
+
+```
+0. EXPLORE    → test-exploratory (optional live probe: guest vs logged-in wander + diff)
+1. RED-TEAM   → test-red-team    (adversarial: UX + pipeline + security + perf)
+2. SECURITY   → audit-security   (static code review: OWASP, auth, RLS, secrets)
+3. BUNDLE     → audit-bundle-size (JS payload: lazy loading, tree-shaking, chunks)
+4. PERFORMANCE→ audit-performance (Core Web Vitals, LCP, CLS, INP)
+5. UNIT TESTS → test-unit        (coverage gaps, regression suite green?)
+```
+
+Gate 0 is optional and does **not** replace Gate 1. Use it when the user asked to
+wander / monkey-test / compare guest vs logged-in first. Run gates in order —
+earlier gates often surface issues that make later gates redundant or change
+their scope.
+
+**Plan-only fork:** if the user asked for a burndown and no code changes,
+replace Gate 2 with `plan-security-audit` (and `plan-rls-audit` /
+`plan-secrets-audit` when those are the symptom). `audit-security` may
+fix inline; do not use it when the user said plan-only.
+
+---
+
+## Gate 1: Red team (read test-red-team)  [HIGH freedom]
+
+> Read the `test-red-team` skill and follow it.
+
+Output: coverage matrix + severity-ranked defect list.
+
+**Blocker for gates 2–5:** if any Critical defect is found in Gate 1, pause
+and ask the user whether to fix it now or continue with the remaining gates.
+Critical defects must be resolved before the verdict can be GO.
+
+---
+
+## Gate 2: Security audit (read audit-security)  [HIGH freedom]
+
+> Read the `audit-security` skill and follow it.
+
+Focus on static code patterns missed by the live red team:
+- Secrets hardcoded in source
+- RLS policies absent or misconfigured
+- Input validation missing on server-side handlers
+- Auth guards missing on API routes
+
+---
+
+## Gate 3: Bundle size (read audit-bundle-size)  [HIGH freedom]
+
+> Read the `audit-bundle-size` skill and follow it.
+
+Threshold: first-load JS > 200 KB (gzip) is a Medium defect; > 400 KB is High.
+
+---
+
+## Gate 4: Performance (read audit-performance)  [HIGH freedom]
+
+> Read the `audit-performance` skill and follow it.
+
+Thresholds (Lighthouse mobile, simulated 4G):
+- LCP > 4 s → High
+- CLS > 0.25 → High  
+- INP > 500 ms → Medium
+
+---
+
+## Gate 5: Unit tests (read test-unit)  [HIGH freedom]
+
+> Read the `test-unit` skill and follow it.
+
+Check: does the existing test suite pass? Are there obvious coverage gaps in
+the code path that was changed for this release?
+
+---
+
+## Verdict format  [LOW freedom — run exactly]
+
+```markdown
+## Quality Gate Report — [App] — [Date]
+
+### Verdict: GO / NO-GO / GO WITH CONDITIONS
+
+### Blockers (must fix before release)
+| # | Gate | Finding | Severity | File | Fix |
+|---|------|---------|----------|------|-----|
+
+### Recommended (fix soon, not blockers)
+| # | Gate | Finding | Severity |
+|---|------|---------|----------|
+
+### Passed
+- Gate 1 (Red team): [N] defects, [N] Critical, [N] High
+- Gate 2 (Security): clean / [N issues]
+- Gate 3 (Bundle): [X KB] first-load JS
+- Gate 4 (Performance): LCP [X]s, CLS [X], INP [X]ms
+- Gate 5 (Unit tests): [pass/fail], coverage [X%]
+```
+
+**GO** = no Critical or High blockers, all gates passed
+**GO WITH CONDITIONS** = High defects present but agreed to fix post-release with a named owner + deadline
+**NO-GO** = any Critical defect, or 2+ High defects without mitigation plan
+
+This skill *runs* the sweep. Whether those gates can be silently bypassed or
+gamed is `audit-gate-logic`. Taking the local working tree to a merge-ready
+PR is `workflow-release-prep`.