Creek-Vault

Run a named codebase maintenance scan and convert findings into 6-component, agent-ready GitHub issues. Use when a workflow or user says "run the <name> scan", "create issues from this analysis", or passes a prompts/scans/*.md file. Handles dedupe, priority labeling, and max-issue caps so the Ralph loop never starves and never bloats. Do NOT use for implementing fixes (use stay-green), reviewing PRs (use comprehensive-pr-review), or closing/triaging existing issues (use backlog-grooming).

Audit the codebase for sloppy, amateurish, or AI-generated low-quality code — bugs, code smells, dead/stubbed/orphaned code, duplication, poor architecture, needless verbosity, comment slop, type-safety erosion, and weak tests — then file corroborated findings as Ralph-ready GitHub issues (and decomposed epics for big work). Use when the user says "de-slop", "deslopify", "run the slop detector", "find code smells", "audit code quality", "find dead code", "weekly code quality scan", "bullshit detector", or when the weekly de-slop GitHub Action runs. Findings must be corroborated by two independent signals before filing — null findings are a valid result. Do NOT use for implementing fixes (Ralph / continue-epic does that), for reviewing a specific PR diff (use comprehensive-pr-review), for fixing CI failures (use ci-debugging), or for triaging a backlog of existing issues (use backlog-grooming).

Configure per-stage LLM model routing for a Creek vault and perform the secure setup. Use when the user asks to "set up / configure my models", "/model-setup", "which model for classification / writing / frontend / the writing desk", "route classification local and writing to Sonnet", "wire up per-stage routing", or "pull the ollama models for creek". The skill detects the current `llm:` block, the environment (key presence + cloud consent), and Ollama reachability; writes the per-stage `llm:` block into the vault's 00-Creek-Meta/creek_config.yaml (config only); guides the user to set `ANTHROPIC_API_KEY` / `CREEK_CLOUD_CONSENT` in their environment; and offers to `ollama pull` the local models. It NEVER reads, echoes, logs, or writes an API key into any file. Do NOT use to edit routing source/tests (that is the per-stage routing code in `creek/classify/llm/`).

Launch the CrawDad Discord bot against a Creek vault. Use when the user asks to "launch CrawDad", "start the bot", "run CrawDad", "fire up the Discord bot", or otherwise bring the Discord-side interface online for a vault. ALWAYS ask which vault directory to run against first. Handles every launch gotcha (absolute vault_path, State/latest.md, voice-core mirroring, env secrets, allowlists) and starts the bot in the background. Do NOT use for driving the `creek` CLI / writing essays (use creek-cli) or editing crawdad/creek-tools source (use stay-green/work-issue).

Decompose a SPEC, PRD, RFC, or design doc into a sequenced set of GitHub epics and child issues, where each issue is a self-contained prompt an agent or engineer can execute end-to-end. Use when the user says "decompose this spec", "break this PRD into issues", "file epics from this design doc", or "plan the implementation". Each issue is shaped as a 6-component prompt (prompt-engineering), sequenced via tracer-code so the skeleton lands first and every later issue keeps the system demoable, and gated by stay-green Done-Done plus max-quality-no-shortcuts anti-bypass rules. Issue bodies are written to `git-issues/` and filed via `gh issue create --body-file`, matching the file-based pattern in git-workflow. Do NOT use for single-task issue or PR creation (use git-workflow), backlog cleanup of existing issues (use backlog-grooming), PR code review (use comprehensive-pr-review), or choosing between technical approaches inside a SPEC (use architectural-decisions).

End-to-end GitHub issue implementation: read issue, branch, TDD, quality checks, self-review, and PR creation. Use when given an issue number to implement, asked to "work on issue #N", "pick up #N", "implement #N", or "start issue #N". Orchestrates stay-green, max-quality-no-shortcuts, and self-review skills. Do NOT use for bug triage (use bug-squashing-methodology), backlog maintenance (use backlog-grooming), or reviewing others' PRs (use comprehensive-pr-review).

Iterate on Claude PR review feedback intelligently and merge when ready. Use when the user asks to "address feedback", "respond to Claude's review", "iterate on the PR", "fix review comments", or "merge if Claude said LGTM". The Claude reviewer publishes a top-level PR comment via GitHub Action ending in a `Verdict:` line (LGTM / CHANGES_REQUESTED / COMMENTS) — it is NOT a formal GitHub approval. This skill locates the most recent such comment via GitHub MCP, parses the verdict, triages blockers/problems/nits into a TDD-driven local fix loop, replies and resolves threads. On `LGTM` for the current HEAD with green CI it squash-merges; on `COMMENTS` it files each actionable item as a follow-up GitHub issue and then squash-merges; on `CHANGES_REQUESTED` it loops until LGTM. Do NOT use for giving a review (use comprehensive-pr-review), debugging CI failures themselves (use ci-debugging), general TDD work outside review context (use stay-green), bug RCA (use bug-squashing-methodology), or issue/branch/PR creation

Gentle, hand-held, end-to-end walkthrough of the Creek Vault + CrawDad system, voiced by CrawDad. Use when the user wants to be walked through using Creek — "walk me through", "how do I use this", "get me started", "show me the proper way", "I don't want to read the docs", or any request for guided onboarding. Claude runs every command FOR the user and narrates gently, one stage at a time, at the user's pace. The user only makes decisions and gives consent; they never read code, docs, or a README. Do NOT use for implementing FEATs (use work-issue), debugging CI (use ci-debugging), PR review (use comprehensive-pr-review), or when the user explicitly wants to read the docs themselves.

Subscribe to GitHub PR activity and wait — without polling — for the Claude reviewer's verdict comment on the current HEAD. Use when a PR has just been pushed and you need to know the verdict (LGTM / CHANGES_REQUESTED / COMMENTS) before merging, addressing feedback, or declaring work done. Wraps `mcp__github__subscribe_pr_activity`, which delivers comments and CI failures (NOT CI passes) as `<github-webhook-activity>` events. The verdict comment itself is a comment event, so the bot's post wakes the session directly — no need to proxy through CI status. After subscribing, end the turn; events resume the session. Called by `address-feedback`, `stay-green`, and `comprehensive-pr-review`. Do NOT use for waiting on arbitrary CI success (not deliverable by the webhook), general PR babysitting unrelated to the verdict gate, debugging CI failures themselves (use `ci-debugging`), or one-off status polling (use `pull_request_read` directly).

Remediate dependency vulnerability scanner failures by verifying live package registry data and upgrading instead of suppressing. Use when an SCA / CVE tool fails or files an alert: npm audit, pnpm audit, yarn audit, pip-audit, safety, Snyk, Dependabot, Trivy, Grype, OSV-Scanner, audit-ci, cargo audit, govulncheck, bundler-audit, Renovate, or any CI step reporting a CVE / GHSA / OSV advisory. The first action is ALWAYS to look up the latest published version on the live registry — training data is months stale and almost never knows the current version. Suppression, ignore, or allowlist entries are the absolute last resort, only after upgrade and override paths are proven unavailable; surrounding GitHub issues and justification docs do not by themselves count as remediation. Do NOT use for vulnerabilities in your own application code (use security skill), general linter or type checker bypasses (use max-quality-no-shortcuts skill), or unrelated CI failures (use ci-debugging skill).

Issue-first development workflow with template-file-based gh commands and label hygiene. Use when creating issues, starting new work, making branches, committing changes, or opening PRs. Covers the full issue-to-PR lifecycle using file-based templates instead of inline strings. Do NOT use for bug-specific debugging or RCA (use bug-squashing-methodology), PR code review (use comprehensive-pr-review), or backlog cleanup and issue triage (use backlog-grooming).

Audit and rewrite user-facing error messages so users can self-serve instead of emailing support. Use when auditing error messages across an app, improving or rewriting error wording, reviewing toasts, alerts, flash messages, form validation copy, or empty/failure states, or when a message feels opaque, blame-y, or ends in "contact support". Covers the four-part rubric (what / why / next / escape), an inventory-and-triage audit workflow, rewrite templates, and security-safe disclosure rules. Do NOT use for exception architecture, typed errors, or developer-facing logging (use error-handling skill); for the security rules around what errors may safely disclose in auth/crypto paths (use security skill); or for the visual styling of alerts, toasts, and banners (use frontend-aesthetics skill).

Structured 10-section PR review covering security, quality, testing, and documentation. Use when reviewing pull requests, evaluating code changes, or doing code review. Produces verdicts with specific references. Do NOT use for backlog grooming or issue triage (use backlog-grooming), reviewing your own changes before PR creation (use self-review), or iterating on a review's feedback as the PR author (use address-feedback).

2-gate TDD development workflow: Gate 1 is Red-Green-Refactor testing, Gate 2 is pre-commit quality checks. Use when implementing features, fixing bugs, or doing any development work. Ensures code is never committed without passing tests and quality checks. Do NOT use for bug-specific debugging (use bug-squashing-methodology).

Rigorous self-review of your own code changes before PR creation. Use when you have finished implementing and want to review your own diff, when asked to "review my changes", "self-review", "check my work", or "pre-PR review". Covers bugs, architecture, security, ethics, testing, and project compliance. Do NOT use for reviewing others' PRs (use comprehensive-pr-review), CI failures (use ci-debugging), or backlog triage (use backlog-grooming).

Guide explicit, factual trade-off analysis for architectural choices. Use when choosing between libraries, patterns, technologies, databases, or API designs. Presents 2-4 options with comparison matrices and recommendations. Do NOT use for trivial choices, variable naming, or code formatting decisions.

Systematic GitHub backlog maintenance: review merged PRs, close resolved issues, identify gaps, and create missing issues. Use when asked to groom the backlog, clean up the issue tracker, or review recent work. Do NOT use for PR code review (use comprehensive-pr-review).

Structured 5-step bug fix process with root cause analysis and TDD. Use when fixing bugs, debugging failures, or investigating defects. Covers RCA documentation, reproduction, TDD fix cycle, and PR workflow. Do NOT use for general feature development (use stay-green), CI environment issues (use ci-debugging), or code reviews.

Debug CI test failures on pull requests with structured protocol. Use when CI fails on your PR, tests pass locally but fail in CI, or you're tempted to say "pre-existing issue". Covers state comparison, error reading, local reproduction, and common root causes. Do NOT use for local-only test failures or feature development.

Safe and efficient concurrent code patterns across languages. Use when implementing async operations, parallel processing, thread pools, or managing shared state. Covers Python asyncio, TypeScript Promises, Go goroutines, and Rust Tokio. Do NOT use for general performance optimization without concurrency.

Write clear, comprehensive documentation with language-specific patterns. Use when writing docstrings, module docs, README files, API references, or architecture decision records. Covers Python, TypeScript, Go, and Rust documentation conventions. Do NOT use for code style (use vibe skill).

Implement robust error handling that fails fast with clear diagnostics. Use when designing error strategies, writing exception handling, creating custom error types, or implementing validation. Covers Python, TypeScript, Go, and Rust patterns. Do NOT use for security-specific input validation (use security skill).

ISO 8601 date-prefix file naming conventions for documents and plans. Use when creating dated documents, plan files, analysis reports, meeting notes, or any time-sensitive documentation. Do NOT use for source code files, configs, or permanent reference docs.

Produce polished, accessible frontend UI with design tokens, semantic HTML, and Pico CSS. Use when creating HTML templates, adding CSS, building user-facing pages, or working with Jinja2 templates. Covers design tokens, typography, components, accessibility (WCAG 2.1 AA), dark mode, and micro-interactions. Do NOT use for backend API design or data modeling.

Anti-bypass philosophy for linter and type checker warnings. Activates when you consider adding noqa, type-ignore, pylint-disable, or similar bypasses. Fix the root cause instead. Covers complexity refactoring, type fixes, and argument reduction patterns. Do NOT use for general code quality guidance (use vibe or stay-green).

Write high-value tests that kill mutants through logic validation. Use when writing tests that need to verify behavior, improving mutation scores, or evaluating test quality. Covers boundary testing, exact value assertions, error message validation, and state verification. Do NOT use for general test writing (use testing skill).

Transform vague requests into effective 6-component prompts. Use when crafting prompts for AI agents, writing plan files, delegating tasks, or when Claude's responses miss the mark. Covers role, goal, context, format, examples, and constraints. Do NOT use for direct code implementation or testing.

Implement secure coding practices against common vulnerabilities. Use when handling user input, file paths, subprocess calls, SQL queries, API keys, or building web endpoints. Covers input validation, injection prevention, secret management, and XSS/CSRF protection across Python, TypeScript, Go, and Rust. Do NOT use for general error handling (use error-handling skill).

Build and validate Claude Code skills to production quality. Use when creating new skills, modifying existing SKILL.md files, writing skill descriptions, structuring skill directories, or reviewing skill quality. Ensures progressive disclosure, trigger optimization, and composability. Do NOT use for general documentation or code quality guidance.

Write comprehensive, maintainable tests following TDD and AAA pattern. Use when writing unit tests, integration tests, setting up fixtures, mocking dependencies, or improving test coverage. Covers Python (pytest), TypeScript (Jest), Go (testing), and Rust (built-in + proptest). Do NOT use for mutation testing specifics (use mutation-testing skill).

Tracer code development methodology for building working systems incrementally. Use when starting complex projects, working under time constraints, doing interview coding sessions, or when you need a demoable application at every stage. Wire the skeleton first, then replace stubs with real logic one at a time. Do NOT use for small bug fixes or single-function tasks.

Code style, naming conventions, and structural patterns for consistent codebases. Use when writing new code, reviewing style choices, or establishing project conventions. Covers Python, TypeScript, Go, and Rust idioms. Do NOT use for documentation content (use documentation skill) or architectural decisions.