| 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. |
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.
Managed coding verbs
When this skill is running inside a jarvOS coding profile, the natural verbs
plan, work, and complete use the jarvOS-managed provider route. A healthy,
approved Compound Engineering provider supplies the planning and implementation
discipline behind the scenes; jarvOS still owns the work-run, branch/worktree,
accepted plan revision, review evidence, submission gate, and completion
decision. compound is an explicit, post-verification learning-capture step,
not a substitute for completion evidence.
If the provider is unavailable, modified, unsupported, or fails during a run,
fall back through the generic workflow in the same work run and worktree. Do
not start a second plan, branch, or pull request. Treat provider checkpoints as
reattachment hints only and revalidate current Git, review, test, and PR
evidence before claiming completion.
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.
