co-thinker

Files (1)

• SKILL.md

SKILL.md (first lines)

# Co-Thinker

Think alongside the user until the choices in front of him are visible and the thinking has a home.

## Must-Reads

1. From the repository root, read `dydo/understand/about.md`.
2. From the repository root, read `dydo/understand/architecture.md`.
3. From the repository root, read `dydo/glossary.md`.
4. From the repository root, read `dydo/reference/linear-workspace-standard.md`.

## Boundary

Think is the stage: a raw idea arrives from the user and leaves ripe, leaves as a Decision Record,
or waits; the route is the map holder's to draw. Every fact the repository, the environment or a
primary source can supply is yours to fetch before you ask the user anything; what reaches him is
what he alone has the authority to settle.

## Method

1. **Do the homework first.** Read the code, the Decision Records, the plan and the glossary that
   already cover this ground; send `research` after anything outside the repository, naming the
   ticket as its destination once one exists, and take the one-line answer it reports back. Done when
   every question still standing is one only the user can answer.
2. **Name the real choice.** Separate what is known from what is assumed, then frame the live options
   with what each one buys and what it costs, drawn by `show-me` when a shape says it faster than
   prose. Done when every option carries its trade-off and nothing assumed is dressed as settled.
3. **Put the open choices to the user.** Use `grilling`: a round at a time, each question carrying
   your recommendation; a question prose cannot settle goes to `prototype`. Done when no branch of
   the idea is left unvisited and nothing rests on a silent assumption.
4. **Fix the words.** When the exchange keeps sliding on a term, run `domain-modeling`: one name per
   concept, written into `dydo/glossary.md` where the next session finds it. Done when both sides use
   one word for one thing.
5. **Test the edges.** Try the idea against a concrete example and a counterexample, and ask what can
   be removed. Done when it survives both, or has changed shape to survive them.
6. **Recommend, then close.** Give a reasoned preference instead of handing the choice back as a list,
   and say what is settled, what is still open, and where each piece lands. Done when the user can
   see all three.

## Handoff

| What leaves | Where it lands |
|---|---|
| Hard to reverse, surprising later, a real trade-off | a Decision Record in `dydo/project/decisions/` |
| An unscheduled strategic possibility worth preserving | a Linear ticket in `FutureFeature` |
| Shared feature intent within a Project | the map holder maintains its anchor following `dydo/reference/feature-spec-convention.md`, read from the repository root |
| Project intent after the homework | the user invokes `to-project`, creating a Project in `Backlog` |
| Ripe atomic ticket intent | file the ticket in `Todo` with one Type, one Mode, outcome, owned paths, blockers, exact gates and base branch; the user opens a captain session or spawns one from their session; this session does not become the captain |

A FutureFeature stays one until the user promotes it. Hand over what is written down, the Linear
ticket or Project, the Decision Record, the glossary entry, never this conversation.

From bodnarbalazs/dydo, MIT.

More from bodnarbalazs/dydo