Prioritize

Shape a large effort into outcomes pursued one at a time: keep the larger direction and deferred ideas, and select one useful focus. The output is direction, a lightweight backlog, and an approved or explicitly pending focus; implementation stays outside this skill. A run ends with the focus recorded in the backlog and working state, where whoever builds it next reads it.

The open question here is which outcome comes first. When the effort instead hinges on design decisions that need research or prototypes over several sessions before anything can be prioritized, say so and stop: those decisions come before choosing a focus.

The project documents and their rules are in project-documents.md; its terms (authorized, obligation, lazy, pointer) apply throughout. This skill works on the backlog, working state, and the changelog, and links existing requirements and specifications.

1. Recover the direction

Read applicable instructions, relevant code, requirements, specifications, decisions, and the project documents. Reconcile actual progress before reprioritizing existing work. Inspect available facts instead of asking the user to repeat them.

Establish the intended outcome, users, constraints, and exclusions. Follow the interview method, rooting its design tree in choosing the next focus.

Completion: outcome, users, constraints, and exclusions are explicit, and every focus-blocking question is identified. Unanswered choices stay pending; detailed future behavior may stay open.

2. Group outcomes and dependencies

Group related ideas into recognizable user or project outcomes: vertical results such as "members can book a slot", in place of layers such as "all database work". Keep uncertain areas coarse; a possible future capability gets a short description.