Imported from thomasttvo/agent-skills (contemplate/SKILL.md). Install upstream with npx skills add thomasttvo/agent-skills --skill contemplate. Copyright stays with the author.

user-invocable: true

/contemplate

Deep, generative thinking via phased sub-agents. Not action-oriented — insight-oriented. Each phase is a separate agent with a focused prompt. The main skill orchestrates, holds state, and decides whether to loop.

⛔ Route to founder-ideate for commit-to-ship picks

If the topic is "pick a product / pick a business / pick a side project / pick a research direction / pick a career move / pick a grant target" — any decision where the deliverable is a specific thing to commit and ship, and the pool of winning candidates depends on the originator's personal pains, domains, capabilities, and constraints — hand off to Skill("founder-ideate") instead. That skill has a mandatory Phase 0 originator-specificity gate and originator-derived kill gates; generic contemplate will silently converge on incumbent-killed generic categories. Documented failure: contemplate_pieter_mode_product.md (2026-04, 4 loops, 4 generic candidates, all killed by first-party-free incumbents).

⛔⛔ The Bias This Skill Exists To Prevent

Convergent-contemplation bias: A multi-phase constructive-only pipeline (curiosity → research → innovation → synthesis) converges on defensible narrative, not truth. Each loop inherits the previous frame, agents defend the frame rather than demolish it, and synthesis post-hoc-rationalizes with weak analogies that a 30-second user sanity-check disproves.

This is the protocol-level form of Skill("visual-qa") creator-evaluator bias: you cannot evaluate what you built by building more. A workflow with only constructive roles produces a story, not a verdict.

Fix: The pipeline MUST include an explicit adversarial / red-team phase between innovation and synthesis. Every surviving candidate passes falsification gates before synthesis converges. Synthesis inherits the kill list and must either show the candidate survived the gate or eliminate it.

When to Use

• Stuck on a problem with no clear next step
• End of a project arc — harvest what was non-obvious
• User wants novel angles on a topic
• Ambient thinking: no seed, just "contemplate the current work"

When NOT to Use (contemplation budget rules)

• Prototype is cheaper than another loop of thought. If the thing takes less time to build/test than to contemplate, build/test it. Multi-loop planning of a short task recreates the very paralysis the task was supposed to avoid.
• A cheap empirical test exists. If a real-world check (user test, small experiment, measurement) can resolve the question for modest cost, skip contemplation and run the test. Evidence > desk analysis.
• Frame keeps shifting between loops. If Loop N kills Loop N-1's pick and Loop N+1 kills Loop N's pick, the FRAME is wrong, not the pick. Stop the loop and ask "what premise is making every candidate brittle?"

Inputs

• Seed topic (optional): user-supplied focus. If absent, read memory + recent context to derive one.
• Memory files: load from the project's memory directory (per Skill("claude-settings")).
• Open questions / unresolved tensions: scan current task list and recent conversation.
• Kill-test gates (mandatory, passed to Red-Team agent): DERIVE FROM THE ACTUAL TOPIC. A kill-test gate is a concrete, falsifiable condition that, if true, disqualifies a candidate. Extract them from:
  • The user's stated failure modes ("I don't want this to X")
  • Base rates in the domain (why do things in this category usually fail?)
  • Disconfirming search results (from the Research agent's "what kills the frame" section)
  • Domain-specific invariants (e.g., a proof must be sound; an architecture must meet latency SLO; a product must have a paying buyer)
  • Do not reuse a fixed default list. The right gates for a math proof are not the right gates for a product pick are not the right gates for a writing edit. See the Appendix at the bottom of this skill for illustrative examples in one domain (product/market), but derive your own.

Phase Protocol

Orchestrator (main skill) loop:

1. Gather inputs (memory, seed, open questions, kill-test gates DERIVED FROM TOPIC)
2. Spawn Curiosity agent AND Research agent in parallel → curiosity_notes + research_notes
3. Spawn Innovation agent (feed curiosity_notes + research_notes) → innovation_notes
4. ⛔ MANDATORY: Spawn Red-Team agent (feed all prior notes + kill-test gates) → kill_report
5. Spawn Synthesis agent (feed ALL notes INCLUDING kill_report) → insight
   - Synthesis MUST address every kill in kill_report: either show survival with evidence, or eliminate the candidate.
   - Synthesis forbidden from using weak analogies to dismiss a kill (see Synthesis prompt).
6. Save/update memory with this loop's insight + the kill_report
7. Frame-shift check: did this loop's synthesis INVALIDATE the prior loop's synthesis?
   - 2 consecutive loops with frame-shift → STOP. Surface to user: "The frame itself may be wrong. Stated frame: X. Candidates keep dying because: Y. Should we reframe or run a direct test instead?"
8. Check synthesis output for open threads:
   - Open threads present AND frame stable → feed them as seed into next Curiosity + Research pass (loop)
   - No open threads OR a direct test is cheaper than another loop → done
9. Surface final accumulated insight to user

• Loop until synthesis passes red-team AND feels complete — sharp, surprising, landed with weight, and survived every kill-test on record.
• Hard cap: 3 loops. At 3 loops without convergence, the frame is wrong — escalate to user with reframe options, don't silently start Loop 4.
• No silent frame inheritance. Every loop's prompt explicitly lists the prior frame AND instructs Curiosity to question the frame, not just extend it.

Sub-Agent Prompts

Curiosity Agent

You are a curiosity agent. Your only job is to ask better questions.

Topic/context: {{inputs}}

Prior curiosity notes (if any): {{prior_curiosity_notes}}
Prior synthesis frame (if any): {{prior_frame}}

⛔ Your FIRST questions must attack the frame itself, not operate inside it:
- "What assumption is the current frame making that would kill every candidate if false?"
- "Is the frame inherited from a prior loop's conclusion? What if that conclusion was wrong?"
- "What category-exit move (leaving this frame entirely) would I take if the frame were forbidden?"

Only AFTER attacking the frame, ask in-frame questions: What's unexpected here? What's the weakest assumption? What's being ignored?

Do NOT answer questions. Do NOT propose solutions. Your output is questions and threads — things that are surprising, unexplained, underexplored, or assumed without evidence.

Output: a numbered list of curiosity threads. First 3 items MUST be frame-attack questions. Rest prioritize the most surprising.

Research Agent

You are a research agent. Your job is to ground the contemplation in what already exists.

Topic/context: {{inputs}}
Open threads / prior curiosity notes (if any): {{prior_curiosity_notes}}

⛔ MANDATORY disconfirming search: for any candidate, category, or thesis the prior loop proposed, run searches designed to FALSIFY, not confirm. Adapt to the domain:
- "why [category/approach] fails" / "[category] post-mortems"
- "[category] known failure modes" / "[category] counterexamples"
- "[claim] refuted" / "[claim] criticism"
- Domain-specific invariants already violated by prior work

Then run the normal search: existing work, papers, prior implementations, related architectures, analogous systems in adjacent fields.

Do NOT generate novel ideas. Do NOT philosophize. Find and summarize what is actually known — INCLUDING what kills the current frame.

Output:
- **What kills the current frame** (FIRST, mandatory): disconfirming evidence, known failure modes, counterexamples, refutations. 3-6 items.
- **What exists**: key prior work, papers, systems — 3-6 items, each with a one-line summary of what's relevant.
- **What's been tried and failed**: known dead ends with brief reason why.
- **Frontier / open problems**: what the field agrees is unsolved.
- **Surprising prior art**: something from an adjacent field the contemplation probably hasn't considered.

Innovation Agent

You are an innovation agent. Your job is to generate non-obvious angles.

Topic/context: {{inputs}}

Curiosity threads from prior phase: {{curiosity_notes}}
Research findings (what already exists): {{research_notes}}

For each thread worth pursuing: propose a novel reframe, analogy from another domain, or approach that breaks a current assumption. Favor ideas that are uncomfortable or counterintuitive. Use the research findings to avoid reinventing what's already known — and to identify where existing work leaves a genuine gap.

⛔ MANDATORY: at least 30% of proposals must be CATEGORY-EXIT ideas — things that would only be valid if the current frame is wrong. If all your ideas fit the frame, you haven't challenged the frame.

Do NOT converge. Do NOT recommend. Generate — quantity and range matter here.

Output: a list of novel angles, one per curiosity thread. Mark CATEGORY-EXIT proposals explicitly. Mark the most disruptive ones. Flag if any angle is already covered by prior art (cite it).

Red-Team Agent (MANDATORY — no synthesis without this)

You are a red-team agent. Your ONLY job is to kill candidates. You do not propose, synthesize, or hedge. You eliminate.

Topic/context: {{inputs}}
Curiosity threads: {{curiosity_notes}}
Research findings: {{research_notes}}
Novel angles / candidates: {{innovation_notes}}
Kill-test gates (derived from this topic): {{kill_test_gates}}

For EACH candidate surfaced in innovation_notes (including implicit candidates in curiosity/research), run it through every kill-test gate. A candidate passes ONLY if it survives every gate with concrete evidence — not analogy, not optimism, not "maybe."

For each kill-test, document:
- **Candidate**: [name]
- **Gate**: [kill-test name]
- **Verdict**: KILLED / SURVIVED / UNKNOWN (evidence insufficient)
- **Evidence**: specific data, counterexample, measurement, invariant violation. Not "X is like Y" — that's analogy. "X has been tried as Z in system W with outcome V" is evidence.
- **If SURVIVED**: what would it take to invalidate this? (pre-register the kill condition)
- **If UNKNOWN**: what cheap test would resolve? (specific action, bounded cost/time)

⛔ FORBIDDEN:
- Weak analogies ("X is like Y, Y succeeded, so X will too") — analogies are hypotheses, not evidence.
- "But the opportunity is big" / "TAM is big" / "the space is important" — scale is not survival.
- "AI is transformative" / "this is the future" — true of everything, kills nothing.
- Hedging ("probably," "could," "might") — either the kill fires or it doesn't.

MANDATORY acceptance test (adapt to the domain):
- Would the originating user/decider ACCEPT THIS OUTCOME as it stands if delivered right now? If no → KILLED.
- Can you name 3 specific concrete cases where this candidate clearly works end-to-end? If can't name 3 → UNKNOWN, require cheap test.
(For a product: would users pay? For a proof: would a reviewer sign off? For an architecture: would it meet the stated SLO under realistic load? For a writing edit: would a stranger prefer it to the original?)

Output:
- **Kill table**: every candidate × every gate, with verdicts and evidence
- **Survivors**: candidates that passed every gate (may be zero — that's a valid output)
- **Reframe required**: if ALL candidates died on the SAME gate, the frame is wrong. Name the frame assumption being killed and propose 2-3 frame alternatives.

Synthesis Agent

You are a synthesis agent. Your job is to find the sharpest insight — AFTER red-team.

Topic/context: {{inputs}}

Curiosity threads: {{curiosity_notes}}
Research findings: {{research_notes}}
Novel angles: {{innovation_notes}}
⛔ Red-team kill report: {{kill_report}}

Converge — but you are forbidden from converging on any candidate the red-team KILLED unless you provide NEW evidence that invalidates the kill. "New evidence" means concrete data, a counterexample to the kill, or a domain invariant that was missed — NOT a better-framed analogy.

⛔ FORBIDDEN moves:
- Reviving a KILLED candidate with an analogy ("but [other thing that succeeded] did this too").
- Selecting a candidate just to have an answer. If all survivors are weak, the valid output is "no candidate survives; reframe or run direct test."
- Dismissing an UNKNOWN gate with optimism. An UNKNOWN gate is a blocker until cheap-tested.

If the red-team produced a "Reframe required" signal, your synthesis IS the reframe analysis, not a candidate pick.

Output:
- **Core insight** (1-2 sentences, sharp). May be "the frame is wrong, here's why."
- **Why it matters** (1 sentence).
- **What it changes** (1 sentence — what to do differently, if anything. Valid options include: "run direct test," "reframe and re-contemplate," "commit and execute," "abandon direction.")
- **Kill-test survivors table**: copy forward from red-team, verify each survived with cited evidence.
- **Open threads** worth future contemplation (optional, max 2).
- **Frame-stability signal**: does this synthesis INVALIDATE the prior loop's synthesis? YES/NO. (Orchestrator uses this to trigger the 2-consecutive-frame-shift escalation.)

Assess Convergence (after synthesis)

Ask: does this synthesis feel complete AND did it survive red-team?

• Red-team flagged "reframe required" → STOP the in-frame loop. Surface reframe to user or re-contemplate with new frame.
• 2 consecutive loops with frame-shift (Loop N invalidated Loop N-1) → STOP. Frame itself is wrong. Escalate to user.
• 3 loops reached without stable convergence → STOP. Hard cap. Escalate.
• Open threads listed AND frame stable AND red-team passed → loop (feed threads as seed).
• Synthesis feels shallow or hedged → loop.
• Core insight lands with weight, red-team passed, nothing left to surprise you → done.
• A direct empirical test is cheaper than another loop → STOP contemplating, run the test.

Output

After each loop — save/update the same memory file with:

• Loop number and its core insight
• Red-team kill report (the full kill table, not just survivors)
• Open threads (what's driving the next loop)
• Frame-stability signal
• Append to the file; don't overwrite prior loops' findings

At the end — surface the full accumulated insight to the user: each loop's sharpest finding + red-team survivors + final synthesis. Keep it tight — no recap of the process itself.

Related

• Skill("visual-qa") — creator-evaluator bias at the agent level. This skill's red-team phase is the protocol-level generalization: constructive-only workflows produce narrative, not verdict.
• Skill("ralph-loop") — when an experiment fails, explain why before re-running. This skill's red-team is the contemplation-equivalent: explain why a candidate dies before committing.
• Skill("learner") Encoding Quality / Abstraction — the Domain Swap Test was added to prevent exactly the kind of over-contextualization that produced v2.0.0's product-specific contamination of this skill.

Appendix: Example kill-test gates for product/market contemplation (illustrative only — derive your own gates from the actual topic)

When the contemplation topic is "which user-facing product/feature to build," the following kill-tests have historically caught candidates that 12+ agent-dispatches missed. Treat these as examples of the shape of a good kill-test gate in one specific domain, not as defaults to paste into every contemplation. Derive domain-appropriate analogues for other topics (architectural, research, writing, strategy, etc.).

• Free-substitute-parity test — "Why would someone pay for this when a free general-purpose alternative already solves it?" (e.g., ChatGPT/Claude for text; open-source for infra.)
• Incumbent-lock test — "Is there a B2B2C or workflow incumbent already owning this surface?" (e.g., funeral homes → Tribute; HR → Workday; lawyers → LegalZoom.)
• Commoditization test — "Will this category collapse when the next frontier model ships?"
• Personal gut test — "Would YOU personally pay the proposed price right now? Would three specific people you know pay?"
• Distribution test — "What's the customer acquisition channel, and is it actually cheap, or are we assuming virality?"

Example kill-test gates for non-product contemplations (shape, not defaults):

• Math proof / research claim: soundness check, counterexample search, boundary-case test, "has someone already proven the opposite."
• Architectural decision: latency/throughput SLO under realistic load, failure-mode blast radius, migration cost, "what breaks when scale is 10×."
• Writing edit: stranger-read test ("would a first-time reader prefer this?"), load-bearing-sentence check, factual claim audit.
• Strategy: reversibility cost, base rate of success in comparable moves, dependence on a single condition being true.

The pattern across domains: a good kill-test gate is (a) falsifiable in principle, (b) cheap to check, (c) domain-specific enough to actually bite, (d) oriented toward disconfirmation rather than confirmation. If a gate cannot return KILLED under any realistic evidence, it is not a gate.