Daily Workflow

Daily workflow: complete a first task

This chapter follows an adopted project from an objective to a reviewed result. Complete First-time setup first. The public template remains blank; the examples below belong in your project's copy.

1. Open the correct project and load its state

Confirm the workspace, selected .SYSTEMX version, and applicable repository instructions. Follow the selected START-HERE.md: standard, current focus, Global context, Master Plan, project memory, relevant work, and your agent memory. For a managed installation, print the bounded Agent 0 context:

systemx run --target "/path/to/project" --offline -- context --agent agent.0

The explicit offline flag keeps this example from checking for updates. Omit it when you want the project's configured startup release check to apply. In the 1.8.9 manager, a notice does not select an update. Read full source records whenever the packet is truncated or the task needs more detail.

Recheck facts that may have changed: local edits, branch or source revision, active jobs, permissions, and the service you intend to inspect. If this is a chat-only project, load the saved handoff and use Chat setup.

2. Define one observable outcome

Write down the result and how you will recognize success. For example: “Users can recover a saved draft after reopening the application, demonstrated by a focused check against the current implementation.” Keep the broader outcome in the Master Plan and the next bounded piece of work in the task ledger.

Avoid treating “build the whole app” as one verifiable task. Break it into reviewable outcomes, connect dependencies, and select the next ready task. An existing task should be continued using its ID rather than recreated.

3. Create and select the task

For a small documentation example:

systemx run --target "/path/to/project" --offline -- task-add \
  --title 'Document the verified local startup command' \
  --owner agent.0 \
  --scope 'README.md' \
  --acceptance 'README describes the existing startup command and evidence records the actual result' \
  --next 'Inspect the project scripts and verify the intended startup command'

Read the returned task ID. The following examples use TASK-001; replace it with the real ID from your project.

systemx run --target "/path/to/project" --offline -- focus \
  --objective 'Make local startup reproducible' --task TASK-001
systemx run --target "/path/to/project" --offline -- task-show TASK-001
systemx run --target "/path/to/project" --offline -- task-set TASK-001 \
  --status in_progress --next 'Inspect and exercise the existing startup command'

focus replaces the selected focus set; include all task IDs you intend to keep selected. It does not change task statuses. The current limit of ten focus IDs is a display/context choice, unrelated to the number of agents.

4. Do the work and record evidence

Use the project's actual tools within the task's scope. Preserve unrelated edits. Record the command or observation, relevant revision or artifact, result, limitations, and the next action. Keep large output in a suitable project evidence location and link to it. Use only a small sanitized summary in shared memory.

If you need parallel work, explicitly authorize it and follow Agent 0 and subagents. Agent 0 coordinates shared resources and canonical ledger writes. If work is blocked, record the concrete blocker and the condition needed to proceed rather than repeatedly retrying an unchanged failure. See Task workflow for status syntax.

For a separate installed CLI provider, Agent Y can take one assigned task through an isolated worktree and optional draft-PR handoff. Select the provider, exact repo/base, allowed files, prompt, and PR opt-in for that task. Count the CLI run and any app-native subagents against one project concurrency, token, and resource budget. Read the actual job and GitHub state back before recording a result; a prepared job does not imply execution.

5. Submit the result and review it

After saving real evidence, replace the example reference below with its actual location. Never create a completion record using a placeholder or invented result.

systemx run --target "/path/to/project" --offline -- task-set TASK-001 \
  --status needs_review --evidence 'path/to/actual-check-result.md'

Agent 0 or the user reviews the original acceptance criteria, the change, and the evidence. Fixes return to active work; unresolved prerequisites remain blocked. Only after the review succeeds:

systemx run --target "/path/to/project" --offline -- task-set TASK-001 \
  --status done --reviewer agent.0

The CLI checks record consistency and requires review/evidence for completion. It does not inspect the evidence's truth or authenticate a reviewer. An Agent 0 self-review in solo work is not an independent review. Use a separate reviewer when project policy or the risk warrants one. Completion also does not authorize publication, deployment, spending, or another external action by itself.

6. Leave a usable checkpoint

Update the task's next action and relevant agent memory. Save a dated checkpoint when handing off, pausing, or approaching context limits. Include the objective, task IDs, changes, actual checks, evidence, uncertainty, active job handles, and one concrete next step. Promote only reviewed, durable facts to project memory.

A checkpoint must exist before selecting it with focus --checkpoint. It is historical evidence; the next session still rechecks changing state. Follow Planning and memory for the record format and Prompt cookbook for a copyable handoff request.

Use the configured project checks to validate the work. Use .SYSTEMX validation to check the records. These prove different things. Once acceptance passes, continue to the next ready task or report the completed outcome and remaining limits; avoid rerunning the entire project history without a relevant reason.

Next: Agent 0 and subagents · Anti-drift and long-running work

Keep time and review bounded

If X/Y/Z roles are enabled, record meaningful work/check/delivery observations with Agent X, use Agent Y only for an authorized CLI channel, then use Agent Z once at the acceptance boundary. Track the remaining difference between the idea, implemented change, checked revision, delivered artifact, and observed live behavior. Use original evidence and reuse unchanged reports. Agent 0 chooses the next bounded action or accepts the task; the scorecard and schedule ledger never do this automatically.

Scale a task into a complete project

Use the one-shot project guide for researched briefs, phases, milestone gates, task dependencies, worker waves, and final delivery. With several chats or bots, follow the shared workspace handoff so every turn resumes the same scope and verified snapshot.

Request detail only for the selected task

If a task needs brand, CSS tokens, research, policy, data, or archive detail, ask Agent Alpha for the relevant specialist(s) in this scope. Inspect any matching completed result before starting work. Carry its revision and original evidence into the task packet, and update only facts changed by accepted work. Keep raw/private/large files under DATA. This optional detail step does not create another status ledger, acceptance path, or repeated daily checklist.