Structured workflow prompt guide

Structured Workflow Prompt Guide

Use this guide for normal planned-feature work that needs a shared specification, one work overview, and one or more ordered direct tasks without phase, milestone, or reconciliation layers.

Structured is the default workflow level when planning-ready specification input exists and no explicit level or parent context selects another level. It preserves shared scope and ordered task ownership while keeping task implementation, evidence, review disposition, and closure task-local. Project review then evaluates the completed direct-task set against the work overview and source specification.

Use .day-shift/workflows/basic-workflow-guide.md for one independent task that does not need an overview. Use .day-shift/workflows/workflow-guide.md for Governed work that needs phases, milestones, reconciliation, cross-team staging, or formal acceptance checkpoints.

Agent priority order:

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

Structured Boundary

The canonical Structured shape is:

.day-shift/planning/structured/<NN>-<work-id>/
├── overview.md
├── tasks/
│   └── <NN>-<task-id>/
│       ├── task-definition.md
│       └── implementation-summary.md
└── project-review.md

The root <NN> represents the level-local implementation_order: values below 10 are zero-padded to two digits and larger root orders retain their full width. Each direct-task <NN> remains the two-digit rendering of that task definition’s parent-local sequence from 1 through 99. The work id, task id, dependencies, attempts, reviews, validations, receipts, and closeout identities remain unprefixed semantic identities. New writes use numbered roots and direct-task directories; unnumbered Structured paths remain compatibility inputs only and move only through explicit digest-bound migration.

In a Structured overview, each ## Task Plan entry records all three task identities with this canonical, machine-readable syntax:

- `01-complete-content-contract-and-validation`
  (`task_id`: `complete-content-contract-and-validation`; sequence: 1): Describe the task outcome.

Here task_id is the unprefixed semantic identity, sequence is the parent-local integer, and the leading reference is ordered_task_root_name, deterministically composed as the two-digit sequence prefix plus task_id. Never copy the prefix into task_id; work task create applies it separately and rejects a prefixed semantic identity before writing. Links-check treats a valid declaration whose pair does not exist yet as a task pending creation and reports a selected-overview work task create recovery action.

project-review.md is created only through an explicit revision-bound review write after read-only project review evidence exists. It is not an implementation summary or milestone reconciliation substitute.

Structured is appropriate when:

• one or more direct tasks share source intent and a work-level outcome
• task ownership and dependency order can be declared without intermediate stages
• every task is independently implementable and closable
• cross-task validation can be reviewed at project closeout
• formal phase or milestone acceptance checkpoints are unnecessary

Promote to Governed before further execution when work needs phases, milestone reconciliation, cross-team staged ownership, long-running decision checkpoints, or a hierarchy that direct dependency order cannot express safely.

Do not create slice, phase, milestone, or reconciliation artifacts inside a Structured root.

Agent Orientation

Start with bounded, read-only orientation:

day-shift agent --format json --detail compact
day-shift agent context --artifact [Structured Overview Or Direct Task] --format json --detail compact
day-shift doctor --artifact [Selected Artifact] --format json

When the overview is known, select it directly. Use work candidates only when no artifact is known. Treat selection, status, inventory, review, and next-action output as derived evidence rather than write authorization.

Prompt Anatomy

Prefer a selected overview, one mode, and one direct request.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]
Mode: [plan|readiness-only|implement|review|close]

[One direct request.]

For one direct task:

Workflow: .day-shift/workflows/structured-workflow-guide.md
Workflow: .day-shift/workflows/task.agent-lifecycle-guide.md
Task definition: [Relative Path To Direct Structured Task]
Mode: [readiness-only|implement]

[One direct request.]

Quick Routing

Intent	Prompt section	Primary command or workflow
Create a Structured root	Create Structured Work	day-shift work create --level structured
Add declared direct tasks	Create Structured Tasks	day-shift work task create
Review work readiness or completion	Review Structured Work	work status / work review
Revalidate stale work scope	Recertify Structured Work	Read-only source, overview, task, and review comparison
Revalidate one stale direct task	Recertify A Structured Task	task.recertify.md
Review one direct task	Review A Structured Task	task readiness-review / task review
Execute one or all tasks	Execute Structured Work	task.agent-lifecycle-guide.md
Persist project disposition	Create Project Review	work project-review create
Materialize review-declared follow-up	Create Review-Declared Follow-Up	work follow-up create
Close the work root	Close Structured Work	work close
Add staged hierarchy	Promote To Governed	work promote

Creation And Revision Prompts

Create Structured Work

Use when: one or more planning-ready specifications need a shared direct-task work boundary.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Workflow: .day-shift/workflows/02-plan-from-spec.md
Spec: [Relative Path To Planning-Ready Specification]
Work id: [Kebab-Case Work Id]

Preview `day-shift work create --level structured --spec <path> --work-id <id> --implementation-order <NN|next> --dry-run`. Verify the numbered Structured destination, matching overview `implementation_order`, root inventory fingerprint, source revisions, defaults, and write preconditions. Apply only after the preview is accepted, then refine the overview without adding phase or milestone decomposition.

For multiple source specifications, repeat --spec and preserve every source in overview traceability. The specifications remain canonical; promotion or planning does not move them.

Likely next structured-workflow-guide prompt: Create Structured Tasks.

Revise A Structured Overview

Use when: the overview exists but its shared outcome, scope, order, or continuation gate needs correction.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]

Revise this overview in place. Preserve source revisions, declare only direct task identities and dependency order, keep project-level acceptance and validation explicit, and stop if the corrected structure requires phases, milestones, or reconciliation.

After overview body changes, run selected-artifact links-check and link-materialization dry-run before any readiness authorization. Apply safe materialization only when the preview stays inside the selected artifact.

Likely next structured-workflow-guide prompt: Review Structured Work or Create Structured Tasks.

Create Structured Tasks

Use when: the overview declares a complete, ordered direct-task set.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Workflow: .day-shift/workflows/02-plan-from-spec.md
Work overview: [Relative Path To Structured Overview]

Build complete Structured task JSON contracts from the overview's declared task set. Preview `day-shift work task create --overview <path> --task <json> ... --dry-run` in dependency order. Require concrete target paths, desired behavior, acceptance criteria, validation commands, rollback or recovery, dependencies, agent mode, evidence profile, and source revision. Verify each returned `sequence`, `sequencePrefix`, `orderedTaskRootName`, numbered pair path, and the parent-local task inventory fingerprint. Apply only the exact declared set after a clean preview.

The declaration’s task_id, sequence, and ordered_task_root_name must match the preview exactly. A sequence/root mismatch or prefixed semantic task ID is invalid and blocks before the first write. Do not invent undeclared tasks, infer ownership from filenames, or write a task pair whose target, adapter, validation, dependency, or rollback seam remains unresolved. Return a refinement finding instead.

After task creation, validate and safely materialize newly resolvable links on the overview before task readiness review.

Likely next structured-workflow-guide prompt: Review A Structured Task.

Review Prompts

Review Structured Work

Use when: the direct-task set needs readiness, progress, or closeout evidence.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]

Run `day-shift work status --overview <path>` and `day-shift work review --overview <path>`. Keep both commands read-only. Report source coverage, task totals, incomplete or blocked task pairs, review eligibility, closeout posture, and the exact next action.

Before task creation, treat missing declared direct tasks as planning blockers. During implementation, distinguish expected pending task evidence from topology defects. Before project review, require every declared task pair to be completed, current, and non-placeholder.

Likely next structured-workflow-guide prompt: Create Structured Tasks, Execute Structured Work, or Create Project Review.

Recertify Structured Work

Use when: source revisions, implementation behavior, or completed task evidence may have made the overview stale.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]

Recertify this work read-only against its registered specifications, current overview revision, direct task set, paired summaries, project review if present, and observed implementation behavior. Recommend whether it should remain active, be revised, be treated as completed or superseded, or be promoted to Governed. Do not create or mutate artifacts in this pass.

Likely next structured-workflow-guide prompt: Revise A Structured Overview, Review Structured Work, or Promote To Governed.

Recertify A Structured Task

Use when: one direct task may be stale, already satisfied, duplicated, or invalidated by earlier sibling work.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Prompt: .day-shift/prompts/user/task.recertify.md
Task definition: [Relative Path To Direct Structured Task]

Recertify this task against the Structured overview, declared dependency order, current implementation, sibling task evidence, and its paired summary. Keep the pass read-only and recommend whether the task should remain active, be revised, be treated as completed or superseded evidence, or trigger Governed promotion.

Likely next structured-workflow-guide prompt: Revise A Structured Overview, Review A Structured Task, or Promote To Governed.

Review A Structured Task

Use when: one direct task needs readiness or completed-evidence review.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Workflow: .day-shift/workflows/task.agent-lifecycle-guide.md
Prompt: .day-shift/prompts/user/task.review.md
Task definition: [Relative Path To Direct Structured Task]

Run revision-bound readiness review with explicit reviewer identity and timestamp. Confirm source revision, declared order, dependency completion, concrete targets, validation, rollback, execution mode, and paired-summary handoff. Stop after review unless authorization or implementation is separately requested.

For completed task evidence, use day-shift task review and day-shift implementation-summary review. Do not use project review to conceal an incomplete direct task.

Likely next structured-workflow-guide prompt: Execute One Structured Task or Revise A Structured Overview.

Implementation And Evidence Prompts

Execute One Structured Task

Use when: one direct task is the selected implementation boundary.

Workflow: .day-shift/workflows/structured-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 Direct Structured Task]
Mode: implement

Execute this task as a full task cycle. Preserve its Structured overview parent and declared order, stop on readiness or dependency blockers, implement only declared scope, capture revision-bound validation and implementation evidence, build and complete the paired summary, run read-only summary review, record explicit disposition, preview task close, and close only on current accepted evidence. Report discovered work without changing the overview or creating siblings implicitly.

After clean closeout, return to the overview and select the next declared ready task.

Likely next structured-workflow-guide prompt: Execute One Structured Task for the next sibling or Review Structured Work.

Execute Structured Work

Use when: the user authorizes the full direct-task lifecycle for one Structured overview.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]
Mode: implement

Execute this Structured work as a strict full cycle. Scaffold only the overview's declared direct tasks, validate and safely materialize overview links before readiness authorization, execute tasks in declared dependency order through `.day-shift/workflows/task.agent-lifecycle-guide.md`, close each task only on current accepted evidence, route deterministic post-baseline additive contract-impact obligations through `task scope-recover` in the existing run, stop on the first blocking dependency or true material authority-boundary change, keep discovered work separate, rerun read-only work status and work review after the final task, and stop before project-review or work-close writes unless those writes are explicitly authorized.

This workflow does not delegate to milestone or phase lifecycles and does not build reconciliation.

Authorized Pre-Write Contract Revision Recovery

Do not treat an exact required writable/generated mirror, consumer, or validation revealed by the current schema-v2 impact fingerprint as a material scope change. Preserve the current direct phase-less or phase-anchored .day-shift/runs/run-<run-id>/, preview/apply task scope-recover with exact run/task/attempt/revision/baseline/fingerprint identities, and follow its single continuation. Untouched additions amend the attempt with supplemental baseline evidence. Already-changed additions preserve the predecessor as contract_gap, open an attribution successor, and return the exact successor-baseline plan that captures a new baseline containing the expanded declared target set. Neither case requires a sibling run, a phase checkpoint, or hand-edited lifecycle metadata.

User authorization for a true material direct-task scope correction is distinct from command eligibility. Objective, acceptance, ownership, external-authority, destructive-boundary, read-only, frozen, unknown, arbitrary, or incomplete changes remain no-write stops. For a separately authorized task contract revision, use the task guide’s bounded direct Structured resume run revise-contract route. A genuinely baseline-only attempt may then use task attempt-supersede; when readiness detects post-baseline target or lifecycle evidence, preserve it through the accepted checkpoint and task attempt-contract-revise instead. Exact deterministic additive closure remains owned by task scope-recover.

Historical attempts, baselines, run entries, receipts, and invalidation identities remain immutable. A user-approved contract edit never authorizes readiness replacement, attempt supersession, project review, or work close by itself; each write still requires its own current preview and explicit apply.

Likely next structured-workflow-guide prompt: Create Project Review.

Build Or Review Structured Task Evidence

Use when: one paired implementation summary needs evidence completion or review.

Workflow: .day-shift/workflows/structured-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 Direct Structured Task]
Implementation summary: [Relative Path To Paired Summary]

Run `day-shift implementation-summary build --task-definition <path>`, complete current-attempt changed paths, acceptance results, validation, deviations, residual risk, and discovered work, then run read-only implementation-summary review. Preserve Runtime, Contract, or Hybrid evidence semantics.

Do not create milestone reconciliation. Structured rolls completed direct-task evidence into project review.

Likely next structured-workflow-guide prompt: Review Structured Work.

Project Review And Closeout Prompts

Create Project Review

Use when: work review reports complete, current Structured closeout evidence.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]

Run read-only `day-shift work review --overview <path>` first. If eligible and project-review persistence is explicitly authorized, preview `day-shift work project-review create` with the exact overview, reviewer, disposition, summary, and any complete follow-up task contracts. Apply only after inspecting revision-bound preconditions. Re-open `project-review.md` and verify source coverage, task evidence, disposition, follow-up declarations, and reviewed revision.

Allowed dispositions are accepted, accepted_with_follow_up, changes_requested, and blocked. Review findings do not authorize this write.

Likely next structured-workflow-guide prompt: Create Review-Declared Follow-Up or Close Structured Work.

Create Review-Declared Follow-Up

Use when: canonical project review declares complete follow-up task contracts and the work must remain open.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Project review: [Relative Path To Structured Project Review]

Preview `day-shift work follow-up create --project-review <path> --task-id <id> ... --dry-run` for only the task ids declared by the current project review. Verify parent-local `sequence`, `sequencePrefix`, `orderedTaskRootName`, numbered pair paths, and the task inventory fingerprint. Apply in dependency order, validate the new pairs, and return them through the normal Structured task lifecycle. Do not invent additional follow-up from review prose.

After the follow-up tasks close, rerun read-only work review and create a new project review bound to the current overview and task-set revisions. Do not close the work root from the pre-follow-up review.

Likely next structured-workflow-guide prompt: Review A Structured Task, then Create Project Review.

Close Structured Work

Use when: the canonical project review and every direct task pair support terminal closure.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Work overview: [Relative Path To Structured Overview]
Project review: [Relative Path To Structured Project Review]

Run `day-shift work close --overview <path> --project-review <path> --dry-run`. Verify current overview revision, terminal task pairs, accepted project disposition, follow-up completion, and overview-only write scope. If clean and explicitly authorized, rerun without `--dry-run`, then re-open the overview and project review and rerun read-only work status/review.

Work close must not propagate child mutations or repair incomplete task pairs.

Likely next structured-workflow-guide prompt: Promote To Governed only if later work needs a new staged hierarchy.

Promotion Prompt

Promote To Governed

Use when: the Structured boundary no longer expresses the required staging or review pressure.

Workflow: .day-shift/workflows/structured-workflow-guide.md
Workflow: .day-shift/workflows/workflow-guide.md
Work overview: [Relative Path To Structured Overview]

Preview `day-shift work promote --overview <path> --to governed` with an explicit implementation order, Governed slice identity, destination phase, and one task-to-milestone mapping per direct task. Preserve the exact preview plan identity and source work id. Apply only with explicit actor, reason, authorization, and current preconditions.

Promotion is transactional and preservation-first. Never move or duplicate Structured artifacts manually, and do not continue Structured implementation after a promotion transaction reports partial state.

Likely next structured-workflow-guide prompt: use .day-shift/workflows/workflow-guide.md after successful promotion.

Stop Conditions

Stop before the next write or implementation gate when:

• specification revisions are stale or not planning-ready
• overview task identity, dependency order, target ownership, validation, or rollback is incomplete
• a declared child is missing or mislabeled without disposition evidence
• readiness or authorization evidence is incomplete or stale
• the next task depends on incomplete producer work
• implementation discovers a phase, milestone, or reconciliation requirement
• project review is requested before all declared task evidence is complete
• follow-up work is not declared by canonical project review
• promotion or closeout reports a conflict, partial transaction, or recovery requirement

Report the selected overview or task, first blocker, required evidence or decision, and whether the correct next boundary remains Structured or requires Governed promotion.

Prompt Snippets

Stop After Read-Only Review

Run Structured status and review surfaces only. Report blockers, totals, posture, and the next callable action, then stop before project-review, follow-up, closeout, promotion, or task writes.

Preserve Direct-Task Topology

Keep tasks directly under the Structured overview. Do not create slice, phase, milestone, or reconciliation artifacts. If those boundaries become necessary, stop and recommend Governed promotion.

Declared-Only Scaffolding

Create only task ids declared by the selected overview or canonical project review, in dependency order, from complete task contracts. Missing executable seams block creation.

Explicit Write

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