⚡ Vibe Coding Workflow

From raw idea to
deployed product
in one session

A fully automated pipeline using Claude AI skills — idea generation, market validation, spec writing, architecture, code, and tests — chained together so nothing falls through the cracks.

8
AI Agents
<1hr
Idea → Code
Daily
Cadence
The Pipeline
💡
Idea Gen
Daily ideas with market framing
✈️
Preflight
5-question PMF filter
🎯
JTBD
Real job discovery
📋
Clarifier
Spec + user stories
🏗️
Architect
Blueprint + data models
⚙️
Builder
Working code, section by section
🔍
Reviewer
Spec compliance check
🧪
Tests
Behavior-driven coverage

Live example: DocDelta

Auto-draft API docs when your OpenAPI spec changes
Step 1 of 6
1
Idea Generation + Preflight
Daily run → instant PMF filter
Skill: idea-generator + preflight
Every morning the idea-generator skill produces 3 product ideas. Each goes immediately through preflight — a 5-question filter covering market size, willingness to pay, demo-ability, competition, and solo-buildability.
Q1 Market ✓ Q2 Pays ✓ Q3 Demoable ✓ Q4 Competition ✓ Q5 Buildable ✓
🟢 VERDICT: GO
Only ideas that clear all 5 gates enter the pipeline. No architecture work is done on ideas that fail preflight.
idea-log.md
## 2026-06-10

### DocDelta 🟢
Technical writers and dev-rel engineers at
growing SaaS companies find out about API
changes via a Slack ping, then manually diff
OpenAPI specs against live docs to figure
out what broke.

Pre-flight:
  Q1 PASS | Q2 PASS | Q3 PASS
  Q4 PASS | Q5 PASS

Verdict: GO — demo is a 90-second
before/after (PR merged → doc draft
appears), existing publishing platforms
validate that this market pays, and
AI-accelerated API shipping has made the
pain acute in the last 18 months.

JTBD angle: Confirm whether the
blocker is detecting stale docs vs.
drafting the fix — MVP surface area
changes substantially depending on which
job the user most wants outsourced.
2
JTBD Discovery
Uncover the real job before writing a line of spec
Skill: jtbd
The JTBD skill interviews you about the idea to find the underlying job, who does it, what they use today, and why that falls short. The insight drives the entire product direction.
Key insight: The job is not "write documentation." It's "never let a shipped API change go undocumented."

That reframe changes the core loop from a writing tool to a trigger + route + draft system — a must-have vs. a nice-to-have.
Target user identified
Current workarounds mapped
Willingness to pay confirmed
Output: jtbd.md
jtbd.md (excerpt)
## The Job

Core job statement:
When I merge a PR that changes an API,
I need to update the documentation
immediately, so that developers using
my API don't get silently broken by
stale docs.

## Why Current Solutions Fall Short

| Pain                | Why it persists     |
|---------------------|---------------------|
| Discovery reactive  | No spec watcher     |
| Context lost by     | PR author moved on  |
|  update time        |                     |
| Tools render docs   | Don't write them    |

## Key JTBD Insight

The primary job is NOT "write docs."
It's "never let a shipped change go
undocumented."

# This means the core loop is:
detect → draft → route → publish
3
Spec + User Stories
Scope locked before any architecture decisions
Output: spec.md
The Clarifier skill turns the JTBD brief into a full product spec: user stories, technical requirements, success criteria, and explicit out-of-scope decisions. Nothing is built that isn't in the spec.
4 user stories written
MVP scope bounded
Success criteria: <90s trigger → PR
GitLab deferred to v2
Success criteria are measurable before the first line of code is written.
spec.md (excerpt)
## User Stories

| # | As a...           | I want to...              |
|---|-------------------|---------------------------|
| 1 | Dev-rel engineer  | Get a PR automatically    |
|   |                   | when an endpoint changes  |
| 2 | Technical writer  | Review AI draft in plain  |
|   |                   | English, not raw YAML     |
| 3 | Backend engineer  | Merge API changes without |
|   |                   | filing a separate ticket  |

## Success Criteria

1. Merged PR triggers doc PR
   within 90 seconds
2. Generated prose accurate for
   85%+ of endpoint changes
3. Zero false-positive triggers
4. Setup time under 15 minutes

## Out of Scope (v1)
- GitLab / Bitbucket
- Auto-publish without review
- Multi-spec monorepo
4
Technical Blueprint
Architecture decided before any code is written
Output: blueprint.md
The Architect skill reads the spec and produces a complete technical blueprint: file structure, typed data models, API contracts between modules, and an explicit build order the Builder follows exactly.
File structure defined
TypeScript interfaces written
Component contracts specified
Build order: 9 steps
The Builder agent never makes architectural decisions — it only follows this blueprint.
blueprint.md (data models)
interface SpecChange {
  type: 'added' | 'removed' | 'modified';
  path: string;        // e.g. "/payments/{id}"
  method: string;      // e.g. "POST"
  before?: EndpointDef;
  after?: EndpointDef;
  breakingChange: boolean;
}

interface DocDraft {
  filePath: string;    // which .md to update
  section: string;     // which section
  content: string;     // generated markdown
  change: SpecChange;
}

// Build order
// 1. config.ts
// 2. diff/parser.ts
// 3. diff/engine.ts
// 4. generate/drafter.ts
// 5. publish/github.ts
// 6. publish/slack.ts
// 7. src/index.ts (wire all)
// 8. GitHub Actions workflow
// 9. Tests
5
Working Code
Builder implements each module, section by section
Output: TypeScript source
The Builder skill follows the blueprint's build order, writing real runnable code — not pseudocode or stubs. Each module is independently testable before the next begins.
diff/engine.ts — change detection
generate/drafter.ts — Claude API call
publish/github.ts — Octokit PR creation
publish/slack.ts — Block Kit notification
src/index.ts — orchestration entrypoint
engine.ts
drafter.ts
export function detectChanges(
  before: OpenAPIObject,
  after: OpenAPIObject
): SpecChange[] {
  const changes: SpecChange[] = [];
  const allPaths = new Set([
    ...Object.keys(before.paths ?? {}),
    ...Object.keys(after.paths ?? {}),
  ]);

  for (const path of allPaths) {
    for (const method of HTTP_METHODS) {
      const beforeOp = beforePath[method];
      const afterOp = afterPath[method];

      if (!beforeOp && afterOp) {
        changes.push({
          type: "added", path, method,
          after: afterOp,
          breakingChange: false
        });
      } else if (beforeOp && !afterOp) {
        changes.push({
          type: "removed", path, method,
          before: beforeOp,
          breakingChange: true // removal is always breaking
        });
      }
    }
  }
  return changes;
}
6
Tests + CI Deployment
Spec-derived tests and GitHub Actions delivery
Output: tests/ + .github/workflows/
The Test Writer skill generates tests from the spec, not from the implementation — testing behaviors, not code paths. Each test maps directly back to a user story or success criterion.
"Removed endpoint is breaking" and "parameter type change is breaking" are requirements from the spec — not implementation details. The tests prove the spec is met.
4 behavioral test cases
Fixture specs committed
GitHub Actions: trigger on spec change
Setup time: <15 min (spec requirement ✓)
diff.test.ts
docdelta.yml
test('removed endpoint is breaking', () => {
  const changes = detectChanges(baseSpec, noPaymentsSpec);
  expect(changes[0].type).toBe('removed');
  expect(changes[0].breakingChange).toBe(true);
});

test('added endpoint is not breaking', () => {
  const changes = detectChanges(baseSpec, withRefundSpec);
  expect(changes[0].breakingChange).toBe(false);
});

test('parameter type change is breaking', () => {
  // id: string → integer (breaking for API consumers)
  const changes = detectChanges(baseSpec, intIdSpec);
  expect(changes[0].breakingChange).toBe(true);
});

test('no changes returns empty array', () => {
  const changes = detectChanges(baseSpec, baseSpec);
  expect(changes).toHaveLength(0);
});

Let's talk

I build systems like this daily — the workflow itself is the product. Available for SE and TPM roles where product sense and shipping velocity both matter.