Unified Development Plan — Auctor Production Readiness

Quick Reference

Phase	Group	Parallel With	Owns (files/dirs)	What It Does	Size
1	1A	1B, 1C	`frontend/app/api/mcp/route.ts`, `frontend/package.json`	Fix production build failure	S
1	1B	1A, 1C	`frontend/src/mastra/workflows/content-engine-workflows.ts` (publish status only)	Fix `published_stub` → real publish status	S
1	1C	1A, 1B	`frontend/src/content-engine/services/competitor-crawl.ts`, `frontend/src/content-engine/db/repositories.ts` (owned-domain sync path only)	Fix owned-domain sync to write `our_page` documents	S
2	2A	2B, 2C	`frontend/skills-seed/consul-voice/`, `frontend/skills-seed/draft-structure/`, `frontend/skills-seed/brief-writing/`, `frontend/skills-seed/seo-checklist/`	Author 4 priority skills (voice, structure, SEO, briefs)	L
2	2B	2A, 2C	`frontend/skills-seed/content-planning/`, `frontend/skills-seed/competitive-analysis/`, `frontend/skills-seed/serp-interpretation/`	Author 3 research & planning skills	M
2	2C	2A, 2B	`frontend/skills-seed/cms-publishing/`, `frontend/skills-seed/post-publish-ops/`, `frontend/scripts/seed-skills.ts`	Author 2 publishing skills + seed script	M
3	3A	—	`CLAUDE.md`	Integration verification script + CLAUDE.md update	M

Executive Summary

Auctor is a content engine that drives a full pipeline—strategy → brief → draft → publish—for the Consul website. All 3 workflows, 42 MCP tools, HITL gates, SEO validation, and Consul publishing are implemented and wired. However, the system cannot launch: the production build is broken, the data pipeline is empty, all 9 agent skills are missing, and several status/classification bugs make the operator experience misleading.

This playbook resolves the code-level blockers across 3 phases with a maximum of 3 parallel agents per phase (7 total work units). Phase 1 fixes the 3 code bugs that block any launch. Phase 2 authors the 9 skills the agent needs for quality output and creates a seed script. Phase 3 updates CLAUDE.md with lessons learned and produces a verification checklist. After all 3 phases, the operator still needs to perform manual steps (API keys, competitor crawls, data population) documented in the Done section.

Key decisions made during synthesis:

Documents 4 and 6 are identical—treated as a single source (5 unique audits total).
All 5 audits agree on the build failure, empty data pipeline, missing skills, and no image pipeline. The image pipeline is explicitly deferred to post-launch (text-first publishing).
Audits 2 & 3 report ANTHROPIC_API_KEY as missing; Audits 4 & 5 say "likely set" (agent sessions exist). Resolution: treat as an operational verification step, not a code fix.
The extraction_configs migration (0003) is flagged by Audit 3 only. Resolution: include as a manual step since it's a single SQL file, not a code change.

Phase 1: Critical Code Fixes

What This Phase Accomplishes

Unblocks the production build, fixes misleading publish status, and corrects document classification for owned-domain content. These are the 3 code-level P0 blockers that every audit identified.

Parallel Groups

All 3 groups run simultaneously. They touch completely different files.

Dashboard

Group	Status	Key Files
1A: Fix Production Build	☐	`frontend/app/api/mcp/route.ts`, `frontend/package.json`
1B: Fix Publish Status	☐	`frontend/src/mastra/workflows/content-engine-workflows.ts`
1C: Fix Owned-Domain Sync	☐	`frontend/src/content-engine/services/competitor-crawl.ts`, `frontend/src/content-engine/db/repositories.ts`

Group 1A: Fix Production Build

Parallel With: 1B, 1C Depends On: Nothing Size: S

Prompt

# [Phase 1, Group 1A]: Fix Production Build Failure

## Context

You are working in an isolated workspace. Other agents are working in parallel
on other parts of the codebase — you cannot see their work.
Do not modify files outside your designated scope.

**Project:** Auctor is a Next.js 16 content engine (TypeScript, pnpm monorepo).
The production build (`pnpm build`) fails because `frontend/app/api/mcp/route.ts`
imports `@mastra/mcp` and `fetch-to-node`, but these packages are not present in
`frontend/node_modules` despite being declared in `frontend/package.json` and
`pnpm-lock.yaml`.

**Tech stack:** Next.js 16.1.6, pnpm workspace, TypeScript, Mastra framework.

**Note:** `frontend/next.config.mjs` sets `typescript.ignoreBuildErrors = true`,
so TypeScript errors won't break the build — but the missing module resolution does.

## Your Task

Fix the production build so `pnpm build` passes. There are two valid approaches
(investigate and choose the best one):

**Option A — Install the missing packages:**
Check if `@mastra/mcp` and `fetch-to-node` are declared in `frontend/package.json`.
If yes, the issue may be a pnpm install problem. Run `pnpm install` in the
frontend directory and verify the packages resolve. If they install correctly,
the build should pass.

**Option B — Remove or gate the route:**
If the packages cannot be installed (e.g., they don't exist in the registry,
version conflicts, etc.), remove or conditionally exclude
`frontend/app/api/mcp/route.ts` from the production build. Options include:
- Wrapping the route in a dynamic import with a try/catch
- Moving the route behind an environment flag
- Removing the route entirely if it's not launch-critical
  (the MCP server is used for tool exposure but is not required for the
  core content pipeline: strategy → brief → draft → publish)

The `/api/mcp` route failure also poisons sibling API routes in the
content-engine namespace (they return 500). Fixing this route unblocks
ALL content-engine API routes.

## Scope

**You own:**
- `frontend/app/api/mcp/route.ts`
- `frontend/package.json` (only dependency additions/removals for the MCP route)

**Do NOT touch:**
- Any file in `frontend/src/mastra/workflows/` (owned by Group 1B)
- Any file in `frontend/src/content-engine/services/competitor-crawl.ts` (owned by Group 1C)
- Any file in `frontend/src/content-engine/db/repositories.ts` (owned by Group 1C)
- Any workflow, tool, or agent definition files

## Requirements

1. `pnpm build` passes with exit code 0.
2. If Option A: `@mastra/mcp` and `fetch-to-node` resolve correctly in node_modules.
3. If Option B: The `/api/mcp` route either doesn't exist or gracefully handles
   the missing dependency without crashing sibling routes.
4. All existing content-engine API routes (`/api/content-engine/*`) must not
   return 500 errors caused by this route's compilation failure.
5. No regressions to `pnpm test:frontend` (currently 21 files, 43 tests passing).

## Patterns to Follow

- Check `frontend/package.json` for the dependency declarations first.
- Check `pnpm-lock.yaml` to see if the packages have valid resolution entries.
- If gating the route, use Next.js dynamic import patterns:
  ```typescript
  // Example: lazy load with fallback
  export async function POST(req: Request) {
    try {
      const { MCPServer } = await import('@mastra/mcp');
      // ... route logic
    } catch {
      return new Response('MCP server not available', { status: 503 });
    }
  }

Verification

Before you're done, run and fix any failures:

cd frontend && pnpm install
pnpm build
pnpm test:frontend

All checks must pass before you consider your work complete.

##### Verify

```bash
cd frontend && pnpm build
pnpm test:frontend

Diff Review

Must see: frontend/app/api/mcp/route.ts changed or removed
Must verify: pnpm build exits 0; no 500 errors on /api/content-engine/readiness
Red flag: Agent modified workflow files, tool definitions, or agent configs

Group 1B: Fix Publish Status Semantics

Parallel With: 1A, 1C Depends On: Nothing Size: S

Prompt

# [Phase 1, Group 1B]: Fix Publish Status Mismatch

## Context

You are working in an isolated workspace. Other agents are working in parallel
on other parts of the codebase — you cannot see their work.
Do not modify files outside your designated scope.

**Project:** Auctor is a content engine with a 6-step draft production workflow.
The final step is called `publishStubStep` — but it actually performs a REAL
publish to `consul.posts` via `publishDraftToConsul()`. Despite this, the
workflow saves the draft status as `published_stub`, which is misleading.
Operators cannot tell whether content was actually published.

**Tech stack:** TypeScript, Mastra workflows with structured step definitions.

**Key file:** `frontend/src/mastra/workflows/content-engine-workflows.ts`
The `publishStubStep` is defined around lines 1117-1172. It:
1. Calls `publishDraftToConsul()` which writes to `consul.posts`, `consul.post_keywords`,
   `consul.post_validations`, and `consul.post_relationships` — this is a REAL publish.
2. Then updates the draft status to `published_stub` — this is WRONG.

The indexing provider IS stubbed (`StubIndexingProvider` in `runtime.ts`), but
the Consul publish itself is real. The status should reflect that content was
published, while noting that indexing is still manual.

## Your Task

1. Rename `publishStubStep` to `publishStep` (or `publishToConsulStep`).
2. Change the draft status from `published_stub` to `published`.
3. Update the step's `id` field from `'publish-stub-step'` to `'publish-step'`
   (or `'publish-to-consul-step'`).
4. Search for any references to `published_stub` as a status string or
   `publish-stub-step` as a step ID throughout the codebase and update them.
   Common locations:
   - Dashboard page (`frontend/app/(app)/content/dashboard/page.tsx`) — may count
     `published_stub` in pipeline metrics
   - Draft review components
   - Type definitions
   - Workflow step references in the strategy or brief workflows

## Scope

**You own:**
- `frontend/src/mastra/workflows/content-engine-workflows.ts` (the publishStubStep
  and any references to the old status/step-id in this file)
- Any file that references the string `published_stub` or `publish-stub-step`
  (search the entire `frontend/` directory)

**Do NOT touch:**
- `frontend/app/api/mcp/route.ts` (owned by Group 1A)
- `frontend/src/content-engine/services/competitor-crawl.ts` (owned by Group 1C)
- `frontend/src/content-engine/db/repositories.ts` (owned by Group 1C for the
  owned-domain sync fix — but you MAY read this file to understand the publish flow)
- The actual `publishDraftToConsul()` function implementation (it works correctly)
- `frontend/src/content-engine/runtime.ts` (the StubIndexingProvider is intentional
  for now — do NOT change it)

## Requirements

1. The step is renamed from `publishStubStep` to a name that reflects real publishing.
2. The step ID is updated from `publish-stub-step` to match the new name.
3. Draft status after successful publish is `published` (not `published_stub`).
4. All references to the old status string and step ID across the codebase are updated.
5. The dashboard and any pipeline views that filter/count by status still work
   correctly with the new `published` status.
6. No changes to the actual publish logic in `publishDraftToConsul()`.
7. No changes to the `StubIndexingProvider` — indexing remains stubbed.

## Patterns to Follow

Use `grep -r "published_stub" frontend/src/ frontend/app/ frontend/components/`
to find all references before making changes.

Use `grep -r "publish-stub-step" frontend/src/ frontend/app/ frontend/components/`
to find all step ID references.

The workflow step pattern in this codebase looks like:
```typescript
const publishStep = createStep({
  id: 'publish-step',
  // ...
});

Draft statuses used elsewhere include: draft, in_review, pending_human_review, approved, ready_to_publish. The new published status should fit this pattern.

Verification

Before you're done, run and fix any failures:

cd frontend
grep -r "published_stub" src/ app/ components/  # Should return 0 results
grep -r "publish-stub-step" src/ app/ components/  # Should return 0 results
grep -r "publish.step\|publish-step\|publishStep\|published" src/mastra/workflows/  # Confirm new naming
pnpm test:frontend

All checks must pass before you consider your work complete.

##### Verify

```bash
cd frontend
grep -r "published_stub" src/ app/ components/
grep -r "publish-stub-step" src/ app/ components/
pnpm test:frontend

Diff Review

Must see: published_stub replaced with published in workflow file; step renamed
Must verify: Zero grep hits for published_stub and publish-stub-step across codebase
Red flag: Agent changed publishDraftToConsul() logic, modified the indexing provider, or touched /api/mcp/route.ts

Group 1C: Fix Owned-Domain Document Classification

Parallel With: 1A, 1B Depends On: Nothing Size: S

Prompt

# [Phase 1, Group 1C]: Fix Owned-Domain Sync Document Classification

## Context

You are working in an isolated workspace. Other agents are working in parallel
on other parts of the codebase — you cannot see their work.
Do not modify files outside your designated scope.

**Project:** Auctor is a content engine. When an operator registers their own
domain (e.g., consul.ai) via `/api/content-engine/site/register-domain`, the
system crawls the site using the competitor crawl infrastructure. The problem:
`syncCompetitorPagesToDocuments()` writes ALL crawled pages as
`document_class: 'competitor_page'` — even when the crawled domain is the
operator's own site. This means first-party content gets classified as
competitor content, and the agent can't find it when looking for `our_page`
documents.

**Tech stack:** TypeScript, Supabase/Postgres, document classification system.

**Key files:**
- `frontend/src/content-engine/services/competitor-crawl.ts` — contains
  `syncCompetitorPagesToDocuments()` and the crawl orchestration
- `frontend/src/content-engine/db/repositories.ts` — contains document CRUD
  and the `buildConsulPostDocument()` function (which correctly creates `our_page` docs)
- `frontend/app/api/content-engine/site/register-domain/route.ts` — the API
  route that triggers owned-domain registration

**Data model context:**
- `auctor.documents` has a `document_class` field with values: `our_page`,
  `competitor_page`, `serp`, `ai_overview`, `brand_voice`
- `auctor.site_targets` has the operator's owned domain
- `auctor.competitor_domains` stores both competitor AND owned domains
  (owned domain is marked via relationship to site_target)

## Your Task

Fix the owned-domain sync path so that when the operator's own domain is crawled,
the resulting documents are classified as `our_page` instead of `competitor_page`.

**Approach:**
1. In `syncCompetitorPagesToDocuments()` (or its caller), check whether the
   domain being synced matches the site target's owned domain.
2. If it matches, set `document_class: 'our_page'` instead of `'competitor_page'`.
3. The check should query `auctor.site_targets` to get the owned domain, or
   accept a parameter indicating whether this is an owned-domain sync.

**Alternative approach (simpler):**
1. In the `/api/content-engine/site/register-domain` route handler, after the
   competitor crawl completes, run an UPDATE query to reclassify the documents
   from `competitor_page` to `our_page` for the owned domain.

Choose whichever approach is cleaner given the existing code structure.

## Scope

**You own:**
- `frontend/src/content-engine/services/competitor-crawl.ts`
  (specifically the `syncCompetitorPagesToDocuments()` function and any helpers)
- `frontend/src/content-engine/db/repositories.ts`
  (only the document classification logic — do NOT modify `publishDraftToConsul()`)
- `frontend/app/api/content-engine/site/register-domain/route.ts`

**Do NOT touch:**
- `frontend/app/api/mcp/route.ts` (owned by Group 1A)
- `frontend/src/mastra/workflows/content-engine-workflows.ts` (owned by Group 1B)
- Any workflow, tool, or agent definition files
- The `publishDraftToConsul()` function
- The competitor crawl logic itself (Firecrawl integration, sitemap discovery, etc.)

## Requirements

1. When the owned domain is crawled via site registration, resulting documents
   have `document_class: 'our_page'`.
2. When a competitor domain is crawled, resulting documents still have
   `document_class: 'competitor_page'` (no regression).
3. The `listDocumentsByClass('our_page')` query returns the owned-domain
   documents after sync.
4. Existing `our_page` documents from Consul post sync (`buildConsulPostDocument()`)
   are not affected.
5. The fix handles the case where the owned domain was already crawled
   (existing `competitor_page` docs should be reclassified).

## Patterns to Follow

The codebase uses Supabase client for DB operations:
```typescript
const { data, error } = await supabase
  .from('documents')
  .update({ document_class: 'our_page' })
  .eq('source_domain', ownedDomain)
  .eq('document_class', 'competitor_page');

Check how site_targets is queried elsewhere in the codebase for the owned domain pattern.

Verification

Before you're done, run and fix any failures:

cd frontend
# Verify no regressions
pnpm test:frontend
# Search for the fix
grep -n "our_page" src/content-engine/services/competitor-crawl.ts
grep -n "our_page" src/content-engine/db/repositories.ts

All checks must pass before you consider your work complete.

##### Verify

```bash
cd frontend
pnpm test:frontend
grep -n "our_page" src/content-engine/services/competitor-crawl.ts

Diff Review

Must see: Logic that checks owned domain and sets document_class: 'our_page'
Must verify: Competitor domains still produce competitor_page classification
Red flag: Agent modified workflow definitions, publish logic, or MCP route

Phase 1 → Phase 2 Transition

State After Phase 1:

pnpm build passes (1A merged)
Content-engine API routes no longer return 500 from MCP compilation failure
Published drafts show status published instead of published_stub (1B merged)
Owned-domain crawl produces our_page documents (1C merged)
The core content pipeline (strategy → brief → draft → publish) is code-complete

CLAUDE.md Update:

Add the following to the project's CLAUDE.md before starting Phase 2:

## Lessons from Phase 1

### Build
- The `/api/mcp` route uses `@mastra/mcp` and `fetch-to-node`. If these packages
  are unavailable, the route must gracefully degrade — a single broken API route
  poisons all sibling routes in Next.js.
- Always run `pnpm build` after dependency changes, not just `pnpm dev`.

### Status naming
- Draft statuses: draft → in_review → pending_human_review → approved →
  ready_to_publish → published
- The old `published_stub` status has been removed. Use `published`.
- The step is now called `publishStep` (or `publishToConsulStep`), not `publishStubStep`.

### Document classification
- Owned-domain pages must be classified as `our_page`, not `competitor_page`.
- The sync path checks `site_targets` to determine the owned domain.
- `competitor_page` is only for actual competitor domains.

Phase 2: Skills Authoring

What This Phase Accomplishes

Authors all 9 agent skills as markdown files. Without these, the agent gets empty strings instead of brand voice rules, content structure guidelines, and SEO checklists — producing generic, low-quality output. The skills are created in a frontend/skills-seed/ directory within the repo, with a seed script that copies them to the workspace.

Parallel Groups

All 3 groups run simultaneously. Each group owns a distinct set of skill directories.

Dashboard

Group	Status	Key Files
2A: Priority Skills	☐	`frontend/skills-seed/consul-voice/`, `draft-structure/`, `brief-writing/`, `seo-checklist/`
2B: Research Skills	☐	`frontend/skills-seed/content-planning/`, `competitive-analysis/`, `serp-interpretation/`
2C: Publishing Skills + Seed Script	☐	`frontend/skills-seed/cms-publishing/`, `post-publish-ops/`, `frontend/scripts/seed-skills.ts`

Group 2A: Author Priority Skills (Voice, Structure, SEO, Briefs)

Parallel With: 2B, 2C Depends On: Phase 1 complete (build passes) Size: L

Prompt

# [Phase 2, Group 2A]: Author Priority Skills — Voice, Structure, SEO, Briefs

## Context

You are working in an isolated workspace. Other agents are working in parallel
on other parts of the codebase — you cannot see their work.
Do not modify files outside your designated scope.

**Project:** Auctor is a content engine that produces blog content for Consul
(consul.ai), a B2B SaaS product for CEOs and founders. The agent uses a
skills system — markdown files loaded via `readSkill()` — to get domain
knowledge during workflow execution. Currently ALL 9 skills are EMPTY. The
agent gets empty strings instead of the knowledge it needs.

**Previous phases established:**
- Phase 1 fixed the production build, publish status, and document classification.
- The codebase builds and the content pipeline is code-complete.
- The skills catalog service reads from `{workspaceRoot}/skills/{skill-id}/SKILL.md`.
- Each skill needs YAML frontmatter (name, description, version, tags) and a
  markdown body with the actual knowledge/instructions.

**How skills are used:**
- `consul-voice` is loaded by the WRITER and EDITOR agents during draft production.
  It defines brand voice, tone rules, and writing style for Consul content.
- `draft-structure` is loaded by the WRITER agent. It defines article structure
  requirements, section patterns, and formatting rules.
- `seo-checklist` is loaded by the WRITER and the SEO VALIDATION step. It defines
  the SEO requirements the agent must satisfy.
- `brief-writing` is loaded by the BRIEF GENERATION agent. It defines the brief
  format, required sections, and quality criteria.

**About Consul (the brand):**
- Consul is a B2B SaaS AI assistant for CEOs and founders
- Target audience: CEOs, founders, and operators evaluating AI-powered executive assistance
- Brand positioning: high-trust, practical, operator-focused
- Editorial rules from the strategy directive:
  - "Avoid generic AI platitudes"
  - "Prefer concrete examples"
  - "Optimize for programmatic SEO without sounding templated"
  - EEAT: "Cite real operator pain", "Favor decision frameworks over fluff",
    "Reserve 20% for human experience and proof"

**SEO validation rules (from `seo-validator.ts`):**
The agent must know these to produce passing content:
1. Meta title: 40-65 characters
2. Meta description: 120-160 characters
3. Heading hierarchy: H1 only at top, H2-H4 thereafter
4. Primary keyword presence: 3+ mentions
5. Keyword density: 0.4%-2.5%
6. Content length: 600+ words (or content type minimum)
7. Internal links: 4+ minimum (to existing consul.ai pages)
8. Schema graph: Must have BlogPosting/FAQPage/WebPage
9. Slug format: valid URL slug (lowercase, hyphens, no special chars)
10. Structural compliance: FAQ blocks + minimum length per content type

## Your Task

Create 4 skill files, each as a self-contained markdown document with YAML
frontmatter. These are the highest-priority skills — the ones that most
directly impact output quality.

### Skill 1: `consul-voice`

Create `frontend/skills-seed/consul-voice/SKILL.md`

This skill defines Consul's brand voice and writing style. It must cover:
- **Tone:** Authoritative but approachable. Expert peer, not lecturer.
  Write as if advising a fellow CEO over coffee.
- **Language rules:**
  - Never use em-dashes (—). Use periods, commas, or semicolons instead.
  - Never use "leverage" as a verb. Use "use" or "apply".
  - Never use "cutting-edge", "game-changing", "revolutionary", or similar
    hyperbolic adjectives.
  - Avoid passive voice. Prefer direct, active constructions.
  - Never start sentences with "In today's fast-paced..." or similar clichés.
  - Use "you" and "your" to address the reader directly.
  - Prefer short sentences. Mix 8-word and 20-word sentences. Average: 14 words.
- **Structure rules:**
  - Lead with the insight or action, not background.
  - Every section must answer "so what?" for the reader.
  - Use concrete numbers, examples, and scenarios over abstract claims.
  - Cite real operator pain points, not hypothetical ones.
  - Reserve ~20% of content for human experience, proof, and real-world examples.
- **Things to avoid:**
  - Generic AI platitudes ("AI is transforming the way we...")
  - Templated-sounding content (vary sentence structure and openers)
  - Unsubstantiated claims without examples or data
  - Overly formal or academic tone
  - Bulleted lists as a crutch (use sparingly, prefer prose)

### Skill 2: `draft-structure`

Create `frontend/skills-seed/draft-structure/SKILL.md`

This skill defines article structure requirements:
- **Content type structures:**
  - Blog post (1200-2000 words): H1 title → intro (hook + thesis, 100-150 words) →
    3-5 H2 sections (each 200-400 words) → FAQ section (3-5 questions) → conclusion
    with CTA
  - Comparison (1500-2500 words): H1 title → intro with comparison framework →
    criteria-based H2 sections → comparison table → recommendation → FAQ → conclusion
  - Pillar page (2500-4000 words): H1 title → comprehensive intro → 5-8 H2
    sections with H3 subsections → internal link hub → FAQ → conclusion
  - How-to/Guide (1500-2500 words): H1 title → problem statement → step-by-step
    H2 sections → troubleshooting tips → FAQ → conclusion
- **Heading hierarchy:**
  - Exactly 1 H1 (the title, at the top)
  - H2 for major sections
  - H3-H4 for subsections (never skip levels)
  - Include primary keyword in H1 and at least 1 H2
- **Required elements:**
  - Introduction: Must hook with a specific pain point or insight in the first sentence
  - FAQ section: 3-5 questions in valid FAQ block format
  - Internal links: 4+ links to existing consul.ai blog posts (woven naturally into prose)
  - Schema graph: BlogPosting (default), FAQPage (if FAQ present), WebPage (for pillar)
  - CTA: Clear call-to-action at the end, relevant to the content topic
- **Image markers:** Use `[IMAGE: description]` format for image placement
  suggestions. Place at least 1 after the intro and 1 mid-article.

### Skill 3: `seo-checklist`

Create `frontend/skills-seed/seo-checklist/SKILL.md`

This skill is the SEO requirements reference:
- **Blocking requirements (ALL must pass to publish):**
  1. Meta title: 40-65 characters, includes primary keyword, compelling
  2. Meta description: 120-160 characters, includes primary keyword, has CTA
  3. Heading hierarchy: Single H1 at top, H2-H4 only thereafter, no skipped levels
  4. Primary keyword presence: 3+ natural mentions in body text
  5. Keyword density: 0.4%-2.5% of total word count
  6. Content length: 600+ words minimum (see content type minimums in draft-structure)
  7. Internal links: 4+ links to existing consul.ai pages
  8. Schema graph: Valid BlogPosting, FAQPage, or WebPage JSON-LD
  9. Slug format: lowercase, hyphenated, no special characters, includes keyword
  10. Structural compliance: FAQ blocks present (3-5 questions), content meets
      type-specific minimum length
- **Warning checks (improve but don't block):**
  - Image markers: at least 1 per 500 words
  - External links: 2+ authoritative external references
  - Readability: Flesch reading ease 50-70 (professional but accessible)
  - Content depth: addresses search intent comprehensively
  - FAQ quality: questions match "People Also Ask" patterns
- **Keyword integration guidelines:**
  - Primary keyword in: H1, meta title, meta description, first 100 words,
    at least 1 H2, URL slug
  - Secondary keywords: distributed naturally through H2s and body
  - Avoid keyword stuffing: no more than 2.5% density
  - Use semantic variations and related terms

### Skill 4: `brief-writing`

Create `frontend/skills-seed/brief-writing/SKILL.md`

This skill defines brief format and quality criteria:
- **Brief structure:**
  - Content angle: The specific thesis or perspective (not just the topic)
  - Target keyword: Primary keyword and 3-5 secondary keywords
  - Search intent: What the reader is trying to accomplish
  - Outline: H2 section titles with 1-sentence description of each
  - Keyword mapping: Which keywords appear in which sections
  - Competitor differentiation: How this content differs from top-ranking results
  - Internal link targets: 4+ existing consul.ai pages to reference
  - External references: Key sources to cite for credibility
  - Voice requirements: Specific voice/tone notes for this piece
  - Content type: blog_post, comparison, pillar, how_to, guide
  - Target word count: Based on content type and competitive analysis
- **Quality criteria for a good brief:**
  - Angle is specific and defensible (not "everything about X")
  - Differentiator is real (not "we'll cover it better")
  - Internal links reference actual existing consul.ai pages
  - Outline sections each have a clear purpose and keyword assignment
  - Voice requirements are specific to this piece, not generic

## Scope

**You own:** (create these files)
- `frontend/skills-seed/consul-voice/SKILL.md`
- `frontend/skills-seed/draft-structure/SKILL.md`
- `frontend/skills-seed/seo-checklist/SKILL.md`
- `frontend/skills-seed/brief-writing/SKILL.md`

**Do NOT touch:**
- Any files in `frontend/skills-seed/content-planning/` (owned by Group 2B)
- Any files in `frontend/skills-seed/competitive-analysis/` (owned by Group 2B)
- Any files in `frontend/skills-seed/serp-interpretation/` (owned by Group 2B)
- Any files in `frontend/skills-seed/cms-publishing/` (owned by Group 2C)
- Any files in `frontend/skills-seed/post-publish-ops/` (owned by Group 2C)
- `frontend/scripts/seed-skills.ts` (owned by Group 2C)
- Any existing source code files

## Requirements

1. Each SKILL.md file has valid YAML frontmatter with: name, description, version
   (use `1.0.0`), and tags (array of relevant strings).
2. `consul-voice` covers tone, language rules (including no em-dashes), structure
   principles, and things to avoid. Minimum 800 words.
3. `draft-structure` covers all 4 content types with specific word counts, heading
   patterns, and required elements. Minimum 600 words.
4. `seo-checklist` lists all 10 blocking checks with exact thresholds matching
   the SEO validator code. Minimum 500 words.
5. `brief-writing` defines the brief format with all required sections and quality
   criteria. Minimum 400 words.
6. All skills reference Consul-specific context (B2B SaaS, CEO audience, consul.ai domain).
7. Skills are written as instructions TO the agent (imperative: "Write in...",
   "Always include...", "Never use...").

## Patterns to Follow

YAML frontmatter format:
```yaml
---
name: "Consul Voice & Tone"
description: "Brand voice rules, writing style, and tone guidelines for Consul content"
version: "1.0.0"
tags: ["voice", "tone", "writing-style", "brand"]
---

Body format: Use markdown with H2 sections. Write as direct instructions to the agent.

Verification

Before you're done, run and fix any failures:

# Verify all 4 files exist and have frontmatter
for skill in consul-voice draft-structure seo-checklist brief-writing; do
  echo "--- $skill ---"
  test -f "frontend/skills-seed/$skill/SKILL.md" && echo "EXISTS" || echo "MISSING"
  head -5 "frontend/skills-seed/$skill/SKILL.md"
  wc -w "frontend/skills-seed/$skill/SKILL.md"
done

All 4 files must exist with valid frontmatter and meet the minimum word counts.

##### Verify

```bash
for skill in consul-voice draft-structure seo-checklist brief-writing; do
  test -f "frontend/skills-seed/$skill/SKILL.md" && echo "$skill: OK" || echo "$skill: MISSING"
  wc -w "frontend/skills-seed/$skill/SKILL.md"
done

Diff Review

Must see: 4 SKILL.md files with YAML frontmatter in frontend/skills-seed/
Must verify: consul-voice includes the no-em-dash rule; seo-checklist thresholds match validator (40-65 meta title, 0.4-2.5% density, 4+ internal links, etc.)
Red flag: Agent created files outside frontend/skills-seed/, or modified source code

Group 2B: Author Research & Planning Skills

Parallel With: 2A, 2C Depends On: Phase 1 complete Size: M

Prompt

# [Phase 2, Group 2B]: Author Research & Planning Skills

## Context

You are working in an isolated workspace. Other agents are working in parallel
on other parts of the codebase — you cannot see their work.
Do not modify files outside your designated scope.

**Project:** Auctor is a content engine for Consul (consul.ai), a B2B SaaS AI
assistant for CEOs and founders. The agent uses skills (markdown files loaded
via `readSkill()`) for domain knowledge during workflow execution.

**Previous phases established:**
- Phase 1 fixed the production build, publish status, and document classification.
- The skills catalog reads from `{workspaceRoot}/skills/{skill-id}/SKILL.md`.
- Each skill needs YAML frontmatter (name, description, version, tags) and a
  markdown body.

**How these skills are used:**
- `competitive-analysis` is loaded during the `competitiveIntelligenceStep` of the
  strategy workflow. It guides how the agent analyzes competitor content, identifies
  gaps, and scores threats.
- `serp-interpretation` is loaded during the `searchLandscapeStep`. It guides how
  the agent reads SERP data, identifies ranking patterns, and spots opportunities.
- `content-planning` is loaded during the `contentStrategyStep`. It guides how the
  agent creates plan items with target keywords, content types, and priority.

**Data available to the agent during these steps:**
- Competitor documents and extractions (content, metadata, structure)
- Summary nodes (page/cluster/domain-level summaries)
- Graph edges (covers_topic, targets_keyword, links_to, competes_on_keyword)
- Tracked keywords with metrics (volume, difficulty, CPC, intent)
- SERP snapshots and rankings
- Domain rankings and threat scores

## Your Task

Create 3 skill files for the research and planning phase of the content pipeline.

### Skill 1: `competitive-analysis`

Create `frontend/skills-seed/competitive-analysis/SKILL.md`

Cover:
- How to analyze competitor content (structure, depth, angle, gaps)
- Threat scoring methodology (content overlap, keyword competition, authority)
- Gap identification (topics competitors cover that we don't, and vice versa)
- Differentiation strategy (how to create content that outperforms competitors)
- Using graph edges and summary nodes to map competitive landscape
- Prioritizing which competitors to focus on

### Skill 2: `serp-interpretation`

Create `frontend/skills-seed/serp-interpretation/SKILL.md`

Cover:
- How to read SERP features (featured snippets, PAA, knowledge panels)
- Identifying search intent from SERP layout
- Ranking pattern analysis (what top results have in common)
- Opportunity signals (weak results, outdated content, thin content in top positions)
- AI overview tracking and implications for content strategy
- Using SERP data to inform content type selection

### Skill 3: `content-planning`

Create `frontend/skills-seed/content-planning/SKILL.md`

Cover:
- Creating plan items with: target keyword, content type, rationale, priority,
  estimated impact, internal link targets
- Content type selection criteria:
  - blog_post: informational queries, thought leadership, 1200-2000 words
  - comparison: "vs" and "best" queries, decision-stage, 1500-2500 words
  - pillar: broad topic hubs, link magnets, 2500-4000 words
  - how_to: procedural queries, problem-solving, 1500-2500 words
  - guide: comprehensive reference, educational, 1500-2500 words
- Prioritization framework: search volume × (1 / difficulty) × business relevance
- Topic clustering: grouping keywords by intent and assigning to content pieces
- Internal linking strategy: how to plan link targets for each new piece
- Calendar scheduling: cadence recommendations and seasonal considerations

## Scope

**You own:** (create these files)
- `frontend/skills-seed/competitive-analysis/SKILL.md`
- `frontend/skills-seed/serp-interpretation/SKILL.md`
- `frontend/skills-seed/content-planning/SKILL.md`

**Do NOT touch:**
- `frontend/skills-seed/consul-voice/` (owned by Group 2A)
- `frontend/skills-seed/draft-structure/` (owned by Group 2A)
- `frontend/skills-seed/seo-checklist/` (owned by Group 2A)
- `frontend/skills-seed/brief-writing/` (owned by Group 2A)
- `frontend/skills-seed/cms-publishing/` (owned by Group 2C)
- `frontend/skills-seed/post-publish-ops/` (owned by Group 2C)
- `frontend/scripts/seed-skills.ts` (owned by Group 2C)
- Any existing source code files

## Requirements

1. Each SKILL.md has valid YAML frontmatter: name, description, version (`1.0.0`), tags.
2. `competitive-analysis` covers gap identification, threat scoring, and
   differentiation. Minimum 500 words.
3. `serp-interpretation` covers SERP features, intent analysis, and opportunity
   signals. Minimum 500 words.
4. `content-planning` covers plan item creation, content type selection, and
   prioritization. Minimum 600 words.
5. All skills reference Consul's B2B SaaS context and CEO audience.
6. Skills are written as instructions TO the agent (imperative mood).

## Patterns to Follow

YAML frontmatter format:
```yaml
---
name: "Competitive Analysis"
description: "How to analyze competitor content and identify strategic gaps"
version: "1.0.0"
tags: ["competitive-analysis", "research", "strategy"]
---

Verification

Before you're done, run and fix any failures:

for skill in competitive-analysis serp-interpretation content-planning; do
  echo "--- $skill ---"
  test -f "frontend/skills-seed/$skill/SKILL.md" && echo "EXISTS" || echo "MISSING"
  head -5 "frontend/skills-seed/$skill/SKILL.md"
  wc -w "frontend/skills-seed/$skill/SKILL.md"
done

All 3 files must exist with valid frontmatter and meet minimum word counts.

##### Verify

```bash
for skill in competitive-analysis serp-interpretation content-planning; do
  test -f "frontend/skills-seed/$skill/SKILL.md" && echo "$skill: OK" || echo "$skill: MISSING"
  wc -w "frontend/skills-seed/$skill/SKILL.md"
done

Diff Review

Must see: 3 SKILL.md files with frontmatter in correct directories
Must verify: Content is Consul-specific (not generic SEO advice); instructions are in imperative mood
Red flag: Agent created files in Group 2A or 2C directories, or modified source code

Group 2C: Author Publishing Skills + Seed Script

Parallel With: 2A, 2B Depends On: Phase 1 complete Size: M

Prompt

# [Phase 2, Group 2C]: Author Publishing Skills + Seed Script

## Context

You are working in an isolated workspace. Other agents are working in parallel
on other parts of the codebase — you cannot see their work.
Do not modify files outside your designated scope.

**Project:** Auctor is a content engine for Consul (consul.ai). The agent uses
skills (markdown files in `{workspaceRoot}/skills/{skill-id}/SKILL.md`) for
domain knowledge. You're authoring the 2 publishing skills and creating a script
to install all 9 skills from the repo into the workspace.

**Previous phases established:**
- Phase 1 fixed the production build, publish status, and document classification.
- The workspace root defaults to:
  `~/Library/Application Support/com.auctor.desktop/workspace/`
- The skills catalog reads from `{workspaceRoot}/skills/{skill-id}/SKILL.md`
- 7 other skills are being authored by parallel agents in:
  `frontend/skills-seed/{skill-id}/SKILL.md`

**How these skills are used:**
- `cms-publishing` is loaded during the `publishStep` (formerly publishStubStep).
  It guides the final publish preparation.
- `post-publish-ops` is loaded after publishing. It guides post-publish tasks
  like indexing, monitoring, and performance tracking.

**Consul CMS publishing context:**
- Publishes to `consul.posts` via Supabase
- Fields: slug, title, content (markdown), excerpt, meta_title, meta_description,
  schema_graph (JSON-LD), faq_blocks, canonical_url, content_type, author_id
  (consul-team), category (ai-assistant default), reading_time, word_count,
  seo_score, cta
- Also writes: `consul.post_keywords`, `consul.post_validations`, `consul.post_relationships`
- Canonical URL pattern: `https://consul.ai/blog/{slug}`
- Content types: article, comparison, pillar, workflow
- Indexing is currently stubbed (manual URL submission to Google Search Console)

## Your Task

### Part 1: Author 2 skill files

#### Skill 1: `cms-publishing`

Create `frontend/skills-seed/cms-publishing/SKILL.md`

Cover:
- Pre-publish checklist: SEO score must be 10/10, all blocking checks pass
- Content field preparation: meta title, meta description, excerpt, slug format
- Schema graph requirements: valid BlogPosting/FAQPage/WebPage JSON-LD
- Internal link verification: all 4+ internal links must resolve to real consul.ai pages
- Category assignment: use `ai-assistant` as default, override when content
  fits `productivity`, `email-management`, or `scheduling`
- Author assignment: use `consul-team` as default
- CTA preparation: must be relevant to the content topic
- Canonical URL: `https://consul.ai/blog/{slug}`
- Content type mapping: blog_post→article, comparison→comparison, pillar→pillar,
  how_to→workflow, guide→article

#### Skill 2: `post-publish-ops`

Create `frontend/skills-seed/post-publish-ops/SKILL.md`

Cover:
- URL submission: manually submit to Google Search Console (indexing API is stubbed)
- Performance monitoring: check GSC for impressions/clicks after 48-72 hours
- Content quality check: verify the published page renders correctly on consul.ai
- Internal linking audit: verify that other pages link back to the new content
  where relevant
- Keyword tracking: monitor tracked keyword positions for the target keyword
- Update cycle: plan content freshness updates based on performance data
- Social distribution: share published content through appropriate channels

### Part 2: Create the seed script

Create `frontend/scripts/seed-skills.ts`

This script copies all 9 skills from `frontend/skills-seed/` to the workspace:

```typescript
// Script: seed-skills.ts
// Usage: npx tsx frontend/scripts/seed-skills.ts
//
// Copies skill files from frontend/skills-seed/{skill-id}/SKILL.md
// to {workspaceRoot}/skills/{skill-id}/SKILL.md
//
// Workspace root defaults to:
//   ~/Library/Application Support/com.auctor.desktop/workspace/
// Override with AUCTOR_WORKSPACE_ROOT env var.

The script must:

Determine workspace root (env var or default path)
List all skill directories in frontend/skills-seed/
For each, create the target directory and copy SKILL.md
Report what was installed
Not overwrite existing skills unless a --force flag is passed

Scope

You own: (create these files)

frontend/skills-seed/cms-publishing/SKILL.md
frontend/skills-seed/post-publish-ops/SKILL.md
frontend/scripts/seed-skills.ts

Do NOT touch:

frontend/skills-seed/consul-voice/ (owned by Group 2A)
frontend/skills-seed/draft-structure/ (owned by Group 2A)
frontend/skills-seed/seo-checklist/ (owned by Group 2A)
frontend/skills-seed/brief-writing/ (owned by Group 2A)
frontend/skills-seed/competitive-analysis/ (owned by Group 2B)
frontend/skills-seed/serp-interpretation/ (owned by Group 2B)
frontend/skills-seed/content-planning/ (owned by Group 2B)
Any existing source code files
The skills catalog code (frontend/src/content-engine/skills/catalog.ts)

Requirements

Each SKILL.md has valid YAML frontmatter: name, description, version (1.0.0), tags.
cms-publishing covers all pre-publish checks and field preparation. Min 400 words.
post-publish-ops covers monitoring, indexing, and update cycles. Min 400 words.
seed-skills.ts is a standalone script runnable with npx tsx.
Seed script handles missing workspace directory gracefully (create if needed).
Seed script skips existing skills unless --force is passed.
Seed script logs each skill installed with path.

Patterns to Follow

YAML frontmatter:

---
name: "CMS Publishing"
description: "Pre-publish preparation and CMS field requirements for Consul"
version: "1.0.0"
tags: ["publishing", "cms", "consul"]
---

Script pattern (Node.js with fs):

import { existsSync, mkdirSync, copyFileSync, readdirSync } from 'fs';
import { join, resolve } from 'path';
import { homedir } from 'os';

Verification

Before you're done, run and fix any failures:

# Check skill files
for skill in cms-publishing post-publish-ops; do
  test -f "frontend/skills-seed/$skill/SKILL.md" && echo "$skill: OK" || echo "$skill: MISSING"
  wc -w "frontend/skills-seed/$skill/SKILL.md"
done

# Check seed script exists and compiles
test -f "frontend/scripts/seed-skills.ts" && echo "seed-skills.ts: OK" || echo "MISSING"
npx tsx --help > /dev/null 2>&1 && echo "tsx available" || echo "tsx not available"

All files must exist and meet word counts.

##### Verify

```bash
for skill in cms-publishing post-publish-ops; do
  test -f "frontend/skills-seed/$skill/SKILL.md" && echo "$skill: OK" || echo "$skill: MISSING"
done
test -f "frontend/scripts/seed-skills.ts" && echo "seed script: OK" || echo "MISSING"

Diff Review

Must see: 2 SKILL.md files + seed-skills.ts script
Must verify: Seed script reads from skills-seed/ and writes to workspace; script has --force flag
Red flag: Agent modified skills catalog code or created files in other groups' directories

Phase 2 → Phase 3 Transition

State After Phase 2:

All 9 skills authored as markdown files in frontend/skills-seed/
Seed script available at frontend/scripts/seed-skills.ts
Skills are ready to be installed to the workspace via the seed script
The agent will now have brand voice rules, structure guidelines, SEO checklists, and all other domain knowledge it needs

CLAUDE.md Update:

Add the following to CLAUDE.md before starting Phase 3:

## Skills System

### Authoring
- Skills live in `frontend/skills-seed/{skill-id}/SKILL.md` (repo source of truth)
- Install to workspace with: `npx tsx frontend/scripts/seed-skills.ts`
- Use `--force` to overwrite existing skills

### Available Skills
- consul-voice: Brand voice, tone, no-em-dash rule, writing style
- draft-structure: Article structure by content type, heading hierarchy, required elements
- seo-checklist: 10 blocking SEO checks with exact thresholds
- brief-writing: Brief format, required sections, quality criteria
- content-planning: Plan item creation, content type selection, prioritization
- competitive-analysis: Gap identification, threat scoring, differentiation
- serp-interpretation: SERP features, intent analysis, opportunity signals
- cms-publishing: Pre-publish checklist, field preparation, CMS mapping
- post-publish-ops: Indexing, monitoring, update cycles

### Conventions
- Skills use YAML frontmatter (name, description, version, tags)
- Body is markdown with H2 sections
- Written as instructions TO the agent (imperative mood)
- All reference Consul's B2B SaaS context and CEO audience

Phase 3: Integration Verification & CLAUDE.md

What This Phase Accomplishes

Creates the final CLAUDE.md with all lessons learned and produces a verification checklist that the operator runs to confirm end-to-end readiness.

Dashboard

Group	Status	Key Files
3A: CLAUDE.md + Verification	☐	`CLAUDE.md`, `frontend/scripts/verify-launch-readiness.sh`

Group 3A: CLAUDE.md + Launch Verification Script

Parallel With: None (final phase) Depends On: Phase 1 and Phase 2 complete Size: M

Prompt

# [Phase 3, Group 3A]: CLAUDE.md + Launch Verification Script

## Context

You are working in an isolated workspace. This is the final phase — all code
fixes and skill authoring are complete.

**Project:** Auctor is a content engine for Consul (consul.ai). The codebase
has been through 2 phases of fixes:
- Phase 1 fixed: production build (MCP route), publish status (published_stub →
  published), and owned-domain document classification (competitor_page → our_page)
- Phase 2 authored: all 9 agent skills and a seed script

**What still needs manual operator action (NOT code changes):**
1. Add API keys to `.env`: ANTHROPIC_API_KEY, FIRECRAWL_API_KEY, DATAFORSEO_LOGIN,
   DATAFORSEO_PASSWORD
2. Apply database migration 0003 (`frontend/drizzle/0003_extraction_configs.sql`)
3. Run `npx tsx frontend/scripts/seed-skills.ts` to install skills to workspace
4. Run competitor crawls for top 5 competitors
5. Build summary nodes and graph edges from existing documents
6. Run keyword metrics collection
7. Execute a full end-to-end test: strategy → brief → draft → publish

## Your Task

### Part 1: Create CLAUDE.md

Create a comprehensive `CLAUDE.md` at the repository root with:
- Project overview (what Auctor is, tech stack)
- Key architectural decisions
- File ownership map (which directories contain what)
- Common commands (build, test, lint, seed skills)
- Known limitations and deferred items
- Lessons from Phase 1 and Phase 2 (included below)
- Convention rules for future development

### Part 2: Create launch verification script

Create `frontend/scripts/verify-launch-readiness.sh` — a bash script that
performs every automated check possible to confirm launch readiness:

1. `pnpm build` passes
2. `pnpm test:frontend` passes
3. All 9 skill files exist in skills-seed directory
4. No remaining references to `published_stub` in codebase
5. No remaining references to `publish-stub-step` in codebase
6. `.env` contains required keys (check for variable names, not values)
7. Backend `/health` returns 200

## Scope

**You own:**
- `CLAUDE.md` (repository root)
- `frontend/scripts/verify-launch-readiness.sh`

**Do NOT touch:**
- Any source code files
- Any skill files (already authored)
- `frontend/package.json` or any config files

## Requirements

1. `CLAUDE.md` is comprehensive, covering project overview, architecture,
   commands, conventions, and known limitations.
2. CLAUDE.md includes all Phase 1 and Phase 2 lessons (provided in context).
3. Verification script is executable (`chmod +x`).
4. Script outputs clear PASS/FAIL for each check.
5. Script exits with code 1 if any critical check fails.

## Content for CLAUDE.md

Include these lessons learned:

### Phase 1 Lessons
- The `/api/mcp` route uses `@mastra/mcp` and `fetch-to-node`. If unavailable,
  the route must degrade gracefully — one broken API route poisons all siblings.
- Always run `pnpm build` after dependency changes, not just `pnpm dev`.
- Draft statuses: draft → in_review → pending_human_review → approved →
  ready_to_publish → published. No `published_stub`.
- Owned-domain pages = `our_page`. Competitor pages = `competitor_page`. The sync
  path checks `site_targets` to determine classification.

### Phase 2 Lessons
- Skills live in `frontend/skills-seed/` and install to workspace via seed script.
- The agent gets empty strings for missing skills — always install before running workflows.
- 9 skills: consul-voice, draft-structure, seo-checklist, brief-writing,
  content-planning, competitive-analysis, serp-interpretation, cms-publishing, post-publish-ops.

### Known Limitations (deferred)
- Image pipeline: not implemented. Use text-first publishing; add images manually.
- Google Indexing API: stubbed. Submit URLs manually via Search Console.
- Post-publish monitoring: stubbed. Check GSC manually.
- Desktop bootstrap: not validated for this launch. Web-only.
- `frontend/next.config.mjs` sets `typescript.ignoreBuildErrors = true`.
- Lint: 92 errors and 15 warnings remain. Concentrated in ContentEngine files.

## Patterns to Follow

CLAUDE.md structure:
```markdown
# Project Name

## Overview
## Architecture
## Getting Started
## Key Commands
## File Structure
## Conventions
## Known Limitations
## Lessons Learned

Verification script pattern:

#!/bin/bash
set -euo pipefail

PASS=0
FAIL=0

check() {
  local name="$1"
  shift
  if "$@" > /dev/null 2>&1; then
    echo "✅ PASS: $name"
    ((PASS++))
  else
    echo "❌ FAIL: $name"
    ((FAIL++))
  fi
}

Verification

Before you're done, run and fix any failures:

# Check files exist
test -f "CLAUDE.md" && echo "CLAUDE.md: OK" || echo "MISSING"
test -f "frontend/scripts/verify-launch-readiness.sh" && echo "verify script: OK" || echo "MISSING"

# Check script is executable
test -x "frontend/scripts/verify-launch-readiness.sh" && echo "executable: OK" || echo "NOT EXECUTABLE"

# Check CLAUDE.md has key sections
grep -q "## Overview" CLAUDE.md && echo "has overview" || echo "missing overview"
grep -q "published_stub" CLAUDE.md && echo "has phase 1 lessons" || echo "missing lessons"
grep -q "skills-seed" CLAUDE.md && echo "has phase 2 lessons" || echo "missing lessons"

All files must exist and contain required sections.

##### Verify

```bash
test -f "CLAUDE.md" && echo "OK" || echo "MISSING"
test -f "frontend/scripts/verify-launch-readiness.sh" && echo "OK" || echo "MISSING"
chmod +x frontend/scripts/verify-launch-readiness.sh

Diff Review

Must see: CLAUDE.md at repo root with architecture and lessons; verification script
Must verify: CLAUDE.md covers all phase lessons; script checks for published_stub absence
Red flag: Agent modified any source code files

Done

The entire plan is complete when:

Automated Checks

# Run the verification script created in Phase 3
./frontend/scripts/verify-launch-readiness.sh

# Or manually:
cd frontend && pnpm build            # Must pass (Phase 1A)
cd frontend && pnpm test:frontend    # Must pass

# Confirm Phase 1B
grep -r "published_stub" frontend/src/ frontend/app/ frontend/components/
# Must return 0 results

# Confirm Phase 1C
grep -n "our_page" frontend/src/content-engine/services/competitor-crawl.ts
# Must show owned-domain classification logic

# Confirm Phase 2
ls frontend/skills-seed/*/SKILL.md | wc -l
# Must show 9

# Confirm Phase 3
test -f CLAUDE.md && echo "OK"

Manual Steps (operator performs after all phases)

These are NOT code changes — they're operational setup:

Add API keys to .env:
- ANTHROPIC_API_KEY=sk-ant-... (required for ALL agent operations)
- FIRECRAWL_API_KEY=fc-... (required for competitor crawling)
- DATAFORSEO_LOGIN=... (required for keyword metrics)
- DATAFORSEO_PASSWORD=...
- Optional: GSC_CLIENT_EMAIL, GSC_PRIVATE_KEY, GSC_SITE_URL, GA4_PROPERTY_ID
Apply migration 0003:

1-- Run in Supabase SQL editor 2-- File: frontend/drizzle/0003_extraction_configs.sql
Install skills to workspace:

1npx tsx frontend/scripts/seed-skills.ts
Populate data pipeline:

1# Run competitor crawls (after FIRECRAWL_API_KEY is set) 2curl -X POST http://localhost:3001/api/content-engine/competitors/crawl 3 4# Build summaries + graph 5# (via API or MCP tool calls) 6 7# Run keyword metrics (after DATAFORSEO is set) 8# (via API or MCP tool calls)
End-to-end validation: Run one full cycle: strategy → approve plan item → brief → approve brief → draft → review → publish → verify in consul.posts

Appendix A: Analysis Report

What The 5 Unique Audits Agreed On

(Note: Documents 4 and 6 are identical — 5 unique audits, not 6.)

Unanimous (5/5):

Production build is broken by /api/mcp/route.ts imports
All 9 agent skills are empty/missing
Data pipeline is completely empty (0 crawled pages, 0 keyword metrics, 0 summaries, 0 graph edges)
No image upload pipeline exists
Indexing provider is stubbed
Publishing to consul.posts is implemented and real
SEO validator is complete with 10 blocking checks
All 3 workflows (strategy, brief, draft) are structurally implemented
33 competitor domains registered but never crawled
178 keywords tracked but not enriched

Majority (3-4/5):

published_stub status is misleading (Audits 4, 5, 6 call it P0; Audits 2, 3 don't mention it)
Owned-domain sync writes competitor_page instead of our_page (Audits 4, 5, 6 call it P0)
Migration 0003 not applied (Audit 3 identifies explicitly; others mention generally)
pnpm lint has 92 errors, 15 warnings (Audits 4, 5 measured; others don't)

Where They Diverged

Issue	Audit 2	Audit 3	Audit 4	Audit 5
`ANTHROPIC_API_KEY`	Missing (P0)	Likely OK (sessions exist)	Likely OK but editor logs it missing	Missing from shell env
Skills content	Lists all 9 as empty	Says "unverified" for consul-voice	Mentions skill/tool mismatch	Same as Audit 4
Desktop launch	Not discussed	Not discussed	P2, defer	Launch blocker for desktop claim
Lint debt	Not discussed	Not discussed	P1 (accept or reduce)	Launch risk

Resolution:

ANTHROPIC_API_KEY: Treated as operational verification, not code fix. The key may exist in .env but not in all runtime contexts. Added to manual checklist.
Skills: All 9 authored from scratch — both "empty" and "unverified" cases are resolved.
Desktop: Deferred. This playbook is web-only.
Lint: Deferred. Not a code fix for this plan.

What Was Missing

Gap	Resolution
No concrete skill content was provided by any audit	Phase 2 authors all 9 skills with Consul-specific content
No seed script to install skills	Phase 2C creates `seed-skills.ts`
No CLAUDE.md for future agents	Phase 3 creates comprehensive CLAUDE.md
No automated verification script	Phase 3 creates `verify-launch-readiness.sh`
Migration 0003 application	Added to manual checklist (single SQL file, not a code change)
Desktop port configuration (3000 vs 3001 vs 3100)	Deferred — web-only launch

Appendix B: Recovery

Agent went off-track

Check the diff — if it touched files outside its ownership, reject the branch and re-run. Key ownership boundaries:

Group 1A: ONLY frontend/app/api/mcp/route.ts and frontend/package.json
Group 1B: ONLY files containing published_stub or publish-stub-step
Group 1C: ONLY competitor-crawl.ts, repositories.ts (sync path), and register-domain route
Groups 2A/2B/2C: ONLY files within their assigned frontend/skills-seed/ subdirectories (plus seed script for 2C)
Group 3A: ONLY CLAUDE.md and verify-launch-readiness.sh

Tests fail after merge

Identify which test(s) fail and which phase likely caused it.
Spin up a new agent with the failing test output and the relevant phase's prompt.
Scope: "Fix the test failure caused by [specific change]. Only modify files within [ownership scope]."

Build fails after merge

Most likely cause: Phase 1A's fix didn't fully resolve the MCP route issue.

Check pnpm build output for the specific error.
Re-run Group 1A with the error message appended to the prompt.

Skills don't load in the agent

Verify skills were installed: ls ~/Library/Application\ Support/com.auctor.desktop/workspace/skills/
If empty, run: npx tsx frontend/scripts/seed-skills.ts --force
If seed script fails, manually copy from frontend/skills-seed/ to workspace.