myaidev-method 0.3.4 → 0.3.5

package/skills/{content-rules-setup → myai-content-rules-setup}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: content-rules-setup
+name: myai-content-rules-setup
 description: Runs an interactive wizard for configuring brand voice, style guidelines, and content generation rules. Use when setting up content-rules.md for the first time, updating brand voice settings, or configuring content generation preferences.
 argument-hint: [--quick] [--update] [--preview]
 allowed-tools: [Read, Write, Edit, AskUserQuestion, Glob, Grep]

package/skills/{content-verifier → myai-content-verifier}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: content-verifier
+name: myai-content-verifier
 description: Verifies content uniqueness, quality, and publishing readiness by checking for plagiarism, AI-generated patterns, and knowledge redundancy. Use when reviewing content before publishing, checking article originality, or assessing content quality.
 argument-hint: [file.md] [--strict]
 allowed-tools: [Read, Write, Edit, Bash, WebSearch, WebFetch, Grep, Glob]

package/skills/myai-content-writer/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: myai-content-writer
+description: Orchestrates professional content creation through a multi-agent pipeline covering research, planning, writing, SEO optimization, and visual generation. Use when creating articles, blog posts, technical tutorials, or any written content.
+argument-hint: "[topic] [--word-count=1500] [--tone=professional] [--type=blog-post] [--with-images]"
+allowed-tools: [Read, Write, Edit, WebSearch, WebFetch, Task, Bash, Glob, Grep, AskUserQuestion]
+context: fork
+---
+
+# Content Writer Skill v2 — Orchestrator Pattern
+
+You are the **Content Production Orchestrator**, a coordinator that decomposes content creation into specialized subagent tasks. Inspired by long-running agent harness patterns, you maintain a lightweight planning context while delegating intensive work to isolated subagents.
+
+## Architecture Overview
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                  ORCHESTRATOR (this skill)              │
+│  • Parses arguments & loads content-rules               │
+│  • Creates execution plan                               │
+│  • Dispatches subagents                                 │
+│  • Aggregates results into final article                │
+│  • Manages scratchpad state files                       │
+└──────────────┬──────────────────────────────────────────┘
+               │ spawns
+    ┌──────────┼──────────────┬─────────────────┐
+    ▼          ▼              ▼                 ▼
+┌────────┐ ┌────────┐  ┌──────────┐  ┌──────────────┐
+│Research│ │Planner │  │  Writer  │  │Visual Planner│
+│ Agent  │ │ Agent  │  │  Agent   │  │    Agent     │
+└────────┘ └────────┘  └──────────┘  └──────────────┘
+                              │
+                    ┌─────────┼──────────┐
+                    ▼         ▼          ▼
+              ┌─────────┐ ┌──────┐ ┌────────┐
+              │SEO Agent│ │Editor│ │Visuals │
+              └─────────┘ └──────┘ └────────┘
+```
+
+## Execution Phases
+
+### Phase 0: Initialize
+- Parse `$ARGUMENTS` for topic, flags, and parameters
+- Load `content-rules.md` if present (check: `./content-rules.md`, `./.claude/content-rules.md`, `./docs/content-rules.md`)
+- Determine content type template and constraints
+- Create scratchpad directory: `.content-session/` (ephemeral, gitignored)
+
+### Phase 1: Research (Subagent)
+Spawn a **research subagent** to gather information:
+
+```
+Task(subagent_type: "general-purpose", prompt: "...")
+```
+
+The research agent:
+- Uses WebSearch to find 5-8 relevant, current sources
+- Extracts key facts, statistics, expert quotes
+- Identifies content gaps in existing coverage
+- Writes findings to `.content-session/research.md`
+- Returns a concise research summary (not raw data)
+
+### Phase 2: Plan (Subagent)
+Spawn a **planning subagent** with research summary + content rules:
+
+The planner:
+- Creates detailed article outline with section structure
+- Assigns word count targets per section
+- Plans keyword placement strategy
+- Identifies visual content opportunities (if `--with-images`)
+- Writes plan to `.content-session/plan.md`
+- Returns the outline structure
+
+### Phase 3: Write (Subagent — main workload)
+Spawn a **writer subagent** with the plan + research + content rules:
+
+The writer:
+- Produces the full article following the plan
+- Applies brand voice from content-rules
+- Integrates research findings naturally
+- Writes draft to `.content-session/draft.md`
+- Returns completion status
+
+### Phase 4: Optimize (Parallel Subagents)
+Spawn SEO and editorial subagents **in parallel**:
+
+**SEO Agent:**
+- Reviews keyword density and placement
+- Generates meta description, slug, tags
+- Suggests internal/external links
+- Checks heading hierarchy
+- Writes SEO report to `.content-session/seo-report.md`
+
+**Editor Agent:**
+- Reviews for clarity, flow, grammar
+- Checks tone consistency
+- Verifies factual accuracy markers
+- Suggests improvements
+- Writes edit notes to `.content-session/edit-notes.md`
+
+### Phase 5: Visual Strategy (Conditional — if `--with-images`)
+Spawn a **visual planning subagent**:
+- Reviews article for visual opportunities
+- Creates image specifications (prompts, types, placements)
+- Writes visual plan to `.content-session/visual-plan.md`
+- Orchestrator then generates images using the visual-generator skill
+
+### Phase 6: Assemble & Finalize
+The orchestrator (this skill):
+- Reads all scratchpad files
+- Applies SEO recommendations to the draft
+- Incorporates editorial improvements
+- Embeds visual references if generated
+- Produces final article with proper frontmatter
+- Saves to `./content-output/{slug}.md`
+- Cleans up `.content-session/` directory
+
+## Parameters
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `topic` | Main subject matter | Required |
+| `--word-count` | Target article length | 1500 |
+| `--tone` | Voice: professional, casual, technical, conversational, academic | professional |
+| `--type` | Template: blog-post, technical-tutorial, how-to-guide, listicle, comparison-guide, case-study, api-documentation, architecture-guide | blog-post |
+| `--audience` | Target reader demographic | general |
+| `--keywords` | Comma-separated primary,secondary keywords | auto-detected |
+| `--with-images` | Enable AI visual generation | false |
+| `--image-service` | Preferred image service: gemini, dalle, flux, imagen | auto |
+| `--publish` | Publish to platform: wordpress, payloadcms, docusaurus, mintlify, astro | none |
+| `--output-dir` | Output directory for final article | ./content-output |
+| `--no-research` | Skip research phase (use for topics you provide context for) | false |
+| `--verbose` | Show detailed progress from each phase | false |
+
+## Content Rules Integration
+
+The orchestrator automatically discovers and loads content rules. Rules are passed to every subagent to ensure consistent brand voice.
+
+**Discovery order:**
+1. `./content-rules.md`
+2. `./.claude/content-rules.md`
+3. `./docs/content-rules.md`
+
+If no rules file exists, suggest running the content-rules-setup skill.
+
+**Rules are injected into subagent prompts as:**
+```
+## Brand & Style Guidelines (from content-rules.md)
+{content of rules file}
+```
+
+## Subagent Prompt Templates
+
+Each subagent has a detailed prompt template in the `agents/` directory. Load the appropriate file when spawning each subagent, injecting the dynamic variables ({topic}, {type}, {tone}, etc.) and {content_rules_section}.
+
+| Phase | Prompt File | Key Variables |
+|-------|-------------|---------------|
+| Research | [agents/research-agent.md](agents/research-agent.md) | topic, type, audience, tone |
+| Planning | [agents/planner-agent.md](agents/planner-agent.md) | topic, type, word_count, tone, audience, keywords, research_summary |
+| Writing | [agents/writer-agent.md](agents/writer-agent.md) | plan_content, research_summary, word_count, tone |
+| SEO | [agents/seo-agent.md](agents/seo-agent.md) | draft_content, keywords, type |
+| Editor | [agents/editor-agent.md](agents/editor-agent.md) | draft_content, tone, audience |
+| Visual | [agents/visual-planner-agent.md](agents/visual-planner-agent.md) | draft_content, type, available_services |
+
+All templates include a `{content_rules_section}` placeholder — inject the loaded content-rules when present.
+
+## Content Type Templates
+
+| Type | Structure | Typical Length | Key Elements |
+|------|-----------|----------------|--------------|
+| `blog-post` | Intro → 3-5 sections → Conclusion | 1500-2500 | Hook, examples, CTA |
+| `technical-tutorial` | Prereqs → Steps → Troubleshooting | 2000-3500 | Code, diagrams, verification |
+| `how-to-guide` | Problem → Solution → Best Practices | 1500-2500 | Step-by-step, tips |
+| `listicle` | Intro → Numbered Items → Summary | 1200-2000 | Consistent format per item |
+| `comparison-guide` | Overview → Deep Dives → Decision | 1500-2500 | Tables, pros/cons |
+| `case-study` | Challenge → Solution → Results | 1200-2000 | Metrics, quotes |
+| `api-documentation` | Overview → Endpoints → Examples | 1000-2000 | Code, tables |
+| `architecture-guide` | Summary → Components → Data Flow | 2500-4000 | Diagrams, tech details |
+
+## State Management (Scratchpad Pattern)
+
+All intermediate work is written to `.content-session/` directory:
+
+```
+.content-session/
+├── config.json          # Parsed arguments and settings
+├── content-rules.md     # Loaded content rules (if found)
+├── research.md          # Research agent output
+├── plan.md              # Article plan
+├── draft.md             # Writer agent output
+├── seo-report.md        # SEO optimization suggestions
+├── edit-notes.md        # Editorial feedback
+├── visual-plan.json     # Visual content specifications
+└── final-meta.json      # Assembled frontmatter data
+```
+
+This keeps the orchestrator's context lean — it reads only what it needs for each phase.
+
+## Execution Flow
+
+```
+1. INIT        → Parse args, load rules, create session dir
+2. RESEARCH    → Spawn research agent (skip if --no-research)
+3. PLAN        → Spawn planner with research summary
+4. WRITE       → Spawn writer with plan + research
+5. OPTIMIZE    → Spawn SEO + Editor agents IN PARALLEL
+6. VISUALS     → Spawn visual planner (if --with-images)
+                  → Generate images using visual-generator skill
+7. ASSEMBLE    → Read all outputs, produce final article
+8. OUTPUT      → Save to output-dir, optionally publish
+9. CLEANUP     → Remove .content-session/ directory
+```
+
+## Error Handling
+
+- If a subagent fails, log the error and continue with what's available
+- Research failure → proceed with plan (user-provided context may suffice)
+- SEO/Editor failure → use draft as-is with basic frontmatter
+- Visual generation failure → produce article without images
+- Never block the entire pipeline on a single failure
+
+## Context Management (Long-Running Agent Patterns)
+
+### Context Regurgitation
+Before dispatching each subagent, briefly restate in your prompt:
+- Current phase number and what's been completed so far
+- Key decisions made (chosen angle, title direction, tone calibration)
+- What this subagent needs to accomplish and how its output feeds the next phase
+
+This keeps critical context fresh at the end of the context window where LLM attention is strongest.
+
+### Dynamic Plan Updates
+If a subagent returns indicating the plan needs revision (e.g., writer discovers research gaps, SEO agent finds the angle is unsearchable):
+1. Parse the update request from the subagent's output
+2. Re-run the affected earlier phase with the new context
+3. Resume the pipeline from the current phase
+4. Maximum **2 plan revisions per session** to prevent infinite loops
+5. Log each revision to `.content-session/revisions.md`
+
+### File Buffering
+All subagent outputs go to `.content-session/` files — never pass raw subagent output directly into the next prompt. Read only the specific file sections needed for each phase. This keeps the orchestrator's active context lean.
+
+## Progress Reporting
+
+At each phase transition, report to the user:
+
+```
+→ Phase 1/6: Researching "{topic}"...
+  ✓ Found 6 sources, identified 3 unique angles
+→ Phase 2/6: Planning article structure...
+  ✓ Outline ready: 5 sections, ~{word_count} words target
+→ Phase 3/6: Writing article...
+  ✓ Draft complete: {actual_word_count} words
+→ Phase 4/6: Optimizing (SEO + Editorial review)...
+  ✓ SEO score: 8.5/10 | Editorial score: 8/10
+→ Phase 5/6: Generating visual content...
+  ✓ 3 images generated ($0.06 total)
+→ Phase 6/6: Assembling final article...
+  ✓ Saved to ./content-output/{slug}.md
+
+📊 Summary:
+  Words: {count} | Reading Time: {time}
+  SEO Score: {score}/10 | Quality: {score}/10
+  Images: {count} | Cost: ${total}
+```
+
+## Output Format
+
+Final article is saved with full frontmatter:
+
+```markdown
+---
+title: [SEO-optimized title]
+meta_description: [150-160 chars]
+slug: [url-friendly]
+tags: [relevant, tags]
+keywords:
+  primary: [main keyword]
+  secondary: [supporting, keywords]
+word_count: [actual count]
+reading_time: [X minutes]
+content_type: [type used]
+generated_at: [ISO timestamp]
+images: [list of generated image paths, if any]
+---
+
+# [Title]
+
+[Full article content with embedded image references]
+```
+
+## Publishing Integration
+
+If `--publish` is specified, after saving the article locally:
+
+1. Determine target platform from flag value
+2. Spawn appropriate publishing subagent:
+   - `wordpress-publisher` for WordPress
+   - `payloadcms-publisher` for PayloadCMS
+   - Use static-site utilities for Docusaurus/Mintlify/Astro
+3. Report published URL to user
+
+## Example Usage
+
+```bash
+# Basic article
+/myaidev-method:content-writer "Kubernetes Best Practices for Production"
+
+# Full-featured with visuals
+/myaidev-method:content-writer "Building a RAG Pipeline" --word-count=2500 --type=technical-tutorial --with-images --tone=technical
+
+# With publishing
+/myaidev-method:content-writer "Getting Started with Docker" --publish=wordpress --tone=conversational
+
+# Skip research (you provide context)
+/myaidev-method:content-writer "Our Q4 Product Launch" --no-research --type=case-study
+
+# Custom output location
+/myaidev-method:content-writer "API Design Patterns" --output-dir=./blog/posts --keywords="api design,rest best practices"
+```
+
+## Quality Checklist (Applied by Editor Agent)
+
+- [ ] Title includes primary keyword and is compelling
+- [ ] Introduction hooks reader within 2 sentences
+- [ ] Content addresses user intent thoroughly
+- [ ] Facts are accurate and attributed
+- [ ] Heading hierarchy is proper (H1 → H2 → H3)
+- [ ] Content is scannable (varied formatting)
+- [ ] Keywords integrated naturally (not stuffed)
+- [ ] Meta description summarizes effectively
+- [ ] Conclusion provides value and next steps
+- [ ] Tone consistent throughout
+- [ ] Original value — not just repackaged existing content
+

package/skills/{infographic → myai-infographic}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: generating-infographics
+name: myai-infographic
 description: Creates diagrams (architecture, flowcharts, timelines, sequences) from Mermaid code and inserts them into markdown articles as asset-referenced images (PNG by default for universal compatibility). Use when enriching articles with diagrams, adding infographics to blog posts, visualizing technical content, or when the user mentions diagrams, infographics, or visual content for markdown.
 argument-hint: "[article.md] [--style=modern] [--max-diagrams=8] [--theme=default]"
 allowed-tools: [Read, Write, Edit, Bash, Task, Glob, Grep, AskUserQuestion]

package/skills/myai-proprietary-content-verifier/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: myai-proprietary-content-verifier
+description: Pre-production gate that scans content-queue stubs for redundancy against existing blog content, scores each stub (1–5), and marks it approved or rejected before writing begins.
+argument-hint: "[--queue-dir=./content-queue] [--blog-dir=./content-output] [--threshold=3]"
+user-invocable: false
+allowed-tools: [Read, Write, WebSearch, WebFetch, Glob, Grep]
+---
+
+# Proprietary Content Verifier
+
+Pre-production quality gate. Runs **before** the content-writer phase to ensure every stub in `content-queue/` is worth producing. Checks for redundancy against existing published/blog content, scores each stub, and stamps an approval decision into the stub's frontmatter.
+
+The production coordinator dispatches this skill on a queue directory (or a single stub). Only stubs marked `approved` proceed to the writing pipeline.
+
+## When This Runs
+
+```
+Ideation (produces stubs) → ** Proprietary Content Verifier ** → Content Writer (approved stubs only)
+```
+
+This is a **pre-production** step — it operates on stubs (lightweight briefs), not full drafts.
+
+## Parameters
+
+| Flag | Purpose | Default |
+|------|---------|---------|
+| `--queue-dir` | Path to content queue directory (or a specific job sub-directory) | `./content-queue/` |
+| `--blog-dir` | Path to existing blog/content output directory to check against | `./content-output/` |
+| `--threshold` | Minimum score (1–5) required for approval | `3` |
+| `--force` | Skip confirmation prompts | `false` |
+
+## Process
+
+1. **Load Existing Content Inventory**
+   - Glob the blog directory (default: `./content-output/`) for `.md` files
+   - For each article, extract: title (from frontmatter or H1), slug, `keywords` (from frontmatter), first 200 words of body
+   - Build an in-memory inventory of existing coverage
+
+2. **Load Brand Context** (optional)
+   - Read `brand-config.json` if present to obtain the site URL for live blog search
+
+3. **Evaluate Each Stub**
+   For each `.md` file in the queue directory with `status: pending`:
+
+   a. **Parse the Stub** — read frontmatter (`title`, `keywords`, `goals`, `strategy`, `references`) and body content (Theme Context, Reference Material)
+
+   b. **Title & Topic Overlap** — compare the stub title against all existing article titles. Look for:
+      - Exact or near-exact title matches (score heavily)
+      - Topically equivalent titles covering the same subject
+
+   c. **Keyword Overlap** — compare the stub's `keywords` list against existing articles' `keywords`. Calculate overlap ratio. High overlap (>60%) is a strong redundancy signal.
+
+   d. **Semantic Overlap** — read the stub's Theme Context and goals, compare against the body openings of existing articles. Assess whether the core argument, angle, or value proposition is materially the same.
+
+   e. **Reference Overlap** — check if the stub's `references` URLs appear in any existing article. Shared references suggest similar sourcing and potential content duplication.
+
+   f. **Live Blog Check** (if site URL available) — use `WebSearch` with `site:{domain} {stub title keywords}` to find existing coverage on the live blog. Factor results into the score.
+
+   g. **Score Assignment** — synthesize all signals into a single Proprietary Value Score (see Scoring below).
+
+4. **Stamp Frontmatter**
+   Update each stub file's YAML frontmatter with a `verification` block:
+
+   ```yaml
+   verification:
+     score: {1-5}
+     label: "{Excellent|Good|Acceptable|Weak|Junk}"
+     decision: "{approved|rejected}"
+     reason: "{2-3 sentence explanation of the score and decision}"
+     checked_against:
+       - "{path to most relevant existing article}"
+       - "{path to second most relevant}"
+     verified_at: "{ISO 8601 timestamp}"
+   ```
+
+   For rejected stubs (score below threshold), also set `status: rejected`.
+
+5. **Return Summary**
+   Return a structured summary listing every evaluated stub with its score, label, decision, and reason.
+
+## Scoring
+
+Each stub receives a **Proprietary Value Score** from 1 to 5:
+
+| Score | Label | Criteria |
+|-------|-------|----------|
+| **5** | Excellent | No meaningful overlap. Strong proprietary angle, unique data/perspective, clear gap in existing coverage. |
+| **4** | Good | Minimal overlap. The stub covers a topic adjacent to existing content but from a distinctly different angle or for a different audience. |
+| **3** | Acceptable | Moderate overlap in topic area, but the stub introduces a fresh perspective, updated data, or a niche sub-topic not covered. |
+| **2** | Weak | Significant overlap. The stub's core thesis, audience, and key points largely mirror an existing article. Limited incremental value. |
+| **1** | Junk | Redundant. An existing article already covers this topic thoroughly with the same angle. Or the stub is too vague/generic to produce distinctive content. |
+
+Stubs scoring **at or above** `--threshold` (default 3) are marked `approved`. Those below are marked `rejected`.
+
+### Scoring Heuristics
+
+Weight these signals when computing the final score:
+
+| Signal | Weight | High Redundancy Indicator |
+|--------|--------|--------------------------|
+| Title/topic match | 30% | Exact or near-exact title match with existing article |
+| Keyword overlap | 25% | >60% keyword overlap with a single existing article |
+| Semantic similarity | 25% | Same thesis, argument structure, and target audience |
+| Reference overlap | 10% | >50% shared reference URLs with existing article |
+| Live blog match | 10% | Direct hit on site search for the stub's topic |
+
+## Frontmatter Stamp Examples
+
+Approved:
+
+```yaml
+verification:
+  score: 4
+  label: "Good"
+  decision: "approved"
+  reason: "Distinct angle on bare-metal GPU clusters not covered in existing content. Minor overlap with 'Cloud vs Bare Metal' article on infrastructure comparison, but this stub focuses specifically on ML workloads."
+  checked_against:
+    - "content-output/cloud-vs-bare-metal.md"
+    - "content-output/gpu-infrastructure-guide.md"
+  verified_at: "2026-02-23T14:30:22Z"
+```
+
+Rejected:
+
+```yaml
+status: rejected
+verification:
+  score: 2
+  label: "Weak"
+  decision: "rejected"
+  reason: "Heavily overlaps with existing article 'Kubernetes Best Practices' — same audience, same key points, no new proprietary angle."
+  checked_against:
+    - "content-output/kubernetes-best-practices.md"
+  verified_at: "2026-02-23T14:30:22Z"
+```
+
+## Execution Flow
+
+```
+1. DISCOVER    → Glob content-queue dir for .md stubs with status: pending
+2. LOAD BLOG   → Glob blog-dir for existing articles, extract titles + keywords + slugs
+3. EVALUATE    → For each stub: run redundancy checks, compute score
+4. STAMP       → Write verification block into each stub's frontmatter
+5. REPORT      → Print summary table and return list of approved slugs
+```
+
+## Output
+
+After verification, print a summary table:
+
+```
+Proprietary Content Verification
+═════════════════════════════════
+Queue:     {queue_dir}
+Blog:      {blog_dir}
+Threshold: {threshold}
+
+Results:
+  ✓ [5] kubernetes_gpu_clusters.md          — Excellent — "Highly original GPU cluster angle"
+  ✓ [4] bare_metal_ml_workloads.md          — Good      — "Fresh take on ML infrastructure"
+  ✓ [3] cloud_native_monitoring.md          — Acceptable — "Some overlap but distinct focus"
+  ✗ [2] kubernetes_best_practices.md        — Weak      — "Heavily overlaps existing article"
+  ✗ [1] docker_getting_started.md           — Junk      — "Already published nearly identical guide"
+
+Approved: 3/5 | Rejected: 2/5
+```
+
+## Constraints
+
+- Only evaluate stubs with `status: pending` — skip `complete`, `failed`, `rejected`, or `in-progress`
+- Do NOT modify any content in the stub body — only update frontmatter fields
+- Do NOT rewrite or edit existing blog articles
+- Provide a clear, specific reason for every score — mention which existing article(s) cause overlap
+- When no existing content inventory is found, note this and default all scores to 5 (no redundancy possible)
+- Process stubs in filename order for deterministic output

package/skills/myai-proprietary-content-verifier/evals/evals.json

@@ -0,0 +1,36 @@
+{
+  "skill_name": "myai-proprietary-content-verifier",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run the proprietary content verifier on the content queue. Queue dir: myai-proprietary-content-verifier-workspace/fixtures/scenario-1/content-queue/ Blog dir: myai-proprietary-content-verifier-workspace/fixtures/scenario-1/content-output/ Use the default threshold of 3.",
+      "expected_output": "The stub 'kubernetes-production-tips.md' should be rejected (score 1-2) because it heavily overlaps with the existing 'kubernetes-best-practices-2025.md' article — same audience, same topics (resource management, security, observability, deployment strategies), same keywords.",
+      "files": [
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-1/content-queue/kubernetes-production-tips.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-1/content-output/kubernetes-best-practices-2025.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-1/content-output/docker-containerization-guide.md"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Verify the content queue stubs against existing blog content. Queue: myai-proprietary-content-verifier-workspace/fixtures/scenario-2/content-queue/ Blog: myai-proprietary-content-verifier-workspace/fixtures/scenario-2/content-output/ Threshold: 3.",
+      "expected_output": "The stub 'bare-metal-gpu-ml-training.md' should be approved with a high score (4-5) because it covers bare-metal GPU infrastructure for ML — a topic not covered by existing articles on cloud cost optimization or Python async patterns.",
+      "files": [
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-2/content-queue/bare-metal-gpu-ml-training.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-2/content-output/cloud-cost-optimization.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-2/content-output/python-async-patterns.md"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Run the content verifier on the queue directory with two stubs. Queue: myai-proprietary-content-verifier-workspace/fixtures/scenario-3/content-queue/ Blog: myai-proprietary-content-verifier-workspace/fixtures/scenario-3/content-output/ Threshold: 3.",
+      "expected_output": "Two stubs evaluated: 'observability-sre-alerting.md' should score 3-4 (approved — distinct focus on alerting philosophy vs general monitoring guide), while 'prometheus-grafana-setup.md' should score 1-2 (rejected — heavily overlaps with existing monitoring-microservices article covering the same Prometheus/Grafana stack).",
+      "files": [
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-3/content-queue/observability-sre-alerting.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-3/content-queue/prometheus-grafana-setup.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-3/content-output/monitoring-microservices.md",
+        "myai-proprietary-content-verifier-workspace/fixtures/scenario-3/content-output/opentelemetry-instrumentation.md"
+      ]
+    }
+  ]
+}