「plan-review」の検索結果

Cross-AI plan convergence - replan until review concerns are resolved.

日本語の概要は準備中です。原文の説明を表示しています。

Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early.

日本語の概要は準備中です。原文の説明を表示しています。

Adversarial plan review by 3 independent reviewers (Feasibility, Completeness, Scope & Alignment) before presenting to user.

日本語の概要は準備中です。原文の説明を表示しています。

Reviews a concrete implementation plan for missing decisions, feasibility and risk before execution; read-only.

日本語の概要は準備中です。原文の説明を表示しています。

Automatic adversarial review gate that spawns 3 independent reviewers in parallel after any plan is drafted - all must PASS before presenting to user

日本語の概要は準備中です。原文の説明を表示しています。

Build work collaboratively in reviewable pieces, handing each piece back for review before starting the next, so the person stays in the lead and steers while the work happens instead of reviewing a finished result. Use when someone says to pair with them on something, asks to collaborate rather than direct, wants to review as it goes, or wants to guide the work piece by piece — on code, on a design decision, or on writing. For a test-first build it runs tdd, for restructuring it runs refactor, for an interface contract it runs design-an-api, and for plan work it runs iterative-plan-review or plan-implementation, each collaboratively; invoke any of those directly instead to run it straight through without pausing. Does not pace someone through code that already exists and builds nothing — use code-walkthrough. Does not explain, summarize, or research something instead of producing it — use code-overview or research.

日本語の概要は準備中です。原文の説明を表示しています。

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.

日本語の概要は準備中です。原文の説明を表示しています。

Builds a feature specification from scratch with plan-a-feature and publishes it to a user-specified Confluence location, posting the spec as a parent page and each companion artifact (decision log, team findings, technical notes) as a child page beneath it. Use when the user wants a new feature planned, designed, scoped, or specified AND posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not plan to local files only — use plan-a-feature. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features to Confluence — use project-documentation-to-confluence.

日本語の概要は準備中です。原文の説明を表示しています。

Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by hand and the outcomes they should expect. Use when you want to create, draft, generate, or outline a manual test plan, manual QA steps, hands-on verification steps, or an acceptance walkthrough for a feature, change, branch, plan, or PR. When the plan holds more than five tests and at least two natural categories emerge, both the test list and the detail sections are organized under plain-language categories. When nothing in the supplied context can be manually tested, it says so and asks for more context instead of producing a document. Does not analyze code for automated test coverage gaps — use automated-test-planning. Does not write test code — use tdd. Does not review code quality — use code-review. Does not stress-test an existing plan — use iterative-plan-review.

日本語の概要は準備中です。原文の説明を表示しています。

Break a trusted implementation plan (or other provided context) into independently-grabbable, atomic work items, written to a single work-items.md file. Use when the user wants to convert a plan into work items, create implementation tickets or tasks, divide a plan into work units, or break the plan down into grabbable pieces. Do not use when there is no implementation plan yet or the plan is not yet trusted — use plan-implementation to produce the plan or iterative-plan-review to harden it first. Does not sequence work into demoable delivery phases — use plan-a-phased-build for that. Does not write code — use tdd to implement a work item.

日本語の概要は準備中です。原文の説明を表示しています。

Builds a feature implementation plan from an existing feature specification (or equivalent context) through a facilitated team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified. Does not specify what the feature should do — use plan-a-feature first. Does not design the contract for an interface — use design-an-api. Does not refine or stress-test an already-written plan — use iterative-plan-review. Runs its resolution rounds to completion and holds its questions until after they finish; to review each round as it lands, use pairing.

日本語の概要は準備中です。原文の説明を表示しています。

Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation. Produces a feature specification focused on system behaviors, not implementation detail. Does not plan a restructure of code that already exists — use plan-a-change. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features — use project-documentation. Does not design the contract for an interface — use design-an-api. Does not research open-ended options before there is a feature to specify — use research. Does not map the bounded contexts of existing code — use ddd-analysis.

日本語の概要は準備中です。原文の説明を表示しています。

Sharpens and stress-tests an existing plan file through multiple codebase-grounded review passes, editing it in place and recording every finding and iteration in cross-referenced companion files. Use this skill whenever the user wants to iterate on, refine, tighten, or improve a plan. Also use it when the user asks to verify, validate, or confirm feasibility of an approach. Does not implement plan steps, write test plans, review code, or investigate bugs, and does not generate new plans from scratch — use plan-a-feature for a new plan. Runs its review rounds to completion without pausing between them; to review each round as it lands, use pairing.

日本語の概要は準備中です。原文の説明を表示しています。

Reviews and adjusts PRD plans based on research findings. Use after completing research to evaluate story modifications. Triggers on: review plan, adjust stories, update prd based on research.

日本語の概要は準備中です。原文の説明を表示しています。

Codex、Gemini、Claude の3つの AI で Plan ファイルを並列レビュー。実装計画の妥当性、抜け漏れ、リスクを分析する。Plan 作成後に呼び出す。

Deep code review - Elixir idioms, Phoenix patterns, architecture, safety. Launches 3 parallel reviewers + plan-reviewer gate. Use when: review, review this, code review, check this code, review my changes, is this good, what do you think, code smells.

日本語の概要は準備中です。原文の説明を表示しています。

Run the current session as a senior developer (Opus) leading a configurable junior fleet. Decomposes requests into scoped tasks, dispatches junior-developer subagents in parallel, optionally runs an architect plan-review gate before dispatch, autonomously resolves escalations, optionally dispatches a doc-writer second wave after juniors complete, then integrates and gates with /test + /governance. Use when the user says "/dev-team", "run the dev team", "delegate this to the juniors", "act as the senior dev", or wants a task built by a senior-led fleet.

日本語の概要は準備中です。原文の説明を表示しています。

Codex CLIで実装計画レビューの改善ループを回す。実装計画ファイルと要件ファイルを指定し、Codexにレビューさせ、指摘をトリアージして計画を修正し、再レビューする。

Claude Code CLIで実装計画レビューの改善ループを回す。実装計画ファイルと要件ファイルを指定し、Claude Codeにレビューさせ、指摘をトリアージして計画を修正し、再レビューする。

[Planning] Use when you need to auto-review a plan for validity, correctness, and best practices — recursive: review, validate findings with why-review, fix validated findings, full re-review until no findings.

日本語の概要は準備中です。原文の説明を表示しています。

planファイルのレビューを依頼された際に使用。Codex CLIを使ってplanファイル自体の実現可能性・技術的妥当性・抜け漏れをレビューし、指摘をタスクリスト化して収束するまで繰り返します。

実装計画（plan.md / pbi-input.md）に含まれる危険操作・触れてはならないスコープ・人間承認必須条件を検出し、AI 自律実行前のゲートとして機能する