Daily Workflow

The Implementation Loop

The daily rhythm of workscope cycles, git practices, and agent tuning that defines life with WSD.

The Daily Rhythm

Once your project has an Action Plan with a populated checkboxlist, a configured test suite, and WSD’s tooling in place, a rhythm emerges. You start a fresh Claude Code session. You run /wsd:init. The Task-Master examines your Action Plan, follows navigation pointers into feature specifications and tickets, and selects the next appropriate work. You glance at your checkboxlists to confirm the right items are marked, then run /wsd:prepare to load context and /wsd:execute to begin. The agent works, the QA gauntlet runs, you review the results, request any followup tweaks, and you close the session with /wsd:close. Then you start a fresh session and do it again.

This is the implementation loop, the repeating cycle that converts your specifications into working software. Each iteration is self-contained: a fresh agent, a defined scope of work, a quality gate, and a clean exit. The loop runs as many times as needed, advancing through your Action Plan one workscope at a time.

What makes this loop distinctive is how little active direction it requires once the specifications are in place. The Task-Master automatically navigates your entire hierarchy of documents, so you do not need to tell it what to work on next.

The cycle that emerges is one of supervised automation. You are not writing code or directing implementation decisions. Those were made during specification work, as described in the Organizing Your Project guide. Instead, you are shepherding a process: confirming workscope assignments, monitoring progress through the work journal, reviewing results, and handling the occasional judgment call that the agents escalate to you. The hard thinking happened when you wrote the specifications. Now you are watching them compile.

This does not mean the loop is passive, as no plan is ever fully conceived from the start. You are opening tickets as issues surface during implementation. You are adding new features to the Action Plan as the project evolve. You are making scope adjustments when the Task-Master selects too much or too little for a single session. And you are watching your project take shape, which builds the kind of ambient familiarity with the codebase that keeps you effective as a technical decision-maker.

Over time, the rhythm becomes habitual. You develop an intuitive sense of where the work frontier is, which branches of the hierarchy are active, and what the Task-Master will select next. The four commands (init, prepare, execute, close) become muscle memory. The loop is simple, but the system it drives is not.

Handling “Human” Work Items

Checkboxlists are designed for AI-executable tasks, work that an agent can perform within a single session given the right context and specifications. But project plans inevitably include items that require human action: running a migration against a production database, obtaining sign-off from a stakeholder, configuring a third-party service with credentials, or testing a physical device integration.

When these items appear in your checkboxlists, mark them [-] (skipped) so the Task-Master does not attempt to assign them to an agent. The [-] state is your general signal: “skip this.” It tells the system that the item exists in the plan for completeness but should not enter the workscope assignment process. If you later perform the work yourself and want to record that it was completed, you can change the mark to [x].

This practice is worth adopting proactively. When you or an agent drafts a checkboxlist, scan it for items that assume human execution and mark them immediately. An agent that receives a workscope containing “deploy to production” or “get team approval” will either object to the task or produce a simulated version of it, neither of which is useful. Catching these items early keeps the implementation loop running smoothly.

Post-Workscope Activities

The space between workscope cycles is where you, the developer, do your part. After /wsd:close finalizes the session, several activities prepare the ground for the next iteration.

Review user action items. The work journal’s final section lists anything the QA gauntlet surfaced that falls outside the workscope’s scope — specification drift noticed by the Documentation-Steward, a dependency vulnerability flagged by the Health-Inspector, a minor inconsistency caught in passing. Most of these you will delegate back to a future agent, but some require your judgment or action.

Commit your work. Workscopes are treated as atomic units, so committing mid-workscope is not practiced. After closure, consider whether you have reached a natural break in the work. A workscope that implemented a few phases from a feature’s checkboxlist is a natural commit unit. Going multiple workscopes between commits is common, though you may prefer committing after every workscope, and your preference will reflect your experience. As starting advice, you should always commit before starting any new Work Plan Document, and at the conclusion of one.

Update documentation if needed. You may wish to occasionally run wsd docs:update to regenerate code documentation if your workscope changed source code. Review whether any plans or rules need adjustment based on what you learned during the session.

Test manually if desired. The QA gauntlet runs automated checks, but there are things only a human can evaluate: whether the UI feels right, whether the API responses make sense in context, whether the feature does what you actually wanted. Manual testing is not required by the workflow, but it is the kind of engagement that keeps you connected to your project.

Start a fresh session. Session cycling (starting a new Claude Code session for each workscope rather than continuing a long-running one) is a core WSD discipline, and the benefits are more substantial than they might initially seem. AI models perform better with smaller prompt history:¹² responses are more focused, hallucination decreases, the assistant follows instructions more precisely, and costs are lower. A fresh session does not mean lost context. WSD’s entire documentation architecture exists to ensure that everything an agent needs is persisted to disk and loadable on demand, which itself is a forcing function for a healthy project. The workscope file, the documentation hierarchy, the workbench artifacts — all of it is available to the next agent without carrying over the conversational baggage of a long-running session. The preparation agents re-curate context from scratch each time, which means each session gets precisely the information it needs rather than inheriting an increasingly noisy accumulation from previous work. Letting sessions run past their natural lifespan leads to the kind of gradual quality drift that is hard to notice in the moment but obvious in retrospect.

The post-workscope routine is brief. Most of the time, it is: review action items, commit, start fresh. The loop continues.

Git Practices and the Git Guardrail

WSD promotes a principle called the Git Guardrail: all commands that modify repository state — add, commit, push, checkout, and every other state-changing git operation — are reserved for the human developer. Agents are permitted to use read-only git commands (status, log, diff, blame) for inspection, but they cannot alter the repository.

This is a deliberate constraint, not a technical limitation. The act of committing is the moment where you, the developer, must understand what changed and why. It is not a rubber stamp. When you review the git diff before staging, you are examining the agent’s work with your own judgment — confirming that the changes make sense, that nothing unexpected was introduced, and that you understand the direction your project is moving. This review habit is what keeps you connected to the codebase even as agents handle an increasing share of the implementation work.

This is not only a quality gate, but it is the primary technique for preventing brain debt. We are all familiar with the technical debt³ that accrues in codebases over time when shortcuts are made for the sake of speed, and the same phenomenon exists in the minds of project owners who consistently detach from the project for the sake of faster development. The Git Guardrail discipline, which becomes progressively easier, prevents this from occurring.

In practice, the diff review becomes lighter over time. WSD aims to both mitigate brain debt as well as relieve the burden of that mitigation. As the rules system matures, as the QA gauntlet catches more issues, and as your specifications become more precise, the gap between what you expect and what the agent produces narrows. You find yourself rarely surprised. But the act of reviewing remains valuable — not because you expect to catch problems, but because it sustains your comprehension of the project’s evolution.

Recovery from Failed Workscopes

Sometimes a workscope fails partway through. The agent might exhaust its context window before completing the work, encounter a design flaw that blocks progress, or produce changes that are fundamentally wrong. When this happens, recovery is straightforward.

Run /wsd:abort. This repairs the checkboxlist state by reverting the [*] marks that were applied when the workscope was assigned, returning them to their previous states. The tasks become available for selection again in a future session. Note that abort repairs task tracking only — it does not touch the code changes the agent made.

Revert the code changes through git. If you have not committed since the workscope began, git checkout . restores every modified file to its last committed state. If you committed other work in between, selective undo or a more targeted revert may be needed.

Depending on the nature of the failure, partial progress may be salvageable. A /wsd:init --custom session with an explanation of what happened and what needs to be rescued can sometimes recover useful work without starting from scratch. Describe what the previous agent accomplished, where it went wrong, and what remains. Having the failed agent output a writeup as a workbench artifact prior to ending its session can ease this process. The fresh agent can pick up from that context and complete the work or adapt the approach.

The combination of /wsd:abort for task tracking and git for code state means that failed workscopes are never catastrophic. The worst case is lost time — the work itself is always recoverable or replaceable.

Adjusting Agent Behavior

As you run workscope cycles, you will encounter situations where agents do not perform as you expect. An agent might use a naming convention you dislike, make an architectural choice that conflicts with your preferences, or repeatedly produce a pattern that you have to correct. These are gaps between your project’s conventions and what the agents know about them.

WSD distributes guardrails across multiple specialized locations rather than cramming everything into a single file. When an agent produces unexpected work, you identify whether the issue is behavioral or architectural and encode the fix in the appropriate place: Agent Rules for behavioral constraints, Design Decisions for project-specific architectural philosophies, or a standards file for task-specific conventions. The Rules Architecture guide covers this system in detail, including the feedback loop by which corrections compound across sessions.