# Lisa Project Ideation > Generate practical, verifiable product ideas for the current host project FROM EVIDENCE-DERIVED PERSONAS, then turn the selected build-ready ideas into real PRDs via lisa-research. First derives the personas the project actually serves by mining its docs, code, data model, and releases (never invented — each persona cites its evidence), then ideates per persona. Every build-ready idea must pass a practicality gate (an obtainable data/source path) and an empirical verification gate (a user-observable outcome the agent can verify). Selected ideas are handed to lisa-research, which creates each PRD in the configured source (Notion / Confluence / GitHub / Linear) — in the draft state by default, or prd-ready (auto-picked-up by lisa-intake) when prd_ready=true. Defaults to creating one PRD (the top-ranked idea); max_prds widens the batch. Invoke for 'generate feature ideas for this project', 'what should we build next for ?', 'looking at , what should we add here?'. - Skill: `codyswanngt/lisa-project-ideation` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add codyswanngt/lisa-project-ideation` - Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-project-ideation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: codyswanngt (https://skillmd.com/u/codyswanngt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/codyswanngt/lisa-project-ideation --- # Project Ideation Generate persona-grounded, verifiable ideas for the host project in `$ARGUMENTS` (or the current working directory), then create PRDs for the selected build-ready ideas via `lisa-research`. The value of this skill is **grounding + filtering**, not brainstorm volume. Ideas come from personas the project demonstrably serves, and an idea you cannot ground in obtainable data and cannot verify yourself is noise — demote it honestly. ## Parameters - **`target`** (first positional, optional) — a target project path, or an external product/site to draw inspiration from. Defaults to the current working directory. - **`prd_ready=true|false`** (default **false**) — the PRD-lifecycle state for the PRDs this run creates. `false` → created in the source's **draft** state for human review. `true` → created **prd-ready** so the PRD side of `lisa-intake` auto-claims them. Passed straight through to `lisa-research` (which maps it to `lisa-prd-source-write`'s `initial_role`) only after the PRD queue pressure gate allows auto-ready writes. - **`max_prds=|all`** (default **1**) — how many build-ready ideas become PRDs this run. Default creates **one** PRD (the single top-ranked idea), because `lisa-research` is a heavy full flow. `max_prds=3` creates the top three; `max_prds=all` creates one per build-ready idea. Discovery Spikes and Rejected ideas are never turned into PRDs regardless of `max_prds`. - **`fixture=`** (optional, verification-only) — a deterministic host-project fixture used for idempotency verification. When present, read the fixture before ranking and honor its declared single persona, single idea, existing-fit anchor, and expected dedupe marker. Do not use this parameter for normal ideation runs. ## When to use - "generate feature ideas for this project" / "what should this app do next?" - "what should we build next for ?" - "looking at , what should we add here?" - "suggest practical improvements we can verify ourselves" This skill **does** create PRDs (via `lisa-research`) for the selected ideas. It does **not** create tracker tickets (that is `lisa-plan`) and does **not** change code (that is `lisa-implement`). ## Two gates every build-ready idea must pass An idea may only become a **Practical Idea** (and thus a PRD candidate) if it passes BOTH gates. Otherwise demote it. 1. **Practicality gate.** The project can plausibly implement the idea from sources that actually exist: existing code, a data model, a route/command/UI surface, a public or integrated API, a scrapeable public page, an existing user input, a local database, or documented integrations. Name the specific source and how the data is obtained. "We could probably get the data somehow" fails. 2. **Empirical verification gate.** You can personally confirm the resulting behavior by using the software (running the CLI, hitting the API, loading the page, querying the DB, inspecting an artifact) and capture a concrete evidence artifact. "Tests could be written later" does NOT satisfy this gate — quality gates are prerequisites, never proof an idea works. Failing the practicality gate → **Rejected / Not Practical Yet** (or **Discovery Spike** if a bounded probe could make it practical), naming the missing data/source/access. Failing only the verification gate → **Discovery Spike** (define the missing proof), never a build-ready recommendation. ## Step 1 — Establish host-project context (always first) Never propose ideas before you understand what exists. Inspect the host project and record: - **Project type and package manager** — manifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, …) and any `.lisa.config.json`. - **Docs and specs** — `README`, `docs/`, `wiki/`, architecture notes, ADRs, marketing/landing copy. - **Current product surfaces or commands** — routes, screens, CLI subcommands, API endpoints, scheduled jobs, generated artifacts. - **Data model and existing user inputs** — schemas, migrations, forms, config the user supplies. - **Available data sources and ingestion/scraping paths** — integrated APIs, public datasets, scrapeable pages, local databases, event streams. - **Existing verification tooling** — how a human currently observes the software works. Use Lisa's existing methodology rather than inventing a parallel flow. Route each evidence source through the matching established practice before any idea is promoted to **Practical Ideas**: - **Host-code inspection** uses `/lisa:codebase-research` concepts: trace data flow from entry point to output, identify modification points, map dependencies, and find reusable code or patterns. - **Public, no-login comparison** uses web/browser research when those tools are available: inspect the public surface, preserve source URLs, and separate observed behavior from inference. - **UI-facing recommendations** use `/lisa:product-walkthrough` methodology first: inspect the current product surface, note existing-component reuse candidates, capture coverage smells or behavioral surprises, and only then list a UI idea as build-ready. ## Step 2 — Derive the personas (evidence-gated, never invented) Ideation is **persona-driven**, and the personas must be gleaned from the project itself — not assumed. Mine the Step 1 evidence for who the project actually serves: - **Docs / README / release notes / CHANGELOG** — stated audiences, "for " framing, who each shipped feature was for. - **Code** — auth roles / RBAC / permission checks, account-type or user-type enums, route guards, feature flags scoped to a cohort, role-specific UI branches. - **Data model** — user / role / tenant / org tables, profile fields, subscription tiers. - **Tests & product walkthrough** — the real user journeys exercised. - **External inspiration** (Step 3, if used) — comparable products' user segments, as inspiration only. Anti-fabrication rule (mechanical): **no evidence citation → no persona.** Generic roles ("admin", "analyst", "end user", "power user") are **banned unless the project has specific evidence for them**. Each persona requires at least **two grounded signals** from different source classes where available; if only one strong signal exists, emit a single **low-confidence "Primary documented user"** persona named as such — never fabricate a full set from thin evidence. Cap the set at **3–6 personas** (merge adjacent personas by goal/workflow; more than six is taxonomy noise). Each persona records: - `name` — concrete and project-specific. - `goals` — what this persona is trying to accomplish. - `pains` — current friction for this persona, grounded in observed behavior/gaps. - `evidence` — the specific files / doc sections / tables / releases that justify the persona. - `confidence` — high | medium | low, with the reason. Always emit a **Personas Derived From Evidence** section, even when no PRDs are created. Spikes and rejected ideas are still tagged with the persona they would serve (or `cross-persona`). ## Step 3 — Optional external / public-source inspection Only when the user references an external product, website, public dataset, or competitor: - Inspect **public, no-login** surfaces only. Preserve every **source URL** so informed ideas cite it. The external source is **inspiration, not a domain you bake in** — keep the workflow reusable. - If the runtime has no browser/web capability, mark that source **unavailable** and proceed with host-project-only ideas (document the fallback rather than fabricating findings). ## Step 4 — Ideate per persona, then filter through the gates For each derived persona, brainstorm ideas that serve that persona's goals/pains, **tag each idea with the persona(s) it serves**, then run every idea through BOTH gates. For each surviving idea, build a **feasibility card**: - **Persona(s) served** — which derived persona(s), and why this matters to them. - **Existing fit** — the current route / API / CLI / model / doc / surface it builds on (this is also the idea's stable "existing-fit anchor" used in the dedupe key). - **Data/source required** + **how it is obtained** — the concrete accessible path. - **Known source limitations** — rate limits, robots/ToS, staleness, missing fields. - **Smallest practical slice** — the minimal useful version. - **Empirical verification steps** — what you (the agent) will do against the running software. - **Evidence artifact** — the screenshot, curl/CLI output, DB row, or generated file the verifier captures. - **Confidence** — high | medium | low, with the reason. ## Step 5 — Rank and select the PRD creation set Rank Practical Ideas by **persona value, feasibility, verification clarity, and project fit**. Then select the creation set by `max_prds` (default **1** → the single top-ranked idea; `` → top n; `all` → every Practical Idea). Spikes and Rejected ideas are reported but never selected. ## Step 5.5 — Block auto-ready writes when the PRD queue has pressure This step runs **only** when `prd_ready=true`. A draft run (`prd_ready=false`) skips this gate and continues to Step 6, because draft PRDs do not create immediate PRD-intake pickup pressure. Before invoking `lisa-research` for any selected idea, inspect the configured PRD source queue with the same PRD reader contract used by `/lisa:queue-status` and evaluate it with `evaluatePrdQueuePressure` from `plugins/lisa/scripts/queue-status-prd-readers.mjs` (source: `plugins/src/base/scripts/queue-status-prd-readers.mjs`). Resolve the queue from `.lisa.config.json` the same way `lisa-intake` resolves the PRD side, and pass the matching queue argument in the blocked outcome (for example, `github intake_mode=prd`). Queue pressure is any unresolved PRD lifecycle work that would make another auto-ready PRD compete with existing intake work. Treat at least these roles as pressure when the helper reports them: `prd-ready`, `prd-in-review`, `prd-blocked`, unresolved `prd-ticketed`, and source-reader failures or misconfiguration snapshots. `prd-shipped` / `prd-verified` terminal history is not pressure unless the reader helper explicitly reports it as unresolved. If the helper returns `allowed: false`, stop before any `lisa-research`, `lisa-prd-source-write`, or vendor PRD writer invocation. Emit **PRDs Created** as a blocked outcome, not as an empty success or a silent idle run. The blocked outcome must include: - `source` and `tracker` from `.lisa.config.json`; - the decisive PRD lifecycle `role`; - the blocking PRD item `ref` and `url`, when the snapshot supplies them; - the smallest next action, preferring the helper's `nextStep` and otherwise using `/lisa:intake `; - a clear statement that no research or PRD source write was invoked. Use this output shape so recurring automations can surface a useful next step without digging through debug logs: ```text ## PRDs Created Blocked: PRD queue pressure prevents auto-ready creation. - source: - tracker: - role: - item: - next action: > - write invoked: no ``` If the helper returns `allowed: true`, continue to Step 6 normally and keep the existing draft/ready creation behavior unchanged. ## Step 6 — Create a PRD per selected idea (via lisa-research) For each idea in the creation set, invoke `/lisa:research` with: - the feasibility card and persona evidence as the problem statement (so the PRD inherits the grounding and the empirical verification plan), - `prd_ready` (this run's flag — `lisa-research` maps it to draft vs prd-ready), - a stable **dedupe marker** (see below) so a re-run references the existing PRD instead of creating a duplicate, - a structured `ideation_ledger_payload` handoff containing the selected marker, automation id and memory path when available, persona names, persona evidence references, rejected overlap candidates, repo identity, `prd_ready`, selected idea title/key, and the expected empirical verification artifact. This payload is the only ideation-run metadata channel between `project-ideation`, `research`, `prd-source-write`, and the vendor writer; keep GitHub-specific rendering out of this skill. `lisa-research` synthesizes the PRD and creates it in the configured source via `lisa-prd-source-write`. `project-ideation` never writes to the source directly — it delegates, so the PRD source stays switchable per project. Capture each returned PRD ref / URL / role / outcome. ### Optional Codex automation memory When the run has a Codex automation id or memory path, maintain a concise local advisory ledger after the PRD source write returns. Resolve the memory path in this order: 1. explicit `memory_file=` or `automation_memory=` argument, when supplied; 2. `$CODEX_AUTOMATION_MEMORY`, when set; 3. `$CODEX_HOME/automations//memory.md`, when `automation_id=` or `$CODEX_AUTOMATION_ID` is available. Create the parent directory and `memory.md` if missing. Write one concise run entry keyed by the dedupe marker and run timestamp. The entry must include the marker, PRD URL/ref, outcome (`created | reused | updated | blocked`), lifecycle role (`draft | ready | blocked` or the returned source role), and `source_agreement` (`github-source-wins`, `memory-created`, `memory-updated`, or `memory-missing-runtime`). If memory says one thing but the PRD source search finds a matching open PRD, GitHub/source truth wins: reuse the source PRD and update memory rather than creating a duplicate. Keep memory advisory only; never use it to override lifecycle labels, source marker matches, or the PRD source writer's returned role. Do not store secrets, tokens, full PRD bodies, or private source excerpts in memory. ### Dedupe marker (stable, never title-based) Each created PRD carries the marker `[lisa-project-ideation] idea=`. Compute `` deterministically from: repo identity (configured repo or git remote + repo-root basename) + a normalized slug of the idea name + the normalized persona key(s) + the existing-fit anchor. **Do not** include rank, date, confidence, or the generated PRD title (they change across runs). `lisa-prd-source-write` searches the source for a PRD carrying this marker before creating — matching by marker, never by title — so re-running ideation updates/references the existing PRD rather than duplicating it. Per the `rejection-detection` rule's **Proposal rejection memory** section, that marker search MUST cover **open AND closed** PRDs (with a body-enumeration fallback on search-index lag), and a PRD **closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/ canceled equivalent on JIRA/Linear — never a hardcoded lane string) is a **durable human decline** that **suppresses** re-proposing that idea. Re-propose only with evidence that **postdates the decline**, and state it in the new PRD as BOTH the machine token (`declined ; recurred in `) and a human acknowledgment sentence (`You declined this on . It has recurred (, ), so we're raising it once more for your review.`). A PRD closed as _completed_ is not a decline. This is tracker-side memory; the advisory ideation memory ledger stays advisory and never overrides it. Every created PRD MUST carry the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it: > To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression. ## Step 7 — Output (no report file) Emit two distinct in-session sections (do not write a report file): 1. **Idea report** (the audit trail): ```markdown ## Personas Derived From Evidence - — goals; pains; evidence (files/docs/tables/releases); confidence ## What Already Exists - ## Practical Ideas ### 1. (persona: ) - Persona value · Existing fit · Data/source path · Practical slice · Empirical verification · Evidence · Confidence ## Discovery Spikes - ## Rejected / Not Practical Yet - ``` 2. **PRDs Created** (the creation summary): for each selected idea — the created/reused PRD ref + URL, its lifecycle role (`draft` or `ready`), its dedupe marker, and `created | reused`. List the Practical Ideas that were **not** created this run and why (e.g. "below the `max_prds=1` cut"). Always include the **Personas**, **What Already Exists**, **Discovery Spikes**, and **Rejected** sections (even if empty) so the user sees what was considered and filtered out. ## Run outcome As the registered `exploratory-prds` automation loop, this run conforms to the `automation-runbook-contract` rule: it ends in **exactly one** of the six run outcomes and records it, so a quiet ideation run and a broken one are never confused. | This run's exit path | Run outcome | |---|---| | PRD(s) created or reused this run (Step 6/7 **PRDs Created**) | `candidate-proposed` | | Nothing to ideate — no Practical Idea cleared the bar; nothing created — **or** every idea was suppressed by a prior decline (`rejection-detection` **Proposal rejection memory**): the summary MUST name the suppression count | `nothing-needed` | | The Step 5.5 **PRD-queue-pressure gate** blocked auto-ready creation — a human must drain the queue before another auto-ready PRD is added | `approval-requested` | | The loop itself could not run — the PRD source reader failed or the queue is misconfigured (a source-reader failure snapshot, not queue pressure) — **or** the open-and-closed rejection-memory marker search could not read the source: a memory check that could not run is a broken loop, never a silent `nothing-needed` | `recovery-required` | | The runbook's **Retirement condition** tripped — the trailing quiet window is empty AND this run proposed nothing AND no unresolved PRD pressure exists while no new surface has shipped — this row supersedes the `nothing-needed` row when it applies | `policy-obsolete` | | A degradation that still let ideation run (optional Codex automation memory unavailable, an inspiration source unreachable) | the outcome it actually reached above, with the summary **leading with the degradation** — degradation never mints a seventh token | The pressure gate is `approval-requested`, **not** `recovery-required`: the loop ran fine and correctly declined to add queue pressure — it is asking a human to drain the queue, not reporting a broken machine. `recovery-required` is reserved for the loop failing to run at all. Before invoking the run-record CLI, evaluate the **Retirement condition** first. If it applies, select `policy-obsolete` as the sole outcome and do not record a prior `nothing-needed` result; otherwise select the ordinary outcome from the table. Record **exactly one** outcome per invocation through the run-record CLI, naming this loop's runbook (the `--summary` is the operator-readable one-liner in the contract's exemplar voice — plain, specific, actionable, e.g. `Reviewed evidence; no practical idea cleared the bar — nothing to propose.` for `nothing-needed`; and for a `recovery-required` from an unreadable decline check, `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`): ```bash node "${CLAUDE_PLUGIN_ROOT:-node_modules/@codyswann/lisa/plugins/lisa}/scripts/automation-run-record.mjs" \ --loop-id exploratory-prds --outcome candidate-proposed \ --summary "Created PRD #1810 for offline export; awaiting your flip to ready." \ --runbook .lisa/automations/exploratory-prds.runbook.md [--ref ]... ``` The `:-` default in that command is load-bearing, not decoration. `CLAUDE_PLUGIN_ROOT` is **not exported into an agent's Bash tool environment**, so the bare `"${CLAUDE_PLUGIN_ROOT}/scripts/…"` form expands to an absolute `/scripts/…` and exits 1. The default names the installed package copy, which resolves from the **consumer repository root** — which is where the recorder is actually invoked. Never substitute a bare `plugins/lisa/scripts/…` or `plugins/src/base/scripts/…` path: those are relative to the **Lisa package root**, not the repository you are standing in, and exit 1 from there. If recording still fails, **degrade, never abort** (per `automation-runbook-contract`): note the recording failure in the run output and finish the run — a recording failure is a degradation to report, never a reason to block the loop. **Retirement evaluation (every run).** Evaluate this loop's runbook **Retirement condition** on every run, exactly as the `automation-runbook-contract` rule's Retirement section defines it — this skill conforms to that text and never restates or diverges from it. On top of the contract's two conditions the runbook seeds a third **domain conjunct** — no unresolved PRD pressure exists and the project has shipped no new surface to ideate against — which only tightens the test and never replaces it: a quiet month because the queue was full is the loop working, not the loop being obsolete. Evaluate all three. When all three hold, record `policy-obsolete` and file **exactly ONE** marker-deduped teardown proposal through `lisa-tracker-write` (per `tracked-work` + `integration-access-layer`): - **Marker** `` plus a visible prose line; matched on the marker, never the title; searched **open AND closed** per `rejection-detection`'s **Proposal rejection memory**. Treat matches by close state: **open** suppresses another proposal; **Not planned** suppresses another proposal unless new evidence postdates the rejection; **Completed** means the prior approved action happened, so a later recurrence may be re-filed. When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files nothing** — the outcome describes this run, while the ticket is filed exactly once. - **Labels** `status:blocked` + `human-needed`, carrying the contract's decision-ready packet. The `human-needed` label marks the proposal human-owned: `lisa-repair-intake` recognizes it and never re-dispatches it as stalled work. - **Evidence** the date-filtered search result, this run's summary, **the loop's current cadence** (the baseline an operator needs to choose a longer one), and a one-line summary of recent runs read from `.lisa/automations/runs/exploratory-prds.jsonl`. Fill the rest of the packet the same way every time: *Work already attempted* is the searches this run ran, and *Risk of inaction* is that the loop keeps consuming schedule slots and tokens for nothing. - **How to answer** names the three operator responses: **approve** — run `/lisa:tear-down-automations exploratory-prds` and only that loop registration goes away; **decline** — close the proposal as **Not planned** (closing it as **Completed** leaves a later re-file open) and the loop simply continues; **re-cadence** — pick a longer cadence off that evidence and re-register with `/lisa:setup-automations` instead of tearing down. - **Operator footer**, verbatim, as on every loop-filed proposal (`rejection-detection`): > To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression. The loop **keeps running at its normal cadence** until a human acts, and never deletes its own registration. ## Out of scope (hard rules) - **No fabricated personas.** No evidence citation → no persona; generic roles banned without evidence (Step 2). - **No sign-in-only ideas** unless the host project already supports sign-in *and* credentials are available. **No private-data assumptions.** **No manual-data-only** requirements unless the user accepts manual curation. **No paid-API / non-scrapeable-source ideas** in the build-ready list — demote with the blocker named. - **Tests, lint, typecheck, and build are not the empirical verification plan** — they are prerequisites; verification must observe user-facing behavior. - **Do not create tracker tickets or mutate the host project's code.** PRD creation (via `lisa-research`) is the only normal write this skill performs; the only tracker-ticket exception is the exactly-one marker-deduped `policy-obsolete` teardown proposal described above. Ticket planning (`lisa-plan`) and implementation (`lisa-implement`) are separate, user-invoked flows. - **Do not write PRDs to the source directly** — always go through `lisa-research` → `lisa-prd-source-write` so the source stays switchable. - **Do not add a new verification/browser-automation framework** when one already exists — reuse it. - **Do not overfit to a source example.** Keep the workflow project-agnostic. ## Handing off The created PRDs flow straight into the lifecycle: - A `draft` PRD → a human reviews it, then promotes it to `ready` (or re-run with `prd_ready=true`). - A `prd-ready` PRD → `/lisa:intake` (PRD side) auto-claims it → `/lisa:plan` decomposes it → `/lisa:implement` builds each item → `/lisa:codify-verification` locks in the verification. ## Example outputs Use the markdown examples in `examples/` as shape references for the idea report: - `host-project-only.md` — ideas grounded only in the current repository. - `public-external-inspiration.md` — public, no-login external sources as inspiration, not hidden requirements. - `unavailable-data-rejection.md` — naming missing private/paid/unavailable sources when demoting. - `evidence-card-format.md` — the required evidence fields every Practical Idea card must carry. - `idempotency-verification-harness.md` — deterministic fixture and script procedure proving that repeated `prd_ready=true` ideation keeps the open GitHub marker count at one, including the missing-memory rerun variant.