shinpr

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

規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。

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

通过基于规模的规划、审批、实现、验证和上报流程协调子智能体。用于将工作路由给子智能体、执行已批准的工作计划，或恢复自主执行时使用。

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

Coordinates subagents through scale-based planning, approval, implementation, verification, and escalation flows. Use when routing work to subagents, executing an approved work plan, or resuming autonomous execution.

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

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

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.

Separates the outcome a change must produce from the requirements proposed to reach it, records what the user excluded, and bands cost from decision-relevant repository evidence. Use when a requirement enters a workflow, before design begins.

Guides subagent coordination through implementation workflows. Use when orchestrating multiple agents, managing workflow phases, or determining autonomous execution mode.

Execute from repository evidence through applicable UI Spec and optional ADR decisions to complete frontend Design Doc approval

Update existing design documents (Design Doc / PRD / ADR) with review

Execute from codebase-scoped analysis through optional ADR decisions to complete Design Doc approval

Execute from repository evidence through applicable UI Spec and optional ADR decisions to complete frontend Design Doc approval

Execute from codebase-scoped analysis through optional ADR decisions to complete Design Doc approval

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.