# Trycycle Executing > Internal trycycle subskill — do not invoke directly. Use when this capability is needed. - Skill: `tomevault-io/trycycle-executing` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/trycycle-executing` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/trycycle-executing/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/trycycle-executing --- # Executing Plans ## Overview 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. ## Step 1: Load Plan 1. Read the implementation plan file and the test plan file 2. Create a TodoWrite entry for every task in the plan ## Step 2: Execute All Tasks For each task, in order: 1. Mark as `in_progress` 2. Follow each step exactly — the plan has bite-sized steps 3. Work through red/green/refactor cycles until the task is genuinely complete: - Run the failing check (red) - Make it pass (green) - Refactor and tighten the implementation and tests, then re-run all relevant automated checks 4. Continue until all required automated checks named or implied by the plan are passing — including any broader regression suite or full project suite the repo requires before completion 5. Mark as `completed` Repeat 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. ## Blockers 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. ## Remember - Follow plan steps exactly - Don't skip verifications - Work red/green/refactor cycles — don't stop at the first green - All required automated checks must pass legitimately before execution is complete - Never weaken or delete a valid test to achieve green - Reference skills when the plan says to - Stop only for genuine blockers — not concerns, not uncertainty, not preference - Never implement on main/master branch without explicit user consent --- > Source: [danshapiro/trycycle](https://github.com/danshapiro/trycycle) — distributed by [TomeVault](https://tomevault.io).