Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.
日本語の概要は準備中です。原文の説明を表示しています。
Use immediately after RBR confirms a root cause and a fix is scoped, before considering the finding complete. Checks whether the confirmed defect is one instance of a structurally identical pattern elsewhere in the same file family, workflow, or business-domain area, and folds in or explicitly defers every other instance found. Mandatory for Architect and CAO — not an optional lens the agent judges when to apply.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
A confirmed root cause describes one instance of a defect. It rarely describes the defect's full blast radius. This skill is the mandatory step between "I found and fixed the reported case" and "I am done" — spend one deliberate pass checking whether the same shape of gap exists anywhere else structurally similar, before closing the finding.
This skill is domain-agnostic. It applies identically to a code defect found by Architect during ticket scoping and to a commercial gap found by CAO during offer or campaign synthesis — nothing here references a specific project, stack, or business domain.
assumptions-audit already exists for pre-flight scope review, and it is explicitly optional —
Architect judges when a plan's ambiguity warrants it. This skill is different in kind: it fires
after a defect is already confirmed via RBR, not before a plan is finalized, and it is not
optional. The reasoning: an optional step only fires when the agent remembers to reach for it —
which is precisely when it is not needed, because the moment a root cause is confirmed is also
the moment attention is narrowest (fixed on the one reported case) and momentum is highest (toward
closing the finding, not widening it). Making the sweep mandatory removes the dependency on
remembering.
A concrete incident that produced this skill: an agent confirmed one real gap in a file and fixed it. The same investigation separately found that a second location in that same file had the identical gap, and fixed that too. But a third instance of the exact same shape existed in a different file entirely, and it was never checked, because the investigation stopped once two instances were found in the original file rather than asking "where else does this shape of gap live?" It only surfaced because someone else asked a pointed question after the fact. A mandatory sweep at the time of the original finding would have caught it without needing that prompt.
This is an always-on discipline, not a task-triggered lens — it is not listed in either agent's
conditional skills table; it is a mandatory step baked into RBR's own sequence (see
agent-foundations/SKILL.md's Root Before Repair section, which cross-references this skill).
State the defect one level of abstraction above the specific case. Not "the checkout retry prompt has no memory of a prior decision" but "a re-entrant prompt/decision point has no memory of its own prior resolution." Not "this lead's follow-up email ignores their stated timeline" but "a customer-stated constraint was gathered but never referenced in the next artifact produced for them." If the general shape can't be stated in one sentence without naming the specific file, lead, or case, it hasn't been abstracted enough yet.
Identify the smallest scope that plausibly contains other instances of the same general shape — not the whole codebase or the whole client list by default, but the natural unit the original instance belongs to:
Widen the family only if the first pass finds nothing and the general shape (step 1) is broad enough that a wider search is still cheap relative to the risk of missing a real instance.
Grep, read, or review every member of the family — not a sample, not "the ones that come to mind."
For code, this is almost always a literal grep/Glob pass against the general shape's
distinguishing signal (a function name, a prompt string pattern, an absent parameter). For
business work, this is reading the other open offers/campaigns/leads directly, not recalling them
from memory.
In the ticket, PR, memory entry, or report where the finding is recorded, say explicitly what was swept and what was found: "Swept every file in the same plugin family for the same re-entrant-prompt-with-no-memory shape — found and fixed one additional instance" or "Swept open campaigns of this type for the same pricing-tier ambiguity — none found." A sweep that isn't stated is indistinguishable, to anyone reviewing later, from a sweep that never happened.
assumptions-audit — that interrogates a single finished plan for what it silently
assumes, before handoff. This sweeps a confirmed defect's blast radius across a family of
similar cases, after root-causing, and is mandatory rather than judged case-by-case.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.
日本語の概要は準備中です。原文の説明を表示しています。
Use when: architecture mode, architect this, ADR, C4, PlantUML, system boundary, design decision, PRD gap, high ambiguity, multiple technical approaches, security architecture, data architecture, integration risk, implementability gap, story ticket, or epic ticket.
日本語の概要は準備中です。原文の説明を表示しています。
Use when: assumptions audit, audit assumptions, check for hidden assumptions, plan/ticket has ambiguous scope edges, pre-flight before finalizing a ticket, unstated assumptions, or 'what am I assuming'. Surfaces unstated assumptions, ambiguous scope edges, and untested preconditions in a finished plan/ticket/ADR before it is handed to Builder. Optional pass — Architect judges when to apply it; not a mandatory gate on every ticket.
日本語の概要は準備中です。原文の説明を表示しています。
Use when: Tester needs UI state evidence for VBR, or Builder needs to verify an integration wire is observable end-to-end. Powered by agent-browser MCP — token-efficient browser automation (200–400 tokens/page).
日本語の概要は準備中です。原文の説明を表示しています。
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
日本語の概要は準備中です。原文の説明を表示しています。
Writing skill for freelancers and independent consultants. Covers project proposals, bids, client emails, and scope summaries. Leads with the client's problem, not the consultant's background.
日本語の概要は準備中です。原文の説明を表示しています。