本文へ移動
cccskills
無料GitHub で公開

pattern-sweep

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.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Pattern Sweep

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.

Why this is mandatory, not optional

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.

When to load

  • Architect: immediately after RBR's step 3 ("STATE the confirmed root cause with evidence"), before step 4 ("propose the fix") — the sweep's findings should shape the fix's actual scope, not arrive after the ticket is already filed.
  • CAO: immediately after confirming a gap or ambiguity in an offer, campaign, lead-triage rule, or call-prep pattern, before treating that single case as resolved.

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).

Method

1. Strip the instance down to its general shape

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.

2. Define the family to search

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:

  • Code: the same file, the same file's sibling files (same naming convention, same shared function signature, same plugin-loader family), or every caller of a shared helper.
  • Business/commercial: every open offer or campaign of the same type, every lead in the same triage bucket, every call-prep brief using the same template.

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.

3. Actually search it

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.

4. For every additional instance found: fold in or defer explicitly, never drop silently

  • Fold in now when the fix is the same shape and the additional cost is small — this is the default when the ticket or task is still open.
  • Defer explicitly when folding in would meaningfully change the scope or risk of the current work — state the deferred instance, why it's deferred, and where it's tracked (a new ticket, a flagged line in the current one, a note to the founder) so it cannot be silently lost.
  • Never report a finding as complete while silently having found — but not mentioned — another instance of the same shape.

5. State the sweep happened

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.

Non-goals

  • This is not a license to redesign or refactor the family you searched — fixing the found instances of the same defect shape, not unrelated issues noticed along the way.
  • This is not 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.
  • Do not let the sweep become the reason a fix ships late. If the family is large and the sweep itself would take meaningfully longer than the original fix, timebox it, state what was and wasn't covered, and say so explicitly rather than silently truncating the search.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.

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

Agistra/agistra.dev52026年10月7日 更新

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.

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

Agistra/agistra.dev52026年10月7日 更新

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.

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

Agistra/agistra.dev52026年10月7日 更新

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).

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

Agistra/agistra.dev52026年10月7日 更新

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.

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

Agistra/agistra.dev52026年10月7日 更新

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.

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

Agistra/agistra.dev52026年10月7日 更新

Agistra のスキルをすべて見る

このスキルの問題を報告する