Workflow Execution

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

1. Classify. Decide whether the request is coordination or execution. Pure Q&A can be answered directly. Execution needs tracking.
2. Track. Create or reuse the smallest issue that matches the work. Check for active or completed duplicates before opening a new one.
3. Plan. Capture goal linkage, scope boundary, definition of done, constraints, risks, and ordered steps.
4. Package context. Attach the plan, relevant design notes, links, and test expectations where the executing agent can retrieve them without chat memory.
5. Route. Decide which repo/workspace owns the change before editing.
6. Execute. Make the smallest coherent change that can satisfy the definition of done. Preserve unrelated local changes.
7. Verify. Run targeted checks, inspect the diff, and record evidence.
8. 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 workflow

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.

In a jarvOS-managed Codex profile, start with jarvos_coding_repositories when an opaque repository identifier is needed, then use one durable run through jarvos_coding_plan, jarvos_coding_accept_plan, jarvos_coding_work, and jarvos_coding_finish. Use jarvos_coding_status or jarvos_coding_resume to continue that run. Never infer a repository root, provider, executable, credential, or registry path from the request.

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.

Code work finishes through this managed workflow rather than stopping at a local commit or open pull request. When the exact pull-request head is aligned with the tracked goal and every required submission gate is clean, merge it autonomously and close the tracked work; routine non-author approval is not a gate. Stop only for unclear goal alignment, a required failed or missing gate, branch or path policy, or separate authority for publication, live activation, spending, destructive action, or an external send.

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.