fix(systematic-debugging): default waitFor's description so examples compile

[An-idd]

Who is submitting this PR? (required)

Field	Value
Your model + version	Claude Opus 4.8 (claude-opus-4-8, 1M-context variant)
Harness + version	Claude Code 2.1.187
All plugins installed	superpowers@6.0.3, ponytail@4.7.0, andrej-karpathy-skills@1.0.0
Human partner who reviewed this diff	An-idd (y1203454599@gmail.com)

Division of labour, stated plainly: human-directed, agent-executed, human-reviewed. My human partner directed an audit of the skills for objective defects and reviewed/approved this complete diff before submission. The defect was surfaced by the agent during that audit and the one-line patch was written by the agent under their direction. This is grounded in a real Claude Code session with Superpowers installed, not reasoned from documentation alone.

What problem are you trying to solve?

The waitFor TypeScript example in skills/systematic-debugging/condition-based-waiting.md does not compile as written.

The "Implementation" snippet declares description: string as a required second parameter:

async function waitFor<T>(
  condition: () => T | undefined | null | false,
  description: string,
  timeoutMs = 5000
): Promise<T> {

…but every usage example in the same file calls waitFor with a single argument — the Core Pattern at L43 (await waitFor(() => getResult() !== undefined);) and all five Quick Patterns rows at L52–L56.

So the skill's own examples contradict the skill's own implementation. An agent that uses this skill to fix a flaky test and copies the documented call form emits code that does not type-check. Reproduced with a real compiler (tsc --noEmit --strict) on the exact snippet plus the exact single-argument example from the file:

condition-based-waiting.md example → error TS2554: Expected 2-3 arguments, but got 1.

Honesty note: this was found via a documentation-consistency audit of the skills, not from a live failing session. It is included here because it is objectively reproducible (compile output above), not a speculative or behavioral claim.

What does this PR change?

Gives description a default value (description = 'condition') in the waitFor snippet, so the single-argument call sites shown throughout the skill type-check. The error-message text is preserved (it now reads Timeout waiting for condition after <ms>ms when no description is passed). One line, one file.

Is this change appropriate for the core library?

Yes. systematic-debugging is a general-purpose core skill. The fix makes its illustrative code correct for everyone who reads it, regardless of project, domain, or tool. No project/team/tool specificity, no third-party integration.

What alternatives did you consider?

1. Add a description argument to all six example call sites. Rejected: it clutters the teaching examples — whose whole point is the concise condition-based pattern — and produces a larger, noisier diff that changes the pedagogy rather than fixing the bug.
2. Make it description?: string (optional, no default). Works for the call sites, but then ${description} interpolates undefined into the timeout error string. Defaulting to 'condition' keeps the error message meaningful, so I chose the default over the bare optional.

Does this PR contain multiple unrelated changes?

No. A single one-line fix to one file.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: none found.

Method: searched all open and closed PRs by title/keyword for condition-based-waiting, waitFor, and systematic-debugging. No PR touches this file or the waitFor snippet. The two systematic-debugging PRs that exist are unrelated (#1145 adds a hypothesis-preflight module; #1558 defuses an "ultrathink" keyword trigger).

Environment tested

Harness (e.g. Claude Code, Cursor)	Harness version	Model	Model version/ID
Claude Code	2.1.187	Claude Opus 4.8	claude-opus-4-8 (1M context)

Verification = TypeScript compile check (TypeScript via npx -p typescript tsc --noEmit --strict) on the skill's snippet + its documented one-argument example:

• Before this PR: error TS2554: Expected 2-3 arguments, but got 1.
• After this PR: no errors, exit 0.

New harness support (required if this PR adds a new harness)

N/A — this PR does not add or change any harness integration.

Evaluation

This is a code-example correctness fix, not a behaviour-shaping change, so behavioural eval sessions do not apply. The relevant verification is a compiler check, run before and after the change:

• Initial prompt that led here: my human partner asked the agent to audit the skills for subtle, objective defects (contradictions, broken references, signature/example mismatches) — not to change any agent behaviour.
• Verification runs after the change: 1 (the tsc before/after above). Before = TS2554 compile error; after = clean compile.
• No behavioural outcome changes are claimed, because none are intended — the agent-facing rules of the skill are untouched.

Rigor

• If this is a skills change: I used superpowers:writing-skills and completed adversarial pressure testing — N/A and intentionally left unchecked. This does not modify behaviour-shaping content; it fixes a TypeScript example that does not compile. No pressure scenarios apply to a compile bug.
• This change was tested adversarially, not just on the happy path — I confirmed the broken snippet actually fails to compile (RED) before confirming the fixed snippet compiles (GREEN), rather than only eyeballing it.
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals — none of that content is touched; the only change is one parameter default in a code block.

Human review

• A human has reviewed the COMPLETE proposed diff before submission