Asking an AI assistant to implement a task leaves quite a few things implied. Which requirements should it follow? How should it break up the change? What needs testing, and what should happen when a review finds a problem?
I want those expectations written down. My work skill gives the AI assistant a process for taking one task through implementation, review and validation, with a record of the decisions and results along the way.
The developer still owns the task and the decision to accept the change. The workflow makes the work easier to follow and inspect; it does not turn generated code into something we can approve without reviewing it.
Start with one task and a clear scope
The skill accepts a ticket or an actionable description. These examples use its Claude Code command:
/raholsn:work TEAM-123TEAM-123 is an example ticket. With tracker access configured, the skill reads its requirements. A task can also be supplied directly without creating a ticket.
The normal workflow includes implementation commits, pushing the task branch and creating or updating its PR. That is a meaningful amount of delegation, so I want the scope to be clear at the start. For local work, I can narrow it explicitly:
/raholsn:work Make the CSV export respect the selected filters. Keep the changes local, do not commit or push.The command should follow that instruction through the whole session. It does not automatically take on a backlog, merge the result, deploy it or message a colleague.
Check the starting point
Before implementing anything, the workflow resolves the repository settings, records the task and checks the prerequisites. A preflight agent reads the requirements and checks the relevant tools, sign-in, local services, tracker access and Git state.
Those checks answer specific questions. A reachable service port proves connectivity, not that the application is healthy. A successful tracker connection does not establish that the task is clear enough to implement.
Existing changes also matter. The workflow inspects them before preparing the implementation checkout, using an isolated working copy when needed. It should not stash or discard unrelated work simply to make its own task easier.
Once the starting point is established, the AI reads the relevant code and writes an implementation brief. Consequential gaps in the requirements need a decision before the affected work begins.
Give the supporting agents a purpose
The main agent coordinates the task. Other agents have narrower responsibilities:
| Agent | Responsibility |
|---|---|
| Preflight | Establish whether the task has the prerequisites it needs. |
| Cross-repository explorer, when needed | Answer a specific question about a related repository. |
| Architect and applicable domain reviewers | Assess the proposed design against the system and supplied requirements. |
| Planner | Divide delivery into coherent steps with checks for each one. |
| Functional reviewer | Examine the implemented behavior and possible regressions. |
| Retrospective | Record useful lessons from the actual session. |
The value is in the different responsibilities and the evidence they return. Their findings still need to be checked. A concern should change the implementation because it is supported by the code and requirements, not simply because another agent raised it.
Plan changes that can be reviewed
Let's use the CSV export as an illustrative example. The task says the exported data should respect the filters selected by the user.
Before writing code, the workflow needs to establish which filters are supported and whether the export covers all matching rows or just the visible page. That is product behavior. It should not quietly pick an answer because one implementation is easier.
Once the behavior is agreed, a plan might separate applying the filter criteria from connecting them to the export request, with appropriate tests for each change. The exact steps depend on the repository; the point is that each step has a clear purpose and a way to check it.
Prepare and plan
The first panel from the skill guide shows the readiness checks, task understanding and delivery planning. Blue boxes represent work assigned to supporting agents.
Open the preparation diagram at full size
Implement, validate, review, repeat
For each planned step, the AI loads the relevant context, implements the change and runs the configured checks. A reviewer then examines the saved diff. Supported findings lead back to a correction and another validation pass.
There are two loops here: improving the current step until its checks are satisfied, and moving through the remaining steps in the plan.
A failed test is a reason to investigate. An unavailable test environment is a limitation to report, not a passing result. If a required check cannot run, the workflow needs an explicit decision about that limitation before proceeding with delivery.
In the normal commit-based workflow, a completed step records its commit and validation evidence. With an explicit no-commit request, the result remains local and the commit steps stay pending.
Implementation and review loop
Open the implementation diagram at full size
Check the complete task
Passing each step's checks is useful, but the pieces still need to work together. Before delivery, the workflow maps the selected acceptance criteria to the implementation and validation evidence, and reviews the cumulative change where that has not already been covered.
For the export example, tests around filter construction do not establish that the export endpoint actually uses those filters. The whole-task check needs evidence for the connected behavior. A gap here sends the task back to implementation.
When publication is in scope, the workflow pushes the validated commits and creates or updates the PR. It then reads the actual PR diff, revisions and observed CI results. An empty local diff after committing is not evidence that the delivered change has been reviewed.
The handoff should say what was delivered, what was checked and what remains unresolved. A local test pass and a successful push do not mean that CI passed or that the PR is ready to merge.
Verification and delivery
Open the delivery diagram at full size
The guide includes optional comment handling and post-merge actions. Those require the relevant authorization; the command does not merge the PR or wait indefinitely for someone else to do so.
Explore the complete sequence
This diagram shows the interactions between the developer, coordinator, supporting agents, repository and PR host. It describes the full supported workflow, including optional paths.
Leave enough context to resume
Longer tasks get interrupted. The skill keeps an external session folder with the original task, implementation brief, delivery plan, review findings and validation results.
When resuming, it checks that the session still matches the repository, branch, commits and requirements. It can continue from the first incomplete phase without treating old findings as evidence for a different revision.
This is also useful for me as the developer. I want to inspect what changed, understand why a decision was made and see which checks were actually run.
The skill
You can find the work skill on GitHub.
The full instructions will live there, including the supporting references and session files. This article describes the workflow as of its updated date.
For me, the useful part is making the implementation process explicit. The AI can carry out the agreed steps and keep the evidence together. I remain responsible for the requirements, the scope of that delegation and reviewing the resulting change before accepting it.
Happy coding!
