[
  {
    "id": "source-library-ingestion-qa",
    "title": "Source Library Ingestion QA",
    "category": "Knowledge",
    "tags": [
      "Obsidian",
      "retrieval",
      "research",
      "metadata"
    ],
    "source": "Paul-created",
    "difficulty": "Intermediate",
    "cadence": "After each source capture",
    "verification": "Metadata complete, transcript/article state honest, useful takeaways present, and qmd retrieval verified or refreshed.",
    "useWhen": "A new article, video, X post, podcast, or image enters your knowledge base and should be findable later.",
    "summary": "Turn raw captures into retrieval-ready knowledge instead of a pile of orphaned links.",
    "steps": [
      "Check canonical URL, title, author, platform, date, source type, and status.",
      "Patch missing takeaways and best-practice sections from the transcript or article only.",
      "Update the source index and refresh retrieval.",
      "Stop when the note can be found by a distinctive query and has no avoidable TBD fields."
    ],
    "prompt": "After a new source note is added, make it retrieval-ready. Verify source metadata, transcript or article state, key takeaways, extracted best practices, and search retrieval. Patch only what is grounded in the source. Output the note path, status, and retrieval proof.",
    "featured": true
  },
  {
    "id": "claude-code-repo-readiness",
    "title": "Claude Code Repo Readiness",
    "category": "Engineering",
    "tags": [
      "Claude Code",
      "repo setup",
      "docs",
      "agent harness"
    ],
    "source": "Paul-created",
    "difficulty": "Beginner",
    "cadence": "Before major agent work",
    "verification": "Repo has agent instructions, documented commands, architecture notes, risk areas, and a docs/loops scaffold.",
    "useWhen": "You are about to let a coding agent do meaningful work in a repo and want fewer dumb mistakes.",
    "summary": "Make the repo legible to agents before asking them to do real work.",
    "steps": [
      "Inventory current README, AGENTS.md or CLAUDE.md, scripts, tests, and architecture docs.",
      "Add missing install, dev, test, lint, typecheck, build, and e2e commands.",
      "Document product goal, architecture, standards, protected areas, and review rules.",
      "Create docs/loops/ for state, progress, and done contracts."
    ],
    "prompt": "Prepare this repository for agentic coding work. Add or update repo instructions, command references, architecture overview, risk areas, PR/review standards, and a docs/loops scaffold. Verify commands where practical and return the patch with readiness evidence.",
    "featured": true
  },
  {
    "id": "project-docs-freshness",
    "title": "Project Docs Freshness",
    "category": "Engineering",
    "tags": [
      "docs",
      "maintenance",
      "APIs",
      "release hygiene"
    ],
    "source": "Paul-created",
    "difficulty": "Beginner",
    "cadence": "Nightly or after meaningful code changes",
    "verification": "Changed behavior, APIs, CLI commands, config, and workflows are reflected in docs. Docs checks pass.",
    "useWhen": "Code changed and the docs are probably now lying by omission.",
    "summary": "Keep documentation synced with what the product actually does.",
    "steps": [
      "Review code changes since the last pass.",
      "Find docs contradicted by changed behavior, config, commands, examples, or APIs.",
      "Patch the highest-risk stale docs first.",
      "Run docs build or link checks and produce a no-change report if clean."
    ],
    "prompt": "Review recent code changes and update stale, missing, or contradicted documentation. Cover public APIs, CLI commands, config behavior, user-facing workflows, and examples. Run docs verification and return the diff or a no-change report.",
    "featured": true
  },
  {
    "id": "test-logging-coverage",
    "title": "Test and Logging Coverage",
    "category": "Engineering",
    "tags": [
      "testing",
      "observability",
      "logging",
      "critical flows"
    ],
    "source": "Paul-created",
    "difficulty": "Intermediate",
    "cadence": "Weekly or before release",
    "verification": "Critical flows have useful tests and structured logs for representative success and failure paths.",
    "useWhen": "Important flows are hard to debug or verify, especially auth, payments, data mutation, external APIs, jobs, and error boundaries.",
    "summary": "Raise the floor for every future loop by improving the evidence system.",
    "steps": [
      "List critical flows and current test/log coverage.",
      "Choose the riskiest blind spot.",
      "Add the smallest useful test and structured log improvement.",
      "Verify logs do not expose secrets and tests prove the path."
    ],
    "prompt": "Review critical flows and improve tests plus structured logging until important paths have useful coverage. Prioritize auth, payments, data mutation, external calls, queue jobs, cron jobs, and error boundaries. Verify where practical and return coverage evidence.",
    "featured": true
  },
  {
    "id": "ci-optimization",
    "title": "CI Optimization",
    "category": "Engineering",
    "tags": [
      "CI",
      "performance",
      "testing",
      "bottlenecks"
    ],
    "source": "Paul-created",
    "difficulty": "Advanced",
    "cadence": "Monthly or when CI is painful",
    "verification": "CI p50/p95 improves against the same workflow without weakening tests or hiding failures.",
    "useWhen": "The team is waiting on CI long enough that it changes behavior.",
    "summary": "Attack one CI bottleneck at a time until the target is met or the bottleneck report is more valuable than another tweak.",
    "steps": [
      "Measure current job and step timing.",
      "Rank bottlenecks by cost and safety.",
      "Optimize one bottleneck with the smallest credible change.",
      "Rerun CI or a faithful local equivalent.",
      "Stop at the target or when no safe gain remains."
    ],
    "prompt": "Reduce CI p50/p95 duration for the selected workflow by the target amount without weakening tests. Measure first, optimize one bottleneck at a time, rerun verification, and finish with before/after timings plus remaining blockers.",
    "featured": true
  },
  {
    "id": "open-loop-stale-memory-cleanup",
    "title": "Open Loop and Stale Memory Cleanup",
    "category": "Knowledge",
    "tags": [
      "Obsidian",
      "memory",
      "open loops",
      "weekly review"
    ],
    "source": "Paul-created",
    "difficulty": "Beginner",
    "cadence": "Weekly",
    "verification": "No current open loop is contradicted by recent daily or project notes.",
    "useWhen": "Your personal operating system has accumulated stale promises, half-decisions, or outdated context.",
    "summary": "Reconcile what the system thinks is open against what actually happened.",
    "steps": [
      "Read recent daily, project, decision, and open-loop notes.",
      "Find open loops contradicted by newer evidence.",
      "Close, update, or flag each stale item with source evidence.",
      "Stop when no contradicted current loop remains."
    ],
    "prompt": "Sweep recent notes against the open-loop and memory records. Close or update anything stale, contradicted, or missing evidence. Do not invent completions. Return the patch and the unresolved list.",
    "featured": true
  },
  {
    "id": "social-source-to-insight",
    "title": "Social Source to Insight",
    "category": "Content",
    "tags": [
      "X",
      "YouTube",
      "content ideas",
      "approval gated"
    ],
    "source": "Paul-created",
    "difficulty": "Intermediate",
    "cadence": "After saving a high-signal source",
    "verification": "Source captured, takeaways extracted, draft angles written, and no public post is published without approval.",
    "useWhen": "A strong X or YouTube source should become reusable insight and possible social material.",
    "summary": "Convert high-signal sources into grounded ideas without auto-posting like a caffeinated intern.",
    "steps": [
      "Capture source metadata and transcript or text.",
      "Extract the useful mechanism, lesson, and examples.",
      "Draft several post angles in the account voice.",
      "Gate publishing and preserve source links."
    ],
    "prompt": "Turn the saved source into a reusable source note and draft social angles. Extract grounded takeaways, best practices, and hooks. Never post publicly without approval. Return the note path and gated drafts.",
    "featured": true
  },
  {
    "id": "fresh-clone-onboarding",
    "title": "Fresh Clone Onboarding",
    "category": "Engineering",
    "tags": [
      "README",
      "developer experience",
      "setup"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Before onboarding",
    "verification": "A clean machine reaches the documented ready state using only the README.",
    "useWhen": "You suspect setup instructions only work for people who already know the system.",
    "summary": "Prove the README works from zero, not tribal memory.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Fresh Clone Onboarding loop. Use it when You suspect setup instructions only work for people who already know the system. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when A clean machine reaches the documented ready state using only the README. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "production-error-sweep",
    "title": "Production Error Sweep",
    "category": "Operations",
    "tags": [
      "reliability",
      "logs",
      "bugs"
    ],
    "source": "Adapted pattern",
    "difficulty": "Advanced",
    "cadence": "Daily or after incident",
    "verification": "Actionable errors are fixed with reproduction or tests, or explicitly classified as noise.",
    "useWhen": "Production telemetry should become repairs, not vibes.",
    "summary": "Turn recurring production errors into verified patches.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Production Error Sweep loop. Use it when Production telemetry should become repairs, not vibes. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Actionable errors are fixed with reproduction or tests, or explicitly classified as noise. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "dependency-cve-burndown",
    "title": "Dependency CVE Burndown",
    "category": "Security",
    "tags": [
      "CVE",
      "dependencies",
      "security"
    ],
    "source": "Adapted pattern",
    "difficulty": "Advanced",
    "cadence": "After security scan",
    "verification": "No exploitable high or critical CVE remains without an explicit risk decision.",
    "useWhen": "Scanners are noisy and you need to know what is actually reachable.",
    "summary": "Rank vulnerabilities by real exposure, then fix the reachable ones first.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Dependency CVE Burndown loop. Use it when Scanners are noisy and you need to know what is actually reachable. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when No exploitable high or critical CVE remains without an explicit risk decision. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "test-flake-stabilizer",
    "title": "Test Flake Stabilizer",
    "category": "Engineering",
    "tags": [
      "testing",
      "flakes",
      "CI"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "When tests are inconsistent",
    "verification": "The repaired test and full suite pass for the required consecutive-run streak.",
    "useWhen": "CI fails differently across comparable runs.",
    "summary": "Find the real cause of flakes instead of wallpapering them with sleeps.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Test Flake Stabilizer loop. Use it when CI fails differently across comparable runs. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when The repaired test and full suite pass for the required consecutive-run streak. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "prepublish-source-check",
    "title": "Pre-Publish Source Check",
    "category": "Content",
    "tags": [
      "fact check",
      "publishing",
      "sources"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Before publishing factual work",
    "verification": "Every checkable claim is supported by a current source or visibly flagged for an editor.",
    "useWhen": "A factual draft is about to go public.",
    "summary": "Inventory the claims before the internet does it for you.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Pre-Publish Source Check loop. Use it when A factual draft is about to go public. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Every checkable claim is supported by a current source or visibly flagged for an editor. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "research-to-artifact",
    "title": "Research to Artifact",
    "category": "Knowledge",
    "tags": [
      "research",
      "decision memo",
      "synthesis"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Whenever research must support a decision",
    "verification": "The artifact meets acceptance criteria, traces important claims to sources, and states uncertainty plainly.",
    "useWhen": "Research should end in a decision-ready memo, not a heap of notes.",
    "summary": "Constrain research around the decision it needs to support.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Research to Artifact loop. Use it when Research should end in a decision-ready memo, not a heap of notes. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when The artifact meets acceptance criteria, traces important claims to sources, and states uncertainty plainly. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "browser-quality-streak",
    "title": "Browser Quality Streak",
    "category": "Evaluation",
    "tags": [
      "QA",
      "browser",
      "product"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Before release",
    "verification": "N realistic scenarios pass consecutively, and earlier failures have regression coverage.",
    "useWhen": "You need confidence that the product works in realistic flows.",
    "summary": "Run real scenarios until the streak proves the product is stable.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Browser Quality Streak loop. Use it when You need confidence that the product works in realistic flows. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when N realistic scenarios pass consecutively, and earlier failures have regression coverage. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "error-message-rewrite",
    "title": "Error Message Rewrite",
    "category": "Design",
    "tags": [
      "UX writing",
      "errors",
      "support"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "When users hit confusing errors",
    "verification": "Every in-scope user-visible error is accounted for, rewritten or blocked, and verified in a reachable state.",
    "useWhen": "Your product exposes raw provider errors, stack traces, or dead-end messages.",
    "summary": "Replace error sludge with clear recovery paths.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Error Message Rewrite loop. Use it when Your product exposes raw provider errors, stack traces, or dead-end messages. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Every in-scope user-visible error is accounted for, rewritten or blocked, and verified in a reachable state. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "accessibility-repair",
    "title": "Accessibility Repair",
    "category": "Design",
    "tags": [
      "accessibility",
      "WCAG",
      "keyboard"
    ],
    "source": "Adapted pattern",
    "difficulty": "Advanced",
    "cadence": "Before launch or when audits fail",
    "verification": "No confirmed accessibility blocker remains in the agreed pages, components, or tasks.",
    "useWhen": "A site or app needs a defined accessibility target and repeatable testing.",
    "summary": "Fix access barriers without silencing checks or weakening the standard.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Accessibility Repair loop. Use it when A site or app needs a defined accessibility target and repeatable testing. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when No confirmed accessibility blocker remains in the agreed pages, components, or tasks. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "cold-load-trim",
    "title": "Cold Load Trim",
    "category": "Engineering",
    "tags": [
      "performance",
      "frontend",
      "bundle size"
    ],
    "source": "Adapted pattern",
    "difficulty": "Advanced",
    "cadence": "When first visit feels heavy",
    "verification": "Initial screen downloads fewer bytes while screenshots and behavior remain unchanged.",
    "useWhen": "A web app ships too much before showing anything useful.",
    "summary": "Reduce first-load bytes without breaking the first impression.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Cold Load Trim loop. Use it when A web app ships too much before showing anything useful. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Initial screen downloads fewer bytes while screenshots and behavior remain unchanged. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "architecture-rubric-refactor",
    "title": "Architecture Rubric Refactor",
    "category": "Engineering",
    "tags": [
      "architecture",
      "refactor",
      "rubric"
    ],
    "source": "Adapted pattern",
    "difficulty": "Advanced",
    "cadence": "When architecture work has a defined scope",
    "verification": "Scoped module meets the written rubric, tests pass, and unresolved objections are explicit.",
    "useWhen": "A refactor matters, but “make architecture better” is too vague.",
    "summary": "Refactor against a written rubric, not taste fumes.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Architecture Rubric Refactor loop. Use it when A refactor matters, but “make architecture better” is too vague. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Scoped module meets the written rubric, tests pass, and unresolved objections are explicit. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "adversarial-pr-review",
    "title": "Adversarial PR Review",
    "category": "Evaluation",
    "tags": [
      "code review",
      "multi-agent",
      "PR"
    ],
    "source": "Adapted pattern",
    "difficulty": "Advanced",
    "cadence": "For meaningful PRs",
    "verification": "An independent critic approves the unchanged version or only accepted findings remain.",
    "useWhen": "One model built the change and should not grade its own homework.",
    "summary": "Separate builder and critic so “looks good to me” means something.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Adversarial PR Review loop. Use it when One model built the change and should not grade its own homework. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when An independent critic approves the unchanged version or only accepted findings remain. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "living-story",
    "title": "Living Story",
    "category": "Operations",
    "tags": [
      "project management",
      "handoff",
      "status"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Weekly or per project window",
    "verification": "Every prior thread is carried forward, closed with evidence, or flagged stale/needs-review.",
    "useWhen": "Work spans repos, notes, goals, and people.",
    "summary": "Maintain an evidence-backed story of what matters and what is unfinished.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Living Story loop. Use it when Work spans repos, notes, goals, and people. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Every prior thread is carried forward, closed with evidence, or flagged stale/needs-review. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "promise-to-proof",
    "title": "Promise to Proof",
    "category": "Growth",
    "tags": [
      "marketing",
      "docs",
      "product truth"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Before launch or campaign refresh",
    "verification": "Every high-risk customer promise is supported, narrowed, or awaiting an explicit decision.",
    "useWhen": "Marketing, docs, demos, and support answers may promise more than the product can prove.",
    "summary": "Make product claims survive contact with reality.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Promise to Proof loop. Use it when Marketing, docs, demos, and support answers may promise more than the product can prove. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Every high-risk customer promise is supported, narrowed, or awaiting an explicit decision. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "seo-geo-visibility",
    "title": "SEO/GEO Visibility",
    "category": "Growth",
    "tags": [
      "SEO",
      "GEO",
      "search"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Monthly",
    "verification": "Priority pages are indexable, answer-ready, internally linked, and no high-impact benchmark gaps remain.",
    "useWhen": "You need search engines and AI answer engines to understand the site.",
    "summary": "Map priority questions to answer-ready pages.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the SEO/GEO Visibility loop. Use it when You need search engines and AI answer engines to understand the site. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Priority pages are indexable, answer-ready, internally linked, and no high-impact benchmark gaps remain. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "one-post-a-week",
    "title": "One Post a Week Experiment",
    "category": "Content",
    "tags": [
      "social",
      "distribution",
      "experiments"
    ],
    "source": "Adapted pattern",
    "difficulty": "Beginner",
    "cadence": "Weekly for six weeks",
    "verification": "Winner is supported by comparable replies, saves, and questions, not just likes.",
    "useWhen": "You want a repeatable content format and need audience evidence.",
    "summary": "Change one variable per week and let useful audience behavior decide.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the One Post a Week Experiment loop. Use it when You want a repeatable content format and need audience evidence. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Winner is supported by comparable replies, saves, and questions, not just likes. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "talk-to-five-buyers",
    "title": "Talk to Five Buyers",
    "category": "Growth",
    "tags": [
      "copywriting",
      "customer research",
      "landing pages"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "Before major landing-page rewrite",
    "verification": "Proposed copy traces to repeated anonymized buyer objections across approved interviews.",
    "useWhen": "Landing-page copy is missing the concern that almost stopped buyers.",
    "summary": "Let buyer language rewrite the page where the objection appears.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Talk to Five Buyers loop. Use it when Landing-page copy is missing the concern that almost stopped buyers. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Proposed copy traces to repeated anonymized buyer objections across approved interviews. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "agent-handoff-continuity",
    "title": "Agent Handoff Continuity",
    "category": "Operations",
    "tags": [
      "handoff",
      "state",
      "agents"
    ],
    "source": "Original",
    "difficulty": "Intermediate",
    "cadence": "Before pausing or switching agents",
    "verification": "A new agent can state goal, current state, proof, blockers, and next action without reading the whole transcript.",
    "useWhen": "Long-running agent work crosses sessions, tools, repos, or humans.",
    "summary": "Prevent the next agent from starting with amnesia and bravado.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Agent Handoff Continuity loop. Use it when Long-running agent work crosses sessions, tools, repos, or humans. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when A new agent can state goal, current state, proof, blockers, and next action without reading the whole transcript. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "toolchain-health-check",
    "title": "Agent Toolchain Health Check",
    "category": "Operations",
    "tags": [
      "agents",
      "tools",
      "MCP"
    ],
    "source": "Original",
    "difficulty": "Beginner",
    "cadence": "Weekly or before a heavy agent run",
    "verification": "Critical tools authenticate, return sane output, and have a known fallback or blocker owner.",
    "useWhen": "Agent setup depends on CLIs, MCP servers, browsers, tokens, local models, and cron jobs.",
    "summary": "Check the harness before blaming the model.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Agent Toolchain Health Check loop. Use it when Agent setup depends on CLIs, MCP servers, browsers, tokens, local models, and cron jobs. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Critical tools authenticate, return sane output, and have a known fallback or blocker owner. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "api-contract-drift",
    "title": "API Contract Drift",
    "category": "Engineering",
    "tags": [
      "API",
      "contracts",
      "tests"
    ],
    "source": "Original",
    "difficulty": "Intermediate",
    "cadence": "After API changes or SDK releases",
    "verification": "Server behavior, client types, examples, and docs agree on request/response contracts.",
    "useWhen": "Backend, frontend, docs, and SDKs may describe different realities.",
    "summary": "Find where the API contract forked and bring every consumer back to one truth.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the API Contract Drift loop. Use it when Backend, frontend, docs, and SDKs may describe different realities. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Server behavior, client types, examples, and docs agree on request/response contracts. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "calendar-promise-proof",
    "title": "Calendar Promise Proof",
    "category": "Personal Ops",
    "tags": [
      "calendar",
      "commitments",
      "follow-up"
    ],
    "source": "Original",
    "difficulty": "Beginner",
    "cadence": "Daily or before week planning",
    "verification": "Every calendar-derived promise has an owner, due date, evidence, or explicit drop decision.",
    "useWhen": "Meetings create obligations that never make it into a task system.",
    "summary": "Mine the calendar for promises before they become social debt.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Calendar Promise Proof loop. Use it when Meetings create obligations that never make it into a task system. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Every calendar-derived promise has an owner, due date, evidence, or explicit drop decision. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "support-refund-followup",
    "title": "Support Refund Follow-Up",
    "category": "Personal Ops",
    "tags": [
      "support",
      "refunds",
      "follow-up"
    ],
    "source": "Adapted pattern",
    "difficulty": "Beginner",
    "cadence": "Until terminal state",
    "verification": "Refund is received, or no approved next step remains and a blocker is named.",
    "useWhen": "A refund or support claim will take multiple conversations and deadlines.",
    "summary": "Keep the case moving until the money lands or the wall is real.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Support Refund Follow-Up loop. Use it when A refund or support claim will take multiple conversations and deadlines. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when Refund is received, or no approved next step remains and a blocker is named. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "loop-hiring-manager",
    "title": "Loop Hiring Manager",
    "category": "Strategy",
    "tags": [
      "automation",
      "loop design",
      "ROI"
    ],
    "source": "Adapted pattern",
    "difficulty": "Intermediate",
    "cadence": "When a project accumulates recurring chores",
    "verification": "At most three candidates fill proven recurring gaps, with one recommended safe manual trial.",
    "useWhen": "You have lots of automation ideas and need to decide which loop deserves oxygen.",
    "summary": "Hire loops like employees: for recurring work with clear outcomes.",
    "steps": [
      "Define the exact scope, source of truth, and approval boundary.",
      "Inspect current state and rank the highest-risk gap.",
      "Make one small, reversible improvement.",
      "Run the stated verification and record evidence.",
      "Stop on success, budget, no progress, or approval required."
    ],
    "prompt": "Run the Loop Hiring Manager loop. Use it when You have lots of automation ideas and need to decide which loop deserves oxygen. Work in bounded iterations: inspect current state, choose the highest-risk gap, make one reversible improvement, verify it, and record evidence. Stop when At most three candidates fill proven recurring gaps, with one recommended safe manual trial. or when blocked, budget exhausted, or approval is required.",
    "featured": false
  },
  {
    "id": "acceptance-scenario-lockstep",
    "title": "Acceptance Scenario Lockstep",
    "category": "Engineering",
    "tags": [
      "acceptance criteria",
      "testing",
      "agent coding"
    ],
    "source": "Mia daily expansion",
    "difficulty": "Intermediate",
    "cadence": "Before and during ambiguous feature work",
    "verification": "The same scenarios written before implementation pass after the change, and any scope expansion is explicitly approved.",
    "useWhen": "A coding agent is about to implement a feature where success could be interpreted three different ways.",
    "summary": "Pin the target with executable scenarios before the agent starts changing code.",
    "steps": [
      "Translate the request into 3-7 user-visible scenarios, including at least one failure or edge case.",
      "Mark which scenarios are in scope, out of scope, or require approval before work starts.",
      "Turn the in-scope scenarios into tests, fixtures, or a checklist that can be rerun unchanged.",
      "Implement only the smallest change needed for those scenarios.",
      "Run the scenarios and stop if new behavior would broaden scope, affect billing/data/security, or require product judgment."
    ],
    "prompt": "Run the Acceptance Scenario Lockstep loop. Use it before ambiguous feature work. First convert the request into 3-7 user-visible scenarios with clear in-scope, out-of-scope, and approval-required labels. Make the in-scope scenarios executable as tests, fixtures, or a repeatable checklist before implementation. Implement only against those scenarios, rerun them unchanged, and stop for approval if the work broadens scope or touches billing, data, security, or product judgment.",
    "featured": false
  },
  {
    "id": "inbox-decision-triage",
    "title": "Inbox Decision Triage",
    "category": "Personal Ops",
    "tags": [
      "inbox",
      "triage",
      "drafts",
      "approval gated"
    ],
    "source": "Mia daily expansion",
    "difficulty": "Beginner",
    "cadence": "Daily or before deep work",
    "verification": "Every sampled message is archived, labeled, delegated, converted to a task, or left with a drafted reply; no external message is sent without approval.",
    "useWhen": "Email, DMs, or comments are creating invisible obligations and context switching.",
    "summary": "Turn inbox sludge into a small list of decisions, drafts, and explicit no-actions.",
    "steps": [
      "Search only the agreed inbox, channel, label, or time window.",
      "Classify each item as FYI, action, decision, relationship-sensitive, or safe archive.",
      "For each action item, capture owner, due date, source link, and next step.",
      "Draft replies or task notes in the user's voice, but keep them unsent unless approval is already explicit.",
      "Do not delete, unsubscribe, spend money, accept terms, or commit the user without approval; stop when only human-judgment items remain."
    ],
    "prompt": "Run the Inbox Decision Triage loop for the specified inbox, channel, label, or time window. Classify messages into FYI, action, decision, relationship-sensitive, and safe archive. For action items, capture owner, due date, source link, and next step. Draft replies or task notes in the user's voice, but do not send, delete, unsubscribe, spend money, accept terms, or make commitments without approval. Return the cleaned count, review queue, and drafted decisions.",
    "featured": false
  },
  {
    "id": "reference-oracle-implementation",
    "title": "Reference Oracle Implementation",
    "category": "Engineering",
    "tags": [
      "reference implementation",
      "testing",
      "parity",
      "agent coding"
    ],
    "source": "Adapted from public agentic-loop case studies",
    "difficulty": "Advanced",
    "cadence": "Before implementing tricky behavior with an external source of truth",
    "verification": "Generated outputs match the reference oracle across the agreed fixture set, with tolerances documented for legitimate differences.",
    "useWhen": "You need a coding agent to implement complex behavior that can be checked against a browser, official library, legacy system, API, compiler, or production output.",
    "summary": "Give the agent an oracle, not a pep talk.",
    "steps": [
      "Identify the most trustworthy reference output: browser engine, legacy implementation, official API, golden files, or production traces.",
      "Build a small command or fixture harness that compares the new implementation against that oracle.",
      "Start with the simplest passing cases, then add one behavior class at a time.",
      "After each change, run the parity harness and record failures with inputs, expected output, actual output, and tolerance rules.",
      "Stop when the scoped fixture set passes or the remaining differences require product or standards judgment."
    ],
    "prompt": "Run the Reference Oracle Implementation loop. First identify the reference oracle for the behavior: browser engine, legacy system, official library, API response, compiler output, or golden files. Build a repeatable parity harness before implementation. Add one behavior class at a time, compare expected vs actual output, document any tolerance rules, and stop when the scoped fixture set passes or remaining differences require human judgment.",
    "featured": false
  },
  {
    "id": "agent-instructions-after-action",
    "title": "Agent Instructions After-Action",
    "category": "Engineering",
    "tags": [
      "AGENTS.md",
      "CLAUDE.md",
      "lessons learned",
      "agent harness"
    ],
    "source": "Adapted from public agentic-loop case studies",
    "difficulty": "Beginner",
    "cadence": "After a successful or painful agent coding session",
    "verification": "Repo instructions contain only reusable, source-grounded lessons and the next similar task can start without rediscovering the same trap.",
    "useWhen": "A coding agent just learned something about the repo, test harness, edge case, command, or convention that future sessions should not relearn the expensive way.",
    "summary": "Turn one agent run into better future agent runs.",
    "steps": [
      "Review the session diff, failed commands, final passing commands, and any repeated confusion.",
      "Extract only reusable lessons: commands, conventions, tolerances, gotchas, protected paths, or fixture setup.",
      "Patch AGENTS.md, CLAUDE.md, repo docs, or a docs/loops note with concise operational guidance.",
      "Remove one-off transcript noise, blame, and implementation trivia.",
      "Verify the instruction file is readable and references real commands or paths."
    ],
    "prompt": "Run the Agent Instructions After-Action loop. Review the completed agent coding session, failed commands, final verification, and any repeated confusion. Extract reusable lessons only, then patch AGENTS.md, CLAUDE.md, or repo loop docs with concise commands, conventions, tolerances, protected paths, and gotchas. Do not paste chat transcripts or secrets. Verify the updated instruction file references real paths/commands and would help the next similar task.",
    "featured": false
  },
  {
    "id": "spec-to-task-shards",
    "title": "Spec to Task Shards",
    "category": "Engineering",
    "tags": [
      "spec-first",
      "planning",
      "task decomposition",
      "agent coding"
    ],
    "source": "Adapted from public agentic-coding handbook patterns",
    "difficulty": "Intermediate",
    "cadence": "Before multi-file feature work or migrations",
    "verification": "A written spec, non-goals, acceptance checks, and ordered task shards exist before implementation begins.",
    "useWhen": "The request is too large or vague for a single coding-agent prompt but not large enough to justify a full project plan ceremony.",
    "summary": "Make the agent split the work before it starts swinging a hammer.",
    "steps": [
      "Read the relevant code, docs, tickets, and constraints before proposing implementation.",
      "Write a short spec with goal, non-goals, affected files, risks, and acceptance checks.",
      "Break the spec into small task shards that can each be implemented and verified independently.",
      "Order shards by risk: scaffold, tests, smallest behavior, integrations, cleanup, docs.",
      "Stop and ask for approval if the spec exposes ambiguous product behavior, data migration risk, or security impact."
    ],
    "prompt": "Run the Spec to Task Shards loop. Inspect the relevant code and docs, then write a concise spec with goal, non-goals, affected files, risks, and acceptance checks. Split it into independently verifiable task shards ordered by risk. Do not implement until the spec and shard list are coherent. Stop for approval if product behavior, data migration, billing, or security scope is ambiguous.",
    "featured": false
  },
  {
    "id": "behavior-ladder-tdd",
    "title": "Behavior Ladder TDD",
    "category": "Engineering",
    "tags": [
      "TDD",
      "tests",
      "business rules",
      "agent coding"
    ],
    "source": "Adapted from public agentic-coding handbook patterns",
    "difficulty": "Intermediate",
    "cadence": "When implementing logic-heavy features",
    "verification": "Each behavior test fails before implementation, passes after the smallest change, and remains green through final refactor.",
    "useWhen": "A pricing rule, validator, parser, permissions rule, workflow state machine, or other logic-heavy feature could balloon if implemented all at once.",
    "summary": "Use tests as the prompt, one behavior at a time.",
    "steps": [
      "Convert business rules into an ordered checklist of behaviors, starting with the simplest valuable case.",
      "Write one failing test for the next behavior and confirm it fails for the expected reason.",
      "Implement only enough code to pass that test.",
      "Run the focused test and the nearest related test set before adding the next behavior.",
      "Refactor only after the ladder is green, and rerun the full relevant suite."
    ],
    "prompt": "Run the Behavior Ladder TDD loop. Convert the business rules into an ordered checklist of small behaviors. For each step, write one failing test first, confirm the expected failure, implement only enough code to pass, then run the focused and related tests. Do not add later rules early. Refactor only after the behavior ladder is green, and rerun the full relevant suite before reporting evidence.",
    "featured": false
  },
  {
    "id": "trace-first-debugging",
    "title": "Trace-First Debugging",
    "category": "Engineering",
    "tags": [
      "debugging",
      "logs",
      "reproduction",
      "root cause"
    ],
    "source": "Adapted from public agentic-coding handbook patterns",
    "difficulty": "Intermediate",
    "cadence": "When an agent is tempted to patch a bug from a hunch",
    "verification": "The bug is reproduced, the root cause is evidenced by traces or tests, and the fix includes a regression check.",
    "useWhen": "A failure has logs, screenshots, stack traces, recent commits, or user reports, but the cause is not obvious yet.",
    "summary": "Make the agent earn the fix before touching code.",
    "steps": [
      "Collect the symptom, expected behavior, recent changes, logs, stack traces, screenshots, and environment details.",
      "List plausible causes and the smallest diagnostic for each before modifying files.",
      "Reproduce the bug or create a failing regression test/check that captures it.",
      "Patch the smallest proven cause and remove temporary debug noise unless it should become structured logging.",
      "Verify the original reproduction fails before and passes after, then run nearby tests."
    ],
    "prompt": "Run the Trace-First Debugging loop. Do not patch from vibes. Gather symptom, expected behavior, recent changes, logs, traces, screenshots, and environment. List likely causes with diagnostics before editing. Reproduce the bug or create a failing regression check, patch the smallest proven cause, remove temporary debug noise, and verify the original reproduction plus nearby tests.",
    "featured": false
  },
  {
    "id": "visual-feedback-repair",
    "title": "Visual Feedback Repair",
    "category": "Design",
    "tags": [
      "frontend",
      "screenshots",
      "browser",
      "visual QA"
    ],
    "source": "Adapted from public agentic-coding handbook patterns",
    "difficulty": "Beginner",
    "cadence": "After AI-generated UI changes or visual bug reports",
    "verification": "Before/after screenshots, console state, and responsive checks show the visual issue is fixed without breaking adjacent states.",
    "useWhen": "The frontend technically works but looks wrong, drifts from design intent, or breaks at specific viewport sizes.",
    "summary": "Show the agent the page, not just the code.",
    "steps": [
      "Capture the failing screen, viewport, interaction state, expected design intent, and any console/network errors.",
      "Ask the agent to identify likely causes from screenshot, DOM, CSS, and component structure before editing.",
      "Patch the smallest layout, spacing, color, typography, or state-handling issue.",
      "Recheck the same viewport plus at least one adjacent viewport or interaction state.",
      "Stop when the issue is fixed with visual evidence or when the remaining judgment is taste/design approval."
    ],
    "prompt": "Run the Visual Feedback Repair loop. Capture the failing screenshot, viewport, interaction state, design expectation, and browser console/network state. Analyze likely causes from screenshot, DOM, CSS, and component structure before editing. Make the smallest frontend fix, then verify with before/after screenshots, the same viewport, one adjacent viewport, and relevant interaction states. Stop for human design judgment when the remaining issue is taste rather than correctness.",
    "featured": false
  },
  {
    "id": "memory-bank-continuity",
    "title": "Memory Bank Continuity",
    "category": "Knowledge",
    "tags": [
      "memory bank",
      "project context",
      "docs",
      "agent continuity"
    ],
    "source": "Adapted from public agentic-coding handbook patterns",
    "difficulty": "Beginner",
    "cadence": "At the start and end of multi-session agent work",
    "verification": "Project brief, active context, decisions, tech constraints, and progress are current enough for a fresh agent to continue safely.",
    "useWhen": "Agent work spans multiple sessions, contributors, or tools and context keeps getting rebuilt from scratch.",
    "summary": "Give stateless agents a project spine.",
    "steps": [
      "At session start, read the project brief, active context, tech constraints, system patterns, and progress files.",
      "During work, record durable decisions, current blockers, changed commands, and important path references.",
      "At session end, update active context and progress with what changed, what passed, what failed, and what comes next.",
      "Do not store secrets, raw transcripts, or giant code dumps in memory files.",
      "Verify a fresh-agent handoff can state goal, current state, commands, blockers, and next action."
    ],
    "prompt": "Run the Memory Bank Continuity loop. Read the repo's project brief, active context, tech constraints, system patterns, and progress files before work. During and after the session, update durable decisions, blockers, changed commands, important paths, verification evidence, and next action. Do not store secrets, raw transcripts, or giant code dumps. Verify the handoff lets a fresh agent continue without rereading the whole chat.",
    "featured": false
  },
  {
    "id": "sandboxed-yolo-probe",
    "title": "Sandboxed YOLO Probe",
    "category": "Security",
    "tags": [
      "sandbox",
      "permissions",
      "YOLO mode",
      "safe agents"
    ],
    "source": "Adapted from public agentic-loop safety guidance",
    "difficulty": "Advanced",
    "cadence": "Before allowing autonomous shell-heavy agent runs",
    "verification": "The agent can run needed commands inside the sandbox, cannot reach forbidden files/secrets, and produces a replayable diff or report before host-side changes.",
    "useWhen": "You want a coding agent to iterate freely, but the command surface, repo contents, or prompt-injection risk makes direct host execution unsafe.",
    "summary": "Let the agent run wild somewhere boring.",
    "steps": [
      "Create a disposable container, codespace, VM, or worktree with only the files and secrets required for the task.",
      "Disable or restrict network access unless specific hosts are required.",
      "Run the agent's exploratory loop inside the sandbox with clear budget, scope, and forbidden actions.",
      "Export only the patch, metrics, logs, and reproduction steps needed for review.",
      "Apply to the real repo only after human or policy review of the diff and verification evidence."
    ],
    "prompt": "Run the Sandboxed YOLO Probe loop. Create a disposable sandbox with only required files and no unnecessary secrets. Restrict network access unless named hosts are required. Let the agent iterate inside that boundary with explicit budget, scope, and forbidden actions. Export a patch, metrics, logs, and reproduction steps. Do not apply host-side changes until the diff and verification evidence have been reviewed.",
    "featured": false
  },
  {
    "id": "parallel-agent-worktree-sweep",
    "title": "Parallel Agent Worktree Sweep",
    "category": "Engineering",
    "tags": [
      "parallel agents",
      "worktrees",
      "orchestration",
      "code review"
    ],
    "source": "Adapted from public Claude Code and agent-orchestration discussions",
    "difficulty": "Advanced",
    "cadence": "When several independent repo improvements can run at once",
    "verification": "Each agent branch has isolated scope, passing checks, a summary, and no conflicting files before integration review.",
    "useWhen": "You have multiple independent coding tasks and the human bottleneck is orchestration, not implementation speed.",
    "summary": "Run more agents, but keep their blast radiuses separate.",
    "steps": [
      "Split the work into independent tasks with non-overlapping files or explicit conflict boundaries.",
      "Create separate branches or worktrees and give each agent its own goal, commands, budget, and done contract.",
      "Require each agent to return diff summary, verification output, known risks, and next-step recommendation.",
      "Review branches in priority order, checking for overlapping files, duplicated abstractions, and integration risks.",
      "Merge only the branches with passing evidence and clear product value; park or discard the rest."
    ],
    "prompt": "Run the Parallel Agent Worktree Sweep loop. Split the repo work into independent tasks with non-overlapping scope, then create one branch or worktree per agent. Give each agent a goal, commands, budget, and done contract. Require diff summary, verification output, risks, and recommendation. Review branches for conflicts, duplicated abstractions, and integration risk before merging anything. Park or discard weak branches instead of forcing a messy merge.",
    "featured": false
  },
  {
    "id": "agent-merge-queue-review",
    "title": "Agent Merge Queue Review",
    "category": "Evaluation",
    "tags": [
      "PR review",
      "merge queue",
      "agent branches",
      "integration"
    ],
    "source": "Adapted from public Claude Code and agent-orchestration discussions",
    "difficulty": "Advanced",
    "cadence": "After multiple agent-generated PRs or branches accumulate",
    "verification": "Only branches with passing checks, clear intent, non-conflicting scope, and human-readable evidence are merged or promoted.",
    "useWhen": "Agent throughput created more branches than a human can safely review from memory.",
    "summary": "Separate useful agent output from merge-shaped confetti.",
    "steps": [
      "List all candidate PRs/branches with goal, touched files, test evidence, risk, and age.",
      "Group related branches and identify conflicts, duplicated work, and dependency ordering.",
      "Run targeted checks for the highest-value candidates first.",
      "Approve, request changes, merge, park, or close each candidate with a reason.",
      "Update repo instructions or loop docs with any recurring failure pattern seen across branches."
    ],
    "prompt": "Run the Agent Merge Queue Review loop. Inventory candidate PRs or branches with goal, touched files, verification evidence, risk, and age. Group related work, find conflicts and duplicated abstractions, run targeted checks for the highest-value candidates, and decide approve/request-changes/merge/park/close with reasons. Capture recurring agent failure patterns in repo instructions or loop docs.",
    "featured": false
  },
  {
    "id": "completion-promise-loop",
    "title": "Completion Promise Loop",
    "category": "Engineering",
    "tags": [
      "coding agents",
      "acceptance criteria",
      "verification",
      "handoff"
    ],
    "source": "Adapted from public agentic-loop discussions about agents quitting halfway through tasks",
    "difficulty": "Intermediate",
    "cadence": "For scoped implementation tasks where half-finished output is the main risk",
    "verification": "Every acceptance criterion is checked with tests, browser evidence, logs, screenshots, or a clear blocker report before the agent stops.",
    "useWhen": "A coding agent keeps declaring work done after the easy part, or a feature has multiple acceptance criteria that must be proven before handoff.",
    "summary": "Make the agent promise completion against explicit evidence, not vibes and a cheerful summary.",
    "steps": [
      "Write the acceptance criteria as a checklist before implementation starts.",
      "Have the agent restate the done contract, allowed files, verification commands, and stop conditions.",
      "Let the agent implement one slice, then immediately run the nearest proof: tests, browser check, lint, logs, screenshot, or fixture comparison.",
      "After each failure or uncovered criterion, repair and re-run the relevant proof instead of moving on to unrelated cleanup.",
      "Stop only when every criterion is proven, the budget is exhausted, or a blocker is returned with exact evidence and the next human decision."
    ],
    "prompt": "Run the Completion Promise Loop. Restate the acceptance criteria, allowed scope, verification commands, and stop conditions before editing. Implement in small slices. After each meaningful change, run the closest proof for the relevant criterion: tests, browser check, lint, logs, screenshot, or fixture comparison. Keep a checklist of criteria and mark each as proven, failed, or blocked with evidence. Continue until every criterion is proven, the budget is exhausted, or a blocker requires human judgment. Return changed files, verification output, remaining risks, and any criteria not proven.",
    "featured": false
  }
]