ring:testing-skills-with-subagents

AI Community

Repo stars 189
Author repo ring

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: | Run scenarios without the skill (RED — watch agent fail), write skill addressing those failures (GREEN), then close loopholes…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “When to use”, “Skip when”, “Related”, “When to Test”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name ring:testing-skills-with-subagents directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “When to use / Skip when / Related” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Testing Skills With Subagents

When to use

Before deploying a new skill
After editing an existing skill
Skill enforces discipline that could be rationalized away

Skip when

Pure reference skill → no behavior to test
No rules that agents have incentive to bypass

Complementary: ring:writing-skills, ring:test-driven-development

Testing skills is TDD applied to process documentation.

Run scenarios without the skill (RED — watch agent fail), write skill addressing those failures (GREEN), then close loopholes (REFACTOR).

Prerequisite: Understand ring:test-driven-development first. Complete worked example: examples/CLAUDE_MD_TESTING.md.

When to Test

Test skills that: enforce discipline (TDD, testing requirements), have compliance costs (time, effort, rework), could be rationalized away ("just this once"), or contradict immediate goals (speed over quality).

Skip: Pure reference skills (API docs), skills without rules to violate.

TDD Mapping

TDD Phase	Skill Testing	What You Do
RED	Baseline test	Run scenario WITHOUT skill, watch agent fail
Verify RED	Capture rationalizations	Document exact failures verbatim
GREEN	Write skill	Address specific baseline failures
Verify GREEN	Pressure test	Run WITH skill, verify compliance under pressure
REFACTOR	Plug holes	Find new rationalizations, add counters

RED Phase: Watch It Fail

Run 3+ combined-pressure scenarios WITHOUT the skill. Document agent choices and rationalizations word-for-word.

Why verbatim? Exact wording reveals the loopholes to close.

Writing Pressure Scenarios

Quality	Example
Bad	"What does the skill say?" — agent recites
Good	"Production down, $10k/min, 5min window" — single pressure
Great	"3hr/200 lines done, 6pm, dinner plans, forgot TDD. A) Delete B) Commit C) Tests now" — multi-pressure + forced choice

Pressure types: Time (deadline), sunk cost (hours invested), authority (senior says skip), economic (job at stake), exhaustion (end of day), pragmatic ("being realistic").

Best tests combine 3+ pressures.

GREEN Phase: Write Minimal Skill

Address the specific failures documented in RED. Don't add hypothetical content — write just enough to address actual observed failures. Re-run same scenarios WITH skill; agent should now comply.

REFACTOR Phase: Close Loopholes

Agent still violated rule despite having the skill? Capture new rationalizations verbatim:

"This case is different because..."
"I'm following the spirit not the letter"
"Being pragmatic means adapting"

For each rationalization, add: explicit negation rule, rationalization table entry, red flag entry.

Meta-test: "You read the skill and chose wrong anyway. How could the skill have been written to make the right answer the only acceptable one?"

Continue REFACTOR until no new rationalizations appear.

Signs of Bulletproof Skill

Agent chooses correct option under maximum pressure
Agent cites skill sections as justification
Agent acknowledges temptation but follows rule anyway
Meta-test reveals "skill was clear, I should follow it"

Real-World Impact

From applying TDD to TDD skill itself:

6 RED-GREEN-REFACTOR iterations to bulletproof
10+ unique rationalizations discovered
Each REFACTOR closed specific loopholes
Final: 100% compliance under maximum pressure

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @LerianStudio · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview ring-testing-skills-with-subagents.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Testing Skills With Subagents

## When to use
- Before deploying a new skill
- After editing an existing skill
- Skill enforces discipline that could be rationalized away

## Skip when
- Pure reference skill → no behavior to test
- No rules that agents have incentive to bypass

## Related
**Complementary:** ring:writing-skills, ring:test-driven-development

**Testing skills is TDD applied to process documentation.**

Run scenarios without the skill (RED — watch agent fail), write skill addressing those failures (GREEN), then close loopholes (REFACTOR).

**Prerequisite:** Understand `ring:test-driven-development` first. Complete worked example: `examples/CLAUDE_MD_TESTING.md`.

## When to Test

Test skills that: enforce discipline (TDD, testing requirements), have compliance costs (time, effort, rework), could be rationalized away ("just this once"), or contradict immediate goals (speed over quality).

**Skip:** Pure reference skills (API docs), skills without rules to violate.

## TDD Mapping

| TDD Phase | Skill Testing | What You Do |
|-----------|---------------|-------------|
| RED | Baseline test | Run scenario WITHOUT skill, watch agent fail |
| Verify RED | Capture rationalizations | Document exact failures verbatim |
| GREEN | Write skill | Address specific baseline failures |
| Verify GREEN | Pressure test | Run WITH skill, verify compliance under pressure |
| REFACTOR | Plug holes | Find new rationalizations, add counters |

## RED Phase: Watch It Fail

Run 3+ combined-pressure scenarios WITHOUT the skill. Document agent choices and rationalizations **word-for-word**.

**Why verbatim?** Exact wording reveals the loopholes to close.

### Writing Pressure Scenarios

| Quality | Example |
|---------|---------|

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> When to use → Skip when → Related → When to Test → TDD Mapping → RED Phase: Watch It Fail
terms    -> Complementary · Testing skills is TDD applied to process documentation. · Prerequisite · Skip · word-for-word · Why verbatim? · Pressure types · Best tests combine 3+ pressures.
files/cmd -> ring:test-driven-development · examples/CLAUDEMDTESTING.md · 10k/min · 3hr/200
body sha256 -> 805ce08f01cf