redline

name	redline
description	Write documents that sound like the user by learning from (draft → final) revisions. Use when drafting, revising, or reviewing any writing — emails, PRDs, memos, proposals, blog posts, social posts — and whenever the user shares a draft alongside the version they actually sent. Stores pairs, lessons, and matchable patterns in a local SQLite db via the `redline` CLI or MCP server.

redline

Make any piece of writing sound like the user. The system learns from (draft, final) revision pairs and automatically lints future drafts against stored voice patterns. One DB, all content types — lessons cross-pollinate across formats.

Where the data lives

• DB: ~/.redline/redline.db (shared by CLI, MCP server, and Tauri app). Override with REDLINE_DB=/path/db.
• CLI: redline (on PATH)
• MCP server: redline mcp (stdio, auto-configured in pi)
• Tauri app: cd redline-app && bun run tauri dev

No LLM calls from the CLI/server. You do all reasoning in-session.

Linting external writing

Not everything needs the draft→finalize loop. For quick writing that goes directly to external systems — Linear comments, Google Docs, Slack messages, social posts — just lint first:

lint(content)

Returns violations only. No draft created, no lifecycle, no learning. Fix violations, then post to wherever it's going.

The draft workflow

When a piece of writing needs the full learning loop, follow these steps:

create_draft returns pending_lessons — finalized pairs that have no derived lessons yet. Before writing a new draft, process them:

1. For each pending pair, call analyze_diff or show_pair to see the diff
2. Derive 1–3 concrete lessons (see step 4 for how)
3. Store them with add_lesson + add_pattern

This clears learning debt. The patterns you derive improve the draft you're about to write — process them first.

1. Create the draft (patterns + transcript injected automatically)

Via MCP:

create_draft(content, context, tags, transcript)

Via CLI:

redline draft <file> --context "topic + audience" --tags email,external

Match the format to the content type. A document is not an email. If the user asks for a memo, PRD, or reference document:

• Use markdown headings (## Section), bullet lists, tables
• Do NOT add "Subject:" lines, "Hi [name]," greetings, or email sign-offs
• Structure as a reference document with sections, not as a message to a recipient
• The first tag should be memo, prd, internal-doc, or content — not email

Transcript is captured automatically. When running inside pi, redline detects the active session and pulls the conversation transcript programmatically — you don't need to pass it. This gives the async derivation daemon the full context behind each draft. The transcript is frozen at draft time and used later to understand why edits were made.

The response returns the draft id PLUS all stored voice patterns, any lint violations, and pending unlearned pairs. The patterns are your constraints — they represent what the user's voice does and doesn't do. Fix violations with save_revision before showing the draft to the user.

If there are violations: rewrite to resolve them, save the revision, check the returned violations again. Repeat until clean.

2. Hand off to the user

Tell the user the draft is ready. They will edit it — in the Tauri app, in Gmail, in Google Docs, in Obsidian, wherever. You don't control this step — wait for them to tell you they're done (or check redline drafts to see status).

If the user edits outside the app: they paste back the final version, and you call add_pair(draft, final, context, tags).

3. Finalize (analysis + promotion returned automatically)

When the user has finalized:

redline finalize <draft_id>

Returns the pair id PLUS diff analysis (deletions, additions, word swaps, categorized changes, existing pattern hits) and any auto-promoted patterns (patterns that hit 3+ pairs auto-confirm).

4. Derive lessons from the analysis

Read the analysis. Focus on:

• Deletions — what got cut entirely (strongest voice signal).
• Categorized changes — each hunk tagged as deletion, structural, stylistic, factual, or punctuation.
• Word swaps — specific before→after replacements.

Derive 1–3 concrete lessons per pair. A good lesson is specific, actionable, and voice-coded:

• ✅ "No em-dashes in client-facing writing" → store as a pattern
• ✅ "Use 'quick note' not 'I wanted to reach out'" → store as pattern + lesson
• ✅ "Lead with the number in investor updates" → store as pattern + lesson
• ❌ "Be clear and professional" → useless, reject it

Store each lesson: redline add-lesson <pair_id> "<lesson>" --tags email,external Store a matchable pattern: redline add-pattern --rule "<rule>" --pattern "<match>" --category style

Always create a pattern alongside a lesson. Lessons without patterns don't lint. That's the write loop — patterns catch voice issues in future drafts automatically.

Key tools

CLI	MCP	Purpose
—	lint	Lint any text against voice patterns — no draft needed
draft	create_draft	Write draft, pass transcript, get patterns + violations + pending lessons
finalize	finalize_draft	Finalize pair, get diff analysis + promotions back
analyze <pair_id>	analyze_diff	Deep-dive: deletions, categorized changes, swaps, hits
add-pattern	add_pattern	Create matchable voice pattern (literal or regex)
list-patterns	list_patterns	See all patterns the lint engine uses
promote	—	Manually trigger pattern promotion
add-lesson	add_lesson	Store a derived voice lesson
lessons	list_lessons	Read all lessons
show <id>	show_pair	Read a pair with diff (lines/sentences/side-by-side)
recent N	recent_pairs	Skim recent finals
feedback	give_feedback	Log what's painful (bugs, suggestions)

Pattern types

• literal — case-insensitive substring match. Pattern "—" catches any em-dash.
• regex — Rust regex syntax. Pattern "^.{1,10}$" catches terse one-liners.

Directions:

• avoid — flag if pattern is found in the draft ("⚠ em-dash detected")
• prefer — flag if pattern is absent ("consider using 'quick note'")

Categories: punctuation, style, structure, factual, deletion.

Patterns auto-promote from unconfirmed → confirmed after appearing in 3+ pairs' drafts. This runs automatically on finalize.

Conventions

• Tags: lowercase, comma-separated. First tag = content type, then context tags.
• Content type vocab: email, prd, memo, proposal, blog, linkedin, x-post, internal-doc, external-doc, content.
• Context tags: pitch, followup, external, internal, apology, decline, intro, update, announcement, review.
• Context line: audience + intent, e.g. "cold intro to investor" or "internal PRD for payments v2".
• Cross-type learning: when deriving lessons, check if a pattern from one type applies to others. "Cut throat-clearing openers" is true for emails, PRDs, and proposals alike.

Failure modes

• Over-fitting to one pair. Confirm across 2–3 before treating as a strong rule. Auto-promotion handles this.
• Generic lessons. If you can't name what specifically changed, don't store it.
• Stale voice. Re-check recent periodically. If a final contradicts an old lesson, flag it.
• Silent edits. Never delete lessons/patterns without surfacing the change.
• Write-only graveyard. Always create patterns alongside lessons — lessons without patterns don't lint.
• Missing transcript. When running outside pi, transcripts aren't auto-captured. Derivation falls back to diff-only analysis, which still works but with less context.

Feedback

This tool is built for agents — your feedback shapes it. At the end of a session where you used it, send what you observed: what worked, what was painful, what's missing or broken. Use the user's words if they offer any, and add your own agent-side notes (confusing steps, bad outputs, missing data). Submit once per session, not every turn.

Prefer the give_feedback MCP tool (it routes to the same server). The curl below is the fallback for sessions without the MCP server:

TOKEN=$(curl -s -X POST https://feedback.collinpfeifer.dev/token | jq -r .token)
curl -s -X POST https://feedback.collinpfeifer.dev/feedback \
  -H "x-feedback-token: $TOKEN" -H "content-type: application/json" \
  -d '{"source":"redline","message":"<likes / dislikes / bugs / wishes>","rating":<1-5 or omit>,"severity":"<info|warning|error|suggestion>","agent_id":"<your model>"}'

rating: 1 = painful, 5 = great (optional). severity is optional. Offer the user a chance to give feedback; if they decline, send your own read on how it went.