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-planning |
| description | Internal trycycle subskill — do not invoke directly. |
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Context: This should be run in an isolated implementation workspace.
Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md
If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
Before writing any tasks, step back and challenge your current framing:
Low bar for changing direction. Big rewrites, architecture resets, and fresh replans are always acceptable when they produce a better answer. Do not preserve earlier decisions just because they already exist. If a better path is visible, take it.
High bar for stopping to ask the user. Use best judgment and keep going unless there is genuinely no safe path forward without a user decision. The only valid reasons to stop are: a fundamental conflict between user requirements, a fundamental conflict between the requirements and reality, or a real risk of doing harm if you guess. For everything else, make a decision and document it in the plan.
Once the architectural direction is stable and you are confident you are solving the right problem in the right way, proceed to detailed task decomposition.
Each step is one action (2-5 minutes):
A task is not done when one targeted test passes. Execution is complete only when:
Test changes are allowed when a test is wrong, obsolete, or can be replaced by a stronger or more faithful check. "Make the test easier so it passes" is never acceptable. If a check reveals a real defect, fix the defect. If checks are still failing, keep improving the code and tests — failed checks mean continue, not stop and declare done.
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use trycycle-executing to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
- [ ] **Step 1: Identify or write the failing test**
Prefer high-value existing checks: run them first to confirm they are currently red, then make them green in Step 3. If no existing check covers this behavior, extend or write a new failing test.
```python
# Option A: run existing test that should be red
# pytest tests/path/test.py::test_existing_behavior -v
# Option B: new failing test when coverage is missing
def test_specific_behavior():
result = function(input)
assert result == expected
```
- [ ] **Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"
- [ ] **Step 3: Write minimal implementation**
```python
def function(input):
return expected
```
- [ ] **Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS
- [ ] **Step 5: Refactor and verify**
Tighten the implementation and tests. Remove duplication, improve clarity, and strengthen assertions where possible. Then re-run the targeted test and the broader required suite to confirm nothing regressed.
Run: `pytest tests/path/test.py::test_name -v`
Run: `<full project suite command>`
Expected: all PASS
- [ ] **Step 6: Commit**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```