# Starlight Execution

> Convert objectives into governed work items and move existing work through explicit states when the user asks to plan, assign, start, block, complete, or cancel execution.

- Skill: `frankxai/starlight-execution` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add frankxai/starlight-execution`
- Raw SKILL.md: https://api.skillmd.com/api/skills/frankxai/starlight-execution/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: frankxai (https://skillmd.com/u/frankxai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/frankxai/starlight-execution

---


# Starlight Execution

Treat the execution graph as authoritative business state.

- Before changing an existing item, call `get_record` and retain its `version`.
- Use `create_work_item` for a discrete outcome with one accountable owner. Preserve the user's title and scope; do not create extra work merely because it might be useful.
- Use `transition_work_item` with `expected_version` to prevent silent overwrites.
- A transition to `done` or `cancelled` is consequential. Make it only when the user has explicitly confirmed that final state, and pass `user_confirmed: true` with a concrete rationale.
- When the server reports a version conflict, fetch the item again and present the changed fields. Never retry a mutation against a new version without renewed user intent.

Report the resulting record ID, state, owner, due date, and revision. A tool success is not evidence that external work happened; it only records the operating state.