ZoeZOE

Feature to Production

ProFeatured

Workflow · engineering

PRD to launch post in six choreographed steps. Six personas, one shipped feature.

6 steps0 installs

What this workflow does

Six-step workflow that takes a feature from "we've decided to build this" to "users have it in their hands." Each step is owned by a different persona — Compass writes the PRD, Syntax scaffolds the implementation, Vector writes the tests, Forge sets up deployment, Ink drafts the changelog, Echo posts the launch. Outputs flow forward as inputs to the next step. Use it when you're tired of features going live without docs, tests, or a launch — and you want a process the team can follow without re-deciding the order every time.

OutcomeA shipped feature with PRD, tests, deployment config, changelog entry, and launch post.

Step by step

6 steps · handoff between 6 personas
compass
STRATEGIST
Step 1 of 6

Write the PRD

Medium

Persona: Compass — the strategic cartographer who makes tradeoffs visible. Skill in play: prd-writer

What this step does

Takes the feature description from the user and produces a PRD that survives engineering review. Names what we''re explicitly NOT building. Specifies how we''ll measure success. Lists the open questions that need answering before the team commits.

Expected inputs

  • Feature description (1-3 sentences)
  • Target user / segment
  • Why-now context (any deadline, market signal, competitive pressure)

Walk

  1. Restate the problem in one sentence to confirm understanding
  2. Draft goals (3-5, each measurable)
  3. Draft non-goals — Compass forces this; without non-goals, scope creep is guaranteed
  4. Draft target user persona for this feature (specific)
  5. Sketch user flow in prose (boxes-and-arrows is for engineering review)
  6. Define metrics — at least one lagging + two leading
  7. List 3-5 risks with named mitigations
  8. List open questions that block engineering estimation

Output handoff to step 2

  • The PRD doc itself
  • A bullet list of "what''s settled / what''s not" — Syntax (step 2) needs to know what''s still ambiguous before scaffolding
Expected output: A 1-3 page PRD with goals, non-goals, target user, metrics, risks, and open questions.
Skills used:prd-writer
syntax
CODER
Step 2 of 6

Scaffold the implementation

Complex

Persona: Syntax — the engineer who treats code as architecture. Skill in play: project-scaffold

What this step does

Translates the PRD into the initial code structure: module boundaries, types, the open PR, the test scaffolding. No business logic yet — that''s for follow-up commits. Goal: the team can clone the branch and start contributing in minutes.

Expected inputs

  • The PRD from step 1
  • The "what''s settled / what''s not" list — anything ambiguous gets a // TODO(prd): marker, not a guess

Walk

  1. Identify the modules that will change. List them.
  2. Create a feature branch (feat/<slug>)
  3. Scaffold types/interfaces first — these are the contract the rest of the code will obey
  4. Stub the public functions/components with type signatures + return types
  5. Add // TODO: markers where business logic will land
  6. Add empty test files matching the source structure (no assertions yet — Vector fills them in step 3)
  7. Open a draft PR with the PRD linked in the description
  8. Set the PR description sections: Why, What, Test plan, Risks, Linked PRD

Output handoff to step 3

  • Branch name + draft PR URL
  • A list of "untested behaviors that need coverage" — Vector uses this as the input for step 3
Expected output: Feature branch with scaffolded types + stub functions + empty test files, draft PR opened with PRD linked.
Skills used:project-scaffold
vector
TESTER
Step 3 of 6

Write the tests

Complex

Persona: Vector — the QA engineer who breaks things on purpose. Skill in play: test-generator

What this step does

Fills in the test files Syntax stubbed in step 2. Covers happy path, edge cases, and failure modes — not just whichever ones come to mind. Vector hunts for the boundary conditions everyone else forgets.

Expected inputs

  • The branch + PR from step 2
  • The "untested behaviors that need coverage" list

Walk

  1. For each public function/component: a. Happy path test (the thing the user asked for) b. Boundary tests (empty input, null, max length, unicode, off-by-one) c. Failure mode tests (network down, DB error, malformed input, race conditions) d. If async: cancellation + timeout
  2. For each new endpoint/route: add an integration test that round-trips through it
  3. Mock at boundaries (network, DB, clock) — never the unit''s own internals
  4. Run the suite. All new tests must pass before the PR moves to ready-for-review
  5. Push. Mark the PR ready-for-review

Output handoff to step 4

  • Test counts per file (e.g., "auth.test.ts: 12 tests, all green")
  • Any test that needed a mock fixture or env var — Forge needs to know in step 4
Expected output: Test suite covering happy path + boundary conditions + failure modes for every public function in the change. CI green.
Skills used:test-generator
forge
DEVOPS
Step 4 of 6

Set up deployment

Medium

Persona: Forge — the infrastructure engineer who treats environments as code. Skill in play: docker-compose-gen

What this step does

Wires the feature for deployment. New env vars, dependency changes, migrations, feature-flag setup. Goal: the merge button shipping the feature is a non-event because the deploy path is already proven.

Expected inputs

  • The PR from step 3 with passing tests
  • Any new env vars / mocks Vector needed in step 3

Walk

  1. Audit the diff for: a. New env vars → add to .env.example AND to the production secret store b. New dependencies → check license + bundle size impact + run npm audit c. New DB migrations → verify zero-downtime safe (no missing default values, no destructive renames mid-deploy) d. New external services → confirm staging credentials exist
  2. If shipping behind a flag (and this should be the default for non-trivial features):
    • Set the flag default to OFF
    • Document the flag in the PR description with the rollout plan
  3. Update docker-compose.yml / k8s manifests if container shape changed
  4. Run a staging deploy and smoke-test the feature end-to-end
  5. Document the rollback procedure in the PR description (one-line git revert, or flag flip)

Output handoff to step 5

  • Confirmation that staging deploy worked
  • The feature flag name (if any) — Ink (step 5) needs it for the changelog
Expected output: Staging deploy verified, env vars + dependencies + migrations audited, rollback procedure documented in PR.
Skills used:docker-compose-gen
ink
WRITER
Step 5 of 6

Write the changelog

Simple

Persona: Ink — the writer who makes technical work readable. Skill in play: changelog-gen

What this step does

Drafts the changelog entry for the release. Translates the engineering work into language the user actually cares about — what changed for them, why, and what they need to do (if anything).

Expected inputs

  • The PR diff + description
  • The feature flag name (if any) from step 4
  • The PRD from step 1 (the "why" lives here)

Walk

  1. Identify the audience (developer-facing API change? End-user feature? Behind-the-scenes infra?)
  2. Lead with the user-visible benefit, not the implementation
  3. Use Ink''s changelog format: a one-line headline + 2-3 sentence body + (if applicable) migration steps + breaking-change call-out
  4. If feature-flagged: note the rollout (e.g., "rolling out to 10% this week, full GA next week")
  5. If breaking: BREAKING: prefix in the headline + dedicated migration section + deprecation timeline
  6. Submit to the changelog repo / docs / website depending on team convention

Output handoff to step 6

  • Final changelog text
  • The feature one-liner — Echo (step 6) uses this as the post hook
Expected output: Polished changelog entry ready to publish, breaking-change notes if applicable, audience-correct language.
Skills used:changelog-gen
echo
MARKETER
Step 6 of 6

Draft the launch post

Simple

Persona: Echo — the marketer who knows when to amplify and when to stay quiet. Skill in play: x-post-writer

What this step does

Drafts the launch post for X (and a LinkedIn variant). Picks the right hook, length, and CTA for each platform. Schedules with the team''s tone — no overpromising, no manufactured excitement.

Expected inputs

  • The changelog entry from step 5
  • The feature one-liner from step 5
  • A landing/docs URL the post should drive to (with a tracking parameter)

Walk

  1. Pick the hook angle (problem-first, demo-first, or "behind-the-scenes")
  2. Draft the X post: one strong opening line, ~2 supporting sentences, optional thread for context, link with utm tag
  3. Draft the LinkedIn variant: longer-form (3-5 short paragraphs), more context, same link
  4. If a screenshot/video helps the post and exists, embed it; if not, ship without — bad media is worse than no media
  5. Schedule for a window the team has agreed on (typically Tue-Thu 9-11am ET for B2B SaaS)
  6. Add to the team''s outbound tracker so engagement gets monitored for the first 24h

Output handoff

  • Scheduled post URLs (X + LinkedIn) with their go-live timestamps
  • The utm tag used so analytics can attribute engagement back to this launch
Expected output: Two scheduled posts (X + LinkedIn), tracking parameters set, audience-correct tone, monitoring planned for first 24h.
Skills used:x-post-writer

How to invoke

  • ›Run the feature-to-production workflow for our new search filters
  • ›Walk me through shipping this feature end-to-end using the feature-to-production workflow
  • ›Use the feature-to-production workflow to take this PRD draft all the way to a launch post