| 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. |
