work-implement
work-implement
Take one tracked issue, implement it, and push it so a different agent can review it — the stateless implement-unit behind work-implement-queue. One issue, one tracker (GitHub via gh or Linear via its MCP), picked per-repo by the same committed config the issue skill uses. State lives in the issue's lifecycle label, never in the agent — so a crashed run resumes instead of restarting.
This skill is the implement half of a two-loop workflow: it builds and pushes; work-review then reviews the pushed work. It never reviews its own output and never sets done — its terminal outputs are reviewRequested (handed to the review loop), blocked, or skipped (contradictory labels — reported, tracker untouched).
Opted out? If the repo config sets work to false, this skill is disabled for the repo (as are the other work-* skills) — stop immediately and tell the user the work skills are turned off in .tituskirch-skills.json. An absent work block is not disabled (it falls back to defaults). Check .work == false on the resolved config before any action — and before indexing .work.*. A missing jq or config exits non-zero too, so a pass is not evidence the config was read.
Workflow
1. Load config & resolve tracker
Resolve .tituskirch-skills.json via templates/resolve-config.sh, never by reading the raw file (REFERENCE.md states how, missing jq included); the work.* section holds tracker, label lifecycle, branch strategy, the feedback destination and Linear scope. Resolution per setting: config → default. Determine the tracker (work.tracker, falling back to issue.tracker) and confirm it is available/authenticated. Reuse the issue catalog cache for labels/teams/states.
Config schema, the full lifecycle and all mechanics: REFERENCE.md.