MrCipherSmith

Phase 2 subagent for autodoc-orchestrator. Deep-dives into a single module to extract purpose, structure, public API surface, patterns, and key dependencies. Use when: dispatched by autodoc-orchestrator Phase 2 (one instance per module). NOT for: direct user invocation.

Phase 3 subagent for autodoc-orchestrator. Synthesizes all module analyses into a system-level architecture description: layers, data flows, integration points, and cross-cutting concerns. Use when: dispatched by autodoc-orchestrator Phase 3. NOT for: direct user invocation.

Phase 5 subagent for autodoc-orchestrator. Assembles all documentation sections into a cohesive package: main README.md and navigation index. Use when: dispatched by autodoc-orchestrator Phase 5. NOT for: direct user invocation.

Autonomous reverse-engineering documentation pipeline — scans an existing codebase and produces comprehensive developer documentation without user involvement after initial setup. Use when: "autodoc", "generate docs for my project", "document this codebase", "reverse engineer documentation", "create project documentation from code", "сгенерируй документацию проекта", "задокументируй кодовую базу", "автодок", "autodoc". Trigger on: user provides a repo path, asks to document existing code, wants onboarding docs, API reference, or architecture overview generated automatically. NOT for: writing new PRDs or planning new features (use gproject-orchestrator).

Phase 1 subagent for autodoc-orchestrator. Scans project structure, detects stack, identifies module boundaries, entry points, and dependencies. Use when: dispatched by autodoc-orchestrator Phase 1. NOT for: direct user invocation.

Phase 4 subagent for autodoc-orchestrator. Writes one documentation section from analysis artifacts. Dispatched in parallel — one instance per section. Use when: dispatched by autodoc-orchestrator Phase 4. NOT for: direct user invocation.

Use when exploring architecture decisions, tech choices, feature ideas, or any open-ended problem that benefits from multiple perspectives.

Use when generating a changelog, release notes, or summarizing what changed between tags, versions, or date ranges.

Use when saving session learnings, coding patterns, conventions, or commands discovered during work into CLAUDE.md files.

Use when running a full quality gate after implementation — lint, type-check, tests, and import validation. Mandatory step in job-orchestrator after task-implementer and after fix iterations. Use standalone when you need a structured verification report.

Use when committing code changes and a well-structured conventional commit message is needed, with optional amend or selective staging.

Use when a job needs a unified context document — gathering docs, libraries, and references for sub-agents before execution.

Use when creating, applying, rolling back, or checking the status of database migrations.

Use when checking for outdated packages or upgrading dependencies with compatibility verification.

Use when deploying to any environment (staging, production) or when a deployment pipeline needs to run.

Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch.

Use when taking a feature from idea or GitHub issue all the way to a merge-ready PR in one guided workflow.

Validates PRD/Implementation Plan against decisions registry, architecture doc, and best practices constraints. Catches contradictions, gaps, and violations. Use when: dispatched by gproject-orchestrator Phase 5. NOT for: direct user invocation.

Collects and structures initial project information from multiple sources. Use when: dispatched by gproject-orchestrator Phase 0. NOT for: direct user invocation — always called through orchestrator.

Project documentation orchestrator — builds PRDs, specs, and implementation plans through a phased pipeline of specialized subagents. Use when: "Create project documentation", "Write PRD for...", "Plan project...", "Document how to implement...", "Spec out feature...", "Project planning", "gproject", "Создай документацию проекта", "Напиши PRD". Make sure to use this skill whenever the user mentions PRD, project planning, technical specification, implementation plan, feature spec, architecture document, project documentation, or wants to plan any software project from scratch or document a new feature in an existing codebase — even if they don't explicitly say "PRD" or "spec". Also trigger on: "how should I build...", "plan out...", "what's the best approach to build...", "document the approach for...", "create a roadmap for...", "spec this out", "write requirements for...". NOT for: code implementation (use job-orchestrator), code review (use code-review skills).

Researches best practices per technology in the chosen stack and defines application architecture patterns. Produces constraints that PRD must follow. Use when: dispatched by gproject-orchestrator Phase 3. NOT for: direct user invocation.

Generates roadmap, milestones, task breakdown, and dependency graph from PRD. Use when: dispatched by gproject-orchestrator Phase 6. NOT for: direct user invocation.

Defines core problems, goals, non-goals, and success metrics from discovery data. Use when: dispatched by gproject-orchestrator Phase 1. NOT for: direct user invocation.

Generates PRD or Implementation Plan constrained by decisions registry, architecture doc, and best practices. Does NOT invent new architectural decisions. Use when: dispatched by gproject-orchestrator Phase 4. NOT for: direct user invocation.

Determines project level (MVP/pet/startup/production) and recommends optimal technology stack with trade-off analysis. Use when: dispatched by gproject-orchestrator Phase 2. NOT for: direct user invocation.

Use when adding automated hook behavior to Claude Code or Cursor from a natural language description.

Use when requirements are ambiguous and precise clarification is needed before proceeding with a complex task.

Use before implementation, design, or migration when requirements are unclear and targeted clarifying questions are needed to gather precise context.

Use when decomposing a GitHub issue into atomic tasks for AI implementation, planning task breakdown, or preparing work for task-implementer agents.

Use when a job folder needs to be initialized, or analysis/report/review documents need to be created or updated in jobs/.

Use when a GitHub issue or complex intent needs to be analyzed, planned, and implemented end-to-end with sub-agents.

Use when measuring bundle size, detecting performance regressions, auditing slow queries, or investigating why something is slow.

Use when a vague or unstructured request needs to be converted into a formal, testable Product Requirements Document.

Use when documenting PR changes, adding a PR description, creating a linked issue for a PR, or updating an existing issue body.

Use when opening a pull request for the current branch.

Use when pushing the current branch to the remote, especially when upstream tracking or safety checks are needed.

Use when: reviewing code for architectural violations — layer violations, dependency direction mistakes, module boundary coupling, SOLID principle breaches, NestJS module/provider structure, React MVVM boundary violations, or MobX store layer misplacement. Triggered by: "review architecture", "check architecture", "architectural review", or dispatched by review-orchestrator with --architecture or --backend. NOT for: style/naming preferences, logic correctness bugs, or security vulnerabilities.

Use when: reviewing NestJS backend changes — API design, service layer, DTO validation, database patterns, and TypeScript correctness. Covers "review backend", "backend review", "review API", "review NestJS", or dispatched by review-orchestrator with --backend flag. NOT for: frontend patterns, MobX, React components, general security vulnerabilities (use review-security-code for XSS/injection/auth-bypass), or performance profiling (use review-performance).

Use when: reviewing code against Clean Code principles (Uncle Bob) and SOLID at the function/class level — meaningful names, small functions, single level of abstraction, argument count, error handling, DRY, comment quality, and SOLID (SRP, OCP, LSP, ISP, DIP) as applied to individual classes and functions. Triggered by: "review clean code", "check clean code", "Uncle Bob review", "SOLID review", "review --clean-code", or dispatched by review-orchestrator. NOT for: architectural layer violations (review-architecture), naming convention formatting (review-style), logic correctness bugs (review-logic), or security (review-security-code).

Use when a frontend review is requested, checking React component patterns, MobX state management (observer, actions, computed, reactions, lifecycle), View-Store boundaries, and TypeScript safety in changed frontend code. NOT for backend patterns, security vulnerabilities, performance bottlenecks, or cross-layer architecture.

Use when: a PR needs codebase-aware review using Greptile — an AI reviewer with full repository indexing. Unlike diff-only reviewers, Greptile understands cross-file impact across the entire codebase. Triggered by: "greptile review", "review with greptile", "review --greptile", or dispatched by review-orchestrator on PRs. Requires: PR number + GitHub/GitLab repo name. NOT for: path-mode reviews or diff without a PR number — use other review-* skills instead.

Use when: reviewing code that will run under high concurrency or high traffic — race conditions, connection pool exhaustion, cache invalidation, missing indexes, unbounded queues, missing backpressure, retry storms, idempotency gaps, hot-path blocking I/O, and distributed systems anti-patterns. Triggered by: "review highload", "review scalability", "highload review", "review concurrency", "review --highload", or dispatched by review-orchestrator. NOT for: frontend re-render performance (review-performance), general N+1 queries (review-performance), clean code style (review-clean-code), or NestJS module structure (review-architecture).

Use when: reviewing code for logic correctness, algorithmic bugs, missing error handling, async/await mistakes, null/undefined risks, race conditions, type contract violations, or spec compliance. Dispatched by review-orchestrator for --frontend, --backend, and --all. Also invoked directly: "review logic", "check correctness", "are there any bugs here". NOT for: security vulnerabilities, performance profiling, style/naming preferences, or architectural pattern concerns — those belong in their respective specialized reviewers.

Use when: a code review is requested and the user does not explicitly name a specialized reviewer. Handles "review", "code review", "review PR", "review --frontend", "review --backend", "review --architecture", "review --security", "review --performance", "review --style", "review --strict", "review --all". Routes to specialized reviewers in parallel and consolidates findings into one unified report. NOT for: running a single specialized reviewer — invoke it directly by name instead.

Use when a performance review is requested, checking for N+1 queries, unnecessary re-renders, memory leaks, missing indexes, large bundle imports, and synchronous blocking in changed code. NOT for security, logic correctness, style, or architecture.

Use when: a developer has received PR review comments and wants to understand them, act on them, or extract patterns from them. Covers "analyze PR comments", "review PR feedback", "what did reviewers say", "parse PR #N", "explain PR comments", or dispatched by review-orchestrator when a PR URL is provided. NOT for: reviewing code directly — this skill reads human or bot PR feedback and makes it actionable. To review code, use the domain review skills.

Use when a code-level security review is requested, checking for injection vulnerabilities, auth gaps, insecure cryptography, secrets, and OWASP Top 10 patterns in changed code. NOT for infrastructure, deployment, or dependency audits.

Use when: a strict engineering pass is needed — either as a meta-reviewer reading consolidated findings from other reviewers and elevating weak findings, or standalone on a git diff. Covers "strict review", "review --strict", "boss review", "review as boss", or dispatched by review-orchestrator as an optional post-pass after other reviewers complete. NOT for: first-pass review (run domain reviewers first); large refactors outside the diff scope (file separately).

Use when: reviewing code for style, naming conventions, readability, and DRY violations — without touching logic, architecture, security, or performance. Covers "review style", "style review", "check naming", "check readability", or dispatched by review-orchestrator with --style flag. NOT for: logic bugs, architectural violations, security vulnerabilities, performance anti-patterns, or any finding that could cause a functional regression.

Use when checking for dependency vulnerabilities, accidentally committed secrets, or security issues in Docker images.

Use when implementing a single decomposed task from issue-analyzer end-to-end, or executing autonomous code changes from a JSON task object.

Use when unit or integration tests need to be written for a specific file or module.

Use when writing test cases BEFORE implementation — converts acceptance criteria into failing test stubs that task-implementer will make pass. Mandatory step in the TDD pipeline between issue-analyzer and task-implementer.