---
artifact_schema_version: 1
artifact_type: workflow
workflow_id: basic-workflow-prompt-guide
---

# Basic Workflow Prompt Guide

Use this guide for one independent, implementation-sized task whose target paths, dependencies, validation, and rollback boundary are already known.

Basic is a workflow level, not a reduced safety mode. It uses the same task readiness, revision binding, implementation evidence, read-only review, explicit disposition, and closeout boundaries as other levels. It omits a work overview, phases, milestones, reconciliation, and project review because one task pair is the complete planning unit.

Use `.day-shift/workflows/structured-workflow-guide.md` when several direct tasks share one specification or require ordering. Use `.day-shift/workflows/workflow-guide.md` for Governed work that needs phases, milestones, reconciliation, or formal staged review.

Agent priority order:

1. Read `.day-shift/agents.md`.
2. Use this guide to preserve the Basic topology and choose the human-facing prompt.
3. Use `.day-shift/workflows/task.agent-lifecycle-guide.md` for full task execution.
4. Use the numbered workflows for detailed planning, implementation, and summary rules.

## Basic Boundary

The canonical Basic shape is:

```text
.day-shift/planning/basic/tasks/<NN>-<task-id>/
├── task-definition.md
└── implementation-summary.md
```

`<NN>` represents the root-local `implementation_order`: values below `10` are zero-padded to two digits and larger values retain their full width. `<task-id>` remains the unprefixed semantic task, dependency, attempt, review, validation, receipt, and closeout identity. New writes use the numbered directory and record matching `implementation_order` metadata in both paired artifacts. Unnumbered Basic directories remain compatibility inputs only and require explicit migration preview/apply rather than implicit relocation.

Basic is appropriate only when:

- the work is one independently closable change
- implementation targets are concrete
- dependencies and sequencing are resolved
- validation commands are executable
- rollback or recovery is explicit
- coordination and review pressure are low

Promote before implementation when the work gains dependent sibling tasks, shared feature-level acceptance criteria, unresolved sequencing, staged review requirements, or milestone reconciliation needs.

Do not create an overview, phase, milestone, reconciliation, or project-review artifact for Basic work. `work status`, `work review`, `work project-review`, and `work close` operate on Structured or Governed work roots; Basic closes through its task pair.

## Agent Orientation

Start with bounded, read-only orientation:

```text
day-shift agent --format json --detail compact
day-shift agent context --artifact [Basic Task Definition] --format json --detail compact
day-shift doctor --artifact [Basic Task Definition] --format json
```

If the task does not exist yet, use bounded discovery or construct the complete task contract before invoking `work create`. Do not use repository-wide scans to guess task ownership or targets.

## Prompt Anatomy

Prefer a selected workflow, one selected artifact, one mode, and one direct request.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Task definition: [Relative Path To Basic Task Definition]
Mode: [readiness-only|implement]

[One direct request.]
```

For creation, provide the complete contract inputs instead of a task path:

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Level: basic
Task id: [Kebab-Case Task Id]

Create one independent Basic task pair from the supplied objective, target paths, acceptance criteria, validation commands, dependencies, constraints, and rollback guidance.
```

## Quick Routing

| Intent | Prompt section | Primary command or workflow |
| --- | --- | --- |
| Create one Basic task pair | Create Basic Work | `day-shift work create --level basic` |
| Check whether Basic still fits | Review Basic Fit | Read-only review and promotion-boundary check |
| Revalidate a stale or possibly satisfied task | Recertify A Basic Task | `task.recertify.md` |
| Review implementation readiness | Review A Basic Task | `day-shift task readiness-review` |
| Execute the task end to end | Execute A Full Basic Cycle | `task.agent-lifecycle-guide.md` |
| Refresh or review task evidence | Build Or Review Basic Evidence | `implementation-summary build` / `review` |
| Close accepted work | Close A Basic Task | `task close` |
| Add coordinated work | Promote Basic Work | `task promote` |
| Repair accepted closed work | Repair A Closed Basic Task | `task review-repair` |

## Creation And Revision Prompts

### Create Basic Work

Use when: one complete independent task contract is ready.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Level: basic
Task id: [Task Id]

Preview `day-shift work create --level basic --implementation-order <NN|next>` with the complete task contract. Require concrete target paths, current and desired behavior, acceptance criteria, validation commands, rollback or recovery, dependencies, constraints, agent mode, and evidence profile. Verify the returned `implementationOrder`, `implementationOrderSource`, `orderedRootName`, and root inventory fingerprint before apply. Apply only after the preview is accepted. Do not create an overview or downstream hierarchy.
```

Use `--task <json>`, `--input-file <path>`, `--stdin`, direct flags, or bounded `--interactive` input as advertised by current command help. A second Basic task requires explicit independence evidence; never use `--confirm-independent` to bypass a real dependency or shared acceptance boundary.

Likely next basic-workflow-guide prompt: [Review A Basic Task](#review-a-basic-task).

### Revise A Basic Task

Use when: the task exists but is not implementation-ready.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Prompt: .day-shift/prompts/user/task.build.md
Task definition: [Relative Path To Basic Task Definition]

Revise this task in place. Keep it independently closable, make every target and validation seam concrete, preserve source traceability, and stop if the revision requires coordinated sibling work.
```

After revision, run selected-artifact link validation, preview safe link materialization, and rerun readiness review. Review output remains read-only and does not authorize implementation.

Likely next basic-workflow-guide prompt: [Review Basic Fit](#review-basic-fit) or [Review A Basic Task](#review-a-basic-task).

## Review Prompts

### Review Basic Fit

Use when: scope may have grown beyond one independent task.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Task definition: [Relative Path To Basic Task Definition]

Review whether this task remains one independent, implementation-sized unit with known targets, resolved dependencies, executable validation, and low coordination pressure. Keep the review read-only. If the boundary fails, recommend Structured or Governed promotion and name the exact failed condition.
```

Likely next basic-workflow-guide prompt: [Execute A Full Basic Cycle](#execute-a-full-basic-cycle) or [Promote Basic Work](#promote-basic-work).

### Recertify A Basic Task

Use when: the task may be stale, already satisfied, duplicated, or no longer independent.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Prompt: .day-shift/prompts/user/task.recertify.md
Task definition: [Relative Path To Basic Task Definition]

Recertify this task against current implementation behavior, its paired summary, source references, and the Basic boundary. Keep the pass read-only. Recommend whether the task should remain active, be revised, be treated as completed or superseded evidence, or be promoted before further implementation.
```

Likely next basic-workflow-guide prompt: [Revise A Basic Task](#revise-a-basic-task), [Review A Basic Task](#review-a-basic-task), or [Promote Basic Work](#promote-basic-work).

### Review A Basic Task

Use when: implementation readiness or completed task evidence needs a read-only check.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Prompt: .day-shift/prompts/user/task.review.md
Task definition: [Relative Path To Basic Task Definition]

Run the revision-bound task readiness review with explicit reviewer identity and timestamp. Report missing evidence, dependency blockers, sequencing issues, and the paired-summary handoff. Stop after review; do not authorize or implement unless separately requested.
```

For completed work, use `day-shift task review --task-definition <path>` and `day-shift implementation-summary review --task-definition <path>` as read-only evidence surfaces.

Likely next basic-workflow-guide prompt: [Execute A Full Basic Cycle](#execute-a-full-basic-cycle) or [Revise A Basic Task](#revise-a-basic-task).

## Implementation And Evidence Prompts

### Execute A Full Basic Cycle

Use when: one Basic task is ready and implementation is authorized.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Workflow: .day-shift/workflows/task.agent-lifecycle-guide.md
Workflow: .day-shift/workflows/03-implement-from-task.md
Prompt: .day-shift/prompts/user/task.next.md
Task definition: [Relative Path To Basic Task Definition]
Mode: implement

Execute this Basic task as one full cycle. Preserve the direct task-pair topology, stop on readiness or revision blockers, open and bind the current attempt through supported task commands, capture required runtime attribution and validation evidence, implement only declared scope, build and complete the paired implementation summary, run read-only summary review, record the explicit review disposition, preview task close, and close only when the exact accepted evidence is current. Report blocked and discovered work separately.
```

Use this strict Basic command spine in the displayed order; the detailed guards and full arguments remain authoritative in `.day-shift/workflows/task.agent-lifecycle-guide.md`.

1. Save a complete `<day-shift-cli> task readiness-review --task-definition <path> --reviewed-by <actor> --reviewed-at <timestamp>` result and branch on `reviewedReadiness`. For `needs_more_evidence`, preview and apply `<day-shift-cli> task readiness-authorize --task-definition <path> --review-result <readiness-review.json> --dry-run` only against that current revision-bound result. For `ready_to_implement`, do not pass the different fresh review to `task readiness-authorize`; preserve the stored authorization and route to the `task attempt-open --dry-run` verifier. Exact original readiness-review replay is receipt recovery only. Stop on every other state or incomplete, invalid, stale, or non-applicable authorization evidence.
2. Preview and apply `<day-shift-cli> task attempt-open --task-definition <path> --attempt-id <attempt-id> --opened-at <timestamp> --dry-run`; for an already-ready task, require the preview to prove that its stored authorization is complete, valid, and revision-applicable. A different fresh review remains fail-closed. Preserve the returned `readinessReviewId`, and when required preview and apply `<day-shift-cli> task baseline --task-definition <path> --task-cycle-id <attempt-id> --checkpoint-id <attempt-readiness-review-id> --captured-by <actor> --captured-at <timestamp> --dry-run` before the first task write.
3. Implement only the declared scope. Run each task-declared validation through command-owned `<day-shift-cli> task validation-record --task-definition <path> ... [--expect-json <json-pointer>=<JSON-literal>]... -- <exact argv...>`. Use repeatable `--expect-json` assertions whenever a structured command's acceptance depends on JSON stdout values rather than exit status alone; dry-run must project the exact assertion plan without execution, and apply must record failed evidence for invalid or truncated JSON, missing pointers, or unequal values even when the process exits zero. Stop on failed, stale, partial, conflicting, or non-callable evidence.
4. Run the pre-authoring `<day-shift-cli> implementation-summary build --task-definition <path>` with run attribution kept on the task definition, manually complete the paired summary body, then run the post-authoring `<day-shift-cli> implementation-summary build --task-definition <path>` with run attribution moved to the paired summary so derived runtime attribution reflects the finished authored evidence without staling the run during authoring.
5. Preview `<day-shift-cli> task implementation-complete --task-definition <path> --attempt-id <attempt-id> --task-revision <task-revision> --completed-by <actor> --completed-at <timestamp> --dry-run`; apply only when `applicable: true`. Treat `applicable: false` as a no-write result and continue only for an explicitly typed profile-valid no-op whose canonical pair already satisfies the profile requirement; otherwise stop.
6. Run the manifest-bound read-only `<day-shift-cli> implementation-summary review --task-definition <path>` without shell redirection or `--review-result-path`. Treat this pending-disposition review receipt as disposition-only: use its exact indexed caller-consumable evidence path to preview and apply `<day-shift-cli> task disposition --task-definition <path>` with accepted disposition, then run a fresh manifest-bound `<day-shift-cli> implementation-summary review --task-definition <path>` after disposition. Preview and apply `<day-shift-cli> task close --task-definition <path>` only with that different current accepted close-authorizing evidence path; the pre-disposition receipt remains invalid for close.
7. Re-open the direct task pair and verify completed task metadata plus one completed, accepted, closed current attempt. Verify the exact indexed task-close gate projects direct phase-less terminal state `task_close_complete` with `nextPermittedGate: null`. Do not create reconciliation, project-review, phase, or parent artifacts for Basic work.

Every previewed write must report the documented preview outcome, current pair revisions or freshness inputs, exact intended paths, and no conflicts before apply. Stop instead of advancing after stale, blocked, partial, conflicting, non-callable, or unexpected output.

Do not route successful Basic completion to milestone reconciliation. The next terminal action is task close. If discovered work is dependent or shares acceptance with this task, stop and recommend promotion instead of creating another implicit Basic task.

Likely next basic-workflow-guide prompt: [Build Or Review Basic Evidence](#build-or-review-basic-evidence) or [Close A Basic Task](#close-a-basic-task).

### Build Or Review Basic Evidence

Use when: implementation happened and the paired summary needs completion or review.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Workflow: .day-shift/workflows/04-summarize-and-reconcile.md
Prompt: .day-shift/prompts/user/implementation.build.md
Task definition: [Relative Path To Basic Task Definition]
Implementation summary: [Relative Path To Paired Implementation Summary]

Run `day-shift implementation-summary build --task-definition <path>`, then complete changed paths, acceptance results, validation evidence, deviations, residual risk, and discovered work. Keep Runtime, Contract, or Hybrid evidence semantics intact and do not fabricate a reconciliation handoff.
```

Review with `day-shift implementation-summary review --task-definition <path>`. Review is read-only; apply lifecycle metadata only through the current command-owned transition.

Likely next basic-workflow-guide prompt: [Close A Basic Task](#close-a-basic-task).

## Closeout And Promotion Prompts

### Close A Basic Task

Use when: the current attempt is complete, accepted, and supported by current paired evidence.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Task definition: [Relative Path To Basic Task Definition]

Run `day-shift task close --task-definition <path> --dry-run`. Inspect revision, attempt, implementation, validation, disposition, and pair preconditions. If clean and explicitly authorized, rerun without `--dry-run`. Re-open both task artifacts and verify the canonical terminal pair. Do not run Structured project review or work close.
```

Likely next basic-workflow-guide prompt: [Repair A Closed Basic Task](#repair-a-closed-basic-task) only if later evidence requires correction.

### Promote Basic Work

Use when: Basic no longer fits before implementation or follow-up work requires a coordinated parent.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Workflow: .day-shift/workflows/structured-workflow-guide.md
Task definition: [Relative Path To Basic Task Definition]

Preview `day-shift task promote --task-definition <path> --to structured --implementation-order <NN|next>` with the required work identity and planning-ready specification evidence. Verify the numbered Structured root and `tasks/<NN>-<task-id>/` destination plus root/task ordering fields. Preserve the unprefixed task identity and exact preview identity. Apply only with the returned plan id, actor, reason, and explicit authorization.
```

Use `--to governed` only when staged hierarchy and reconciliation are already justified. Promotion is transactional; never move Basic task files manually.

Likely next basic-workflow-guide prompt: use the selected destination guide after promotion.

### Repair A Closed Basic Task

Use when: accepted closed work needs a narrow successor repair.

```text
Workflow: .day-shift/workflows/basic-workflow-guide.md
Task definition: [Relative Path To Closed Basic Task Definition]

Keep the closed evidence immutable. Obtain a fresh readiness review, preview `day-shift task review-repair` with the exact review result and successor attempt identity, and apply only when the repair scope remains independently closable. Promote first if repair scope requires coordinated work.
```

Likely next basic-workflow-guide prompt: [Execute A Full Basic Cycle](#execute-a-full-basic-cycle) for the authorized successor attempt.

## Stop Conditions

Stop before implementation or mutation when:

- the task is not independently closable
- target paths, adapters, validation, rollback, or dependencies are incomplete
- another task must run first
- the readiness result is incomplete or stale
- the selected task revision does not match authorization evidence
- implementation needs an overview, shared acceptance boundary, staged review, or reconciliation
- validation cannot establish the task acceptance criteria
- a command reports partial state, transaction recovery, or a non-callable next action

Report the selected task, first blocker, required evidence or decision, and recommended destination level.

## Prompt Snippets

### Stop After Review

```text
Keep this pass read-only. Report readiness, evidence gaps, and the next callable action, then stop before authorization, implementation, disposition, closeout, or promotion.
```

### Preserve The Basic Boundary

```text
Do not create an overview, phase, milestone, reconciliation, or project review. If the work needs any of those boundaries, stop and recommend promotion.
```

### Explicit Write

```text
Preview the descriptor-backed write first. Apply only the exact selected-artifact mutation after preconditions and authorization are explicit.
```
