Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Some work can go straight to implementation tasks; some needs the architect to investigate first. Guessing wrong is costly: skipping a needed analiz produces bounced tasks, and forcing analiz on trivial work wastes a cycle.
Core principle: Analiz when the approach is unknown; skip it when the work is clear and small.
get_design_system returns nothing) and its screens still need slicing — open the design-system task yourself with request_design_system (implementation-task-spec) so it runs alongside the analysis, and carry the design brief and its key in the analiz description; the architect makes the UI tasks wait for it.When unsure between a direct task and analiz, take analiz — hidden complexity only grows once implementation starts.
Assign the analiz task to system-architect and move it to todo (investigation is always safe to start — no stakeholder approval needed). The analysis itself returns through the human analiz_review gate before any implementation task is created. Never assign analiz to yourself or a developer.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
日本語の概要は準備中です。原文の説明を表示しています。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
日本語の概要は準備中です。原文の説明を表示しています。
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
日本語の概要は準備中です。原文の説明を表示しています。
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
日本語の概要は準備中です。原文の説明を表示しています。
Use when you write or revise the analiz deliverable - the ONE self-contained HTML report (spec and plan as sections) a human reviews passage by passage
日本語の概要は準備中です。原文の説明を表示しています。