Stress-test a plan and its implementation with repeated and adversarial runs (edge cases, extreme inputs, concurrency, load) before the solution is executed or finalized. Use when a plan or code patch must be proven highly reliable before completion. For idea interviews without execution, use grilling (with records in grill-with-docs).
Installs into .claude/skills of the current project.
Are you the author of Grills?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/majinmagros-grills)
---
name: grills
description: Stress-test a plan and its implementation with repeated and adversarial runs (edge cases, extreme inputs, concurrency, load) before the solution is executed or finalized. Use when a plan or code patch must be proven highly reliable before completion. For idea interviews without execution, use grilling (with records in grill-with-docs).
argument-hint: "<target: plano | codigo | ambos>"
---
# Grills
Prove reliability of a plan and/or its generated code through repeated, adversarial testing before finalizing.
## When to use
Before declaring a solution finished (or executing a plan against real state), when the cost of failure is high: error-prone code paths, concurrency, shared state, I/O, timing, user-facing flows.
## Steps
1. **Inventory the target** — take the plan and/or code being tested. List the "hot spots" where failures live:
- Boundaries and limits (max sizes, ranges, overflow, empty/null inputs)
- Shared state, concurrency, ordering, race conditions
- I/O: network, filesystem, databases, retries, timeouts
- Timing: delays, reentrancy, missed deadlines
- Anything the plan itself flags as risky or assumes will hold
2. **Ask the plan "how would this fail?"** — for each step of the plan, state the precondition it depends on and the failure mode if that precondition is violated. If a step has no testable precondition, name that gap explicitly.
3. **Build the test battery**:
- Repetition: run the same scenario N times (minimum 10; more for flaky-prone code) and record failures per run
- Edge cases: empty/null, minimum/maximum, overflow, unicode, wrong types, malformed input
- Adversarial: concurrent access, interrupted I/O, timeout injection, resource exhaustion (memory, handles, disk)
- Load: volume scaling where applicable (N records, N requests) and confirm behavior degrades predictably, not catastrophically
4. **Execute** — run the battery. Capture per-case results: pass/fail, errors, timeouts, flakiness (same input, different results between runs).
5. **Evaluate against acceptance criteria**:
- Zero failures across all repetitions and cases
- No flakiness: deterministic results across runs
- No unexpected timeouts or resource growth
- No new failure mode surfaced by adversarial cases
6. **Report** — produce a table: case | repetitions | result | error. Classify each failure: fixable in code, design flaw in the plan, or out-of-scope (declared, not hidden).
7. **Loop until proven** — if any failure is fixable or reveals a plan flaw: fix, then re-grill the affected cases until the battery passes. Do not skip back to finalize.
8. **Gate** — only finish when the battery passes. If the environment prevents stress testing something (no harness, external dependency unavailable), say so explicitly and list what remains unproven — never claim "tested" for what wasn't run.
## Acceptance criteria format
```
Target: [plano | codigo | ambos]
Battery: [repetitions | edge | adversarial | load - which were run]
Result: PASS | FAIL
Failures found: [list]
Unproven (declared): [list]
```
## Rules
- NEVER claim reliability from a single run — repetition is the point.
- NEVER hide a failure to reach PASS; a declared limitation beats a silent risk.
- If the target is untestable as written (no way to invoke it), report that as a blocker, not a pass.
