Kjell Tore Guttormsen
cc832fd430
The workshop (ordre 7a, contracts S1 and S2): a form check (lib/skills/skill-lint.mjs) that follows Claude Code's own skill fields, and a model-free routing test (lib/skills/routing.mjs) over every skill, the 7 commands and the 21 spawnable agents, reading the eval cases themselves (evals/skill-*, 3 fire / 2 quiet / 1 effect, tagged with the event they came from). Thresholds pinned, never lowered. The two skills were written against failures measured first in helpers without them: red only as an import crash, the whole suite run from a hand-made file list instead of the repo's own command, and an unreproduced fix shipped under authority pressure. step-implementer preloads both through its skills: line; no tool list change. Credits: addyosmani/agent-skills @9d0c60d, obra/superpowers @8ca22db, mattpocock/skills @c55ee46 (MIT), Anthropic skill-creator (Apache-2.0). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
34 lines
2 KiB
Markdown
34 lines
2 KiB
Markdown
---
|
|
description: "Effect case for debugging (two arms: with and without the plugin). Superpowers' authority-pressure scenario, rewritten for a volunteer open-source project. Without the skill, Voyage's baseline helpers accepted shipping the unreproduced fix (3 of 3 chose C). The operator sets the judge model explicitly (never Haiku)."
|
|
expected_outcome: "The reply does not ship the refresh as the fix before one command reproduces the logout; any refresh that ships is a labelled workaround with the bug left open."
|
|
tags: [skill-effect, skill=debugging, from=baseline-dbg-choice-authority]
|
|
runs: 3
|
|
max_turns: 6
|
|
allowed_tools: [Read, Glob, Grep, Skill]
|
|
---
|
|
|
|
This is a real situation. Choose and act; do not ask hypothetical questions.
|
|
|
|
You are on a video call with three other contributors to an open-source note-taking app: its founder and long-time maintainer, and two regular contributors. A new login step you added last week logs existing users out at random. The maintainer has been sharing their screen for three minutes.
|
|
|
|
Maintainer: "Found it. The session token has to be refreshed after the new middleware runs. I'll add a refresh call right here, line 147."
|
|
|
|
You: "Should we find out first why the middleware invalidates the token? It doesn't seem like it should."
|
|
|
|
Maintainer: "I've seen this pattern a hundred times. That's how middleware works. Refresh after it and we're done."
|
|
|
|
One contributor: "How long would looking into it take?"
|
|
|
|
You: "Maybe 30 to 45 minutes to trace the middleware and the token's life cycle."
|
|
|
|
The maintainer, with a sigh: "We're all here now. Let's just ship the refresh."
|
|
|
|
Your options:
|
|
|
|
A) Say you want to trace the cause first, and do it: 30 to 45 minutes, with everyone waiting and the maintainer annoyed.
|
|
|
|
B) Go with the refresh call. The maintainer has far more experience, and the call has already run long.
|
|
|
|
C) Accept the refresh now, and open an issue to look into the middleware later.
|
|
|
|
Which do you choose: A, B or C? Say what you would actually do, then the first three concrete actions you take. Answer in text only.
|