My AI coding workflow: Droid plan mode + SDD

i often start with Droid's plan mode, especially for small to mid-sized tasks.

why i use Droid

i use Droid first because, so far, it has been the best at keeping long-running sessions coherent, even after compacting.¹

Claude Code was my first terminal-based AI coding agent.² i loved it and i still do. i still sometimes alternate between Claude Code and Droid depending on the task.

when a task gets non-trivial, i switch to spec-driven development (SDD). it keeps AI-assisted engineering high-signal, reduces rework, and makes reviews faster.

i start with:

/sdd-spec <description>

then i pass the resulting <slug> into the rest of the workflow.

my loop

1. write a small spec (goal, non-goals, constraints, acceptance checks).
2. ask Droid to propose an implementation plan.
3. implement in small diffs and run validators frequently.
4. end with a tight PR description + screenshots/logs.

the four templates i use (SpecKit-inspired)

i keep four small markdown templates (inspired by GitHub's SpecKit and spec-driven development):³⁴

• spec.md: what are we building and why?
• plan.md: how are we going to build it?
• tasks.md: what are the concrete steps?
• verify.md: how do we prove it works?

i wire these up as Droid custom commands so i can quickly bootstrap a consistent workflow:

⁵

/sdd-spec <description>
/sdd-plan <slug>
/sdd-tasks <slug>
/sdd-verify <slug>

spec.md

### goal

### non-goals

### context

### constraints
- API contracts
- performance
- security

### acceptance checks
- [ ] go test ./...
- [ ] golangci-lint run
- [ ] go vet ./...
- [ ] gofmt -w .
- [ ] docs (if needed)

plan.md

### approach

### file-level changes
- [ ] path/to/file.go: what changes and why

### edge cases

### roll-out / backwards compatibility

### risks

tasks.md

### tasks
1. [ ]
2. [ ]
3. [ ]

verify.md

### local checks
- [ ] go test ./...
- [ ] golangci-lint run
- [ ] go vet ./...
- [ ] gofmt -w .

### manual qa
- [ ]

### release notes
- [ ]

the point isn’t the exact template. it’s that Droid (and i) always have the same shared map.

specs in PRs

i also include the spec doc in the PR (either pasted or linked) and use the review as an alignment checkpoint. i’ve found it practical: it keeps devs aligned on the overview goal and the direction of the task, and it makes reviews faster because everyone is reacting to the same intent.

whether you commit all the SDD-related docs, nothing, or just spec.md really depends on the team. i’ve seen it work both ways. the important part is that the intent is easy to find during review.

why SDD works with coding agents

• it forces explicit interfaces, edge cases, and tests before code diverges.
• it limits the blast radius: the agent can be “biased for action” safely.
• i also like creating and maintaining a high-signal AGENTS.md (agent-facing) or CLAUDE.md at the repo root and in key subdirectories so Droid (and other agents) can find commands, architecture, and conventions quickly.

when i skip this and just use plan mode

if the task is small and i can explain it in a sentence or two, i’ll often just use Droid’s default plan mode and keep moving.

footnotes

1. Factory.ai on context compression for long-running sessions: https://factory.ai/news/evaluating-compression and https://docs.factory.ai/guides/power-user/evaluating-context-compression ↩

2. Claude Code docs (Anthropic): https://code.claude.com/docs/en/overview ↩

3. GitHub SpecKit repository: https://github.com/github/spec-kit ↩

4. Birgitta Böckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl" (Martin Fowler) (2025). https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html ↩

5. Factory docs on custom slash commands: https://docs.factory.ai/cli/configuration/custom-slash-commands ↩