AI-Powered Content Pipeline

​

AI-Powered Content Pipeline v2

​

Vision

• Vision
• Four Content Domains
• Building Blocks
• Tooling Stack
• Demo Script Workflow
• Publishing Cadence
• Launch Weeks
• “AI Building AI” Content Strategy
• Quality Standards
• Implementation Roadmap
• Open Questions
• Summary

​

Four Content Domains

​

1. API Reference Documentation

• Human-readable endpoint descriptions
• Multi-language code examples (cURL, TypeScript, Python)
• Common usage patterns
• Migration guides for breaking changes

• OpenAPI spec (auto-generated)
• Spec diffs between versions
• Route handler source code
• Existing published docs

​

Pipeline

​

2. Changelog & Release Notes

• Structured changelog entries
• Narrative release notes organized by Atlas/Arc audience
• Concise Slack posts

• Changesets (.changeset/*.md files)
• Conventional commits
• Merged PRs + labels
• Sprint demo scripts
• Optional user-provided highlights

​

Pipeline

​

3. Product Documentation & Guides

• Feature walkthroughs (from demo scripts)
• Getting started guides
• Troubleshooting docs
• Architecture overviews
• Concept explainers

• Sprint demo scripts
• Internal design docs and ADRs
• System requirements
• API specs
• Meeting transcripts
• User-provided notes

​

Pipeline

​

4. Blog Posts & Public Communications

• Draft posts from outlines
• “Building in public” updates
• Technical deep-dives
• Announcement posts
• “How we use AI to build AI” content

• Sprint work
• ADRs and engineering decisions
• Industry context
• Author outlines
• Meeting transcripts

​

Pipeline

​

Demo Script Pipeline

​

Building Blocks

​

Sources (Input Blocks)

​

Generators (Transform Blocks)

​

Quality Gates (Validation Blocks)

​

Orchestration (Workflow Blocks)

​

How Blocks Compose

# Run a single source block
pnpm pipeline source:commits --from sprint-4 --to sprint-5

# Run a single generator
pnpm pipeline generate:release-notes --sprint 5 --dry-run

# Run a full pipeline
pnpm pipeline run:release --sprint 5

# Run quality checks on any content
pnpm pipeline check content/blog/sprint-5-release.mdx

​

Tooling Stack

​

What We Have

​

What We Add

​

OpenAPI Quality with Spectral

# .spectral.yaml
extends:
  - "spectral:oas"  # Built-in OpenAPI rules
  - "https://unpkg.com/@stoplight/spectral-owasp-ruleset/dist/ruleset.mjs"  # OWASP security

rules:
  # k0rdent API standards
  k0rdent-response-envelope:
    description: "All responses must use { success, data|error, meta } envelope"
    given: "$.paths[*][*].responses[*].content['application/json'].schema"
    then:
      function: schema
      functionOptions:
        schema:
          required: ["properties"]
          properties:
            properties:
              required: ["success", "meta"]

  k0rdent-resource-ids:
    description: "Resource IDs must use prefixed format (srv_, cls_, org_, etc.)"
    given: "$.paths[*][*].responses[*].content['application/json']..examples..id"
    severity: warn
    then:
      function: pattern
      functionOptions:
        match: "^(srv|cls|org|stk|run|pool|key|evt|usr|prj)_"

  k0rdent-camelcase-fields:
    description: "All JSON fields must be camelCase"
    given: "$.paths[*][*]..properties[*]~"
    then:
      function: casing
      functionOptions:
        type: camel

  operation-description:
    description: "Every operation must have a description"
    given: "$.paths[*][*]"
    then:
      field: description
      function: truthy

  parameter-description:
    description: "Every parameter must have a description"
    given: "$.paths[*][*].parameters[*]"
    then:
      field: description
      function: truthy

# CI: Lint on every PR touching API routes
spectral lint openapi.json --ruleset .spectral.yaml

# Local: VS Code extension provides real-time feedback while developing routes

​

Orchestration Options

​

AI Model Selection

​

Demo Script Workflow

​

Step 1: Generate Outline

Sprint 5 Issues → AI organizes by:
  - Primary features (60-90 sec each, max 3)
  - Secondary features (20-30 sec each)
  - Architectural/process updates
  - What's next
→ Author reorders based on narrative flow

​

Step 2: Generate Script

• Opening (25-30 sec): Context, what this sprint was about
• Primary features (60-90 sec each): Screen directions, narration, key moments
• Secondary features (20-30 sec each): Quick hits
• What’s next (30-45 sec): Next sprint priorities
• Closing (20-25 sec): Recap, reinforcement of core talking points

​

Step 3: Author Edit Pass (Iterative)

1. Intro: Tune the opening message — what are the core talking points that frame everything? What narrative thread connects the demos?
2. Feature sections: For each demo section, add/remove/update content. Ensure screen directions match actual UI. Adjust narration to sound natural when spoken.
3. Conclusion: Quick recap that reinforces the original talking points. Brief look at what’s next. Thank you or closing messaging.

​

Step 4: Production Notes + Record

​

Step 5: Script Feeds Other Pipelines

• Release notes pipeline: Demo narration is already benefit-oriented language
• Feature guide pipeline: “Here’s what I’m showing you” → “Here’s how you do it”
• Blog post pipeline: Sprint summary or feature deep-dive

​

Publishing Cadence

​

Internal (Team + Stakeholders)

​

Public (Docs Site + Blog + Community)

​

Internal → Public Flow

​

Launch Weeks

​

Key Takeaways for k0rdent

1. Features ship early, not on launch day. Build behind feature flags, test with early users, flip the flag on announcement day. This is already how we work with feature flags.
2. Visual features get the most attention. Prioritize announcements that can be shown, not just described. Atlas and Arc UIs are inherently visual — lean into this.
3. Daily content plan per announcement. Each day needs: blog post, social thread (self-contained, not just a link), demo video, and optionally an email to waitlist.
4. Main Stage + Build Stage. Not everything is a headline announcement. Bundle smaller improvements into a “Build Stage” or “bonus announcements” track alongside the main features.
5. Art direction matters. A cohesive visual theme across the week makes it feel like an event, not just a sequence of blog posts. Resend commissions custom illustrations. Supabase creates themed micro-sites.
6. List on launchweek.dev. Free visibility in the dev tools community. Submit our launch week when ready.
7. Run a retrospective. Track impressions, signups, doc traffic, and GitHub activity. Compare to baseline. Feed learnings into the next launch week.

​

What a Launch Week Looks Like

• New Spectral-powered API linting rules (open sourced)
• CLI improvements and developer experience updates
• Documentation search powered by AI
• Community contribution guidelines

​

Launch Week Planning

​

Launch Week Cadence

• Launch Week 1: Public docs launch + initial product showcase
• Launch Week 2: ~3 months later. Major feature milestone (e.g., Stacks MVP, one-click deployments)
• Ongoing: Quarterly consideration for launch weeks when there’s enough to announce

​

Post-Launch Week

• Recap all announcements (main stage + build stage)
• Highlight community reception and metrics
• Thank contributors and early testers
• Tease what’s next
• This also serves as a single shareable link for anyone who missed the week

​

References

• Resend: Launch Week Behind the Scenes — The best tactical breakdown. Covers product prioritization (large-impact, visual, requestable features), art direction, feature flags for soft-launching before the public reveal, daily content plan (blog + social + video + email), waitlist with double opt-in, and post-launch week metrics tracking. Key insight: they build features behind flags weeks before launch, get real user feedback, then flip the flag on launch day with confidence. Resend saw a 45% increase in impressions over their previous launch week with this approach. They also run a retro afterwards to improve the next one.
• launchweek.dev — Community-maintained directory tracking every dev tool launch week in the industry. Useful for timing (avoid colliding with bigger launches), format inspiration, and understanding the landscape. Notably powered by Mintlify. Key quotes: “Launch weeks have been great for both aligning the team and getting traction within the community” (Rory Wilding, Supabase COO). Companies of all sizes participate — from solo makers to 100-person teams. We should list ours here when the time comes.
• Supabase Launch Week — The gold standard format. Supabase pioneered this and is on Launch Week 15. Their structure: “Main Stage” (5 major announcements, one per day) plus “Build Stage” (surprise smaller releases throughout the week) plus a community hackathon plus worldwide community meetups. Read Ant Wilson’s (CTO) advice: ship features to prod a week early, not on launch day itself.
• Supabase Launch Week 15: Top 10 — Wrap-up post format showing how to recap and amplify a launch week after it ends. Good template for our own post-launch-week content.

​

”AI Building AI” Content Strategy

​

Content Ideas

​

Monthly Cadence

​

Quality Standards

​

OpenAPI Quality (Spectral)

​

Prose Quality (Vale)

​

Content Quality Gates

​

Human Review Requirements

​

Implementation Roadmap

​

Phase 1: Foundation (Weeks 1-3)

• Set up Mintlify with k0rdent branding and navigation structure
• Configure Mintlify OpenAPI integration with Hono-generated spec
• Set up Spectral with k0rdent custom ruleset (API linting)
• Set up Vale with k0rdent custom rules (prose linting)
• Write style guide and glossary manually (foundation for all AI generation)
• Set up changesets in monorepo (@changesets/cli + config)
• CI: Spectral lint on every PR touching API routes
• CI: Export OpenAPI spec on merge → update Mintlify
• Write 1 golden example per content type (by hand)

​

Phase 2: Changelog & Release Notes (Weeks 4-6)

• Integrate changesets with release workflow
• Build release notes generator (changesets + commits + PRs + demo script → Claude → narrative)
• Build Slack announcement generator
• Quality gate pipeline for generated content
• Run for Sprint 5 as first real test
• Iterate on prompt quality based on human edit rate

​

Phase 3: Product Docs & Guides (Weeks 7-10)

• Build demo script → feature guide generator
• Build doc gap scanner (compare published docs vs shipped features)
• AI enrichment for API docs (examples, patterns, migration guides)
• Interactive mode: iterate on drafts in Cursor
• Tune demo script Claude Skill based on actual usage
• Build demo outline generator from GitHub Project issues

​

Phase 4: Blog + Launch Week Prep (Weeks 11-14)

• Blog post pipeline (outline + sources → AI draft → author edit)
• Write first “AI building AI” blog post
• Set up Mintlify analytics
• Plan Launch Week 1 theme and daily topics
• Create launch week content backlog
• Establish bi-weekly publishing cadence
• Configure RSS/Atom feed for changelog and blog

​

Open Questions

1. Mintlify vs Fumadocs: Stay with Mintlify (managed, AI-native) or self-host with Fumadocs (full control, Next.js native)? Can decide after Phase 1 experience.
2. Changesets + conventional commits: Both can coexist. Changesets for versioning and structured changelog. Conventional commits for commit hygiene and as additional signal for AI generation. Confirm this is the intended setup.
3. Demo script skill quality: Test the existing Claude Desktop skill. Key inputs: outline, past scripts as examples, timing constraints, voice guide. Iterate based on output quality.
4. Launch Week 1 timing: When is there enough to announce across 4-5 days? Likely after Stacks MVP + public docs + Arc onboarding are ready.
5. Open source the pipeline? The docs pipeline itself could be open sourced as a “how we do it” artifact. Good for credibility but adds maintenance burden. Decide after it’s battle-tested.
6. API playground: Interactive try-it-out in API reference? Mintlify supports this natively. Requires auth integration.

​

Summary