From ship
Runs a two-phase adversarial challenge to judge whether a discovered problem is real and a proposed idea is usable, outputting a GO or NO-GO verdict.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ship:challenge [proposal file | description]When to use
devils advocate, 反論, チャレンジ, challenge, 叩いて, 穴探し, grill me, 壁打ち
[proposal file | description]opusThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Judge in two phases whether a discovered problem is real and a proposed idea usable, so the next decision proceeds from a verified GO / NO-GO.
Judge in two phases whether a discovered problem is real and a proposed idea usable, so the next decision proceeds from a verified GO / NO-GO.
$ARGUMENTS may contain the challenge target (a proposal file path or description). If empty, stop and ask the user to specify the target, since silent inference from the conversation has high misfire risk. If non-empty, treat it as the challenge target.
Grill the proposal from evidence on its own, then return only the unresolved residual to the user, sorted by reversibility. Each open question in the proposal is either a fact or a preference; facts get verified and may overturn the core. A preference that survives verification becomes the residual, routed to the user by reversibility.
Aggregate grill findings into critic-design input schema before spawning.
| Field | Source |
|---|---|
| source | user-grill |
| artifact_type | inferred from $ARGUMENTS (spec / plan / design / ADR / doc) |
| approach | one-line summary of the proposal core |
| decisions | architectural-level decisions crystallised during grill (terminology checks and scope minutiae excluded) |
| trade-offs | trade-offs surfaced during grill |
| referenced_files | files cited or read during grill |
| outcome_ref | OUTCOME.md path plus a digest of its done state / non-goals / constraints. If OUTCOME.md is absent, use the outcome confirmed in Step 1 |
Land the Phase 1 material on two critic-design (internal attack / OUTCOME.md attack), adversarially probing for holes.
| Pass | Role |
|---|---|
| advisor | Evidence synthesis / self-consistency check / sorting audit |
| critic-design (internal) | Attack the proposal on its own terms (hidden weaknesses, failure modes) |
| critic-design (outcome) | Attack whether it reaches the outcome (outcome fit / non-goal / constraint breach) |
Lead with the Verdict, concentrate the backing in Why, name the next move in Actionable items.
| Section | Content |
|---|---|
| Verdict | GO / NO-GO. Note the condition if conditional. One line, first |
| Why | The fact-verification evidence (reproduction / refutation), the two critic-design verdicts (internal / outcome), and the residuals advanced on a best-guess with their reversibility (the user's veto targets). Close with a one-line note that the verdict is a judgment within evidence range |
| Actionable items | Top 3 concrete actions (keep / remove / revise) |
npx claudepluginhub thkt/dotclaude --plugin shipAdversarially reviews proposals by challenging the why, what, and how, and suggesting alternative approaches. Use for stress-testing or getting a second opinion before moving to specs/design.
Constructively critiques ideas and proposals by challenging assumptions, finding edge cases and risks, anticipating objections, and suggesting mitigations to strengthen arguments.
Scrutinizes ideas or plans adversarially: spawns skeptics across lenses like technical, economic, operational; advocate defends; synthesizes feedback report. No code or artifacts.