claude-code-blueprint

Review and post feedback on a GitHub or Gitea pull request end-to-end: fetch the PR diff, run a multi-agent code review, and auto-post the verdict as a real PR review (approve/request-changes/comment) via the platform's API. Triggers on: 'review this PR', 'review PR #N', 'check this pull request', 'post a PR review', 'do a PR review on <url>'. For local uncommitted changes or a branch diff with no open PR, use review-full instead.

MUST use before any git push to main/master/production, or when user mentions 'deploy', 'going live', 'push to prod', 'ready to ship', 'merge to main', 'release'. Also trigger before any npm publish for CLI tools, or on 'audit', 'check vulnerabilities', 'are our deps safe?', 'npm audit', 'yarn audit'. Performs: test suite validation, dev-artifact scan (`console.log`, `TODO`/`FIXME`, hardcoded secrets like `password:` / `token:` / API keys), dependency audit (npm audit, pip-audit, bundle audit, cargo audit, govulncheck, etc.), build verification, ORM/schema safety check, auth-middleware coverage on new endpoints. Verdict: GO / NO-GO with per-check checklist.

Run E2E tests or interactive browser verification. Triggers on: 'run e2e', 'e2e test', 'browser test', 'check in browser', 'verify UI', 'interactive test'.

Structured pre-feature requirements gathering. Run before writing any new feature or API endpoint to clarify scope, acceptance criteria, and technical constraints. Produces: a Requirements Summary (Problem | Scope | Stories | Acceptance Criteria | Out of Scope | Open Questions), presented to the user for confirmation BEFORE saving to a file, so requirements can be edited before they become reference for implementation.

Restore session context at the start of every new conversation. Auto-triggers on session start, or when user says 'continue', 'what were we doing', 'where did we leave off'.

Register an existing project in memory. Use when starting work on a new repo or when a project needs its own context file. Triggers on: 'register project', 'add project to memory', 'track this project', 'create project file'.

Scan git diffs for project-specific anti-patterns. Triggers on: 'scan diff', 'check diff', 'anti-pattern check', 'pattern scan', 'review changes'.

Run a comprehensive multi-perspective code review on recent changes. Also triggers on 'is this secure?', 'security review', 'check for vulnerabilities', 'could this be exploited?' for security-focused review. Produces: GO/NO-GO verdict + findings table (Severity | Category | File:Line | Issue | Recommendation) grouping CRITICAL/HIGH/MEDIUM/LOW across code quality (patterns, error handling, types), security (OWASP Top 10, auth gaps, hardcoded secrets), and database logic (N+1 queries, soft-delete violations, missing models).

MUST use when user says 'save diary', 'write diary', 'diary entry', 'update diary', or 'document session'. Also auto-trigger at the end of any significant session (feature shipped, major bug fixed, architecture decision, new project started).

MUST use when user says 'save', 'save session', or explicitly wants to preserve session state. {USER_NAME} does NOT use slash commands; also trigger proactively when significant work has been completed and session context should be persisted. For session endings (bye/done/goodbye), use the session-end skill instead which combines save-session + save-diary.

Scaffold a new project with standard structure, configs, and CLAUDE.md

MUST use when user says 'bye', 'goodbye', 'good night', 'gnight', 'done for today', 'that's all', 'that's it', 'see you', 'see ya', 'let's stop', 'stopping here', 'wrapping up', 'signing off', 'closing down', 'done', 'finished for now', 'talk later', 'cya'. The user does NOT use slash commands; detect these natural session-ending phrases and run the full wrap-up automatically.

MUST use when user describes a multi-step feature to build, says 'let's build', 'new project', 'let's implement', or when a task clearly requires more than 3 steps and no plan exists yet. Do NOT trigger for simple additions like adding a comment, renaming a variable, or single-file changes. Produces: task breakdown with S/M/L/XL size estimates, dependency ordering, risk analysis, and a Definition of Done checklist; output is a structured markdown plan ready for implementation.

MUST use when user asks 'what's new?', 'any updates?', 'latest versions?', 'breaking changes?', 'should we upgrade?', 'what changed in X?', or when starting a new project. Detects dependencies dynamically from `package.json` / `requirements.txt` / `go.mod` / `composer.json` first, then reports per-package: latest version (vs. installed), breaking changes since installed version, security advisories (CRITICAL/HIGH), and deprecation warnings. Falls back to a generic stack table only when no manifest file is found.

Validate database schema integrity and check for common issues

Show project status dashboard across registered repositories

MUST use after implementing new features or bug fixes, when user asks 'run the tests', 'are tests passing?', 'test this', or before any deployment step. Also trigger when tests were previously failing and fixes were applied.

Generate a changelog from git history since a tag, date, or commit