Adversarial feature challenge

If the current repo has a specific challenge skill, it wins.

This skill vs. others

• This skill when: the feature is announced "done", golden path green, and you want to know what breaks before closing the ticket / shipping
• validating-features-end-to-end instead if: you first need to prove the intended behavior works (proof before verdict). Validate first, challenge afterward
• writing-robust-tests if: the goal is to harden coverage, not to hunt flaws by hand

Principle

• You try to break, not to validate. 0 bugs found = a bad challenge, not a perfect feature - start over with another persona
• Proof mandatory: every flaw = a documented reproduction (steps + curl/SQL/screenshot output), no offhand claims
• The natural reflex covers backend security and edge cases well; the systematically forgotten angles are UX, accessibility and non-technical personas - hence the checklist

Context to gather (before acting)

• The ticket/spec: what is the expected behavior and the business limits (thresholds, quotas, roles) to attack
• How to start the app and call the API (project dev commands) - a challenge without a running app proves nothing
• Multi-tenant / authorization model: 2 accounts from 2 tenants to test cross-tenant leaks
• Real surface: endpoints, forms, async jobs touched by the feature

Protocol

1. Pick a persona (table below) and attack the feature from its point of view - don't validate, break
2. Walk the layers: go through every block of the checklist, inject assets/fuzz-payloads.txt into the inputs
3. Document each flaw in the challenge report: repro steps + output (curl/SQL/screenshot) + severity. The report is a file in the audited repository - CHALLENGE-REPORT.md at the root unless the project has a place for it - started by copying templates/challenge-report.md out of the skill directory, which is read-only and is not the deliverable
4. Switch persona and start over - 0 bugs = insufficient challenge, not a perfect feature. Stopping after one persona is not a challenge: the first persona finds what you already suspected, the second finds what you did not. Name each persona explicitly in the report as you go, so the count is visible.
5. Verdict + tickets: one ticket per confirmed flaw, rule blocking / improvement / green-light

Traps & rationalizations

Tooling

• templates/challenge-report.md - full checklist to tick + flaws table + verdict. A model to copy into the audited repository and fill in there; never edited in place
• assets/fuzz-payloads.txt - ready-to-inject payloads (SQLi, XSS, Unicode, numeric bounds, dates, tricky emails)

Checklist by layer

UX & interactions: double-click submit (idempotence), back/reload mid-flow, close while saving, buttons disabled during loading, empty state (0 items), saturated state (10k+), zoom 200%/50%, mobile (touch targets)

Inputs: empty/null, edge whitespace, Unicode (emoji, RTL), 10,000+ char string, SQL/XSS injection, path traversal, numbers (0, negative, MAX, NaN), extreme dates, IDs (other tenant, nonexistent, malformed)

Auth & multi-tenant: session expired mid-action, another tenant's token → strict 403/404, shared URL cross-tenant → 404 not 200, role downgrade mid-session, CSRF on destructive actions

Concurrency: 2 users editing the same object, deletion during edit, business invariants under simultaneous requests

Network & state: connection drop during submit (retry? idempotence?), high latency, API 500 → degraded UX, 200 payload but empty/malformed

Data: deletion of a referenced entity (cascade/orphans), modification during a long async process, threshold/quota bounds

Accessibility: 100% keyboard navigation, visible focus, labels on icon buttons, contrast, screen reader

Observability: logs on each key action (no PII), metrics, is the error visible in a dashboard?

Personas to walk through

Exit condition

• At least 2 personas walked through (one of them non-technical) - no feature is OK without ≥ 1 challenge round
• Each checklist layer walked or explicitly waived (justified out-of-scope)
• Each flaw = archived repro (steps + output) + severity, in the challenge report written into the audited repository
• One ticket opened per confirmed flaw
• Verdict set: blocking / improvement required / green-light