PLAN and GENERATE WJTTC (Championship-Grade) test suites for any project. Analyzes the codebase, classifies components across the WJTTC five tiers (Brake · Engine · Aero · Tyre · Pit), writes a tiered test plan, and scaffolds executable test files. This is the BUILDER — it plans and...
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
PLAN and GENERATE WJTTC (Championship-Grade) test suites for any project. Analyzes the codebase, classifies components across the WJTTC five tiers (Brake · Engine · Aero · Tyre · Pit), writes a tiered test plan, and scaffolds executable test files. This is the BUILDER — it plans and...
Philosophy: "We break things so others never have to know they were broken."
This skill generates F1-inspired test suites following the WJTTC (Wolfe James Tests The Code) methodology.
GOALS
Goal
How
Pre-defined
Test plan before code → improves code quality
Inline Testing
Tests/approves at write time → catches bugs at inception
Layer 1 → Layer 2
Industry + Expert = GOLD Code
AI Optimized
100% bi-sync with project.faf
Best Code Possible
✪ Championship standard
GOLD Code ✨
Code earns GOLD status when:
┌────────────────────────────────────────┐
│ ✪ GOLD CODE ✨ │
│ ════════════════════════════════════ │
│ ✓ Pre-test plan defined │
│ ✓ Inline testing at write time │
│ ✓ Layer 1: 100% industry coverage │
│ ✓ Layer 2: WJTTC expert edge cases │
│ ✓ Bi-sync with project.faf │
│ ✓ All tests passing │
│ ════════════════════════════════════ │
│ This code has earned its name. │
└────────────────────────────────────────┘
Position in Development Pipeline
WJTTC comes AFTER project.faf, BEFORE coding:
1. project.faf → Define WHAT we're building (context)
2. WJTTC-TESTS.md → Define SUCCESS CRITERIA (tests first)
3. Code → Build to pass the tests
4. Test → Pass/Fail
5. Repeat → Until Championship grade
Test-Driven Code (TDC)
The WJTTC Cycle:
Think → Cross-check → Confirm → Code → Test → [Repeat]
│ │ │ │ │
│ │ │ │ └── Pass/Fail verdict
│ │ │ └── Write implementation
│ │ └── Green light to proceed
│ └── STOP if missing info - get it first
└── Understand what we're building
Cross-check Gate: STOP if missing information. Get it before proceeding.
Missing requirements? Ask.
Unclear acceptance criteria? Clarify.
Unknown edge cases? Define them.
Red → Green → Refactor:
Write failing test (RED)
Write code to pass (GREEN)
Clean up (REFACTOR)
Never code without knowing what "done" looks like.
Two-Layer Testing Architecture
Layer 1: Industry Standard (100% Coverage)
Use the framework's native testing - Jest, pytest, Vitest, etc.
Unit tests
Integration tests
Standard assertions
Coverage requirements
This is the baseline. Non-negotiable.
Layer 2: WJTTC Expert (Stress + Edge Cases)
The championship layer that catches what industry tests miss:
Category
What We Test
Syntax
Special chars, escapes, quotes, brackets
Emoji
🏎️ in strings, filenames, variables
Typecases
camelCase, snake_case, SCREAMING_CASE, mixed
Variables
Empty, null, undefined, MAX_INT, negative
Unicode
RTL text, combining chars, zero-width
Injection
SQL, XSS, command injection attempts
Boundaries
0, 1, -1, MAX, MAX+1, empty array
Test Targets:
MCP servers and tools
CLI commands and flags
API endpoints and payloads
Engine internals
Infrastructure configs
We Test the Testing
Meta-testing checklist:
Do the tests actually run?
Do they fail when code is broken?
Do they pass when code is correct?
Are edge cases covered?
Can tests be run in isolation?
Do tests clean up after themselves?
Signal Integrity Audit (The Red-Means-Real Doctrine)
Before you measure coverage, measure signal trust.
Red CI is a contract: stop, look, fix. If red means "shrug, runner had a noisy neighbor, just rerun," the signal is dead — and dead signal is worse than no signal at all. A test suite with 100% coverage but flaky reds is less trustworthy than one with 80% coverage and zero false alarms, because the team has stopped reading the reds.
This is the parent doctrine. Every other testing principle serves it.
The Audit
For any test suite under review, classify the last 30 days of CI failures into three buckets:
Bucket
Meaning
Action
Real bug
Red corresponded to an actual code defect that was fixed by a code change
✓ Signal worked
Flake
Red was timing/network/concurrency noise; passed on rerun with no code change
✗ Test design defect
Infra
Red was missing secret, runner image change, dep upstream — not the code under test
The credibility problem precedes the coverage problem. A suite at 60% coverage with 100% SI is healthier than one at 95% coverage with 70% SI.
Common Flake Sources to Eliminate on Sight
Hard absolute-time perf assertions on shared CI runners — expect(time).toBeLessThan(30). Move to non-gating workflow with continue-on-error: true.
Network-dependent tests in main suite — mock at the boundary or route to integration tier.
Concurrency tests without explicit ordering — use deterministic schedulers.
OS scheduler-dependent timing — replace with statistical (P95 over N) or relative (vs same-run baseline) assertions.
Secret-dependent steps that fail when missing — grey-skip, don't fail.
The Inverse Rule
Green CI that passes when something is broken is equally a contract violation. If a real bug shipped despite green CI, that's a coverage gap that demands a regression test BEFORE the fix lands. Treat false negatives with the same urgency as false positives.
When the Conversation Is the Real Gate
Automated CI is supporting infrastructure. The human + AI conversational audit — noticing patterns, tracing root causes, fixing systems — is the actual quality gate. Flaky CI wastes the conversation's bandwidth. Signal Integrity exists to keep CI worthy of the conversation it serves.
When to Use This Skill
AFTER defining project.faf context
BEFORE writing any implementation code
When starting a new feature (define tests first)
When fixing a bug (write failing test first)
Building regression test suites
Test Tier System — the WJTTC Five
WJTTC has five tiers: Brake · Engine · Aero · Tyre · Pit. The builder classifies every component into one of them. (faf wjttc audits a suite for the same five and flags untiered tests — name your tests with a tier word so the audit can place them.)
Pass rate maps to the canonical FAF tier system (the same tiers FAF uses everywhere):
Score
Tier
Symbol
Status
100%
Trophy
✪
Perfect — Gold Code
99%
Gold
★
Exceptional
95%
Silver
◆
Top tier
85%
Bronze
◇
Production ready
70%
Green
●
Solid foundation
55%
Yellow
●
Needs improvement
1%
Red
○
Major work needed
0%
White
♡
Empty
Quick Generation Command
To generate a test suite for the current project:
Analyze the codebase structure
Identify all testable components
Assign tiers to each component
Generate WJTTC-TEST-SUITE.md
Optionally generate executable test files
Example Test Table Format
### T1.1 - [Test Name]**Status:** ⏳ PENDING
**Priority:** CRITICAL
| Test | Expected | Actual | Status |
|------|----------|--------|--------|
| [Scenario 1] | [Expected result] | | |
| [Scenario 2] | [Expected result] | | |
**Test Command:**
\`\`\`bash
[How to run this test]
\`\`\`
Integration — where the builder hands off
This skill is the builder: it plans and generates. It does not run the suite.
Execute + report → use the wjttc-tester skill (it runs tests, finds bugs, writes WJTTC reports).
Audit tier balance → faf wjttc classifies an existing suite across the five tiers and flags untiered tests (--strict exits non-zero on any untiered; --json for CI). Name your generated tests with a tier word (brake/engine/aero/tyre/pit) so the audit can place them.
Wire CI receipts → faf taf setup installs the TAF receipt printer so each run leaves a verifiable record.
Championship Testing Standards 🏎️
Limitations
Use this skill only when the task clearly matches its upstream source and local project context.
Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
