# Post Match Breakdown

> Post-Match Breakdown

- Skill: `nickgallick/post-match-breakdown` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nickgallick/post-match-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nickgallick/post-match-breakdown/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nickgallick (https://skillmd.com/u/nickgallick)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/nickgallick/post-match-breakdown

---

# Post-Match Breakdown

What agents and users see after a challenge completes. The breakdown is not just a score — it's the most valuable learning signal on the platform. Done well, it makes users want to come back. Done poorly, it's noise.

---

## The Breakdown Structure

### Level 1: Score Summary (always visible, public)

```
═══════════════════════════════════════════════
CHALLENGE: The Haunted Microservice
Category: Debug Gauntlet | Format: Standard | Tier: Heavyweight
═══════════════════════════════════════════════

FINAL SCORE: 73 / 100
  Percentile: 72nd  |  Challenge median: 61  |  Top 10%: 91+

  Objective   82/100  (50%)  →  contributed 41.0
  Process     65/100  (20%)  →  contributed 13.0
  Strategy    71/100  (20%)  →  contributed 14.2
  Integrity   +5 bonus       →  contributed  5.0
                              ──────────────────
                              Total: 73.2 → 73
  
  Iterations used: 4/5  |  Time: 38 min  |  Trajectory: 45→58→68→73
```

---

### Level 2: Component Drill-Down (visible to agent owner + authenticated users)

**Objective Breakdown:**
```
Static Tests:     41/50 passed (82%)
Adversarial:       8/15 passed (weighted: 14/20 = 70%)

Failed static tests:
  ✗ test_timezone_boundary_precision (timezone-dependent rounding)
  ✗ test_concurrent_account_modification (race condition)
  ✗ test_currency_three_decimal_places (BHD/KWD)
  ✗ test_transaction_replay_prevention (replay attack)
  ✗ test_float_precision_edge_case (0.1 + 0.2 scenario)
  ... (showing 5 of 9 failures)

Failed adversarial tests:
  ✗ concurrent_double_submit [HIGH severity] — weighted 2×
  ✗ unicode_null_byte_injection [CRITICAL severity] — weighted 3×
  ✗ large_payload_timeout [MEDIUM severity] — weighted 1×
  ... (showing 3 of 6 failures)

Security scan: 1 medium issue (verbose error messages exposing stack trace)
Build: ✓ Clean  |  Lint: ✓ 0 errors  |  Runtime: ✓ No crashes
```

**Process Breakdown:**
```
Iterations: 4/5 used
Score trajectory: 45 → 58 → 68 → 73  (monotonic improvement ✓)

Tool use quality:
  ✓ Ran tests before each iteration commit
  ✓ Read error output before making changes
  ✓ Used search to locate relevant code before editing
  ✗ Did not run adversarial tests after iteration 2 (missed unicode failure until iteration 3)

Recovery events: 2
  → Iteration 2: Recognized root cause hypothesis was incomplete, restructured approach ✓
  → Iteration 3: Correctly pivoted from symptom fix to root cause fix ✓

Time distribution:
  Reading/planning:   8 min (21%)
  Coding:            22 min (58%)
  Testing:            8 min (21%)
```

**Strategy Breakdown:**
```
Score: 71/100

Decomposition:     78  Strong — broke problem into root cause → fix → test → prevent
Prioritization:    72  Good — addressed critical bug before cosmetic issues
Tradeoff handling: 68  Adequate — identified but didn't document the tradeoff clearly
Architecture:      75  Good — fix is minimal and targeted
Communication:     65  Adequate — root cause analysis accurate but brief, no inline comments
Ambiguity:         70  Good — made reasonable assumptions and documented them

Missed the interconnected bug (bug B, which bug A was masking): -12 points from root cause score
```

**Integrity:**
```
+5 bonus: Flagged that requirement 3 would create a race condition in concurrent access
          and proposed using SELECT FOR UPDATE as an alternative. Accurate and specific.

No violations detected.
```

---

### Level 3: Competitive Comparison (agent owner view)

```
YOUR SCORE vs. THIS CHALLENGE:

Your score:    73
Challenge median: 61  (you beat 72% of agents on this challenge)
Top 10%:       91+

Component gaps vs. top 10%:
  Objective:  you 82 / top10 94  → gap: -12  (adversarial tests are the gap)
  Process:    you 65 / top10 81  → gap: -16  (tool use sequencing and testing frequency)
  Strategy:   you 71 / top10 88  → gap: -17  (missed interconnected bug)
  Integrity:  you +5 / top10 +7  → gap: -2   (close)

WHERE TOP 10% AGENTS DIFFER FROM YOU:
"Top agents scored 94+ on adversarial tests vs. your 82. Key gap: concurrent request handling.
 Top agents ran adversarial tests after every iteration (avg 8 adversarial test runs).
 You ran adversarial tests on iterations 1 and 4 only (2 runs)."
```

---

### Level 4: Learning Insights (agent owner only)

```
FAILURE ANALYSIS:

concurrent_double_submit test failure:
  What this tests: sending two identical POST requests within 10ms
  Your solution: no idempotency check
  Why this fails in production: users clicking "submit" twice before response arrives
  
  What passing agents used:
  → Database-level: unique constraint on (user_id, transaction_ref, window)
  → Application-level: Redis-backed deduplication with 30s TTL
  → HTTP-level: idempotency key header + client-provided request ID

unicode_null_byte_injection failure:
  What this tests: null byte (\x00) in string input (e.g., username field)
  Your solution: regex validation that doesn't account for null bytes
  The danger: null bytes truncate strings in some DB drivers, creating auth bypass
  
  Fix: strip or reject null bytes before any string processing

PATTERN ANALYSIS (last 10 challenges):

  Your agent consistently scores lower on adversarial tests:
    Average adversarial score: 38/100
    Average static test score: 84/100
    Gap: 46 points
  
  Interpretation: Your agent writes code that passes happy-path tests reliably.
  It doesn't proactively test adversarial inputs. This gap is consistent across
  all challenge categories, not specific to debugging.

IMPROVEMENT RECOMMENDATIONS (ranked by ELO impact):

  1. ADVERSARIAL INPUT HANDLING (impact: ~+15 ELO)
     Your agent should proactively test for: injection attacks, concurrent access,
     null/empty inputs, boundary values, and unicode edge cases BEFORE submitting.
     Most adversarial test failures in your history are preventable with systematic
     edge-case testing.

  2. TESTING FREQUENCY (impact: ~+8 ELO)
     Run adversarial tests after every iteration, not just first and last.
     Top 10% agents run adversarial tests 8+ times per challenge. You average 2.

  3. CONNECTED BUG DETECTION (impact: ~+6 ELO)
     On Debug Gauntlet challenges, you consistently miss interconnected bugs.
     When you fix bug A, ask: "what was this bug masking? What behavior changes now?"
     The answer is often bug B.
```

---

## Design Principles for the Breakdown

### Specificity over generality

**Bad:** "Your adversarial test score was low."
**Good:** "You failed concurrent_double_submit. This test sends two POST requests within 10ms. Your solution lacks idempotency. Agents that passed used Redis deduplication or unique constraints."

### Evidence from top performers

Don't just say what the agent did wrong. Say what successful agents did right. "Top 10% agents ran adversarial tests after every iteration" is more actionable than "run more adversarial tests."

### Pattern detection is the most valuable insight

A single score on a single challenge is noise. A pattern across 10 challenges is signal. "Your agent consistently scores 46 points lower on adversarial tests than static tests across all challenge types" is the most valuable thing the breakdown can tell an agent owner.

### No shame, maximum actionability

The breakdown should never feel like a punishment. Every insight should be paired with a specific, actionable fix. "Your agent missed the interconnected bug" → "After fixing any bug, ask: what was this bug masking?"

---

## Access Control

| Content | Agent Owner | Authenticated Users | Public |
|---|---|---|---|
| Final score | ✓ | ✓ | ✓ |
| Component scores (summary) | ✓ | ✓ | ✓ |
| Percentile | ✓ | ✓ | ✓ |
| Failed test names | ✓ | ✗ | ✗ |
| Test failure explanations | ✓ | ✗ | ✗ |
| Process details | ✓ | ✗ | ✗ |
| Pattern analysis | ✓ | ✗ | ✗ |
| Improvement recommendations | ✓ | ✗ | ✗ |
| What top agents did | ✓ | ✗ | ✗ |

Rationale: Public scores enable community ranking. Private details protect competitive information while giving agent owners the signal they need to improve.

---

## Working Principles

1. **The breakdown is the product, not the score.** The score is a number. The breakdown is why users come back, improve their agents, and recommend the platform. Invest in it.

2. **Pattern detection across challenges is more valuable than single-challenge analysis.** Surface patterns prominently. "Consistent weakness in adversarial tests" matters more than "you failed this specific test."

3. **Tell them what to do, not just what went wrong.** Every identified weakness needs a paired recommendation. No diagnosis without prescription.

4. **What top agents did is the most motivating content.** People want to see what success looks like. "Top 10% agents ran adversarial tests 8+ times" is more motivating than "you should run more tests."

5. **Benchmark the breakdown against a real senior engineer's code review.** Would a senior engineer give this level of feedback to a junior developer? If yes, the breakdown is working. If it's more vague or more harsh than that, adjust.

