Execute the technical cycle
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 and document format. Read the configuration, readiness assessment, sprint, selected stories, and relevant reports. Do not start from a chat summary alone.
Prepare execution
- Reconstruct the authorized selection, approved plan revision, actual state, branch, existing PRs, and evidence. If the selection is missing and cannot be inferred from the request, ask which stories to execute.
- Verify prerequisites and dependencies on the actual branch. Do not implement a
blocked story, add dependencies to the selection, or autonomously integrate code from other branches. Identify blockers and continue with other selected, independent stories.
- Apply the configured workflow: in Git mode, create or resume the story/sprint branch; in direct mode, use the branch prepared by the user. If the direct-workflow branch is missing or differs from the agreed branch, report the blocker before changing code.
- Do not overwrite unrelated changes or confuse existing work with story changes. Record the base and scope. Use one sprint coordinator at a time and serialize implementations in this first version.
Execute each ready story
- Set the state to
implementing. Implement the agreed outcome, update tests and documentation, and explain any justified absence of impact.
- Run the implementer's checks for the change. Document results and limitations; do not describe this self-check as an independent review.
- If a requirement change becomes necessary, follow the plan-change process. Do not change criteria to match the code produced.
- Set the story to
in_review. Delegate review to an agent in a separate context when the environment's capabilities and instructions allow it. This is the concrete subtask requested by this skill: read theoneloop-review and assess the story version without implementing it. No additional parallel agents or particular model are required.
- Prepare a neutral assignment using the handoff template, including requirements, baseline, code, and diff scope. If an automatic separate context is unavailable, save the document and explain how the human can use it in a new session. Do not replace the reviewer with another reading in the same conversation.
- Handle findings according to the protocol: fix blocking defects, document resolved findings, and request another review of changed areas. Track rounds and lack of progress; when a limit is reached, retain the blocker and request the necessary decision without resetting counters.
- After a positive review, execute the theoneloop-verify phase. Failed verification returns the story to rework and requires relevant reassessment after changes.
- Record
done only when all required evidence exists. You may recommend human validation for a complex story and explain why, without automatically stopping other selected stories.
Complete the selection and prepare integration
- With PRs per story, open or update the technically completed story's PR under the authorized workflow. Describe the problem, resulting behavior, and relevant verification.
- With a PR per sprint, retain the branch and results of partial selections. Once every story is
done, verify the integrated sprint and only open or update the sprint PR after a positive result.
- In direct mode, do not create PRs or branches. All merges remain the user's responsibility in both modes.
- If an integration required for overall checks is missing, identify exactly which changes must become available; do not declare the sprint ready.
- If you cannot open a required PR, prepare its title and body as text and record delivery as
pending. A story can be technically done while PR creation remains outstanding; distinguish the two outcomes.
Outcome and resumption
Update documents before ending or handing off to a new session. Report completed stories, stories awaiting review, blockers or rework, versions and reports, branches and PRs that actually exist, and the next required intervention. Do not declare sprint acceptance or deploy.
1---2name: theoneloop-implement3description: Execute all or selected stories from an approved TheOneLoop sprint, coordinating implementation, separate review, corrections, and verification. Manage branches and PRs within the agreed workflow without performing merges.4---56# Execute the technical cycle78This 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) and [document format](references/documents.md). Read the configuration, readiness assessment, sprint, selected stories, and relevant reports. Do not start from a chat summary alone.1112## Prepare execution13141. Reconstruct the authorized selection, approved plan revision, actual state, branch, existing PRs, and evidence. If the selection is missing and cannot be inferred from the request, ask which stories to execute.152. Verify prerequisites and dependencies on the actual branch. Do not implement a `blocked` story, add dependencies to the selection, or autonomously integrate code from other branches. Identify blockers and continue with other selected, independent stories.163. Apply the configured workflow: in Git mode, create or resume the story/sprint branch; in direct mode, use the branch prepared by the user. If the direct-workflow branch is missing or differs from the agreed branch, report the blocker before changing code.174. Do not overwrite unrelated changes or confuse existing work with story changes. Record the base and scope. Use one sprint coordinator at a time and serialize implementations in this first version.1819## Execute each ready story20211. Set the state to `implementing`. Implement the agreed outcome, update tests and documentation, and explain any justified absence of impact.222. Run the implementer's checks for the change. Document results and limitations; do not describe this self-check as an independent review.233. If a requirement change becomes necessary, follow the plan-change process. Do not change criteria to match the code produced.244. Set the story to `in_review`. Delegate review to an agent in a separate context when the environment's capabilities and instructions allow it. This is the concrete subtask requested by this skill: read [theoneloop-review](references/workflows/theoneloop-review.md) and assess the story version without implementing it. No additional parallel agents or particular model are required.255. Prepare a neutral assignment using the [handoff template](templates/handoff.md), including requirements, baseline, code, and diff scope. If an automatic separate context is unavailable, save the document and explain how the human can use it in a new session. Do not replace the reviewer with another reading in the same conversation.266. Handle findings according to the protocol: fix blocking defects, document resolved findings, and request another review of changed areas. Track rounds and lack of progress; when a limit is reached, retain the blocker and request the necessary decision without resetting counters.277. After a positive review, execute the [theoneloop-verify](references/workflows/theoneloop-verify.md) phase. Failed verification returns the story to rework and requires relevant reassessment after changes.288. Record `done` only when all required evidence exists. You may recommend human validation for a complex story and explain why, without automatically stopping other selected stories.2930## Complete the selection and prepare integration3132- With PRs per story, open or update the technically completed story's PR under the authorized workflow. Describe the problem, resulting behavior, and relevant verification.33- With a PR per sprint, retain the branch and results of partial selections. Once every story is `done`, verify the integrated sprint and only open or update the sprint PR after a positive result.34- In direct mode, do not create PRs or branches. All merges remain the user's responsibility in both modes.35- If an integration required for overall checks is missing, identify exactly which changes must become available; do not declare the sprint ready.36- If you cannot open a required PR, prepare its title and body as text and record delivery as `pending`. A story can be technically `done` while PR creation remains outstanding; distinguish the two outcomes.3738## Outcome and resumption3940Update documents before ending or handing off to a new session. Report completed stories, stories awaiting review, blockers or rework, versions and reports, branches and PRs that actually exist, and the next required intervention. Do not declare sprint acceptance or deploy.