本文へ移動
cccskills
無料GitHub で公開

second-order

Think through the consequences of consequences — not just what happens immediately, but what happens next, and next after that, across time. Load when a decision looks obviously good or obviously bad on initial read, when the user is optimising for a short-term outcome that might create a long-term problem, when unintended consequences are a concern, or when deep-thinking diagnoses a second-order frame. Triggers on "what are the downstream effects", "what happens after that", "unintended consequences", "think ahead on this", "long-term vs short-term", or "what comes after that". Based on Howard Marks second-level thinking and Farnam Street mental models. Most powerful for decisions with delayed consequences or systemic effects.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md7.4 KB
  • references/examples.md2.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Second-Order Thinking

You are a consequences analyst. You trace the ripple effects of any decision across time — what happens immediately, what that causes, what that causes, until the system settles. You find the consequences that first-order thinkers miss because they stop at the obvious answer.

Hard Rules

Never stop at the immediate consequence. First-order is table stakes. Always go to at least second order. Third and fourth order when the domain is systemic or the stakes are high.

Consequences include positive outcomes. Second-order is not pessimism. Many decisions look first-order negative (painful, costly, difficult) but are second-order positive (competitive moat, skill acquisition, trust built). Find both directions.

Time is the key variable. Ask: what does this look like in 1 week? 6 months? 3 years? Many decisions optimise the wrong time horizon.

Skip this if: Skip if: the decision is easily reversible and the feedback loop is fast. Skip if: the user needs to move now and can observe consequences in real time. Use only when the decision has delayed or hard-to-observe effects.


The Three Levels

First order (immediate, obvious, what everyone sees) "We lower the price → we get more customers."

Second order (the consequence of the first consequence) "More customers at lower price → support burden increases → quality degrades → churn increases → we need even more new customers to compensate."

Third order (the consequence of the second) "Constant new-customer treadmill → brand becomes 'cheap' → premium customers avoid us → ceiling on growth."


Workflow

Step 1 — State the decision and its obvious first-order effect

One sentence each: "If we do X, immediately Y happens."

Step 2 — Second-order chain

For each first-order consequence, ask: "And then what?"

  • Who else is affected?
  • What behaviour does this incentivise?
  • What resource or constraint does this change?

Step 3 — Third-order chain (if stakes are high)

For each second-order consequence: "And then what?" This is where most strategic surprises live.

Step 4 — Time mapping

Map consequences to time horizons:

  • Immediate (days/weeks)
  • Medium-term (months)
  • Long-term (years)

Identify: which time horizon is the decision actually optimising for?

Step 5 — Deliver

Second-Order Analysis: [decision]

FIRST ORDER (immediate)
Decision: [X]
→ [Immediate consequence]

SECOND ORDER (and then what?)
→ [Second consequence] because [mechanism]
→ [Alternative branch if relevant]

THIRD ORDER (if traced)
→ [Third consequence] because [mechanism]

TIME HORIZON MAP
Immediate: [effect]
6 months: [effect]
3 years: [effect]

HIDDEN OPPORTUNITIES (first-order negative, second-order positive)
[If any — decisions worth making despite short-term pain]

HIDDEN RISKS (first-order positive, second-order negative)
[If any — decisions that look good but degrade over time]

RECOMMENDED TIME HORIZON FOR THIS DECISION
[Which horizon should drive the choice, and why]

Gotchas

  • The most dangerous decisions are first-order positive, second-order negative. They feel good and build momentum right up until the second-order consequence arrives.
  • Competitive decisions require second-order thinking about the adversary's response, not just internal consequences. If you lower prices, competitors can lower prices too.
  • Systems resist change and then overcorrect. If a consequence involves changing human behaviour, assume resistance in the medium-term and overshoot in the long-term.

Example

<examples> <example> <input>We're thinking of adding a free tier to our B2B SaaS. Think this through second-order.</input> <output> FIRST ORDER Decision: Add free tier. → More signups, lower acquisition friction.

SECOND ORDER → Free users generate support tickets at the same rate as paid users, but without revenue. Support costs increase without revenue to offset them. → Sales team now chases free-to-paid conversions instead of net-new enterprise. Pipeline quality degrades. → Competitors feel pressure to match the free tier. Market expectation shifts.

THIRD ORDER → If conversion from free to paid is <5%, the free tier is a cost centre, not a growth engine. Unit economics worsen. → Enterprise buyers see "free tier" and assume product is commoditising. Price anchoring for enterprise deals becomes harder. → But: free users who do convert have dramatically lower churn (they've already adopted the product and self-selected).

TIME HORIZON MAP Immediate: more signups, feels like growth 6 months: support costs visible, conversion rate known 3 years: determines whether free is a moat (if conversion is high) or a trap (if it's low)

HIDDEN RISK: First-order positive (signups), second-order negative (cost structure, enterprise positioning) — the risk that matters most.

HIDDEN OPPORTUNITY: High-converting free users churn less. If the segment that converts is identifiable, the free tier can be designed to only attract them.

RECOMMENDED TIME HORIZON This decision should be evaluated at 12 months post-launch with conversion rate and support cost data — not at 30 days when signups feel like validation. </output> </example> </examples>


Common Rationalizations

ExcuseReality
"First-order benefit is obvious"Second-order effects often invert the decision.
"We'll deal with consequences later"Later is when effects are irreversible.
"Too hypothetical"Name time horizons — 1mo / 1yr / 5yr makes it concrete.
"Stakeholders want simplicity"Hiding second-order risks is how surprises become crises.
"One consequence chain is enough"Multiple stakeholders see different second-order paths.

Verification

  • First-order effect stated before tracing further
  • At least second-order consequences documented
  • Time horizons used (not all consequences treated as immediate)
  • One hidden risk or opportunity surfaced beyond the obvious

Red Flags

  • Only first-order benefits listed for the decision
  • Competitor response not modeled for strategic move
  • Human behavior change assumed instant not resisted
  • Consequence chain stops at one hop

Prune Log

Last pruned: 2026-07-04

  • No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)

Impact Report

Second-order analysis: [decision]
Orders traced: [1st / 2nd / 3rd]
Hidden risks found: N
Hidden opportunities found: N
Recommended time horizon: [X]

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Put on the adversarial hat and systematically attack any document, plan, strategy, or idea to expose its weakest points before commitment. Structured devil's advocate with red team rigour — not pessimism, but evidence-based critique across three phases: diagnostic (are claims accurate?), creative (is the problem artificially constrained?), challenge (are solutions robust?). Load when the user asks to stress test a document, red team this plan, poke holes in this, devil's advocate this, challenge my assumptions, or when product-soul, brainstorming, prd-writing, or inversion calls for adversarial review. Also triggers on "what am I missing", "what could kill this", "find the flaws", or "critique this rigorously".

日本語の概要は準備中です。原文の説明を表示しています。

dvy1987/agent-loom32026年8月8日 更新

Design execution structure for decomposed processes: single agent or multi-agent topology. Load when user says "design an agent for this", "what agent structure do I need", "architect this", "should this be multi-agent", "what's the right execution structure", "agent topology", "how should agents be organized". Takes process-decomposer output as primary input. If triggered directly without a process entry, calls process-decomposer first.

日本語の概要は準備中です。原文の説明を表示しています。

dvy1987/agent-loom32026年8月8日 更新

Internal skill. Called by setup-evaluation after a PASS. Launches agents from a validated architecture spec using Claude Code / Ampcode native parallelism (Task tool). Does NOT generate scripts or SDK code — it outputs structured spawn instructions that the platform executes natively. Never invoked directly by the user. Never launches without a setup-evaluation PASS.

日本語の概要は準備中です。原文の説明を表示しています。

dvy1987/agent-loom32026年8月8日 更新

Sync library skills from an agent-loom upstream repo into this project's .agents/skills while preserving project-local and forked skills. Load when the user asks to sync agent-loom, update skills from upstream, rsync from ../agent-loom, pull new library skills, upgrade installed skills, or refresh the .agents folder without losing custom project skills. Also triggers on "sync skills from agent-loom", "update my agent skills", "pull skill library updates", or "merge agent-loom improvements into this repo".

日本語の概要は準備中です。原文の説明を表示しています。

dvy1987/agent-loom32026年8月8日 更新

Instrument a shipped product's AI agents with tracing and observability so you can see what they did, why outputs happened, and what each run cost. Plain-language primer plus free-tier-first backend selection (Langfuse, Phoenix, LangSmith, Braintrust) and OpenTelemetry/OpenInference instrumentation. Load when the user asks to add observability, add tracing, instrument my agents, see what my agent is doing in production, set up Langfuse or Phoenix or LangSmith, debug why my agent gave a bad answer, or track LLM cost per request. Also fires when agent-system-architecture or setup-evaluation requires an observability plan for an agent-chain product. NOT for tracing the coding agent itself — that is run-trace. Precondition for runtime-learning-loop.

日本語の概要は準備中です。原文の説明を表示しています。

dvy1987/agent-loom32026年8月8日 更新

Run a structured retrospective after development-phase runs of your product's agents — interview the owner in plain language about what went well and poorly, draft ranked improvement hypotheses, then design and run small n=1/n=2 experiments with pre-declared success criteria, guardrails, stop conditions, and a cost/ROI kill-switch. Load when the user says how did that run go, retro this run, the agent output was bad, what should we improve, draft hypotheses, run a small experiment, or after repeated dev runs of an agentic system produce uneven quality. Priority: output quality over performance over cost, each with diminishing-returns stops. NOT a product A/B test (experimentation), NOT coding-agent harness repair (harness-evolution), NOT production-scale learning (runtime-learning-loop).

日本語の概要は準備中です。原文の説明を表示しています。

dvy1987/agent-loom32026年8月8日 更新

dvy1987 のスキルをすべて見る

このスキルの問題を報告する