feat(workflows): add coding-backwards workflow for copilot

[pranavsankar2]

Summary

Adds a general-purpose coding-backwards workflow for the Copilot agent that implements the 4-step "Coding Backwards" methodology as an interactive, conversational pipeline. It guides users through architecting and building any new software project from scratch by deferring code generation until after requirements are fully understood.

Changes

• New file: .atomic/workflows/coding-backwards/copilot/index.ts — 4-stage sequential workflow using defineWorkflow<"copilot">
• Stage 1 – Write the Readme: Interviews the user and collaboratively drafts a detailed README.md covering architecture, data structures, and future possibilities before any code is written
• Stage 2 – Make Skeleton Files: Scaffolds empty files and placeholder functions with header comments based on the agreed-upon README
• Stage 3 – Progressive Build-n-Test: Incrementally implements and tests application logic starting from the skeleton structure
• Stage 4 – Explain it to Me: Explains the generated code block-by-block so the user understands and owns the codebase

Notes

• Each stage passes its output transcript to the next via s.transcript(), creating a coherent context chain across all four stages
• This is the first workflow under .atomic/workflows/coding-backwards/; Claude and OpenCode variants are not yet included

[claude]

Code Review — feat(workflows): add core coding backwards workflow for copilot

Thanks for adding this workflow! The 4-stage structure is a nice translation of the Coding Backwards methodology. I have a few concerns, ordered by severity.

🔴 Must-fix

1. defineWorkflow<"copilot">(...) uses the wrong type parameter.

defineWorkflow's generic is for the inputs schema, not the agent type (see src/sdk/define-workflow.ts:186-190 and the workflow-creator skill):

export function defineWorkflow<
  const I extends readonly WorkflowInput[] = readonly WorkflowInput[],
>(options: WorkflowOptions<I>): WorkflowBuilder<AgentType, I[number]["name"]>

Passing "copilot" here makes I = "copilot", which does not extend readonly WorkflowInput[]. The only reason CI didn't catch this is that tsconfig.json only includes src/ — .atomic/workflows/ is not type-checked. At runtime the generic is erased, but the workflow loses all agent-narrowed typing: s.session is inferred as CopilotSession | OpencodeSession | ClaudeSessionWrapper, so s.session.send({...}) shouldn't type-check under strict TS.

The SDK docs explicitly warn against this pattern (src/sdk/define-workflow.ts:72-92). The fix matches every other workflow in this repo (hello-world, parallel-hello-world, headless-test):

export default defineWorkflow({
  name: \"coding-backwards\",
  description: \"...\",
})
  .for<\"copilot\">()
  .run(async (ctx) => { ... })
  .compile();

2. Fire-and-forget send() + immediate getMessages() will hand off incomplete transcripts.

Per .agents/skills/workflow-creator/references/agent-sessions.md:291-316, s.session.send() returns as soon as the prompt is dispatched — it does not wait for the agent (or the user, in an interactive interview) to finish. The moment s.save(await s.session.getMessages()) runs, the buffer may be empty or only contain the user prompt.

This is especially bad here because Stage 2–4 each do s.transcript(prior) expecting the interview/skeleton/build output to already be persisted. If the agent hasn't finished, the next stage reads an empty transcript. For an interactive, human-in-the-loop workflow like this, you likely want sendAndWait with an explicit long timeout (the skill suggests 5 min as a default when the user hasn't specified one), e.g.:

const SEND_TIMEOUT_MS = 30 * 60 * 1000; // generous — user-in-the-loop interview
await s.session.sendAndWait({ prompt }, SEND_TIMEOUT_MS);

The existing hello-world workflows use bare send() because they're demos with no cross-stage handoff. This workflow has real inter-stage data dependencies, so the contract is stricter.

🟡 Should-fix

3. Prompts have ambiguous handoff contracts.

• Stage 1's prompt says "write a README.md file" but doesn't specify where — on disk, in the transcript, in chat? Stage 2 assumes "described in the README" (the file) exists, but the interview format may never actually produce one.
• Stage 2 passes transcript.path (the transcript file), not the README path. Consider directing Stage 1 to explicitly Write a README.md in the repo root, and have Stage 2 read from that canonical path — this mirrors the "external shared state" pattern in state-and-data-flow.md.
• Stage 2's "For each file, add a comment at the top with the file name" is unusual — file names are already the file names. What value does this add? If it's load-bearing to the methodology, explain why in a comment; otherwise drop it.

4. No declared inputs.

For a workflow that builds a new project from a blank slate, at least one input (e.g., project_description / project_name) would let users kick off via atomic workflow -n coding-backwards -a copilot --project_description=\"…\" without having to redo the interview through the TUI. The picker form becomes much more useful too. See references/workflow-inputs.md.

🟢 Nit

5. Style consistency.

• Leading blank line on L1 of the file — other workflows start immediately with the import.
• Stage name progressive-build-n-test: the -n- contraction is informal; progressive-build-and-test is more consistent with other stage names in the repo.
• Prompts embed \\n\\n escape sequences inside template literals. Prefer real newlines in the template literal for readability (e.g. the hello-world workflows do this).

Test coverage

None added, which is consistent with existing .atomic/workflows/ practice (none of the sibling workflows ship tests). No action needed, though considering .atomic/ isn't type-checked in CI, adding even a minimal smoke test (or moving .atomic/ into tsconfig.include) would have caught issue #1.

Summary

The methodology translation is thoughtful and the 4-stage narrative is clear. But #1 silently loses agent-type safety, and #2 breaks the cross-stage handoff that the workflow's own structure depends on. I'd block on those two and address the rest as polish.

[flora131]

closing this for now as was part of example not to go into prod