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 a component talks to the backend - go through the typed api client, type every response, and handle loading, success, and error states explicitly
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Every remote call is three states, not one. The recurring defects are raw fetch scattered in components, untyped responses, and errors swallowed into console.log while the UI half-updates.
Core principle: One typed client, three states (loading/success/error), no swallowed errors.
web/src/api.ts helpers — never raw fetch in components.console.log — surface them to the user and keep the UI consistent (no half-updated state on failure).// ✅ typed client call, three states, no half-update on failure
const [state, setState] = useState<Loadable<Task[]>>({ status: "loading" });
useEffect(() => {
let active = true;
api.listTasks(projectId) // typed helper from api.ts
.then(tasks => active && setState({ status: "ok", data: tasks }))
.catch(err => active && setState({ status: "error", message: err.message }));
return () => { active = false; }; // ignore stale response
}, [projectId]);
if (state.status === "loading") return <Spinner />;
if (state.status === "error") return <ErrorView message={state.message} />;
return <TaskList tasks={state.data} />; // success only
The active flag drops a stale response when projectId changes; the error branch shows a real message instead of leaving a spinner or a half-list.
fetch in a component.any response.catch(e => console.log(e)) with the UI left inconsistent.fetch( inside a component file.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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
日本語の概要は準備中です。原文の説明を表示しています。