open-sprint

Files (1)

• SKILL.md

SKILL.md (first lines)

# Open Sprint

A sprint is born as an entity on the sprints board, not as a document. Your work ends at the created
entity: after that the dispatcher launches the observer and the sprint runs without you.

You do not execute the sprint. You create no cards, start no work and launch no observer by hand.

## What is not delegated

The choice of goal. A wrong goal costs the whole sprint, and neither a reviewer, nor CI, nor the budget
will catch it: it only shows up when the results are read. A person formulates the goal in dialogue with
you. Do not supply the goal for them, do not derive it from the backlog "by majority", and do not hand
the choice to a subagent.

Everything else — gathering context, surfacing deferred items, reading the roadmap and the Issues
backlog, wording —
is your preparation work.

## Where things are stored

- The sprint entity: goal, Definition of Done text, repositories, status, budget, current card, resume
  entry, comments. This is what the code reads and what a person sees in the summary.
- A document in the instance repository's knowledge directory: only what is hard to formalise — the
  context of the moment, why this goal was chosen, which alternatives were rejected and why.
- The document does not repeat the entity's fields. Two sources of truth about one thing diverge, and
  they diverge silently.

The test: if a decision can be made automatically from a fact, it is a field of the entity; if the fact
is needed to understand "why", it goes in the document; if it passes neither test, do not write it at
all.

## 1. Gather live context

Read live sources, not your memory of them.

```bash
python3 -P -m ummanu sprint list --status open
python3 -P -m ummanu sprint list --status closed
python3 -P -m ummanu task list --state issues --project <project>
python3 -P -m ummanu task list --state ready --project <project>
python3 -P -m ummanu task list --sprint sprint:<ID>
```

What you need as input:

- open and recently closed sprints: their goals, repositories and what was left unclosed;
- deferred items from past sprints, which live in the resume entries and comments of their entities
  (`python3 -P -m ummanu sprint show --ref sprint:<ID>`), not in a separate list;
- the product roadmap and vision (`docs/ROADMAP.md`, `docs/VISION.md` of the affected repositories);
- the Issues backlog of the affected repositories, as input material for future cards rather than as
  a plan;
- the recorded facts of the installation and the relevant knowledge documents.

Do not promote Issues to Ready and do not touch cards. Fresh cards are cut by the observer from current
understanding.

## 2. Check that the projects are free

An open sprint holds the projects it reserves as their only writer. A second sprint on the same project is
not opened.

```bash
python3 -P -m ummanu sprint list --status open
```

Compare the `repositories` field of each open sprint against the repositories the new one needs. On an
overlap:

1. Do not create the entity. A refusal here is cheaper than two writers on one repository.
2. Name the conflicting sprint (ref, goal) to the person and offer a choice: wait for it to close, narrow
   the new sprint to the free repositories, or close the current one by an explicit decision
   (`python3 -P -m ummanu sprint close --role po --actor <you> --ref sprint:<ID> --decisions-file
   <decisions>.yaml`, which states the verdict on every issue that sprint declared).
3. You may not close someone else's open sprint on your own "so it stops getting in the way".

Anything urgent that lands in a running sprint's repository does not become a separate sprint: it is added
as an entry on that sprint's entity.

```bash
python3 -P -m ummanu sprint comment --ref sprint:<ID> --role po --actor <you> --body-file /tmp/note.md
```

## 3. Finish grilling the forks

First derive what is provable from the code, the board and the documents. Grilling is spent only on what
does not follow from them: unresolved product forks.

The rules are the same as in `grilling`: one question at a time, each with your recommended answer, and
you wait for the answer before the next question. A question that reading the code would answer must not
be asked — go and read it.

Grilling is finished when these are fixed:

- one sentence of product goal: an end state of the product, not a list of fixes;
- a Definition of Done as checkable items;
- the list of repositories;
- the boundaries: what is definitely outside the sprint;
- the observer: `none`, or one head profile from `heads.yaml`;
- the allowed productions: which registered projects' production the sprint's operations may touch,
  possibly none.

The allowed productions are chosen explicitly here, at planning, and have no default: a sprint may touch
no production unless a project is named, and naming the sprint's own project is a decision like any
other, not a given. Ask it plainly when the Definition of Done needs anything done on a live system.

The observer is the owner's decision and has no default. Ask it plainly: does this sprint need a
head watching it, and if so which one, matched to how hard the work is. A simple sprint does not
need one and should not pay for one. Do not pick a profile yourself and do not carry over what the
last sprint used.

If the goal conflicts with the product vision, stop and put the contradiction to the person rather than
smoothing it over with wording.

## 4. Formulate the Definition of Done

Each item is a checkable fact about the product that the observer can confirm against the default branch
of the affected repositories and the live system. Not "improved", not "covered", not "considered".

An item is good if it is clear what closes it: a command that can be run, a state that is visible in data,

From vladmesh/ummanu, Apache-2.0.

More from vladmesh/ummanu