By name: workflow-execution description: Plan-first workflow for non-trivial work: define the goal, create or reuse a tracker issue, package context, execute on an issue-named branch when code changes, and verify completion with evidence. triggers:
- make a plan
- plan this
- build this
- scaffold
- multi-step execution
- workflow-execution metadata: jarvos: bundle: operating-system-skills portability: generic
Workflow Execution
Use this skill for meaningful work: implementation, multi-step investigation, architecture changes, iterative bug fixing, scheduled automation, or anything that needs durable follow-through.
Contract
The workflow is complete only when:
- work has a clear goal and scope boundary
- execution work is tracked in the local tracker before code changes begin
- the plan and context live on the tracker issue or another durable project artifact, not only in chat
- code work uses an issue-named branch or equivalent review lane
- completion is verified with concrete evidence
- the issue ends in a real final disposition: done, in review, blocked with an owner/action, or delegated to a linked follow-up issue
Default loop
- Classify. Decide whether the request is coordination or execution. Pure Q&A can be answered directly. Execution needs tracking.
- Track. Create or reuse the smallest issue that matches the work. Check for active or completed duplicates before opening a new one.
- Plan. Capture goal linkage, scope boundary, definition of done, constraints, risks, and ordered steps.
- Package context. Attach the plan, relevant design notes, links, and test expectations where the executing agent can retrieve them without chat memory.
- Route. Decide which repo/workspace owns the change before editing.
- Execute. Make the smallest coherent change that can satisfy the definition of done. Preserve unrelated local changes.
- Verify. Run targeted checks, inspect the diff, and record evidence.
- Close or hand off. Move the issue to done only when no follow-up remains. Use in-review only when a real reviewer path exists.
Definition of done template
## Definition of Done
- [ ] Artifact or code path exists in the intended repo/workspace
- [ ] Documentation explains how to use or adapt it
- [ ] Tests or smoke checks pass
- [ ] Diff contains only intended files
- [ ] Review/merge path is clear
Tracker-neutral notes
Use whatever tracker the workspace has chosen: Paperclip, GitHub Issues, Linear, or a local markdown issue file. The invariant is not the tool. The invariant is that execution state, plan, blockers, and proof survive the current chat.