@codyswann/lisa 2.52.0 → 2.54.0

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/commands/project-ideation.md

@@ -0,0 +1,6 @@
+---
+description: "Generate practical, verifiable product or workflow ideas for the current host project. Inspects code, docs, data sources, and current surfaces (and optionally an external public product), then returns a prioritized report separating build-ready ideas from discovery spikes and rejected ones. Every build-ready idea must have an obtainable data/source path and an empirical verification plan."
+argument-hint: "[target project path or external product to compare against]"
+---
+
+Use the /lisa:project-ideation skill to generate a decision-ready idea report for the host project. $ARGUMENTS

package/plugins/lisa/skills/project-ideation/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: project-ideation
+description: "Generate practical, verifiable product or workflow ideas for the current host project. Inspects the host project (code, docs, scripts, data sources, current surfaces), optionally compares against external public products, and returns a prioritized idea report. Every build-ready idea must pass a practicality gate (an obtainable data/source path the project can plausibly implement) and an empirical verification gate (a user-observable outcome the agent can verify itself). Ideas that fail either gate are demoted to Discovery Spikes or Rejected / Not Practical Yet. Invoke for prompts like 'generate feature ideas for this project', 'looking at <external product>, what should we add here?', 'suggest practical improvements we can verify ourselves', or 'what should this app do next given the data we can get?'. Vendor- and stack-agnostic: works for web apps, APIs, CLIs, wiki systems, data pipelines, and internal tools. Does not create tickets or mutate the project — it produces a decision-ready report the user can later hand to a Research, Plan, or Implement flow."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep", "WebFetch", "WebSearch"]
+---
+
+# Project Ideation
+
+Produce a decision-ready idea report for the host project described in `$ARGUMENTS` (or the current working directory if no target is given). The report separates ideas that are **build-ready now** from ideas that need a **discovery spike** and ideas that are **rejected / not practical yet**.
+
+The value of this skill is **filtering**, not brainstorming volume. An attractive idea you cannot ground in obtainable data and cannot verify yourself is not a recommendation — it is noise. Demote it honestly.
+
+## When to use
+
+Trigger this skill on prompts such as:
+
+- "generate feature ideas for this project"
+- "looking at <external product / website>, what should we add here?"
+- "suggest practical improvements we can verify ourselves"
+- "what should this app do next given the data we can get?"
+- "what high-value features could we add to <repo>?"
+
+Do **not** use this skill to create tickets, write a PRD, or change code. It stops at a report. The user can then ask Lisa to turn one or more ideas into a PRD (`/lisa:research`), a plan (`/lisa:plan`), or an implementation (`/lisa:implement`).
+
+## Two gates every build-ready idea must pass
+
+An idea may only appear under **Practical Ideas** if it passes BOTH gates. Otherwise demote it.
+
+1. **Practicality gate.** The project can plausibly implement the idea from sources that are actually available: existing code, an existing data model, a route/command/UI surface, a public or already-integrated API, a scrapeable public page, an existing user input, a local database, or documented integrations. You must be able to name the specific source and how the data is obtained. "We could probably get the data somehow" fails the gate.
+2. **Empirical verification gate.** You can personally confirm the resulting behavior by using the software or workflow — running the CLI, hitting the API, loading the page, querying the database, or inspecting a generated artifact — and capture a concrete evidence artifact. Saying "tests could be written later" does **not** satisfy this gate. Quality gates (tests, lint, typecheck, build) are prerequisites, never proof that an idea works.
+
+If an idea fails the practicality gate → it goes under **Rejected / Not Practical Yet** (or **Discovery Spikes** if a bounded probe could make it practical), with the missing data/source/access named explicitly.
+
+If an idea fails only the empirical verification gate → it goes under **Discovery Spikes** (define the missing proof) or stays as a strategic note, never as 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** — read the manifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, etc.) and any `.lisa.config.json`.
+- **Docs and specs** — `README`, `docs/`, `wiki/`, architecture notes, ADRs.
+- **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 already supplies.
+- **Available data sources and ingestion/scraping paths** — integrated APIs, public datasets, scrapeable public pages, local databases, event streams.
+- **Existing verification tooling and empirical paths** — how a human currently observes that the software works (a local dev server, a CLI you can run, a seedable DB, a dry-run mode).
+
+Use Lisa's existing methodology rather than inventing a parallel flow. Read the host code through the same lens as `/lisa:codebase-research` (trace data flow, find reusable code, identify modification points). When the request references an external product, use web/browser research; when the ideas would touch a live UI, use `/lisa:product-walkthrough` to ground the analysis in what exists today.
+
+## Step 2 — Optional external / public-source inspection
+
+Only when the user references an external product, website, public dataset, competitor, or example:
+
+- Inspect **public, no-login** surfaces only. Do not assume sign-in, credentials, or paid access.
+- Preserve every **source URL** you used so each informed idea can cite it.
+- If the runtime has no browser or web capability, mark that research source as **unavailable** and proceed with host-project-only ideas (document the fallback rather than fabricating findings).
+
+The external source is **inspiration, not a domain you bake in**. Keep the workflow reusable across any Lisa-managed repository.
+
+## Step 3 — Generate ideas, then filter through the gates
+
+Brainstorm broadly, then run every idea through both gates from the top of this skill. For each surviving idea, build a **feasibility card** containing at least:
+
+- **User/persona value** — why the host project's user would care.
+- **Existing fit** — the current route / API / CLI / model / doc / surface it builds on.
+- **Data/source required** — the specific data the idea consumes.
+- **How the data can be obtained or scraped** — the concrete accessible path (endpoint, query, public page, existing input).
+- **Known source limitations or terms constraints** — rate limits, robots/ToS, staleness, missing fields.
+- **Smallest practical implementation slice** — the minimal useful version.
+- **Empirical verification steps** — what you (the agent) will do against the running app / API / CLI / DB / artifact to confirm it works.
+- **Evidence artifact** — the screenshot, curl output, CLI output, DB row, or generated file the verifier captures.
+- **Confidence** — high | medium | low, with the reason.
+
+## Step 4 — Rank and assemble the report
+
+Rank build-ready ideas by **user value, feasibility, verification clarity, and project fit**. Emit the report in this shape:
+
+```markdown
+## What Already Exists
+- <current surfaces, data, commands, or workflows discovered — so duplicates are not re-proposed>
+
+## Practical Ideas
+### 1. <Idea name>
+- User value: <why the host project's user would care>
+- Existing fit: <current route/API/CLI/model/doc/surface it builds on>
+- Data/source path: <specific accessible source or scrape/API path>
+- Practical slice: <smallest useful version>
+- Empirical verification: <steps the agent can perform against the running software>
+- Evidence: <screenshot, curl output, CLI output, DB row, generated file, etc.>
+- Confidence: high|medium|low with reason
+
+## Discovery Spikes
+- <ideas that need proof of data, access, or verification before they can be build-ready — name the missing proof>
+
+## Rejected / Not Practical Yet
+- <attractive ideas rejected because data, access, legality, or verification is not available — name what is missing>
+```
+
+Always include the **What Already Exists** section so the user can tell genuinely new ideas from duplicates, and so the report records existing capabilities. Always include both the **Discovery Spikes** and **Rejected / Not Practical Yet** sections (even if empty) so the user can see what was deliberately filtered out and why.
+
+## Out of scope (hard rules)
+
+- **No sign-in-only ideas** unless the host project already supports sign-in *and* credentials are available.
+- **No private-data assumptions** — do not premise an idea on data the project cannot legitimately obtain.
+- **No manual-data-only requirements** unless the user explicitly accepts manual curation.
+- **No paid-API or non-scrapeable-source ideas** in the build-ready list — demote them with the blocker named.
+- **Tests, lint, typecheck, and build are not the empirical verification plan.** They are prerequisites; the verification plan must observe user-facing behavior.
+- **Do not auto-create tracker tickets or mutate the host project.** Produce the report only; planning and implementation are separate, user-invoked flows.
+- **Do not add a new verification or browser-automation framework** when the host project already has one — reuse it.
+- **Do not overfit to a source example.** Keep the workflow project-agnostic and reusable.
+
+## Handing off
+
+When the user wants to act on an idea, preserve its feasibility and verification card as the source artifact so downstream flows inherit the evidence:
+
+- Turn an idea into a PRD → `/lisa:research`
+- Turn a PRD into tickets → `/lisa:plan`
+- Build a ticket end-to-end → `/lisa:implement`
+- Lock in the verification so it never regresses → `/lisa:codify-verification`
+
+## Example outputs
+
+Use the markdown examples in `examples/` as shape references when composing reports:
+
+- `host-project-only.md` shows ideas grounded only in the current repository.
+- `public-external-inspiration.md` shows how public, no-login external sources can inspire ideas without becoming hidden requirements.
+- `unavailable-data-rejection.md` shows how to name missing private, paid, or unavailable data sources when demoting ideas.
+- `evidence-card-format.md` shows the required evidence fields every Practical Idea card must carry.

package/plugins/lisa/skills/project-ideation/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Project Ideation"
+short_description: "Generate practical, verifiable product or workflow ideas for the current host project"
+default_prompt:
+  - "Use $project-ideation: Generate practical, verifiable product or workflow ideas for the current host project."

package/plugins/lisa/skills/project-ideation/examples/evidence-card-format.md

@@ -0,0 +1,21 @@
+# Evidence Card Formatting Example Output
+
+## What Already Exists
+- Lisa work items already use Validation Journey evidence markers.
+- Skill reports can be saved as markdown artifacts and reviewed by humans.
+
+## Practical Ideas
+### 1. Evidence-First Idea Cards
+- User value: A reviewer can decide whether an idea is ready without asking how it will be proven.
+- Existing fit: Uses the project-ideation report shape and Lisa's evidence-first verification rules.
+- Data/source path: Existing local project files plus any public URLs cited in the report.
+- Practical slice: Require each practical idea to include `Empirical verification` and `Evidence` lines before it can remain in the practical list.
+- Empirical verification: Render this example and confirm every practical idea card includes the two evidence fields.
+- Evidence: Text output showing all practical cards pass the field check.
+- Confidence: high because the check is structural and does not require external services.
+
+## Discovery Spikes
+- Evidence attachments inside generated reports: needs a storage and retention decision for binary artifacts.
+
+## Rejected / Not Practical Yet
+- Treating lint, typecheck, or unit tests as the only proof for a user-facing idea: rejected because quality gates are prerequisites, not empirical evidence artifacts.

package/plugins/lisa/skills/project-ideation/examples/host-project-only.md

@@ -0,0 +1,22 @@
+# Host Project Only Example Output
+
+## What Already Exists
+- CLI command registration is documented in the repository README.
+- Skill sources live under `plugins/src/base/skills/` and are copied into the generated Lisa plugin.
+- The project already has unit tests that verify generated plugin artifacts.
+
+## Practical Ideas
+### 1. Plugin Surface Drift Report
+- User value: Maintainers can see which source skills are not represented in the generated plugin before publishing.
+- Existing fit: Builds on the existing plugin source tree and generated plugin artifact tests.
+- Data/source path: Local files under `plugins/src/base/skills/` and `plugins/lisa/skills/`.
+- Practical slice: Emit a markdown report listing source-only, generated-only, and mismatched skill directories.
+- Empirical verification: Run the report command in a clean checkout after intentionally adding one fixture-only source skill.
+- Evidence: CLI output showing the mismatched skill and the generated markdown report path.
+- Confidence: high because the required data is already local and deterministic.
+
+## Discovery Spikes
+- Skill usage frequency ranking: needs a bounded source of invocation telemetry before it can be recommended.
+
+## Rejected / Not Practical Yet
+- Personalized skill suggestions from private user history: rejected because the repository does not have access to private Codex usage history.

package/plugins/lisa/skills/project-ideation/examples/public-external-inspiration.md

@@ -0,0 +1,22 @@
+# Public External Inspiration Example Output
+
+## What Already Exists
+- The host project already has a command catalog and source-authored skill files.
+- The host project can inspect public documentation pages without sign-in.
+- Existing verification can run through CLI commands and generated markdown artifacts.
+
+## Practical Ideas
+### 1. Public Pattern Checklist Import
+- User value: Maintainers can compare their command guidance against public best-practice pages without copying private or paid content.
+- Existing fit: Builds on the current docs and skill authoring workflow.
+- Data/source path: A public, no-login documentation URL supplied by the user, plus local `README.md` and skill files.
+- Practical slice: Generate a checklist of public patterns found in the external page and mark whether each is already represented locally.
+- Empirical verification: Run the ideation workflow against a fixed public URL and inspect the generated checklist.
+- Evidence: Generated markdown containing source URLs, matched local file paths, and unmatched public patterns.
+- Confidence: medium because public pages can change, but the source path is accessible and citeable.
+
+## Discovery Spikes
+- Automated freshness checks for public pages: needs a policy for when external pages may be re-fetched and cached.
+
+## Rejected / Not Practical Yet
+- Importing examples from a sign-in-only competitor workspace: rejected because the data source is not publicly obtainable.

package/plugins/lisa/skills/project-ideation/examples/unavailable-data-rejection.md

@@ -0,0 +1,22 @@
+# Unavailable Data Rejection Example Output
+
+## What Already Exists
+- The host project can read local source files, docs, scripts, and generated artifacts.
+- The host project does not expose customer analytics, private support tickets, or paid market datasets.
+
+## Practical Ideas
+### 1. Local Verification Gap Finder
+- User value: Maintainers can identify skills that describe empirical verification but do not name an evidence artifact.
+- Existing fit: Builds on local skill markdown files and existing unit tests.
+- Data/source path: Local `SKILL.md` files under the plugin source tree.
+- Practical slice: Scan skill files for verification sections and report entries that mention tests but no observable artifact.
+- Empirical verification: Run the scanner against a fixture skill with one missing evidence line.
+- Evidence: CLI output naming the fixture skill and the missing evidence field.
+- Confidence: high because the input is local and fully inspectable.
+
+## Discovery Spikes
+- Prioritize gaps by real-world usage: needs an obtainable telemetry source or a manually approved usage export before it can rank by frequency.
+
+## Rejected / Not Practical Yet
+- Recommend ideas from private customer support pain points: rejected because the missing source is a legitimate support-ticket export or configured support integration.
+- Recommend ideas from paid analyst reports: rejected because the missing source is a licensed data feed available to the agent at runtime.

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.52.0",
+  "version": "2.54.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/commands/project-ideation.md

@@ -0,0 +1,6 @@
+---
+description: "Generate practical, verifiable product or workflow ideas for the current host project. Inspects code, docs, data sources, and current surfaces (and optionally an external public product), then returns a prioritized report separating build-ready ideas from discovery spikes and rejected ones. Every build-ready idea must have an obtainable data/source path and an empirical verification plan."
+argument-hint: "[target project path or external product to compare against]"
+---
+
+Use the /lisa:project-ideation skill to generate a decision-ready idea report for the host project. $ARGUMENTS

package/plugins/src/base/skills/project-ideation/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: project-ideation
+description: "Generate practical, verifiable product or workflow ideas for the current host project. Inspects the host project (code, docs, scripts, data sources, current surfaces), optionally compares against external public products, and returns a prioritized idea report. Every build-ready idea must pass a practicality gate (an obtainable data/source path the project can plausibly implement) and an empirical verification gate (a user-observable outcome the agent can verify itself). Ideas that fail either gate are demoted to Discovery Spikes or Rejected / Not Practical Yet. Invoke for prompts like 'generate feature ideas for this project', 'looking at <external product>, what should we add here?', 'suggest practical improvements we can verify ourselves', or 'what should this app do next given the data we can get?'. Vendor- and stack-agnostic: works for web apps, APIs, CLIs, wiki systems, data pipelines, and internal tools. Does not create tickets or mutate the project — it produces a decision-ready report the user can later hand to a Research, Plan, or Implement flow."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep", "WebFetch", "WebSearch"]
+---
+
+# Project Ideation
+
+Produce a decision-ready idea report for the host project described in `$ARGUMENTS` (or the current working directory if no target is given). The report separates ideas that are **build-ready now** from ideas that need a **discovery spike** and ideas that are **rejected / not practical yet**.
+
+The value of this skill is **filtering**, not brainstorming volume. An attractive idea you cannot ground in obtainable data and cannot verify yourself is not a recommendation — it is noise. Demote it honestly.
+
+## When to use
+
+Trigger this skill on prompts such as:
+
+- "generate feature ideas for this project"
+- "looking at <external product / website>, what should we add here?"
+- "suggest practical improvements we can verify ourselves"
+- "what should this app do next given the data we can get?"
+- "what high-value features could we add to <repo>?"
+
+Do **not** use this skill to create tickets, write a PRD, or change code. It stops at a report. The user can then ask Lisa to turn one or more ideas into a PRD (`/lisa:research`), a plan (`/lisa:plan`), or an implementation (`/lisa:implement`).
+
+## Two gates every build-ready idea must pass
+
+An idea may only appear under **Practical Ideas** if it passes BOTH gates. Otherwise demote it.
+
+1. **Practicality gate.** The project can plausibly implement the idea from sources that are actually available: existing code, an existing data model, a route/command/UI surface, a public or already-integrated API, a scrapeable public page, an existing user input, a local database, or documented integrations. You must be able to name the specific source and how the data is obtained. "We could probably get the data somehow" fails the gate.
+2. **Empirical verification gate.** You can personally confirm the resulting behavior by using the software or workflow — running the CLI, hitting the API, loading the page, querying the database, or inspecting a generated artifact — and capture a concrete evidence artifact. Saying "tests could be written later" does **not** satisfy this gate. Quality gates (tests, lint, typecheck, build) are prerequisites, never proof that an idea works.
+
+If an idea fails the practicality gate → it goes under **Rejected / Not Practical Yet** (or **Discovery Spikes** if a bounded probe could make it practical), with the missing data/source/access named explicitly.
+
+If an idea fails only the empirical verification gate → it goes under **Discovery Spikes** (define the missing proof) or stays as a strategic note, never as 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** — read the manifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, etc.) and any `.lisa.config.json`.
+- **Docs and specs** — `README`, `docs/`, `wiki/`, architecture notes, ADRs.
+- **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 already supplies.
+- **Available data sources and ingestion/scraping paths** — integrated APIs, public datasets, scrapeable public pages, local databases, event streams.
+- **Existing verification tooling and empirical paths** — how a human currently observes that the software works (a local dev server, a CLI you can run, a seedable DB, a dry-run mode).
+
+Use Lisa's existing methodology rather than inventing a parallel flow. Read the host code through the same lens as `/lisa:codebase-research` (trace data flow, find reusable code, identify modification points). When the request references an external product, use web/browser research; when the ideas would touch a live UI, use `/lisa:product-walkthrough` to ground the analysis in what exists today.
+
+## Step 2 — Optional external / public-source inspection
+
+Only when the user references an external product, website, public dataset, competitor, or example:
+
+- Inspect **public, no-login** surfaces only. Do not assume sign-in, credentials, or paid access.
+- Preserve every **source URL** you used so each informed idea can cite it.
+- If the runtime has no browser or web capability, mark that research source as **unavailable** and proceed with host-project-only ideas (document the fallback rather than fabricating findings).
+
+The external source is **inspiration, not a domain you bake in**. Keep the workflow reusable across any Lisa-managed repository.
+
+## Step 3 — Generate ideas, then filter through the gates
+
+Brainstorm broadly, then run every idea through both gates from the top of this skill. For each surviving idea, build a **feasibility card** containing at least:
+
+- **User/persona value** — why the host project's user would care.
+- **Existing fit** — the current route / API / CLI / model / doc / surface it builds on.
+- **Data/source required** — the specific data the idea consumes.
+- **How the data can be obtained or scraped** — the concrete accessible path (endpoint, query, public page, existing input).
+- **Known source limitations or terms constraints** — rate limits, robots/ToS, staleness, missing fields.
+- **Smallest practical implementation slice** — the minimal useful version.
+- **Empirical verification steps** — what you (the agent) will do against the running app / API / CLI / DB / artifact to confirm it works.
+- **Evidence artifact** — the screenshot, curl output, CLI output, DB row, or generated file the verifier captures.
+- **Confidence** — high | medium | low, with the reason.
+
+## Step 4 — Rank and assemble the report
+
+Rank build-ready ideas by **user value, feasibility, verification clarity, and project fit**. Emit the report in this shape:
+
+```markdown
+## What Already Exists
+- <current surfaces, data, commands, or workflows discovered — so duplicates are not re-proposed>
+
+## Practical Ideas
+### 1. <Idea name>
+- User value: <why the host project's user would care>
+- Existing fit: <current route/API/CLI/model/doc/surface it builds on>
+- Data/source path: <specific accessible source or scrape/API path>
+- Practical slice: <smallest useful version>
+- Empirical verification: <steps the agent can perform against the running software>
+- Evidence: <screenshot, curl output, CLI output, DB row, generated file, etc.>
+- Confidence: high|medium|low with reason
+
+## Discovery Spikes
+- <ideas that need proof of data, access, or verification before they can be build-ready — name the missing proof>
+
+## Rejected / Not Practical Yet
+- <attractive ideas rejected because data, access, legality, or verification is not available — name what is missing>
+```
+
+Always include the **What Already Exists** section so the user can tell genuinely new ideas from duplicates, and so the report records existing capabilities. Always include both the **Discovery Spikes** and **Rejected / Not Practical Yet** sections (even if empty) so the user can see what was deliberately filtered out and why.
+
+## Out of scope (hard rules)
+
+- **No sign-in-only ideas** unless the host project already supports sign-in *and* credentials are available.
+- **No private-data assumptions** — do not premise an idea on data the project cannot legitimately obtain.
+- **No manual-data-only requirements** unless the user explicitly accepts manual curation.
+- **No paid-API or non-scrapeable-source ideas** in the build-ready list — demote them with the blocker named.
+- **Tests, lint, typecheck, and build are not the empirical verification plan.** They are prerequisites; the verification plan must observe user-facing behavior.
+- **Do not auto-create tracker tickets or mutate the host project.** Produce the report only; planning and implementation are separate, user-invoked flows.
+- **Do not add a new verification or browser-automation framework** when the host project already has one — reuse it.
+- **Do not overfit to a source example.** Keep the workflow project-agnostic and reusable.
+
+## Handing off
+
+When the user wants to act on an idea, preserve its feasibility and verification card as the source artifact so downstream flows inherit the evidence:
+
+- Turn an idea into a PRD → `/lisa:research`
+- Turn a PRD into tickets → `/lisa:plan`
+- Build a ticket end-to-end → `/lisa:implement`
+- Lock in the verification so it never regresses → `/lisa:codify-verification`
+
+## Example outputs
+
+Use the markdown examples in `examples/` as shape references when composing reports:
+
+- `host-project-only.md` shows ideas grounded only in the current repository.
+- `public-external-inspiration.md` shows how public, no-login external sources can inspire ideas without becoming hidden requirements.
+- `unavailable-data-rejection.md` shows how to name missing private, paid, or unavailable data sources when demoting ideas.
+- `evidence-card-format.md` shows the required evidence fields every Practical Idea card must carry.

package/plugins/src/base/skills/project-ideation/examples/evidence-card-format.md

@@ -0,0 +1,21 @@
+# Evidence Card Formatting Example Output
+
+## What Already Exists
+- Lisa work items already use Validation Journey evidence markers.
+- Skill reports can be saved as markdown artifacts and reviewed by humans.
+
+## Practical Ideas
+### 1. Evidence-First Idea Cards
+- User value: A reviewer can decide whether an idea is ready without asking how it will be proven.
+- Existing fit: Uses the project-ideation report shape and Lisa's evidence-first verification rules.
+- Data/source path: Existing local project files plus any public URLs cited in the report.
+- Practical slice: Require each practical idea to include `Empirical verification` and `Evidence` lines before it can remain in the practical list.
+- Empirical verification: Render this example and confirm every practical idea card includes the two evidence fields.
+- Evidence: Text output showing all practical cards pass the field check.
+- Confidence: high because the check is structural and does not require external services.
+
+## Discovery Spikes
+- Evidence attachments inside generated reports: needs a storage and retention decision for binary artifacts.
+
+## Rejected / Not Practical Yet
+- Treating lint, typecheck, or unit tests as the only proof for a user-facing idea: rejected because quality gates are prerequisites, not empirical evidence artifacts.

package/plugins/src/base/skills/project-ideation/examples/host-project-only.md

@@ -0,0 +1,22 @@
+# Host Project Only Example Output
+
+## What Already Exists
+- CLI command registration is documented in the repository README.
+- Skill sources live under `plugins/src/base/skills/` and are copied into the generated Lisa plugin.
+- The project already has unit tests that verify generated plugin artifacts.
+
+## Practical Ideas
+### 1. Plugin Surface Drift Report
+- User value: Maintainers can see which source skills are not represented in the generated plugin before publishing.
+- Existing fit: Builds on the existing plugin source tree and generated plugin artifact tests.
+- Data/source path: Local files under `plugins/src/base/skills/` and `plugins/lisa/skills/`.
+- Practical slice: Emit a markdown report listing source-only, generated-only, and mismatched skill directories.
+- Empirical verification: Run the report command in a clean checkout after intentionally adding one fixture-only source skill.
+- Evidence: CLI output showing the mismatched skill and the generated markdown report path.
+- Confidence: high because the required data is already local and deterministic.
+
+## Discovery Spikes
+- Skill usage frequency ranking: needs a bounded source of invocation telemetry before it can be recommended.
+
+## Rejected / Not Practical Yet
+- Personalized skill suggestions from private user history: rejected because the repository does not have access to private Codex usage history.

package/plugins/src/base/skills/project-ideation/examples/public-external-inspiration.md

@@ -0,0 +1,22 @@
+# Public External Inspiration Example Output
+
+## What Already Exists
+- The host project already has a command catalog and source-authored skill files.
+- The host project can inspect public documentation pages without sign-in.
+- Existing verification can run through CLI commands and generated markdown artifacts.
+
+## Practical Ideas
+### 1. Public Pattern Checklist Import
+- User value: Maintainers can compare their command guidance against public best-practice pages without copying private or paid content.
+- Existing fit: Builds on the current docs and skill authoring workflow.
+- Data/source path: A public, no-login documentation URL supplied by the user, plus local `README.md` and skill files.
+- Practical slice: Generate a checklist of public patterns found in the external page and mark whether each is already represented locally.
+- Empirical verification: Run the ideation workflow against a fixed public URL and inspect the generated checklist.
+- Evidence: Generated markdown containing source URLs, matched local file paths, and unmatched public patterns.
+- Confidence: medium because public pages can change, but the source path is accessible and citeable.
+
+## Discovery Spikes
+- Automated freshness checks for public pages: needs a policy for when external pages may be re-fetched and cached.
+
+## Rejected / Not Practical Yet
+- Importing examples from a sign-in-only competitor workspace: rejected because the data source is not publicly obtainable.

package/plugins/src/base/skills/project-ideation/examples/unavailable-data-rejection.md

@@ -0,0 +1,22 @@
+# Unavailable Data Rejection Example Output
+
+## What Already Exists
+- The host project can read local source files, docs, scripts, and generated artifacts.
+- The host project does not expose customer analytics, private support tickets, or paid market datasets.
+
+## Practical Ideas
+### 1. Local Verification Gap Finder
+- User value: Maintainers can identify skills that describe empirical verification but do not name an evidence artifact.
+- Existing fit: Builds on local skill markdown files and existing unit tests.
+- Data/source path: Local `SKILL.md` files under the plugin source tree.
+- Practical slice: Scan skill files for verification sections and report entries that mention tests but no observable artifact.
+- Empirical verification: Run the scanner against a fixture skill with one missing evidence line.
+- Evidence: CLI output naming the fixture skill and the missing evidence field.
+- Confidence: high because the input is local and fully inspectable.
+
+## Discovery Spikes
+- Prioritize gaps by real-world usage: needs an obtainable telemetry source or a manually approved usage export before it can rank by frequency.
+
+## Rejected / Not Practical Yet
+- Recommend ideas from private customer support pain points: rejected because the missing source is a legitimate support-ticket export or configured support integration.
+- Recommend ideas from paid analyst reports: rejected because the missing source is a licensed data feed available to the agent at runtime.