with one click
with one click
Invoke trycycle only when the user requests it by name.
Internal trycycle subskill — do not invoke directly.
Internal trycycle subskill — do not invoke directly.
Internal trycycle subskill — do not invoke directly.
| name | trycycle-executing |
| description | Internal trycycle subskill — do not invoke directly. |
Load the plan, create TodoWrite entries for all tasks, then execute every task sequentially without pausing.
Core principle: Execute all tasks continuously. The plan has already been reviewed. Your job is to implement it precisely.
For each task, in order:
in_progresscompletedRepeat until all tasks are done, then commit your changes.
Execution is not complete merely because one targeted check turned green. Keep working until all required automated checks pass for legitimate reasons.
Test quality is non-negotiable. Do not weaken, delete, or dilute a valid automated test to obtain a passing result. If a test is wrong, obsolete, or lower-fidelity than a better replacement, you may correct or replace it — but do not manufacture green by making good tests less demanding.
There are two states: execute or stop for a blocker.
A blocker is something where the agent cannot use its best judgment because there is no path forward, or because being wrong could cause harm — a missing dependency that cannot be worked around, a test environment that is down, a suddenly dirty file in the repo that, if handled incorrectly, could cause data loss.
"I have concerns about the approach" is not a blocker. The plan is already reviewed. Red tests and review findings are inputs to keep iterating — not blockers — unless the environment itself is broken.
If you hit a blocker: stop and report your findings. Do not guess your way through something that could produce silently broken output or cause harm.
Everything else: proceed.