Key tasks

A key task is a state that has to be reached or held on the way to an end state, whatever approach gets there. People use key tasks to stay on course once the plan stops fitting (ADP 6-0, 2026). Picking them is a judgment about what is decisive, and it binds the work below. A key task that only one approach needs takes the choice of approach away from whoever does the work, which is exactly what an end state is meant to leave open.

This skill names the key tasks. It does not plan, pick an approach or order the work.

Steps

1. Sketch the approaches. Name two or three ways to reach the end state, as different from each other as the situation allows. They exist only to test candidates, and they stay out of the output, since choosing among them belongs to whoever does the work.
2. Keep what every approach needs. For each approach, list the states it could not do without, whether reached once or held throughout. Keep only those that every approach needs. Leave out a state that only some approaches need, even when it looks like the obvious first step.
3. Keep the decisive few. Drop a state that follows from another one on the list, a state that is part of the end state itself, a state that only serves to check the end state, since that belongs to its checks, and a state that only gathers information before acting (a baseline, a breakdown, an inventory), since that belongs to the plan. Most end states have none to three key tasks, and none is a common answer for a small effort.
4. Frame each as an effort. Call the Skill tool with "as-effort" on each key task, with the end state in view, so its so that says what it lets the end state rely on.

What to produce

One as-effort line per key task, in as-effort's default format. When none survive, one line: No key tasks: every state found depends on the approach. Nothing else: start with the first line, and never name the approaches from step 1.

When it doesn't fit

If the input names no end state, so there is nothing to reach, say so in one line and stop.