shinpr

コードの品質問題、アンチパターン、可読性を検査。機能実装、コードレビュー、リファクタリング時に使用。

変更に必要なPRD、ADR、UI Spec、Design Doc、作業計画書と、それぞれの保存先を判定する。ドキュメントの範囲を決める時、または技術ドキュメントを作成・レビューする時に使用。

リポジトリで設定済みのReactテスト・ブラウザハーネスを使用してフロントエンドテストを設計。RTL、MSW、Vitest、Playwrightが存在する場合に適用。コンポーネント、loading/error state、統合、フロントエンドE2Eテストの追加・レビュー時に使用。

実装戦略（垂直スライス、水平、ハイブリッド）をリスク評価で選択。機能の実装計画時に使用。

受け入れ済みの振る舞いを観測可能な境界で証明する、最小限の統合/E2Eテストセットを選定・設計する。E2Eテストまたは統合テストの作成・レビュー時に使用。

リポジトリに即したTypeScriptテスト設計、振る舞いの証明、独立性、モック境界の基準を適用する。ユニットテストの作成・レビュー時に使用。

检测代码异味、反模式和可读性问题。在实现功能、评审代码或重构时使用。

判断某项变更需要哪些 PRD、ADR、UI 规范（UI Spec）、设计文档（Design Doc）和工作计划，以及每种文档的存放位置。用于决定文档范围，或创建/评审技术文档时使用。

Investigate problem, verify findings, and derive solutions

Applies language-agnostic and backend technical decision criteria, anti-pattern detection, debugging, and quality gates. Use when reviewing general/backend implementation choices, code smells, failures, or implementation completeness.

Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Use when deciding documentation scope, or when creating or reviewing a technical document.

Applies React/TypeScript-specific technical decision criteria, anti-pattern detection, debugging, and frontend quality gates. Use when reviewing components, hooks, browser behavior, or frontend implementation completeness.

Implementation strategy selection framework. Use when planning implementation strategy, selecting development approach, or defining verification criteria.

Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria. Use when designing integration tests, E2E tests, or reviewing test quality.

Language-agnostic testing principles for choosing which tests a change needs, test quality, and proof ownership, with frontend and browser E2E implementation references. Use when writing tests, deciding test scope, or reviewing test quality.

Adjust an already-implemented UI in-session with verification against the design source

Add integration/E2E tests to existing codebase using Design Docs.

Execute an approved backend Work Plan autonomously through task execution, quality fixes, commits, and final verification.

Execute from codebase-scoped analysis to design document creation.

Investigate problem, verify findings, and derive solutions through structured diagnosis.

Adjust an implemented UI with focused evidence, verification, and quality checks.

Execute an approved frontend Work Plan autonomously through frontend implementation, quality fixes, commits, and final verification.

Execute from codebase-scoped analysis to frontend design document creation including UI Spec.

Create frontend work plan from design document with test skeleton generation.

Selects and defines the structural design context needed by a prototype or PRD. Use when shared information architecture, flows, content, brand, Visual Tokens, or AI interaction decisions are missing.

Creates a delivery-ready PRD from validated hypotheses with material 4 Risks evidence and necessary traceability. Use when turning validation results into requirements or user stories.

Frames product Opportunities and creates decision-relevant hypotheses from available evidence. Use when exploring a problem, market opportunity, or user need.

Creates or updates evidence-backed personas with the context and JTBD needed for product decisions. Use when user segments or behavior affect discovery, design, or requirements.

Exports an evidence-grounded prompt for Lovable, v0, or a similar external prototype generator. Use when the desired artifact is a reusable generator prompt rather than an internally generated HTML prototype.

Use when a design-capable human wants to refine the auto-derived Visual Tokens in `docs/product/design/brand-direction.md`

Orchestrates reflection by updating affected artifacts and distilling reusable knowledge from validation results.

Validates a hypothesis with a risk-appropriate method and records decision-relevant evidence. Use when testing Value, Usability, Feasibility, or Viability assumptions.

Applies root-cause analysis, impact inspection, and completeness checks without expanding approved scope. Use when fixing bugs, refactoring, reviewing quality, or resolving unexpected implementation evidence.

Applies repository-aware rules for maintainable implementation, contracts, errors, and refactoring. Use when writing or modifying code.

Determines which PRD, ADR, Design Doc, and Work Plan a change requires. Use when deciding documentation scope or creating technical documents.

Selects the smallest sufficient implementation strategy and verification boundary from current requirements and repository evidence.

Applies integration and E2E implementation, mock-boundary, and review rules. Use when: writing integration or E2E tests or reviewing their quality.

Checks task understanding, evidence, scope, and stopping conditions at decision-changing moments. Use when starting repository work, changing task type, encountering unexpected evidence, or completing a meaningful phase.

Applies repository-aware TDD, observable test design, and applicable quality checks. Use when changing behavior, writing tests, or reviewing test quality.

Selects the narrowest sufficient test boundary from requirements, repository evidence, and maintenance cost. Use when deciding integration or E2E coverage.

Improves LLM-facing context while preserving intent, execution boundaries, and proportional work. Use when creating or reviewing prompts, agent definitions, skill definitions, or other instructions for an LLM.

Retrieves and updates project-specific prompt knowledge from comparison evidence and user feedback. Use only for prompt analysis or post-comparison learning within a Rashomon evaluation.

Compares original and optimized prompts through repeated blind paired execution in git worktrees. Use when evaluating prompt improvement effects or learning prompt engineering through concrete examples.

Creates or updates Claude Code skills through interactive dialog, then evaluates effectiveness with sequential paired comparisons. Use when creating new skills, updating existing skills, or evaluating skill quality.

Creates, pins, and cleans isolated Git worktree pairs for comparison trials. Use only when a Rashomon prompt or skill evaluation needs paired execution environments or orphan recovery.

Guides task boundary decisions when splitting requirements into implementation-ready value units. Use when determining task size, responsibility scope, or real blocking dependencies.

Decomposes Linear issues or requirement documents into the fewest implementation-ready value units, then registers the approved tasks in Linear. Use when "decompose", "break down tasks", "split into tasks", "task breakdown", or "create Linear issues from…

Evaluates implementation decisions against the user's stated outcome. Use when a plan, design, code change, dependency, or code-review response is being chosen or adopted, including when nobody asked for a review.

Diagnoses one Claude Code or Codex session across user utterances, work management, and the operative instruction environment. Use when: an agent session was incomplete, wasteful, or behaved unexpectedly.

Searches, saves, and maintains a local document index through a local RAG MCP server. Use when user says "search my docs", "save this page", "read around that chunk", "sync my index", or invokes `npx mcp-local-rag`.

Optimizes image generation prompts using Subject-Context-Style structure. Use this skill when generating images, creating illustrations, photos, visual assets, editing images, or crafting prompts for any image generation model.

Run agent definitions as sub-agents. Use when the user names an agent or sub-agent to run, references an agent definition, or delegates a task to an agent.

Guides parents in subagent model selection and delegation through completion. Use when assigning work to subagents, assessing their progress or results, or intervening in delegated work.