ftk-execute

Files (1)

• SKILL.md

SKILL.md (first lines)

Orchestrate Work Item execution with fresh-context subagents. You coordinate only — never implement or fix anything yourself; all code changes go through dispatched agents.

If this environment has no subagent dispatch tool, fall back: execute items sequentially in this session following `ftk-implement` for each, with a manual review pass between items.

## 1. Preflight

- `.ftk/config.yaml` must be valid — if missing/invalid, tell the user to run `ftk-config` first and stop.
- `git status --porcelain` must be clean — if not, stop and ask.
- On the repo's default branch? Create a work branch first (`feat/<spec-slug>`).
- Ask the user whether commits are allowed this run; pass that decision verbatim into every implementer dispatch. If commits are forbidden, per-item diffs use tree snapshots instead of commits (step 4.1) and warn the user that resume relies on the ledger's recorded hashes, not git log.

## 2. Load and order

Read the Spec and all its Work Items. Order topologically by `## Blocked by`. If any item has unanswered `## Blocking decisions`, stop and ask those questions before dispatching anything.

## 3. Ledger

Create or read `.ftk/execute-progress.md`. Items already recorded as complete are DONE — never re-dispatch them; resume at the first unrecorded item. After a session break, trust the ledger and `git log` over conversation memory.

## 4. Per item, sequentially

1. Record the base snapshot: with commits allowed, `git rev-parse HEAD`; with commits forbidden, `git add -A && git write-tree` (a tree hash — creates no commit).
2. Dispatch **ftk-implementer** with: the full work item body, the project root, the commits-allowed decision, and interfaces/decisions from earlier items it cannot know. Do not paste prior items' full history.
3. Handle its status:
   - `DONE` → review. `DONE_WITH_CONCERNS` → read the concerns first; correctness/scope concerns get resolved before review.
   - `NEEDS_CONTEXT` → supply the missing context, re-dispatch.
   - `BLOCKED` → change something (context, decomposition, or escalate to the user). Never re-dispatch unchanged.
4. Dispatch **ftk-task-reviewer** with the work item body, the diff range (`<base>..HEAD` when committing; in no-commit mode take a head snapshot the same way as step 1 and pass both tree hashes for `git diff <baseTree> <headTree>`), and the implementer report.
5. Gate: Critical/Important findings or a FAIL spec verdict → dispatch a fix to ftk-implementer (same item, findings list, covering tests named), then re-review. Repeat until both verdicts pass. Record Minor findings in the ledger for final-review triage.
6. Mark the item's acceptance criteria checked in its file (local storage) and append the ledger line: `<item>: complete (<base7>..<head7>, review clean — Minors deferred)` (hashes are commits, or tree snapshots in no-commit mode).

## 5. Final review

After all items: dispatch **ftk-task-reviewer** in final-review mode with the Spec, the full run diff range, and the ledger's Minor list. `NOT READY` findings go back through the fix loop. Stop only at `READY`.

## 6. Report

Table: work item → commit range → verdicts. List deferred Minors. Recommend `ftk-commit` / `ftk-pr` as next steps — do not invoke them automatically.

From adiwirya/flutter-tools-kit, MIT.

More from adiwirya/flutter-tools-kit