Basic workflow prompt guide
Basic Workflow Prompt Guide
Section titled “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:
- Read
.day-shift/agents.md. - Use this guide to preserve the Basic topology and choose the human-facing prompt.
- Use
.day-shift/workflows/task.agent-lifecycle-guide.mdfor full task execution. - Use the numbered workflows for detailed planning, implementation, and summary rules.
Basic Boundary
Section titled “Basic Boundary”The canonical Basic shape is:
.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
Section titled “Agent Orientation”Start with bounded, read-only orientation:
day-shift agent --format json --detail compactday-shift agent context --artifact [Basic Task Definition] --format json --detail compactday-shift doctor --artifact [Basic Task Definition] --format jsonIf 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
Section titled “Prompt Anatomy”Prefer a selected workflow, one selected artifact, one mode, and one direct request.
Workflow: .day-shift/workflows/basic-workflow-guide.mdTask 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:
Workflow: .day-shift/workflows/basic-workflow-guide.mdLevel: basicTask 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
Section titled “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
Section titled “Creation And Revision Prompts”Create Basic Work
Section titled “Create Basic Work”Use when: one complete independent task contract is ready.
Workflow: .day-shift/workflows/basic-workflow-guide.mdLevel: basicTask 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.
Revise A Basic Task
Section titled “Revise A Basic Task”Use when: the task exists but is not implementation-ready.
Workflow: .day-shift/workflows/basic-workflow-guide.mdPrompt: .day-shift/prompts/user/task.build.mdTask 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 or Review A Basic Task.
Review Prompts
Section titled “Review Prompts”Review Basic Fit
Section titled “Review Basic Fit”Use when: scope may have grown beyond one independent task.
Workflow: .day-shift/workflows/basic-workflow-guide.mdTask 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 or Promote Basic Work.
Recertify A Basic Task
Section titled “Recertify A Basic Task”Use when: the task may be stale, already satisfied, duplicated, or no longer independent.
Workflow: .day-shift/workflows/basic-workflow-guide.mdPrompt: .day-shift/prompts/user/task.recertify.mdTask 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, Review A Basic Task, or Promote Basic Work.
Review A Basic Task
Section titled “Review A Basic Task”Use when: implementation readiness or completed task evidence needs a read-only check.
Workflow: .day-shift/workflows/basic-workflow-guide.mdPrompt: .day-shift/prompts/user/task.review.mdTask 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 or Revise A Basic Task.
Implementation And Evidence Prompts
Section titled “Implementation And Evidence Prompts”Execute A Full Basic Cycle
Section titled “Execute A Full Basic Cycle”Use when: one Basic task is ready and implementation is authorized.
Workflow: .day-shift/workflows/basic-workflow-guide.mdWorkflow: .day-shift/workflows/task.agent-lifecycle-guide.mdWorkflow: .day-shift/workflows/03-implement-from-task.mdPrompt: .day-shift/prompts/user/task.next.mdTask 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.
- Save a complete
<day-shift-cli> task readiness-review --task-definition <path> --reviewed-by <actor> --reviewed-at <timestamp>result and branch onreviewedReadiness. Forneeds_more_evidence, preview and apply<day-shift-cli> task readiness-authorize --task-definition <path> --review-result <readiness-review.json> --dry-runonly against that current revision-bound result. Forready_to_implement, do not pass the different fresh review totask readiness-authorize; preserve the stored authorization and route to thetask attempt-open --dry-runverifier. Exact original readiness-review replay is receipt recovery only. Stop on every other state or incomplete, invalid, stale, or non-applicable authorization evidence. - 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 returnedreadinessReviewId, 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-runbefore the first task write. - 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-jsonassertions 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. - 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. - 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 whenapplicable: true. Treatapplicable: falseas 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. - 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. - 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_completewithnextPermittedGate: 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 or Close A Basic Task.
Build Or Review Basic Evidence
Section titled “Build Or Review Basic Evidence”Use when: implementation happened and the paired summary needs completion or review.
Workflow: .day-shift/workflows/basic-workflow-guide.mdWorkflow: .day-shift/workflows/04-summarize-and-reconcile.mdPrompt: .day-shift/prompts/user/implementation.build.mdTask 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.
Closeout And Promotion Prompts
Section titled “Closeout And Promotion Prompts”Close A Basic Task
Section titled “Close A Basic Task”Use when: the current attempt is complete, accepted, and supported by current paired evidence.
Workflow: .day-shift/workflows/basic-workflow-guide.mdTask 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 only if later evidence requires correction.
Promote Basic Work
Section titled “Promote Basic Work”Use when: Basic no longer fits before implementation or follow-up work requires a coordinated parent.
Workflow: .day-shift/workflows/basic-workflow-guide.mdWorkflow: .day-shift/workflows/structured-workflow-guide.mdTask 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
Section titled “Repair A Closed Basic Task”Use when: accepted closed work needs a narrow successor repair.
Workflow: .day-shift/workflows/basic-workflow-guide.mdTask 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 for the authorized successor attempt.
Stop Conditions
Section titled “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
Section titled “Prompt Snippets”Stop After Review
Section titled “Stop After Review”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
Section titled “Preserve The Basic Boundary”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
Section titled “Explicit Write”Preview the descriptor-backed write first. Apply only the exact selected-artifact mutation after preconditions and authorization are explicit.