Analysis and planning
This installed skill is self-contained. Resolve Markdown links relative to the file containing them. Use bundled resources rather than looking for a source checkout or sibling skills. Write project state to the target project's .theoneloop/, not to the installation directory.
Read the protocol, document format, and the project's configuration and readiness assessment.
Analyze the issue
- Accept text, a local document, or content available through an integration. Preserve the source and supplied IDs; do not require a particular issue tracker.
- Distinguish the need, proposed solution, constraints, existing behavior, and expected outcome. For a bug, seek a reproduction and the expected correct behavior.
- Read the code and documentation needed to assess impact. If uncertainty prevents verifiable criteria, document an investigation or question; do not invent requirements.
- Use the issue template, distinguishing agreed decisions, proposals, and open questions.
Define stories and sprints
- Use the story template, preserving its context, grouped criteria, technical notes, tests, and out-of-scope sections. The As a / I want / so that format is optional for technical activities that do not benefit from it.
- Define observable criteria with stable IDs and a verification plan for each. Include error cases and nonfunctional requirements relevant to the work without imposing universal checklists.
- Make dependencies, constraints, tests, and documentation impact explicit. Check that referenced IDs exist and dependencies do not form cycles; resolve cycles during planning before declaring stories executable. Distinguish product requirements, agreed technical constraints, and possible implementation choices.
- Propose sprints using the sprint template. Each objective must describe the complete increment that will become available. A story does not have to be independently releasable.
- Consider splitting stories that are too large for a comprehensible review without imposing fixed sizes or counts. Keep all parts needed for a complete feature in the same sprint.
- Detail only the next sprint. Keep subsequent sprints
draft, with an objective, known dependencies, and indicative stories; do not invent precision or automatically infer durations from qualitative sizes.
- Agree on integrated sprint checks and fundamental prerequisites before execution. Record release constraints separately, including external constraints already identified in the requirements.
- Present the objective, scope, criteria, dependencies, verification plan, and Git choices to the human. After explicit approval, record the revision and decision; set the sprint to
approved and stories to ready or blocked according to known impediments.
Change an approved plan
Record the proposal and its impact on the outcome, criteria, dependencies, and evidence. Pause affected work while the human decision is pending. After the decision, increment plan_revision, preserve the previous requirement or its reference, and reopen affected activities. Do not seek approval again for ordinary technical details already within scope.
Outcome
Provide links to the documents and identify what is approved, what remains a draft, and which decisions or blockers remain. Plan approval does not automatically select every story for execution.
1---2name: theoneloop-plan3description: Analyze issues with the human and prepare TheOneLoop stories and sprints as complete increments. Use to plan the next sprint or agree on requirement changes; keep future sprints in draft.4---56# Analysis and planning78This installed skill is self-contained. Resolve Markdown links relative to the file containing them. Use bundled resources rather than looking for a source checkout or sibling skills. Write project state to the target project's `.theoneloop/`, not to the installation directory.910Read the [protocol](references/protocol.md), [document format](references/documents.md), and the project's configuration and readiness assessment.1112## Analyze the issue1314- Accept text, a local document, or content available through an integration. Preserve the source and supplied IDs; do not require a particular issue tracker.15- Distinguish the need, proposed solution, constraints, existing behavior, and expected outcome. For a bug, seek a reproduction and the expected correct behavior.16- Read the code and documentation needed to assess impact. If uncertainty prevents verifiable criteria, document an investigation or question; do not invent requirements.17- Use the [issue template](templates/issue.md), distinguishing agreed decisions, proposals, and open questions.1819## Define stories and sprints20211. Use the [story template](templates/story.md), preserving its context, grouped criteria, technical notes, tests, and out-of-scope sections. The As a / I want / so that format is optional for technical activities that do not benefit from it.222. Define observable criteria with stable IDs and a verification plan for each. Include error cases and nonfunctional requirements relevant to the work without imposing universal checklists.233. Make dependencies, constraints, tests, and documentation impact explicit. Check that referenced IDs exist and dependencies do not form cycles; resolve cycles during planning before declaring stories executable. Distinguish product requirements, agreed technical constraints, and possible implementation choices.244. Propose sprints using the [sprint template](templates/sprint.md). Each objective must describe the complete increment that will become available. A story does not have to be independently releasable.255. Consider splitting stories that are too large for a comprehensible review without imposing fixed sizes or counts. Keep all parts needed for a complete feature in the same sprint.266. Detail only the next sprint. Keep subsequent sprints `draft`, with an objective, known dependencies, and indicative stories; do not invent precision or automatically infer durations from qualitative sizes.277. Agree on integrated sprint checks and fundamental prerequisites before execution. Record release constraints separately, including external constraints already identified in the requirements.288. Present the objective, scope, criteria, dependencies, verification plan, and Git choices to the human. After explicit approval, record the revision and decision; set the sprint to `approved` and stories to `ready` or `blocked` according to known impediments.2930## Change an approved plan3132Record the proposal and its impact on the outcome, criteria, dependencies, and evidence. Pause affected work while the human decision is pending. After the decision, increment `plan_revision`, preserve the previous requirement or its reference, and reopen affected activities. Do not seek approval again for ordinary technical details already within scope.3334## Outcome3536Provide links to the documents and identify what is approved, what remains a draft, and which decisions or blockers remain. Plan approval does not automatically select every story for execution.
riktar