Changelog Writer

Create clear, accurate changelog entries that help developers understand what's new in Lightfast releases.

Critical: Fact-Check First

Before writing anything, verify against docs/architecture/implementation-status/README.md :

Check implementation status to verify:

• What's actually completed vs planned

• Current limitations and known gaps

• Technical accuracy of claims

Never oversell:

• Use specific names: "GitHub File Sync (File Contents)" not "GitHub Integration"

• Disclose limitations: "Currently supports X; Y coming in vZ"

• Be honest about conditionals: "when 3+ customers request"

Verify every claim:

• If you cite a number, confirm it's in implementation docs

• If you mention a feature, confirm it exists in production

• When uncertain, ask for clarification

Writing Guidelines

• Concise & scannable: 1-3 sentences per feature (Cursor-style brevity)

• Lead with benefit: Start with what users can do, then how

• Be transparent: Mention beta status, rollout timelines, limitations

• User-focused but technical: Balance benefits with specifics developers need

• Active voice: "You can now..." not "Users are able to..."

• No emoji: Professional tone

• Specific examples: Include config snippets, API calls

• SEO-conscious: Use target keywords naturally

• AEO-conscious: Write tldr for AI citation engines, excerpt for listings

• FAQ quality: Questions must match real search queries, answers must be complete

Workflow

• Gather input: PR numbers, URLs, or manual change list

• Read implementation status for fact-checking

• Draft following templates

• Cross-check claims against implementation reality

• Add SEO elements per seo-requirements

• Review with checklist

Quick Reference

Do

• "GitHub File Sync (File Contents)" with limitations disclosed

• "When 3+ customers request: Linear integration"

• Include code examples for every major feature

• Link to 3-5 related docs

Don't

• "GitHub Integration" (vague - what does it cover?)

• "Coming soon: Linear, Notion, Slack!" (when at 0%)

• Long paragraphs (keep to 1-3 sentences per feature)

• Claims without verification

Output

Save drafts to: thoughts/changelog/{title-slug}-{YYYYMMDD-HHMMSS}.md

Required Frontmatter Fields

Every draft MUST include:

• title , slug , publishedAt (core)

• excerpt , tldr (AEO)

• seo.metaDescription , seo.focusKeyword (SEO)

• _internal.status , _internal.source_prs (traceability)

Fields: prefix and slug

These are two separate fields:

• prefix : Version identifier shown in breadcrumbs. Format: \d+-\d+ (e.g., 0-1 , 0-2 ). BaseHub regex constraint: ^\d+-\d+$

• slug : Descriptive URL slug, no version prefix. Format: lightfast-<feature-slug> (e.g., lightfast-neural-memory-foundation-2026 )

Examples:

• prefix: 0-1 / slug: lightfast-github-file-sync-semantic-search

• prefix: 0-2 / slug: lightfast-pr-metadata-linear-integration

Recommended:

• seo.secondaryKeyword , seo.faq[] (enhanced SEO)

The frontmatter structure maps directly to ChangelogEntryInput type. Use /publish_changelog to publish drafts to BaseHub.

See resources/templates.md for complete frontmatter template.

Resources

• Document Templates

• SEO Requirements

• Examples

• Pre-Publish Checklist