Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use after the targeted cases pass - choosing the adjacent behaviour this change can break from the PR's files and the component's links, and the per-repository smoke set
インストールする前に、エージェントに与えられる指示の中身を確認できます。
After the targeted scenarios pass, run a quick regression sweep of adjacent behaviour. Choose what to sweep from:
list_links — who else calls this component; a change to a shared API or schema can break every caller.Keep it in project memory (search_memory "regression smoke") so it accumulates across rounds instead of being reinvented each time: app boots, login works, primary navigation works, the main create/read flow works, the landing page renders with no console errors (Lighthouse errors-in-console or a manual console check). When a regression escapes to UAT, extend the set with save_memory so the next round catches it.
One screenshot at 360 and 1440 of the one or two most-used unchanged screens that share the changed component or design tokens — a token/layout change can break a screen nobody touched in this task.
Record swept cases as category: regression.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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 deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
日本語の概要は準備中です。原文の説明を表示しています。