Constant STARTER_SKILLS_JSON 

const STARTER_SKILLS_JSON: &str = "[\n  {\n    \"name\": \"Systematic Debugging\",\n    \"trigger\": \"systematic-debugging\",\n    \"skill_type\": \"prompt\",\n    \"description\": \"Use before proposing any fix for a bug, test failure, or unexpected behavior \u{2014} root-cause first, patch second.\",\n    \"content\": \"# Systematic Debugging\\n\\nInformed by the real-world, widely-used `systematic-debugging` skill from obra/superpowers (github.com/obra/superpowers), one of the most popular Claude Code skill collections in the community.\\n\\n**Core principle:** find the root cause before attempting a fix. A patch that makes a symptom go away without explaining *why* the bug happened is not a fix \u{2014} it\'s a coin flip on whether it comes back, and a strong chance it creates a new bug elsewhere.\\n\\n**When to use:** any bug report, failing test, unexpected behavior, performance regression, or build failure \u{2014} especially under time pressure, when the temptation to guess is highest.\\n\\n## The process\\n\\n1. **Reproduce it.** If you can\'t reliably reproduce the failure, you don\'t understand it yet \u{2014} don\'t propose a fix based on a guess about what\'s happening.\\n2. **Isolate the variable.** Bisect: what changed between last-known-good and now? Narrow the surface area before reading code line by line.\\n3. **Read the actual error, not the assumed one.** Stack traces, exact error messages, and line numbers are more reliable than your first hypothesis.\\n4. **Form ONE hypothesis, test it, then move on.** Don\'t chase a single theory for more than a few minutes without new evidence \u{2014} if it\'s not panning out, that\'s information, not a reason to keep pushing.\\n5. **Fix the root cause, not the symptom.** If the fix is \\\"add a null check\\\" ask why the value was null in the first place \u{2014} that\'s usually where the real bug lives.\\n6. **Verify the fix actually addresses the root cause** \u{2014} re-run the original reproduction, not just a quick smoke test.\\n\\nIf you catch yourself about to try a fix without being able to explain *why* the bug happened, that\'s the signal to go back to step 1.\"\n  },\n  {\n    \"name\": \"Test-Driven Development\",\n    \"trigger\": \"tdd\",\n    \"skill_type\": \"prompt\",\n    \"description\": \"Use when implementing new behavior or fixing a bug \u{2014} write the test that proves it first.\",\n    \"content\": \"# Test-Driven Development\\n\\nInformed by the real-world, widely-used `test-driven-development` skill from obra/superpowers (github.com/obra/superpowers), one of the most popular Claude Code skill collections in the community.\\n\\n**Core principle:** write a test that fails for the right reason before writing the code that makes it pass. This forces you to know exactly what \\\"done\\\" looks like before you start, and leaves behind a regression test instead of just a fix.\\n\\n**When to use:** new features, bug fixes (write a test that reproduces the bug BEFORE fixing it \u{2014} otherwise you can\'t prove the fix worked or prevent it regressing), and any change to logic that has edge cases.\\n\\n## The cycle\\n\\n1. **Red** \u{2014} write a test for the behavior you want, and confirm it actually fails (for the right reason, not a typo or setup error).\\n2. **Green** \u{2014} write the minimum code to make it pass. Resist the urge to build more than the test demands.\\n3. **Refactor** \u{2014} clean up now that you have a passing test as a safety net.\\n\\n## What makes a good test\\n\\n- Covers the failure path and edge cases, not just the happy path \u{2014} the happy path is the case least likely to break.\\n- Fast and deterministic \u{2014} no sleeps, no flaky timing assumptions, no dependence on execution order.\\n- Tests behavior, not implementation \u{2014} a test that breaks every time you refactor without changing behavior is testing the wrong thing.\\n- One assertion of intent per test \u{2014} a test with an unclear failure message is a test that wastes the next person\'s time.\\n\\nIf writing the test first feels awkward because the design isn\'t clear yet, that discomfort is useful signal \u{2014} it usually means the design itself isn\'t settled, not that testing should be skipped.\"\n  },\n  {\n    \"name\": \"Code Review \u{2014} Requesting & Receiving\",\n    \"trigger\": \"code-review\",\n    \"skill_type\": \"prompt\",\n    \"description\": \"Use before requesting review, when reviewing someone else\'s change, and when responding to review feedback.\",\n    \"content\": \"# Code Review \u{2014} Requesting & Receiving\\n\\nInformed by the real-world, widely-used `requesting-code-review` and `receiving-code-review` skills from obra/superpowers (github.com/obra/superpowers), one of the most popular Claude Code skill collections in the community.\\n\\n**Core principle:** review early and often \u{2014} catching an issue before it\'s built on top of is cheap; catching it after is expensive. Treat review as a normal part of the work, not a gate to get past.\\n\\n## Before requesting review\\n\\n- Self-review the diff first \u{2014} read it as if you were the reviewer, not the author. Most nitpicks and obvious bugs should be caught here, not by someone else.\\n- State intent, not just changes \u{2014} a good PR description says *why*, what was tried and rejected, and what the test plan was. \\\"Fixed bug\\\" tells a reviewer nothing about what to check.\\n- Keep the diff reviewable \u{2014} a 2,000-line PR gets a rubber stamp, not a real review. Split unrelated changes into separate PRs.\\n\\n## What to check when reviewing someone else\'s change\\n\\n- **Correctness** \u{2014} does it actually do what it claims, including edge cases and error paths, not just the described happy path?\\n- **Tests** \u{2014} do they cover the new behavior and the bug being fixed, not just re-assert what already worked?\\n- **Scope** \u{2014} does the diff match the stated intent, or did unrelated changes sneak in?\\n- **Security-sensitive surfaces** \u{2014} anything touching auth, input parsing, file paths, or shell/SQL construction deserves closer scrutiny than a style tweak.\\n- **Readability for the next person** \u{2014} not just \\\"does this work,\\\" but \\\"will someone understand why this exists in six months.\\\"\\n\\n## Responding to feedback\\n\\n- Assume good faith \u{2014} a reviewer flagging something is trying to help ship correct code, not criticize you personally.\\n- If you disagree, explain your reasoning rather than just pushing back \u{2014} the reviewer might be missing context, or you might be missing theirs. Either way, resolve it explicitly rather than silently ignoring the comment.\"\n  },\n  {\n    \"name\": \"Git Commit & Branch Hygiene\",\n    \"trigger\": \"commit-hygiene\",\n    \"skill_type\": \"prompt\",\n    \"description\": \"Use when committing changes, creating branches, or finishing a piece of work \u{2014} keeps history reviewable and revertible.\",\n    \"content\": \"# Git Commit & Branch Hygiene\\n\\nInformed by the real-world, widely-used `finishing-a-development-branch` and `using-git-worktrees` skills from obra/superpowers (github.com/obra/superpowers), one of the most popular Claude Code skill collections in the community.\\n\\n**Core principle:** git history is a tool for the next person (often future-you) trying to understand why something is the way it is. Optimize commits for that reader, not for finishing fast.\\n\\n## Commits\\n\\n- Keep commits atomic \u{2014} one logical change per commit. A commit that mixes a refactor with a bug fix makes both harder to review and impossible to revert independently.\\n- Write the message to explain *why*, not *what* \u{2014} the diff already shows what changed; a message that just restates the diff (\\\"update file.ts\\\") wastes the one place you could record intent.\\n- Don\'t commit half-finished work to a shared branch \u{2014} a commit that doesn\'t build or doesn\'t pass tests breaks bisecting for everyone who comes after.\\n\\n## Branches\\n\\n- One branch per logical unit of work \u{2014} resist the urge to pile unrelated changes onto a branch that\'s already open, even if it\'s convenient right now.\\n- Before finishing a branch: confirm it\'s rebased/mergeable cleanly, the tests pass, and the diff still matches the original intent (scope tends to creep during a long-running branch \u{2014} check it hasn\'t).\\n- Delete branches after merge \u{2014} both local and remote. A repo full of stale merged branches makes it harder to spot the ones that are actually still in progress.\\n\\n## Worktrees over branch-switching, when working on multiple things at once\\n\\nIf you need to context-switch between two pieces of work without losing your uncommitted state on either, a second git worktree (`git worktree add`) is usually better than stashing and switching branches \u{2014} it gives you two real working directories against the same repo, so nothing needs to be stashed, reordered, or risked.\"\n  },\n  {\n    \"name\": \"Verification Before Completion\",\n    \"trigger\": \"verification-before-completion\",\n    \"skill_type\": \"prompt\",\n    \"description\": \"Use before declaring any task done \u{2014} replace \'it should work\' with an actual observed result.\",\n    \"content\": \"# Verification Before Completion\\n\\nInformed by the real-world, widely-used `verification-before-completion` skill from obra/superpowers (github.com/obra/superpowers), one of the most popular Claude Code skill collections in the community.\\n\\n**Core principle:** \\\"this should work\\\" is not verification. Before calling anything done, actually run it and look at the real output \u{2014} don\'t infer success from the code looking plausible.\\n\\n**When to use:** before saying a task is complete, before closing a bug as fixed, before merging, before reporting a result back to a user or teammate.\\n\\n## What counts as verification\\n\\n- **For a code change:** actually run the affected code path (a test, a manual invocation, the real UI flow) and observe the output \u{2014} not just that it compiles or that the diff looks right.\\n- **For a bug fix:** re-run the exact reproduction that demonstrated the bug, and confirm it no longer occurs \u{2014} not a different, easier-to-pass check.\\n- **For a claim about behavior:** if you\'re not sure, say so explicitly rather than stating it with unearned confidence. \\\"I haven\'t verified X\\\" is more useful to the reader than a guess dressed up as a fact.\\n\\n## Common failure mode this guards against\\n\\nDeclaring success based on: the code compiling, the logic looking correct on a read-through, a similar case working before, or a partial test that doesn\'t actually exercise the changed behavior. All of these can be true while the actual thing being asked for still doesn\'t work \u{2014} the only way to know is to observe it directly.\"\n  },\n  {\n    \"name\": \"Security Review Basics\",\n    \"trigger\": \"security-basics\",\n    \"skill_type\": \"prompt\",\n    \"description\": \"Use when reviewing or writing code that handles user input, secrets, file paths, or external commands.\",\n    \"content\": \"# Security Review Basics\\n\\nInformed by the checks performed by Anthropic\'s own official `claude-code-security-review` GitHub Action (github.com/anthropics/claude-code-security-review), an AI-powered security review tool for Claude Code.\\n\\n**Core principle:** most real-world vulnerabilities come from a small set of recurring patterns, not exotic attacks. Checking for these specifically catches the majority of issues.\\n\\n## What to check\\n\\n- **Input validation** \u{2014} is any value that comes from a user, a file, an API response, or an environment variable trusted without validation before being used in a path, a command, a query, or a template?\\n- **Injection classes** \u{2014} command injection (shell strings built from untrusted input), SQL injection (string-concatenated queries instead of parameterized ones), path traversal (`../` in a user-supplied filename), and template/HTML injection (unescaped user content rendered as markup).\\n- **Secrets handling** \u{2014} are credentials, API keys, or tokens ever logged, committed, or embedded in a client-visible artifact? Do error messages leak secrets in stack traces?\\n- **Least privilege** \u{2014} does this code request more permission/access than the task actually needs? A process, token, or API scope that\'s broader than necessary is a bigger blast radius if something goes wrong elsewhere.\\n- **Auth/authorization boundaries** \u{2014} does every code path that should require authentication or a specific permission actually check for it, including new endpoints/handlers added alongside existing ones?\\n\\n## Practical habit\\n\\nWhen touching code in any of the categories above, ask explicitly: \\\"what\'s the worst input an adversary could supply here, and what does this code do with it?\\\" \u{2014} that one question catches a large fraction of real vulnerabilities before they ship.\"\n  }\n]\n";

The embedded starter-skills manifest JSON. Content is authored externally and must not be edited here — see crates/srv/src/config/starter-skills.json.