v0.12.2 1adbe2f

SKILL.md RawHistoryFolder


name: tasked-phases description: Use when the user wants a spec turned into phased work with checklist tasks tracked by the tasked_phases tool, or when ongoing work should be tracked phase by phase.

Tasked Phases

Use the tasked_phases tool as the source of truth for the spec, phases, current focus, and checklist progress.

Workflow

  1. Clarify missing requirements when the spec is ambiguous.
  2. Save the accepted spec with tasked_phases using set_spec.
  3. Create or materially revise the plan with replace_plan.
  4. Keep phases small and tasks concrete enough to check off.
  5. Set the focus with set_current_phase and pass the target phaseId.
  6. Call set_task_checked immediately after each checklist task is completed.
  7. Use set_phase_checked to complete or reopen every task in a phase. The phase must already contain at least one task.
  8. When every task is checked, treat the plan as closed. For unrelated work, call clear to discard the plan, or call set_spec immediately followed by replace_plan to record a new spec and a new set of phases.

Successful mutations return one progress line; use get_status or replace_plan for details. set_task_checked changes one task; set_phase_checked changes every task in a phase.

Planning rules

  • Prefer 3–7 phases unless the task is tiny.
  • Each task should describe an observable outcome.
  • Avoid vague tasks such as “work on this” or “finish implementation”.
  • Keep the stored spec and plan concise and operational.

Tool guidance

  • Use get_status before relying on remembered state or revising a long-running plan.
  • Use replace_plan for a substantial restructuring; use add_*, update_*, and remove_* for small changes.
  • Pass phaseId as the raw ID shown in brackets, without the brackets. The tool also accepts a complete phase label or a unique phase title when recovering from copied output.
  • Do not rely on prose alone for completion state; update the tool after each completed task.
source
1---
2name: tasked-phases
3description: Use when the user wants a spec turned into phased work with checklist tasks tracked by the tasked_phases tool, or when ongoing work should be tracked phase by phase.
4---
5
6# Tasked Phases
7
8Use the `tasked_phases` tool as the source of truth for the spec, phases, current focus, and checklist progress.
9
10## Workflow
11
121. Clarify missing requirements when the spec is ambiguous.
132. Save the accepted spec with `tasked_phases` using `set_spec`.
143. Create or materially revise the plan with `replace_plan`.
154. Keep phases small and tasks concrete enough to check off.
165. Set the focus with `set_current_phase` and pass the target `phaseId`.
176. Call `set_task_checked` immediately after each checklist task is completed.
187. Use `set_phase_checked` to complete or reopen every task in a phase. The phase must already contain at least one task.
198. When every task is checked, treat the plan as closed. For unrelated work, call `clear` to discard the plan, or call `set_spec` immediately followed by `replace_plan` to record a new spec and a new set of phases.
20
21Successful mutations return one progress line; use `get_status` or
22`replace_plan` for details. `set_task_checked` changes one task;
23`set_phase_checked` changes every task in a phase.
24
25## Planning rules
26
27- Prefer 3–7 phases unless the task is tiny.
28- Each task should describe an observable outcome.
29- Avoid vague tasks such as “work on this” or “finish implementation”.
30- Keep the stored spec and plan concise and operational.
31
32## Tool guidance
33
34- Use `get_status` before relying on remembered state or revising a long-running plan.
35- Use `replace_plan` for a substantial restructuring; use `add_*`, `update_*`, and `remove_*` for small changes.
36- Pass `phaseId` as the raw ID shown in brackets, without the brackets. The tool also accepts a complete phase label or a unique phase title when recovering from copied output.
37- Do not rely on prose alone for completion state; update the tool after each completed task.

Keyboard shortcuts

Single-key shortcuts are on. ctrl k and esc work whatever this says.

ctrl k :
go to a section, branch, tag, file or repository
?
this list
j k
move the row cursor down / up
enter
open the row under the cursor; on Files, a directory opens or closes in place
↑ ↓ ← → home end
in the file tree (focus on a row): previous / next row, close / open a directory or go to its parent / first entry, first / last row. They never open a file
l h
on Files: open a directory or a file / close a directory or go up to its parent, then to the parent page. Elsewhere: into the side panel (on a merge request, its files) / back to the content; there j k move between its controls
g g G
first / last row
/
filter the list; on Files, find a file anywhere in the repository (esc clears, enter opens the best match)
b
switch branch or tag
g s g f g c g b g m g i g r g a
tabs: summary, files, commits, branches & tags, merge requests, issues, releases, actions (when available)
g h
home
w
wide mode: use the whole width of the screen, or not (remembered)
y
copy a permalink pinned to the commit
d u x
diff: split / unified / collapse or expand all
e E
diff: the whole file in view / every file, with the lines the hunks hide
n
merge request: next note in the diff
esc
close a dialog, leave a field

Branches 1

Tags 476

↑↓ moveenter openesc close