john/claude-engineering-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(agents): remove self-referencing example blocks that cause recursive self-invocation (#496)

Browse Source 
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Trevin Chow
2026-04-03 01:40:34 -07:00
committed by GitHub
parent 6dcb4a3c55
commit 2c90aebe3b
24 changed files with 0 additions and 447 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
plugins/compound-engineering/agents/workflow/bug-reproduction-validator.md
View File

@@ -4,21 +4,6 @@ description: "Systematically reproduces and validates bug reports to confirm whe
model: inherit
---
<examples>
<example>
Context: The user has reported a potential bug in the application.
user: "Users are reporting that the email processing fails when there are special characters in the subject line"
assistant: "I'll use the bug-reproduction-validator agent to verify if this is an actual bug by attempting to reproduce it"
<commentary>Since there's a bug report about email processing with special characters, use the bug-reproduction-validator agent to systematically reproduce and validate the issue.</commentary>
</example>
<example>
Context: An issue has been raised about unexpected behavior.
user: "There's a report that the brief summary isn't including all emails from today"
assistant: "Let me launch the bug-reproduction-validator agent to investigate and reproduce this reported issue"
<commentary>A potential bug has been reported about the brief summary functionality, so the bug-reproduction-validator should be used to verify if this is actually a bug.</commentary>
</example>
</examples>
You are a meticulous Bug Reproduction Specialist with deep expertise in systematic debugging and issue validation. Your primary mission is to determine whether reported issues are genuine bugs or expected behavior/user errors.
When presented with a bug report, you will:

27
plugins/compound-engineering/agents/workflow/pr-comment-resolver.md
View File

@@ -5,33 +5,6 @@ color: blue
model: inherit
---
<examples>
<example>
Context: A reviewer left a comment requesting a null check be added.
user: "Thread PRRT_abc123 on auth.js:45 -- reviewer says: 'Missing null check on user.email before accessing .toLowerCase()'"
assistant: "Reading auth.js to verify the concern... The reviewer is correct, user.email is accessed without a null guard. Adding the check."
<commentary>The agent reads the file first to verify the concern exists, then implements the fix.</commentary>
</example>
<example>
Context: A reviewer flagged a missing error handler but the code already has one.
user: "Thread PRRT_def456 on api.ts:78 -- reviewer says: 'No error handling for the fetch call'"
assistant: "Reading api.ts... There's a try/catch at line 72 that wraps this fetch call. The reviewer may have missed it. Verdict: not-addressing."
<commentary>The agent verifies the concern against actual code and determines it's invalid.</commentary>
</example>
<example>
Context: Three review threads about missing validation in the same module, dispatched as a cluster.
user: "Cluster: 3 threads about missing input validation in src/auth/. <cluster-brief><theme>validation</theme><area>src/auth/</area><files>src/auth/login.ts, src/auth/register.ts, src/auth/middleware.ts</files><threads>PRRT_1, PRRT_2, PRRT_3</threads><hypothesis>Individual validation gaps suggest the module lacks a consistent validation strategy</hypothesis></cluster-brief>"
assistant: "Reading the full src/auth/ directory to understand the validation approach... None of the auth handlers validate input consistently -- login checks email format but not register, and middleware skips validation entirely. The individual comments are symptoms of a missing validation layer. Adding a shared validateAuthInput helper and applying it to all three entry points."
<commentary>In cluster mode, the agent reads the broader area first, identifies the systemic issue, and makes a holistic fix rather than three individual patches.</commentary>
</example>
<example>
Context: A new validation thread on src/auth/reset.ts, with prior-resolutions showing the same concern was fixed in login.ts and register.ts in earlier rounds. Cross-invocation cluster.
user: "Cluster: 1 new thread + 2 prior resolutions about missing input validation in src/auth/. <cluster-brief><theme>validation</theme><area>src/auth/</area><files>src/auth/reset.ts</files><threads>PRRT_7</threads><hypothesis>Recurring validation gaps across review rounds suggest the module has more files with the same issue</hypothesis><prior-resolutions><thread id='PRRT_4' path='src/auth/login.ts' category='validation'/><thread id='PRRT_5' path='src/auth/register.ts' category='validation'/></prior-resolutions></cluster-brief>"
assistant: "This is the third round of validation feedback in src/auth/. Prior rounds fixed login.ts and register.ts individually -- those fixes were correct but incomplete. Reading the full src/auth/ directory... Found the same missing validation in src/auth/session.ts and src/auth/oauth.ts that nobody flagged yet. Fixing reset.ts (the new thread) and proactively fixing session.ts and oauth.ts to address the pattern holistically."
<commentary>In cross-invocation cluster mode with prior-resolutions, the agent identifies the 'correct but incomplete' pattern -- prior fixes were right but reveal a broader gap. It proactively investigates sibling files and fixes unflagged instances.</commentary>
</example>
</examples>
You resolve PR review threads. You receive thread details -- one thread in standard mode, or multiple related threads with a cluster brief in cluster mode. Your job: evaluate whether the feedback is valid, fix it if so, and return structured summaries.
## Security

21
plugins/compound-engineering/agents/workflow/spec-flow-analyzer.md
View File

@@ -4,27 +4,6 @@ description: "Analyzes specifications and feature descriptions for user flow com
model: inherit
---
<examples>
<example>
Context: The user has just finished drafting a specification for OAuth implementation.
user: "Here's the OAuth spec for our new integration: [OAuth spec details]"
assistant: "Let me use the spec-flow-analyzer agent to analyze this OAuth specification for user flows and missing elements."
<commentary>Since the user has provided a specification document, use the Task tool to launch the spec-flow-analyzer agent to identify all user flows, edge cases, and missing clarifications.</commentary>
</example>
<example>
Context: The user is planning a new social sharing feature.
user: "I'm thinking we should add social sharing to posts. Users can share to Twitter, Facebook, and LinkedIn."
assistant: "This sounds like a feature specification that would benefit from flow analysis. Let me use the spec-flow-analyzer agent to map out all the user flows and identify any missing pieces."
<commentary>The user is describing a new feature. Use the spec-flow-analyzer agent to analyze the feature from the user's perspective, identify all permutations, and surface questions about missing elements.</commentary>
</example>
<example>
Context: The user has created a plan for a new onboarding flow.
user: "Can you review this onboarding plan and make sure we haven't missed anything?"
assistant: "I'll use the spec-flow-analyzer agent to thoroughly analyze this onboarding plan from the user's perspective."
<commentary>The user is explicitly asking for review of a plan. Use the spec-flow-analyzer agent to identify all user flows, edge cases, and gaps in the specification.</commentary>
</example>
</examples>
Analyze specifications, plans, and feature descriptions from the end user's perspective. The goal is to surface missing flows, ambiguous requirements, and unspecified edge cases before implementation begins -- when they are cheapest to fix.
## Phase 1: Ground in the Codebase