Token导航 LogoToken导航

Agent Skill · 研究检索

ring%3atesting-agents-with-subagents(Ring%3 正在测试具有子 Agent 的 Agent)

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

ring%3atesting-agents-with-subagents 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 44,915。

总安装 881周安装 36GitHub Stars 180下载 285核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:ring%3atesting-agents-with-subagents(Ring%3 正在测试具有子 Agent 的 Agent)
来源仓库:https://github.com/lerianstudio/ring
仓库路径:skills/ring%3Atesting-agents-with-subagents
安装命令:
npx skills add https://github.com/lerianstudio/ring --skill ring:testing-agents-with-subagents
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/lerianstudio/ring --skill ring:testing-agents-with-subagents

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于辅助测试设计、自动化测试、用例整理和回归验证。适合编写单元测试、端到端测试或根据失败日志定位问题。使用时需确认项目测试框架、运行命令和夹具数据,避免误改逻辑。涉及浏览器或外部服务时,应区分本地模拟与生产环境。

ring%3atesting-agents-with-subagents 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/ring%3Atesting-agents-with-subagents

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/lerianstudio/ring --skill ring:testing-agents-…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

ring%3atesting-agents-with-subagents 怎么安装?

在终端执行 npx skills add https://github.com/lerianstudio/ring --skill ring:testing-agents-with-subag…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

ring%3atesting-agents-with-subagents 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

ring%3atesting-agents-with-subagents 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

ring%3atesting-agents-with-subagents 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

ring%3atesting-agents-with-subagents 用的人多吗?

公开数据是累计安装 881 次,近一周安装 36 次,下载 285 次,GitHub 180 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

ring%3atesting-agents-with-subagents 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
ring%3atesting-agents-with-subagents

Ring%3 正在测试具有子 Agent 的 Agent · 本页

881180只读未明确未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Testing Agents With Subagents

Overview

Testing agents is TDD applied to AI worker definitions.

You run agents with known test inputs (RED - observe incorrect outputs), fix the agent definition (GREEN - outputs now correct), then handle edge cases (REFACTOR - robust under all conditions).

Core principle: If you didn't run an agent with test inputs and verify its outputs, you don't know if the agent works correctly.

REQUIRED BACKGROUND: You MUST understand ring:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill provides agent-specific test formats (test inputs, output verification, accuracy metrics).

Key difference from testing-skills-with-subagents:

  • Skills = instructions that guide behavior; test if agent follows rules under pressure
  • Agents = separate Claude instances via Task tool; test if they produce correct outputs

The Iron Law

NO AGENT DEPLOYMENT WITHOUT RED-GREEN-REFACTOR TESTING FIRST

About to deploy an agent without completing the test cycle? You have ONLY one option:

STOP. TEST FIRST. THEN DEPLOY.

You CANNOT:

  • ❌ "Deploy and monitor for issues"
  • ❌ "Test with first real usage"
  • ❌ "Quick smoke test is enough"
  • ❌ "Tested manually in Claude UI"
  • ❌ "One test case passed"
  • ❌ "Agent prompt looks correct"
  • ❌ "Based on working template"
  • ❌ "Deploy now, test in parallel"
  • ❌ "Production is down, no time to test"

ZERO exceptions. Simple agent, expert confidence, time pressure, production outage - NONE override testing.

Why this is absolute: Untested agents fail in production. Every time. The question is not IF but WHEN and HOW BADLY. A 20-minute test suite prevents hours of debugging and lost trust.

When to Use

Test agents that:

  • Analyze code/designs and produce findings (reviewers)
  • Generate structured outputs (planners, analyzers)
  • Make decisions or categorizations (severity, priority)
  • Have defined output schemas that must be followed
  • Are used in parallel workflows where consistency matters

Test exemptions require explicit human partner approval:

  • Simple pass-through agents (just reformatting) - only if human partner confirms
  • Agents without structured outputs - only if human partner confirms
  • You CANNOT self-determine test exemption
  • When in doubt → TEST

TDD Mapping for Agent Testing

TDD PhaseAgent TestingWhat You Do
REDRun with test inputsDispatch agent, observe incorrect/incomplete outputs
Verify REDDocument failuresCapture exact output issues verbatim
GREENFix agent definitionUpdate prompt/schema to address failures
Verify GREENRe-run testsAgent now produces correct outputs
REFACTORTest edge casesAmbiguous inputs, empty inputs, complex scenarios
Stay GREENRe-verify allPrevious tests still pass after changes

Same cycle as code TDD, different test format.

RED Phase: Baseline Testing (Observe Failures)

Goal: Run agent with known test inputs - observe what's wrong, document exact failures.

This is identical to TDD's "write failing test first" - you MUST see what the agent actually produces before fixing the definition.

Process:

  • Create test inputs (known issues, edge cases, clean inputs)
  • Run agent - dispatch via Task tool with test inputs
  • Compare outputs - expected vs actual
  • Document failures - missing findings, wrong severity, bad format
  • Identify patterns - which input types cause failures?

Test Input Categories

CategoryPurposeExample
Known IssuesVerify agent finds real problemsCode with SQL injection, hardcoded secrets
Clean InputsVerify no false positivesWell-written code with no issues
Edge CasesVerify robustnessEmpty files, huge files, unusual patterns
Ambiguous CasesVerify judgmentCode that could go either way
Severity CalibrationVerify severity accuracyMix of critical, high, medium, low issues

Minimum Test Suite Requirements

Before deploying ANY agent, you MUST have:

Agent TypeMinimum Test CasesRequired Coverage
Reviewer agents6 tests2 known issues, 2 clean, 1 edge case, 1 ambiguous
Analyzer agents5 tests2 typical, 1 empty, 1 large, 1 malformed
Decision agents4 tests2 clear cases, 2 boundary cases
Planning agents5 tests2 standard, 1 complex, 1 minimal, 1 edge case

Fewer tests = incomplete testing = DO NOT DEPLOY.

One test case proves nothing. Three tests are suspicious. Six tests are minimum for confidence.

Example Test Suite for Code Reviewer

TestInputExpected
SQL InjectionString concatenation in SQLCRITICAL, OWASP A03:2021
Clean AuthProper JWT validationNo findings or LOW only
Ambiguous ErrorCaught but only loggedMEDIUM silent failure
Empty FileEmpty sourceGraceful handling

Running the Test

Dispatch via Task tool with test input → Document exact output verbatim (don't summarize).

GREEN Phase: Fix Agent Definition (Make Tests Pass)

Write/update agent definition addressing specific failures documented in RED phase.

Common fixes:

Failure TypeFix Approach
Missing findingsAdd explicit instructions to check for X
Wrong severityAdd severity calibration examples
Bad output formatAdd output schema with examples
False positivesAdd "don't flag X when Y" instructions
Incomplete analysisAdd "always check A, B, C" checklist

Example Fix: Severity Calibration

RED Failure: Agent marked hardcoded password as MEDIUM instead of CRITICAL

GREEN Fix: Add severity calibration: CRITICAL (hardcoded secrets, SQL injection, auth bypass), HIGH (missing validation, error exposure), MEDIUM (verbose errors, missing security headers), LOW (headers, deps)

Re-run Tests

After fixing, re-run ALL test cases. If any fail → continue fixing, re-test.

VERIFY GREEN: Output Verification

Goal: Confirm agent produces correct, well-structured outputs consistently.

Accuracy Metrics

MetricTarget
True Positives100%
False Positives<10%
False Negatives<5%
Severity Accuracy>90%
Schema Compliance100%

Consistency Testing

Run same input 3 times → outputs should be identical. Inconsistency indicates ambiguous agent definition.

REFACTOR Phase: Edge Cases and Robustness

Agent passes basic tests? Now test edge cases.

Edge Case Categories

CategoryTest Cases
Empty/NullEmpty file, null input, whitespace only
Large10K line file, deeply nested code
UnusualMinified code, generated code, config files
Multi-languageMixed JS/TS, embedded SQL, templates
AmbiguousCode that could be good or bad depending on context

Stress Testing

Test edge cases: Large file (5000 lines, 20 issues), Complex nesting (15-level deep). Verify all issues found with reasonable response time.

Ambiguity Testing

Test context-dependent cases (e.g., hardcoded password with "local dev" comment). Agent should flag but acknowledge context.

Plugging Holes

For each edge case failure, add explicit handling to agent definition:

  • Empty files: Return "No code to review" with PASS
  • Large files: Focus on high-risk patterns first
  • Minified code: Note limitations
  • Context comments: Consider but don't use to dismiss issues

Testing Parallel Agent Workflows

When agents run in parallel (like 5 reviewers), test combined workflow:

  • Parallel Consistency: Same input to all reviewers → check findings overlap appropriately, no contradictions
  • Aggregation Testing: Same issue found by multiple reviewers → severity should be consistent; fix misalignments

Agent Testing Checklist

RED Phase: Create test inputs (known issues, clean, edge cases) → Run agent → Document failures verbatim

GREEN Phase: Update agent definition → Re-run tests → All pass

REFACTOR Phase: Test edge cases → Test stress scenarios → Add explicit handling → Verify consistency (3+ runs) → Test parallel integration (if applicable) → Re-run ALL tests after each change

Metrics (reviewer agents): True positive >95%, False positive <10%, False negative <5%, Severity accuracy >90%, Schema compliance 100%, Consistency >95%

Prohibited Testing Shortcuts

You CANNOT substitute proper testing with:

ShortcutWhy It Fails
Reading agent definition carefullyReading ≠ executing. Must run agent with inputs.
Manual testing in Claude UIAd-hoc ≠ reproducible. No baseline documented.
"Looks good to me" reviewVisual inspection misses runtime failures.
Basing on proven templateTemplates need validation for YOUR use case.
Expert prompt engineering knowledgeExpertise doesn't prevent bugs. Tests do.
Testing after first production useProduction is not QA. Test before deployment.
Monitoring production for issuesReactive ≠ proactive. Catch issues before users do.
Deploy now, test in parallelParallel testing still means untested code in production.

ALL require running agent with documented test inputs and comparing outputs.

Testing Agent Modifications

EVERY agent edit requires re-running the FULL test suite:

Change TypeRequired Action
Prompt wording changesFull re-test
Severity calibration updatesFull re-test
Output schema modificationsFull re-test
Adding edge case handlingFull re-test
"Small" one-line changesFull re-test
Typo fixes in promptFull re-test

"Small change" is not an exception. One-line prompt changes can completely alter LLM behavior. Re-test always.

Common Mistakes

MistakeFix
Testing only "happy path" inputsInclude ambiguous + edge cases
Not documenting exact outputsCapture verbatim, compare to expected
Fixing without re-running all testsRe-run entire suite after each change
Testing single agent in isolation (parallel workflow)Test parallel dispatch + aggregation
Not testing consistencyRun same input 3+ times
Skipping severity calibrationAdd explicit severity examples
Not testing edge casesTest empty, large, unusual, ambiguous
Single test case validationMinimum 4-6 test cases per agent type
Manual UI testing as substituteDocument all test inputs and expected outputs
Skipping re-test for "small" changesRe-run full suite after ANY modification

Rationalization Table

ExcuseReality
"Agent prompt is obviously correct"Obvious prompts fail in practice. Test proves correctness.
"Tested manually in Claude UI"Ad-hoc ≠ reproducible. No baseline documented.
"One test case passed"Sample size = 1 proves nothing. Need 4-6 cases minimum.
"Will test after first production use"Production is not QA. Test before deployment. Always.
"Reading prompt is sufficient review"Reading ≠ executing. Must run agent with inputs.
"Changes are small, re-test unnecessary"Small changes cause big failures. Re-run full suite.
"Based agent on proven template"Templates need validation for your use case. Test anyway.
"Expert in prompt engineering"Expertise doesn't prevent bugs. Tests do.
"Production is down, no time to test"Deploying untested fix may make outage worse. Test first.
"Deploy now, test in parallel"Untested code in production = unknown behavior. Unacceptable.
"Quick smoke test is enough"Smoke test misses edge cases. Full suite required.
"Simple pass-through agent"You cannot self-determine exemptions. Get human approval.

Red Flags - STOP and Test Now

If you catch yourself thinking ANY of these, STOP. You're about to violate the Iron Law:

  • Agent edited but tests not re-run
  • "Looks good" without execution
  • Single test case only
  • No documented baseline
  • No edge case testing
  • Manual verification only
  • "Will test in production"
  • "Based on template, should work"
  • "Just a small prompt change"
  • "No time to test properly"
  • "One quick test is enough"
  • "Agent is simple, obviously works"
  • "Expert intuition says it's fine"
  • "Production is down, skip testing"
  • "Deploy now, test in parallel"

All of these mean: STOP. Run full RED-GREEN-REFACTOR cycle NOW.

Quick Reference (TDD Cycle for Agents)

TDD PhaseAgent TestingSuccess Criteria
REDRun with test inputsDocument exact output failures
Verify REDCapture verbatimHave specific issues to fix
GREENFix agent definitionAll basic tests pass
Verify GREENRe-run all testsNo regressions
REFACTORTest edge casesRobust under all conditions
Stay GREENFull test suiteAll tests pass, metrics met

Example: Testing a New Reviewer Agent

Step 1: Create Test Suite

TestInputExpected
SQL Injection"SELECT * FROM users WHERE id = " + user_idCRITICAL, OWASP A03:2021
Parameterized (Clean)db.execute(query, [user_id])No findings
Hardcoded SecretAPI_KEY = "sk-1234..."CRITICAL
Env Variable (Clean)os.environ.get("API_KEY")No findings
Empty File(empty)Graceful handling
Ambiguouspassword = "dev123" # Local devFlag with context

Step 2: RED Phase - Run tests, document failures: Test 1 marked HIGH not CRITICAL, Test 3 missed, Test 5 errored, Test 6 dismissed.

Step 3: GREEN Phase - Fix definition: Add severity calibration (SQL=CRITICAL), hardcoded secrets pattern, empty file handling, "context comments dont dismiss issues".

Step 4: Re-run - All tests pass with correct severities and handling.

Step 5: REFACTOR - Add edge cases: minified code, 10K line file, mixed languages, nested vulnerabilities. Run, fix, repeat.

The Bottom Line

Agent testing IS TDD. Same principles, same cycle, same benefits.

If you wouldn't deploy code without tests, don't deploy agents without testing them.

RED-GREEN-REFACTOR for agents works exactly like RED-GREEN-REFACTOR for code:

  1. RED: See what's wrong (run with test inputs)
  2. GREEN: Fix it (update agent definition)
  3. REFACTOR: Make it robust (edge cases, consistency)

Evidence before deployment. Always.


Blocker Criteria

STOP and report if:

Decision TypeBlocker ConditionRequired Action
No test inputsCannot create meaningful test cases for agentSTOP and define expected inputs/outputs before testing
Agent unreachableCannot dispatch agent via Task toolSTOP and fix agent accessibility first
Inconsistent outputsSame input produces different outputs across runsSTOP and fix agent definition ambiguity
Below metrics thresholdAgent fails accuracy metrics after multiple fixesSTOP and report for human partner review

Cannot Be Overridden

The following requirements CANNOT be waived:

  • MUST run agent with documented test inputs before deployment
  • MUST complete minimum test suite (4-6 cases per agent type)
  • MUST re-run FULL test suite after ANY agent modification
  • MUST NOT substitute manual UI testing for documented test runs
  • MUST NOT deploy agent that fails accuracy metrics

Severity Calibration

SeverityConditionRequired Action
CRITICALAgent deployed without any testingMUST halt deployment, run full test suite immediately
HIGHAgent modified but not re-testedMUST re-run full test suite before any further use
MEDIUMAgent tested but edge cases missingMUST add edge case tests before production use
LOWAgent passes but consistency below 95%Should investigate and fix definition ambiguity

Pressure Resistance

User SaysYour Response
"Deploy now, we'll test in production""CANNOT deploy untested agent. Production is not QA. Will complete test suite first."
"One test case passed, ship it""MUST have minimum 4-6 test cases. One case proves nothing about agent behavior."
"I reviewed the prompt carefully, it's fine""CANNOT substitute prompt review for execution. Must run agent with test inputs."
"Small change, no need to re-test everything""MUST re-run full test suite after ANY change. Small prompt changes can alter behavior completely."

Anti-Rationalization Table

RationalizationWhy It's WRONGRequired Action
"Agent prompt is obviously correct"Obvious prompts fail in practice. Execution proves correctness, not reading.MUST run with test inputs
"Tested manually in Claude UI"Manual testing is ad-hoc with no documented baseline. Not reproducible.MUST document inputs and expected outputs
"Based on a proven template"Templates need validation for YOUR use case. Context changes behavior.MUST test even template-based agents
"Expert in prompt engineering"Expertise doesn't prevent bugs. Only tests catch runtime failures.MUST test regardless of expertise
"Change was tiny, re-test is overkill"Tiny changes cause big behavior shifts in LLMs. One word can change everything.MUST re-run full suite after any change

平台分布

Codex

35.63%
按下载量换算102

Claude

31.44%
按下载量换算90

Cursor

16.94%
按下载量换算48

Gemini CLI

9.85%
按下载量换算28

安全审计

暂无安全审计结果可展示。

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills