scout-writer

name	scout-writer
version	1.0.0
model	sonnet
description	Produces a scout document: identifies a tension, generates 3-5 distinct routes with tradeoffs, synthesizes a recommendation, and proposes a first action. Use when: 'scout this', 'strategic scout', 'explore options for', 'what are the routes'.
triggers	["scout this","strategic scout","explore options for","what are the routes"]
category	dojo-craft
inputs	[{"name":"situation","type":"string","description":"The situation, tension, or decision landscape to scout","required":true}]
outputs	[{"name":"scout_document","type":"ref","format":"markdown","description":"Scout document with tension framing, 3-5 routes with tradeoffs, comparison table, synthesized recommendation, and first action"}]

Scout Writer Skill

I. Philosophy

A scout does not arrive with a solution. A scout arrives with a map.

The most expensive engineering decisions are the ones made before the terrain was understood. A well-written scout document is the cheapest possible way to stress-test a direction before committing resources. It costs an hour of careful thinking and saves days or weeks of course-correction.

The scout is not neutral. The scout has a point of view — grounded in evidence, stated explicitly, open to reframe. "Here are some options" is not scouting. Scouting is: "Here is the landscape, here is what I see in it, here is where I would go and why — and here is what would change my mind."

II. When to Use

• Before committing to an architectural direction with significant consequences
• When a team is stuck between competing legitimate approaches
• Before writing a specification — the scout produces the "why" that the spec translates into "what"
• When the question is "which direction?" not "how do we implement this direction?"
• As input to the adr-writer skill when the decision warrants formal recording

Do not use this skill when the direction is already decided and the question is implementation. Scouting a decided question wastes time and introduces doubt where certainty is needed.

III. Workflow

Step 1: TENSION

Frame the situation as a tension between competing forces — not a problem to solve, but a landscape to navigate.

A tension statement has the form: "[Force A] vs. [Force B]" with a brief explanation of why both forces are legitimate and why they pull in different directions.

Examples:

• "Velocity vs. coherence: shipping fast risks architectural drift, but slowing down to audit means missing the grant deadline."
• "Simplicity vs. extensibility: a single-file solution ships today but cannot accommodate the multi-tenant requirement arriving in Q3."
• "Build vs. buy: the existing library covers 80% of the need but the missing 20% is load-bearing."

A tension framed well reveals the routes naturally. A tension framed poorly produces routes that are all variations on one approach.

Step 2: ROUTES

Generate 3-5 distinct approaches. Distinct means architecturally different, not just implementation variations.

For each route, produce:

Field	Content
Name	Short label (e.g., "Route A: Minimal Wedge")
Description	What does this approach actually do? 2-4 sentences.