Pipeline Idea Generator

Purpose

A work-idea pipeline only processes what it already knows about. This skill is the mechanism by which it learns about new things: when the queue drops below 5 actionable items, this skill runs, queries whatever institutional-knowledge sources you have available, scores each candidate, deduplicates against existing work, and appends new items to the queue.

This piece is only as good as the institutional memory behind it. On a fresh install with no oracle, no error history, and no past sessions to mine, there's genuinely little for it to find — that's not a bug to route around, it's the truth about what it's drawing on. Say so plainly rather than inventing plausible-sounding filler. As you accumulate real history (see the sources below), this fills in on its own.

Pipeline tracker location: run alignment-harness records pipeline to get (and create, if needed) the local folder for this. The default file inside it is PIPELINE-TRACKER.md. If you already keep your own equivalent tracker somewhere else in your project, use that path instead — the format below (a markdown table with an ID, score, title, and status per row) is what matters, not the exact location.

---

When to Run

Trigger automatically or on demand when:

1. The tracker's ## Proposed / Queue table has fewer than 5 queued items
2. Explicitly invoked: "generate pipeline ideas", "feed the pipeline", "refill pipeline"
3. After a major batch of pipeline items reaches done status

Check queue depth first:

# Count queued items in your pipeline tracker
grep -c '| queued' "$(alignment-harness records pipeline)/PIPELINE-TRACKER.md" 2>/dev/null

If count >= 5, print: "Queue has {N} queued items — no refill needed." and stop.

If the tracker doesn't exist yet or the count is 0, say so plainly before running the sources below: "Your pipeline queue is empty (or doesn't exist yet). I'm going to look across whatever institutional knowledge you've got set up — an oracle if you have one, past session history, anything I can find — and see what surfaces. On a fresh install with little history, don't expect much yet; the more you've used the harness, the better this gets."

---

Step 1: Gather Candidates from All Sources

Run these source queries. Do them in parallel where possible. Collect raw candidates — do not score yet. Each source is independent: if one isn't set up, skip it, say so in the summary (Step 6), and keep going with the rest. Never let a missing source block the others, and never invent a candidate to make up for one that returned nothing.

Source A — Person-Prediction Oracle (optional)

If you have an oracle set up (see /oracle-pre-query and /alignment-harness:harness-setup), ask it what hasn't been proposed yet:

Based on everything you know about the person's priorities, patterns, and corrections,
what are the 3 highest-leverage things that haven't been proposed or investigated yet?
Focus on unaddressed pain points, gaps, and quality issues.

Run it through /oracle-pre-query first, exactly like any other oracle call — this question is squarely product-ux/business-strategy territory and still benefits from the domain framing.

If no oracle is configured: skip this source and note "Source A (oracle): not set up, skipped" in the summary. Do not guess at what an oracle "would probably say."

Source B — Leverage Predictor

Invoke /leverage-predictor to generate new proposals based on current codebase state. Ask the skill to produce candidates (not yet submit them) with scores >= 60.

The /leverage-predictor skill workflow produces scored candidates with user impact (40%), business value (30%), effort efficiency (20%), risk reduction (10%) breakdowns. Capture those candidates here.

Source C — Predict Next Action

Invoke /predict-next-action for session context signal. The output will be a UX possibility + highest-leverage next move. Treat this as one candidate if it is not already in the pipeline.

Source D — Institutional memory: recent errors, complaints, system patterns

If you have an institutional-memory search tool (like agent_find / agent-swarm) set up, query it:

# Example, if you have such a tool installed:
node <path-to-your-memory-search-cli> \
  "recent error logs user complaints system failures unaddressed" --limit 8

If you don't have one, fall back to what's actually on the machine:

# Recent errors surfaced in your own logs, if you have any
grep -riE 'error|exception|fail' path/to/your/app/logs/*.log 2>/dev/null | tail -50

# The harness's own telemetry, if you're using it
tail -100 .claude/logs/agent-telemetry.jsonl 2>/dev/null | grep -i 'error\|fail'

# Corrections and complaints in your own past Claude Code sessions
grep -l -i "that's wrong\|that's not right\|fix this\|broken" ~/.claude/projects/*/*.jsonl 2>/dev/null

Extract up to 3 candidates from distinct error patterns not already tracked in your pipeline tracker. If none of these turn anything up, say so — "Source D: no error signal found" — rather than fabricating one.

Source E — Past-Session Incomplete Items

If you keep session compaction records (via /compact-agentic-session) in a service or API of your own, query it for unfinished items from prior sessions.

If you don't, use the local records folder and your own transcripts instead:

# Local compaction records, if you've been writing them
grep -rl -i "incomplete\|not done\|todo\|still needs" "$(alignment-harness records compactions)" 2>/dev/null

# Past Claude Code sessions that mention leftover work
grep -l -i "incomplete\|didn't finish\|left off\|still need to" ~/.claude/projects/*/*.jsonl 2>/dev/null

Extract up to 3 candidates from confirmed incomplete items that represent real unfinished work — read enough of the surrounding context to confirm it's a real gap, not a stray word match.

---

Step 2: Deduplicate Against Existing Pipeline

Before scoring, eliminate any candidate that is already in the pipeline.

# Read the tracker to check existing titles and any run/tracking directories
cat "$(alignment-harness records pipeline)/PIPELINE-TRACKER.md" 2>/dev/null

Dedup rule: If a candidate's core claim substantially overlaps with any existing queued, in-progress, or done item, it is a duplicate. Drop it. When in doubt — if 60%+ of the core finding is already tracked — drop it.

---

Step 3: Score Each Remaining Candidate

Score each candidate the same way /governer would score the same finding, so this piece's numbers and every other gate's numbers come from one consistent method rather than two formulas that happen to agree today. Use the harness's own scorer:

alignment-harness score --task "{candidate title/claim}" --ac {N} --hp {N} --ew {N} --category {category if it fits payment/auth/coaching/onboarding}

Where --ac (affected count), --hp (harm potential), and --ew (effort/work) are your best-faith estimates from the factors below — see /governer for exactly what each factor means and how the category floors work:

Factor	Weight	Questions
User Impact	40%	How many users affected? How visibly?
Business Value	30%	Revenue, retention, conversion delta?
Effort Efficiency	20%	Expected impact per hour of work?
Risk Reduction	10%	Prevents future outages or silent failures?

If alignment-harness score isn't available for some reason, derive the score by hand from the four-factor table above rather than skipping scoring — but flag in the summary that it was hand-derived, not from the canonical scorer.

Minimum threshold: Only carry forward candidates scoring >= 50. Drop anything below.

Print a quick score table:

| Candidate | Source | Score | Category floor applied? | Final Score |
|-----------|--------|-------|--------------------------|--------------|
| {title}   | A      | 72    | no                       | 72           |

---

Step 4: Format as Queue-Ready Items

For each surviving candidate, produce a queue-ready entry in the same format as existing rows in your tracker:

| {prefix}-{next} | {score} | {Short descriptive title} | queued | — | — | Source: {A|B|C|D|E} — {1 sentence core claim to verify} |

Numbering: Read the highest existing item number from the tracker and increment. Pick any short prefix you like (one working tracker uses LP-, for "leverage proposal" — pick your own or keep that convention, it's arbitrary).

Title format: 2-5 words, noun phrase, describes the capability or gap — not the finding. For example: "Retry Failed Webhook Sends" or "Cache Cold-Start Fix" — short enough to scan in a table, specific enough to know what it's about without opening it.

Notes field must include:

• Source: {letter} — which source surfaced it
• One sentence stating the core claim that a later verification step will confirm or disprove
• Initial score

---

Step 5: Append to the Pipeline Tracker

Read the tracker, find the ## Proposed / Queue table (or create the file with that heading if it doesn't exist yet), and append the new rows before the blank line that ends the table. Do not reorder existing entries. Do not change any existing row's status.

Update a "Last updated" line at the bottom with today's date and note: "pipeline-idea-generator — {N} new items added."

---

Step 6: Print Summary

After writing, print:

## Pipeline Refilled

Sources queried: A (oracle) — {ran | not set up, skipped}
                 B (leverage-predictor)
                 C (predict-next-action)
                 D (error/complaint signal) — {institutional-memory tool | local log fallback | none found}
                 E (incomplete items) — {compaction service | local fallback | none found}
Raw candidates: {total}
After dedup: {N}
After score filter (>=50): {N}
New items added to queue: {N}

New items:
  {prefix}-{N}: {title} — Score: {score} — Source: {A|B|C|D|E}

Queue depth now: {new total queued count}

If institutional memory is thin (little or no history in D/E, no oracle for A), say that explicitly here too — "these suggestions are thin because there isn't much history yet" — rather than presenting a short list as a confidently complete scan.

---

Anti-Patterns

• NEVER add an item already tracked (any status) — check both table rows and any run/tracking directories you keep
• NEVER add candidates scoring < 50 — they waste queue capacity
• NEVER fabricate scores — derive from the 4-factor formula or the real /governer-style scorer
• NEVER skip the dedup step — the pipeline tracker is the single source of truth
• NEVER add items from Source A alone without checking whether Source D corroborates them — an oracle's prediction needs some independent signal to be credible, not just its own confidence
• NEVER modify existing tracker rows — only append new ones
• NEVER invent a plausible-sounding candidate because a source came back empty — say the source came back empty instead

---

Related Skills

• /leverage-predictor — generates scored proposals
• /predict-next-action — session-context next move prediction
• /oracle-pre-query — required framing before any oracle call in Source A
• /governer — the scoring methodology this piece reuses
• /next-priority-tasks — aggregated ranked task view
• /how-to-submit-and-track-proposals — proposal submission after pipeline processing, if you have that skill