adepthood

Query the Adepthood knowledge graph to orient before reading code: what connects two modules, the impact of changing a symbol, a plain-language explanation of a node, or the graph's freshness/status. Use when the user says "query the graph", "what connects X and Y", "impact of changing X", "what depends on X", "is the graph fresh", "/graph", "record the graph outcome", or wants a graph-first answer instead of a blind file sweep. Wraps the graphify query, path, explain, affected, save-result, and reflect subcommands plus a graph-meta.json freshness check, and defaults to the federated pan-graph.json when it is present. Do NOT use to file bugs or features (use flare), to run code-quality or slop audits (use de-slopify), or to build or refresh the graph itself (run scripts/graph/build.sh or scripts/graph/update.sh).

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 filing a new bug/feature report as a GitHub issue (use flare) — this skill starts once an issue already exists and work is underway.

Fast, one-shot bug or feature reporting: research the repo, write a world-class QA/PM ticket, and file it to GitHub Issues with Ralph-ready labels in a single turn. Use when the user says "flare this", "file a bug", "report this", "open an issue for X", "/flare", or hands you a short bug/idea description and wants it turned into a ticket right now. Grounds the report in real code (file:line, snippets, git history), applies the 6-component prompt-engineering framework so the ticket is directly consumable by the Ralph agent fleet, decomposes oversized asks into an epic + sub-issues, and dedupes against existing issues before creating anything. Do NOT use for automated tool-output-driven maintenance scans (use scan-issue-writer), for triaging/closing/grooming the existing backlog (use backlog-grooming), for the root-cause-analysis and TDD fix cycle once an issue already exists (use bug-squashing-methodology), or for reviewing an open PR's diff (use comprehensive-pr-review).

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), backlog cleanup and issue triage (use backlog-grooming), or fast research-backed bug/feature report filing with Ralph labels (use flare).

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), closing/triaging existing issues (use backlog-grooming), or filing a one-off bug/feature report from a live user description (use flare).

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).

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, and merges only when the latest verdict is `LGTM`, the comment was posted after the current HEAD's push, and all required checks are green. 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 (use git-workflow).

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).

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), issue-first development workflow and PR creation (use git-workflow), 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).

Security best practices for Adepthood's FastAPI + React Native stack. Use when handling user input, API keys, JWT tokens, database queries, CORS configuration, or preparing for production deployment. Covers OWASP Top 10, secrets management, and deployment hardening.

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) and TypeScript (Jest/React Native Testing Library).