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.
## 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.
## 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
## 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
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
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; }
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); });
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.