@codyswann/lisa 2.189.7 → 2.189.9

package/plugins/lisa/skills/intake/SKILL.md

@@ -1,133 +0,0 @@
----
-name: intake
-description: "Vendor-agnostic scanner for Ready queues. Given a Notion PRD database URL → finds the first Ready PRD and runs lisa:plan. Given a Confluence space or parent page URL → finds the first prd-ready PRD and runs lisa:plan. Given a Linear workspace URL or team key → finds the first prd-ready Linear project and runs lisa:plan. Given a GitHub repo URL or `org/repo` token → finds the first prd-ready GitHub issue and runs lisa:plan. Given a JIRA project key or JQL filter → finds the first Ready ticket and runs lisa:implement. Given a GitHub repo URL or `org/repo` token when `tracker = github` → finds the first `status:ready` issue and runs lisa:implement. On the PRD side it also closes the loop: each cycle rolls a ticketed PRD up to shipped and dispatches lisa:verify-prd for one shipped PRD (shipped → verified on pass; on fail, re-opened shipped → ticketed with build-ready fix tickets that auto-build and re-verify — never blocked). Designed as the cron target for /schedule — one eligible item per invocation, exits cleanly on empty. Symmetric counterpart to the single-item lisa:plan and lisa:implement skills."
-allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-search", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluenceSpaces", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getJiraIssue"]
----
-
-# Intake: $ARGUMENTS
-
-Run one intake cycle against the queue identified by `$ARGUMENTS`. Scans for `Status = Ready`, claims the first eligible item, dispatches it to the appropriate single-item lifecycle skill, then exits. Remaining Ready items are left for later scheduler invocations.
-
-For build-queue runs, Intake also accepts an optional `assignee=<vendor-user-id-or-login>` filter.
-Resolution order is:
-
-1. `$ARGUMENTS` `assignee=<...>`
-2. `.lisa.config.local.json` `intake.assignee`
-3. empty default
-
-When the resolved assignee is empty, Intake keeps the shared queue behavior and scans any ready
-item. When non-empty, it forwards the filter to the vendor build-intake skill so that only ready
-items already assigned to that assignee are considered. Intake never assigns or reassigns tickets
-as part of this filter.
-
-## Confirmation policy
-
-Do NOT ask the caller whether to proceed. Once invoked with a queue, run the cycle to completion. The caller (a human at the CLI or a scheduled cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
-
-Specifically forbidden:
-
-- Previewing projected scope (number of items, projected ticket counts, write counts) and asking whether to continue.
-- Offering A/B/C-style choices like "proceed / skip / dry-run only" — the documented behavior IS the default. Dry-run is a different skill, not an option here.
-- Pausing because the queue is large, items have many open questions, or items are likely to end in `Blocked`. `Blocked` is a valid terminal state of the downstream lifecycles, not a failure mode — routing items to `Blocked` with clarifying comments is success.
-- Pausing because validation looks expensive. The cost of one cycle is bounded; the cost of stalling a scheduled cron waiting on a human is unbounded.
-
-The only legitimate reasons to stop early:
-
-- Missing required input (no queue argument, missing project configuration). Surface the missing value and exit.
-- The queue itself is misconfigured (Status property missing expected values, JIRA workflow can't reach required transitions). Surface and exit.
-- Empty `Ready` set. Exit cleanly with the idle-case message.
-
-## Orchestration: agent team
-
-If you are NOT already operating inside an agent team (no prior successful team-creation or subagent-delegation tool call in this session, not spawned into a team context), the very first thing you do is establish team orchestration.
-
-Use the team tool for the current runtime:
-
-- Claude: use `TeamCreate`. If `TeamCreate` has not been loaded yet, first use `ToolSearch` with `query: "select:TeamCreate"` to load its schema.
-- Codex: do not call `TeamCreate`; Codex does not expose that Claude tool. Use `tool_search` with a query like `multi-agent tools` to load `multi_agent_v1`, then use `multi_agent_v1.spawn_agent` for teammate delegation. Treat the first successful `spawn_agent` call as establishing team orchestration.
-- Other runtimes: use the current runtime's tool-discovery mechanism to discover and call the appropriate multi-agent/team tool.
-
-If no team creation or subagent delegation tool is available, explicitly state that team orchestration is unavailable in this runtime, continue as the lead agent, and preserve the workflow's review, verification, and task-tracking obligations locally.
-
-Until the team is established, the first Codex teammate has been spawned, or the no-team fallback has been declared, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Scanning the queue, claiming items, dispatching per-item flows — all of those are tasks for the team you are about to create, not for the lead session before orchestration exists.
-
-If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT create a second team — many harnesses reject double-creates — and do NOT collapse the nested flow into a single inline worker. A nested team-first flow must still bring in the specialists it requires by adding them to the existing team, not by doing the work itself:
-
-- **Claude:** teams are flat and only the lead can add named teammates, so do NOT call `Agent` with a `name` from a teammate (the harness rejects it: *"Teammates cannot spawn other teammates — the team roster is flat"*). Send the team lead a message naming the specialist teammate(s) this flow needs, their task assignments, and completion criteria, then coordinate through the shared task list until they finish. An anonymous subagent (`Agent` with `name` omitted) is permitted only for bounded one-shot work whose result returns directly to you — it is not a substitute for the required lifecycle specialists.
-- **Codex:** do NOT call `TeamCreate`. If the lead/root agent is addressable (you were given its id/handle), send it a request to `multi_agent_v1.spawn_agent` the specialist agent(s), including each agent's prompt, ownership, and expected result. If no lead handle exists but `spawn_agent` is available to you, spawn only the bounded specialist agent(s) this flow needs, `wait_agent` for their results, and relay those results upward to the parent/lead.
-
-Treat the first successful lead-spawn request (or, on the Codex fallback, the first specialist spawn) as preserving team orchestration. Never satisfy a team-first lifecycle flow by doing all the work inline.
-
-The cycle's outer team is created by Intake. The one item it processes (a PRD via `lisa:plan`, a ticket via `lisa:implement`) executes within that team — those skills' orchestration preambles detect the existing team and skip creating a second team. One team per cron cycle, one eligible Ready item per cycle.
-
-## Source dispatch
-
-Detect the queue type from `$ARGUMENTS` and route:
-
-| If `$ARGUMENTS` is... | Queue type | Per-item dispatch |
-|------------------------|------------|---------------------|
-| A Notion **database** URL or database ID | PRD queue (Notion) | Invoke `lisa:notion-prd-intake` (which scans the DB for Status=Ready, claims the first eligible PRD, runs `lisa:plan` via the dry-run validate → branch → write pipeline, then exits) |
-| A Confluence **space** URL or space key (e.g. `https://acme.atlassian.net/wiki/spaces/PRD` or `PRD`) | PRD queue (Confluence) | Invoke `lisa:confluence-prd-intake` (which CQL-queries the space for `label = "prd-ready"`, claims the first eligible PRD by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline, then exits) |
-| A Confluence **parent page** URL or page ID (the page whose descendants are PRDs) | PRD queue (Confluence, narrowed) | Invoke `lisa:confluence-prd-intake` with the parent ID (CQL: `ancestor = <id> AND label = "prd-ready"`) |
-| A Linear **workspace** URL (e.g. `https://linear.app/acme`) | PRD queue (Linear) | Invoke `lisa:linear-prd-intake` (which queries `list_projects({label: "prd-ready"})` across the workspace, claims the first eligible project by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline, then exits) |
-| A Linear **team** URL (e.g. `https://linear.app/acme/team/ENG/projects`) or a token already routed as a Linear team key | PRD queue (Linear, narrowed) | Invoke `lisa:linear-prd-intake` with the team key (`list_projects({team, label: "prd-ready"})`) |
-| The literal token `linear` | PRD queue (Linear, default workspace) | Invoke `lisa:linear-prd-intake linear` — only valid if `linear.workspace` is configured in `.lisa.config.json` |
-| A JIRA project key (e.g. `SE`) | Work queue (JIRA) | Invoke `lisa:jira-build-intake` (which scans the project for Status=Ready, claims the first eligible ticket via In Progress, runs `lisa:implement`, transitions to On Dev on success, then exits) |
-| A full JQL filter (e.g. `project = SE AND component = "frontend"`) | Work queue (JIRA, narrowed) | Invoke `lisa:jira-build-intake` with the JQL |
-| A GitHub **repository** URL or `org/repo` token (e.g. `https://github.com/acme/product-prds` or `acme/product-prds`) when used for **PRDs** | PRD queue (GitHub) | Invoke `lisa:github-prd-intake` (which queries `gh issue list --label prd-ready`, claims the first eligible PRD by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline, then exits). PRD discovery is independent of the destination tracker — the resulting tickets land wherever `.lisa.config.json` `tracker` says. |
-| A GitHub **repository** URL or `org/repo` token when `tracker = github` is configured (build-queue mode) | Work queue (GitHub) | Invoke `lisa:tracker-build-intake` which dispatches to `lisa:github-build-intake` (which queries `gh issue list --label status:ready`, optionally narrows by the resolved assignee filter, claims the first eligible issue via `status:in-progress`, runs `lisa:implement`, relabels to `status:on-dev` on success, then exits). |
-| The literal token `github` | Defaults to `.lisa.config.json` `github.org` / `github.repo`. Routes by **the `intake_mode` flag** in `$ARGUMENTS` (`prd` or `build`); if the flag is absent, prefer the PRD queue when both label namespaces are present, otherwise pick whichever exists. | Invoke the matching skill (`lisa:github-prd-intake` or `lisa:tracker-build-intake`). |
-
-Disambiguation rules:
-
-- A `notion.so` / `notion.site` URL → Notion queue.
-- An Atlassian Confluence URL containing `/wiki/spaces/<KEY>` with no `/pages/...` segment → Confluence space queue.
-- An Atlassian Confluence URL containing `/wiki/spaces/<KEY>/pages/<ID>/...` → Confluence parent-page queue (the page is the parent whose descendants are PRDs). If the user actually meant "this single page is a PRD, plan it", route to `lisa:plan` instead — this skill is batch-only.
-- A `linear.app` URL → Linear queue. If the path is `/<workspace>` only or `/<workspace>/team/<KEY>/...`, route here. If the path includes `/project/<slug>-<id>` it's a single-PRD URL — direct the caller to `lisa:plan` instead, this skill is batch-only.
-- The literal token `linear` (case-insensitive) → Linear queue, default workspace from `linear.workspace` in `.lisa.config.json`.
-- A `github.com` URL or an `<org>/<repo>` token → GitHub queue. The PRD-vs-build dispatch is determined by which label namespace the repo currently uses: PRD-side (`prd-ready`) → `lisa:github-prd-intake`; build-side (`status:ready` and `tracker = github` in `.lisa.config.json`) → `lisa:tracker-build-intake`. If both namespaces are present, prefer the PRD queue unless `$ARGUMENTS` includes `intake_mode=build`. If the URL points at a single issue (`https://github.com/<org>/<repo>/issues/<n>`), this skill is batch-only — direct the caller to `lisa:plan` (for a single PRD issue) or `lisa:implement` (for a single build issue).
-- The literal token `github` (case-insensitive) → GitHub queue, default repo from `.lisa.config.json` `github.org` / `github.repo`.
-- A bare alphanumeric token that matches the JIRA project key regex (uppercase letters / digits / hyphen, ≤10 chars — typically the value of `jira.project` in `.lisa.config.json`) is treated as a JIRA project key by default. A token that does not match the regex is treated as a Confluence space key. If it does not resolve as a Confluence space key either, attempt to resolve as a Linear team key via `lisa:linear-access operation: list-teams({query})` before giving up. The only time to stop and ask is when the token resolves to more than one of {JIRA project, Confluence space, Linear team, GitHub `org/repo`} simultaneously — in that overlap the user must disambiguate which queue to scan.
-- An `<org>/<repo>` token (slash-separated, both halves are GitHub-name-shaped) → GitHub queue.
-- A string starting with `project = ` or containing JQL operators (`AND`, `OR`, `=`, `!=`, `~`, etc.) → JQL filter.
-
-The single-item skills (`lisa:plan`, `lisa:implement`) and the per-vendor batch skills (`lisa:notion-prd-intake`, `lisa:confluence-prd-intake`, `lisa:linear-prd-intake`, `lisa:github-prd-intake`, `lisa:jira-build-intake`, `lisa:github-build-intake`) are internal — Intake is the public entry point. Developers schedule `/lisa:intake <queue>`; the rest is composition.
-
-## Cycle behavior
-
-1. **Resolve the queue** — fetch the database/project metadata, confirm the Status property/workflow has the expected `Ready` value.
-2. **Pre-flight check** — for JIRA, confirm `In Progress` and `On Dev` are reachable transitions before doing any per-ticket work. Stop with a clear error if the workflow is misconfigured.
-3. **Find Ready items** — query the queue. Empty → exit cleanly with `"No items with Status=Ready. Nothing to do."` This is the common idle case for a scheduled run.
-4. **Process the first eligible Ready item only** (claim-first ordering for idempotency):
-   - Notion PRDs → `lisa:notion-prd-intake` handles per-item: claim (Status=In Review), dry-run validate, branch to Blocked or Ticketed, coverage audit
-   - Confluence PRDs → `lisa:confluence-prd-intake` handles per-item: claim (relabel to `prd-in-review`), dry-run validate, branch to `prd-blocked` or `prd-ticketed`, coverage audit
-   - Linear PRDs → `lisa:linear-prd-intake` handles per-item: claim (relabel project to `prd-in-review`), dry-run validate, branch to `prd-blocked` or `prd-ticketed` (with a sentinel feedback issue under each project hosting clarifying-question comments), coverage audit
-   - GitHub PRDs → `lisa:github-prd-intake` handles per-item: claim (relabel issue to `prd-in-review`), dry-run validate, branch to `prd-blocked` or `prd-ticketed` (with clarifying-question comments posted directly on the PRD issue), coverage audit
-   - JIRA tickets → `lisa:jira-build-intake` handles per-item: claim, dispatch to `lisa:jira-agent`, transition to On Dev on success
-   - GitHub build issues (when `tracker = github`) → `lisa:tracker-build-intake` → `lisa:github-build-intake` handles per-item: optional ready-queue assignee filtering, claim (relabel to `status:in-progress`), dispatch to `lisa:github-agent`, relabel to `status:on-dev` on success
-   - Duplicate-already-fixed build tickets are the one build-intake closeout exception: when `ticket-triage` returns `DUPLICATE_ALREADY_FIXED` with a canonical item and empirical base-branch evidence, the vendor build-intake skill closes the claimed ticket as a duplicate without opening a PR. This does not apply to `BLOCKED`, ambiguous, duplicate-of-open, or otherwise human-owned terminal dispositions.
-   - **Closing the PRD loop:** beyond claiming one Ready PRD, every PRD scanner also runs the closure rollup (`ticketed → shipped`, Phase 3f) and **dispatches `lisa:verify-prd` for one shipped PRD** (Phase 3g) each cycle — so a shipped PRD does not sit unverified. On pass the PRD goes `shipped → verified`; on fail it is re-opened `shipped → ticketed` with **build-ready fix tickets** that auto-build and trigger a re-verify (never `blocked`). The scanner only dispatches; `lisa:verify-prd` owns the transition (per the `prd-lifecycle-rollup` rule's "Closing the loop" section), and the self-healing loop continues until the PRD verifies.
-5. **Stop after one item** — a claimed Ready item, a safe-blocked container, or a per-item error ends the *ready-claim* portion of the cycle. The per-vendor PRD scanner still runs its rollup and one verify-prd dispatch. Remaining Ready items stay untouched for later scheduler invocations.
-6. **Summary report** — the single processed/skipped/error item, total processed, total errors. Before returning, record intake usage on the persisted cycle-summary artifact via `lisa:usage-accounting` so the summary carries a direct `intake` entry in the canonical `## Lisa Usage` section. If the claimed / skipped work item's parent-child graph is already known, prefer `record_and_rollup` so ancestor totals refresh in the same cycle; otherwise still write the direct entry, and if runtime usage is unavailable, use `source: unavailable` with nullable token/cost fields instead of skipping the row.
-
-## Schedule examples
-
-```text
-/schedule "every 30 minutes" /lisa:intake https://www.notion.so/<workspace>/<database-id>
-/schedule "every 30 minutes" /lisa:intake https://acme.atlassian.net/wiki/spaces/PRD
-/schedule "every 30 minutes" /lisa:intake https://linear.app/acme
-/schedule "every 30 minutes" /lisa:intake https://linear.app/acme/team/ENG/projects
-/schedule "every 30 minutes" /lisa:intake https://github.com/acme/product-prds
-/schedule "every 30 minutes" /lisa:intake acme/product-prds
-/schedule "every 30 minutes" /lisa:intake SE
-/schedule "every 30 minutes" /lisa:intake acme/frontend-v2 intake_mode=build
-/schedule "every 30 minutes" /lisa:intake acme/frontend-v2 intake_mode=build assignee=codyswanngt
-/schedule "every hour" /lisa:intake "project = SE AND component = 'frontend'"
-```
-
-## Rules
-
-- Never run a cycle without an explicit queue. Side effects too high to default.
-- Never modify the source/destination lifecycles directly — Intake delegates per-item to the vendor adapter, which owns status transitions.
-- Never run two Intake cycles concurrently against overlapping queues — concurrent claims could race. The scheduling layer is responsible for serialization.
-- Stop and surface failures rather than retry-loop.

package/plugins/lisa/skills/intake/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Intake"
-short_description: "Vendor-agnostic scanner for Ready queues"
-default_prompt:
-  - "Use $intake: Vendor-agnostic scanner for Ready queues."

package/plugins/lisa/skills/intake-explain/SKILL.md

@@ -1,279 +0,0 @@
----
-name: intake-explain
-description: "Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts. Resolves the item's queue family, lifecycle role, ownership boundary, and gate outcomes using the same source/tracker detection, lifecycle naming, leaf-only, dependency, staleness, and backoff semantics the write-side intake and repair flows already enforce."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Intake Explain: $ARGUMENTS
-
-`/lisa:intake-explain` is the operator-facing explanation surface for one specific item in the **current repo or project**. It answers the per-item diagnosis question Lisa's batch flows intentionally do not answer directly: what lifecycle lane the item belongs to, which Lisa rule or gate applies right now, whether the item is eligible for intake or repair, and what the next relevant action should be.
-
-This command is **read-only** in v1. It does not claim, relabel, repair, transition, comment on, decompose, or otherwise mutate the item. It complements `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, `/lisa:automation-status`, and tracker-native inspection; it does not replace them.
-
-## Confirmation policy
-
-Do **not** ask for confirmation once invoked. This skill inspects one item and reports what the current Lisa contract says about it. There are no write-side effects in the v1 surface.
-
-## Scope
-
-Inspect exactly one repo-scoped item reference:
-
-- a GitHub issue URL or `owner/repo#123` ref
-- a Linear issue or project URL
-- a JIRA issue key
-- a Notion PRD/item URL
-- a Confluence PRD page URL
-
-The skill must determine whether the item belongs to the PRD lifecycle or the build lifecycle, then explain the item's status using the **same contract** Lisa already uses for `/lisa:intake` and `/lisa:repair-intake`. Do **not** invent a second source of truth for queue detection, lifecycle role naming, repo scoping, or repair eligibility.
-
-## Operator usage
-
-Typical entrypoints:
-
-```text
-/lisa:intake-explain https://github.com/acme/repo/issues/123
-/lisa:intake-explain owner/repo#123
-/lisa:intake-explain ENG-123
-/lisa:intake-explain https://linear.app/acme/issue/ENG-123/example
-```
-
-Use this command when an operator needs one deterministic answer to questions like:
-
-- "Would Lisa intake this item right now, or skip it?"
-- "Is this state still product-owned, or has it crossed into a Lisa-owned lane?"
-- "Is repair eligible yet, or am I still waiting on staleness or backoff?"
-- "Is the real next step `/lisa:intake`, `/lisa:repair-intake`, blocker cleanup, decomposition, or manual product clarification?"
-
-Keep the diagnosis terminal-first and human-readable: observable item facts first, then the smallest useful next command or manual action.
-
-## Contract reuse
-
-Resolve item family, queue source/tracker, and lifecycle role names from `.lisa.config.json` plus the same defaults the active intake and repair flows already consume.
-
-Route one-item diagnosis through the same contract surfaces the write-side flows already trust:
-
-- determine whether the item belongs to the configured PRD **source** lane or build **tracker** lane using the same `source` / `tracker` settings that `/lisa:intake` and `/lisa:repair-intake` already resolve
-- read vendor lifecycle role names from the same config keys and fallback defaults documented in the `config-resolution` rule rather than inventing hardcoded status names
-- keep repo/project scoping aligned with the same current-repo detection and queue-target rules the active intake scanners use
-
-When the runtime can identify the item but cannot confidently resolve its source lane, tracker lane, lifecycle namespace, or current repo/project scope from that contract, report `MISCONFIGURED` instead of guessing.
-
-Reuse the existing execution-side semantics instead of recreating them by hand:
-
-- queue/source detection and lifecycle naming from intake + repair-intake
-- one-item routing helpers for resolving the item's queue family against the correct source/tracker contract
-- product-owned versus Lisa-owned lifecycle roles
-- leaf-only and repo-scope build eligibility
-- active dependency holds
-- repair staleness thresholds and activity signals
-- repair backoff / loop-prevention suppression
-
-Work from the same vendor families Lisa already supports for intake and repair: GitHub, Linear, JIRA, Notion, and Confluence.
-
-## What to report
-
-Render a stable terminal-first diagnosis for one item:
-
-1. Item identity and resolved lifecycle family (`PRD` or `BUILD`).
-2. The current lifecycle role and whether that role is product-owned or Lisa-owned.
-3. The exact rule, gate, or ownership boundary currently driving behavior.
-4. A verdict such as `ELIGIBLE_FOR_INTAKE`, `ELIGIBLE_FOR_REPAIR`, `WAITING_ON_STALENESS`, `HELD_BY_BLOCKERS`, `NON_LEAF_CONTAINER`, `PRODUCT_OWNED_STATE`, or `MISCONFIGURED`.
-5. The smallest useful next action, such as `/lisa:intake`, `/lisa:repair-intake`, decomposition, blocker resolution, or manual product clarification.
-
-Keep observable item facts separate from the recommended next step so operators can tell what Lisa knows versus what Lisa suggests.
-
-## Verdicts and next actions
-
-Use verdicts as stable operator language, not as an excuse to dump raw tracker state:
-
-- `ELIGIBLE_FOR_INTAKE`: the item is in the correct actionable lane and Lisa could pick it up with `/lisa:intake`.
-- `ELIGIBLE_FOR_REPAIR`: the item is Lisa-owned, stale or stuck enough to qualify for `/lisa:repair-intake`, and repair suppression rules are not currently preventing action.
-- `WAITING_ON_STALENESS`: the item is Lisa-owned but too fresh to repair yet; explain which activity signal or freshness window is still protecting it from a repair loop.
-- `HELD_BY_BLOCKERS`: the item is otherwise actionable, but explicit blockers or dependency holds mean Lisa would wait rather than claim it.
-- `NON_LEAF_CONTAINER`: the item is structurally a container, childless Epic, or otherwise not directly buildable; explain that direct build pickup is disallowed until decomposition or reclassification happens.
-- `PRODUCT_OWNED_STATE`: the item is currently in a product-owned role or pre-intake lane, so Lisa should not mutate it yet.
-- `MISCONFIGURED`: Lisa could not resolve the item's queue, lifecycle namespace, repo scope, or another required contract signal confidently enough to explain actionability.
-
-Each verdict must carry a concrete next action:
-
-- Prefer `/lisa:intake` for `ELIGIBLE_FOR_INTAKE`.
-- Prefer `/lisa:repair-intake` for `ELIGIBLE_FOR_REPAIR`.
-- Prefer "wait and re-check later" for `WAITING_ON_STALENESS`.
-- Prefer blocker resolution for `HELD_BY_BLOCKERS`.
-- Prefer decomposition or type correction for `NON_LEAF_CONTAINER`.
-- Prefer manual product clarification or the upstream product workflow for `PRODUCT_OWNED_STATE`.
-- Prefer fixing config, lifecycle adoption, or repo scoping for `MISCONFIGURED`.
-
-## Ownership and repair readiness
-
-Classify ownership before recommending any command. Intake-explain should make clear whether the item is waiting for a human/product promotion, already belongs to Lisa automation, or is terminal enough that normal intake should leave it alone.
-
-Product-owned roles are roles that Lisa must not mutate from this read-only diagnosis and that normal intake/repair should not "fix" just because the item exists:
-
-- PRD `draft`: still being authored; next action is manual product clarification or promotion to `ready`.
-- PRD `shipped`: generated work is complete and the next automated owner is `/lisa:verify-prd`, not PRD intake or repair.
-- PRD `verified`: empirically checked terminal state; no intake or repair action is required unless a human reopens scope.
-- Build items with no build lifecycle role or without the configured current-repo scope: outside the build pickup lane until a human adopts the lifecycle label or fixes repo scoping.
-
-Lisa-owned roles are roles where the framework has accepted responsibility for moving the item forward or surfacing a precise blocker:
-
-- PRD `ready`: actionable for `/lisa:intake`.
-- PRD `in_review`: already claimed by PRD intake; repairable only when the item is stale beyond `stale_after` and not suppressed by repair backoff.
-- PRD `blocked`: Lisa asked for clarification or failed validation; repairable only when new answers, dependency changes, or other current signals make another validate-to-route pass materially different.
-- PRD `ticketed`: generated work exists; normal PRD intake owns rollup toward `shipped`, while repair-intake may reconcile rollup drift when all generated top-level work is terminal.
-- Build `ready`: actionable for `/lisa:intake` if repo-scope, leaf-only, and dependency gates pass.
-- Build `claimed`: already claimed by build intake; repairable only when stale beyond `stale_after` and not protected by recent PR/check/comment activity.
-- Build `blocked`: Lisa surfaced an implementation blocker; repairable only when every parsed blocker is cleared or the blocker fingerprint changed enough to justify a new attempt.
-- Build `done`: terminal build role; repair-intake may only reconcile provider-native close-out drift, not re-run implementation.
-
-Report repair readiness in this order:
-
-1. If the role is product-owned, return `PRODUCT_OWNED_STATE` and name the product or verification workflow that owns the next move.
-2. If the item is Lisa-owned but in an in-progress role, compare the newest activity signal with the configured staleness threshold. Fresh activity returns `WAITING_ON_STALENESS`; stale activity can return `ELIGIBLE_FOR_REPAIR`.
-3. If the item is Lisa-owned but blocked, evaluate current blockers, clarifying answers, and the `[lisa-repair-intake]` fingerprint/backoff window. Active blockers or unchanged fingerprints stay held; cleared blockers or new answers can return `ELIGIBLE_FOR_REPAIR`.
-4. If the item is ready for first pickup, run the same repo-scope, leaf-only, and dependency checks used by intake before returning `ELIGIBLE_FOR_INTAKE`.
-
-## Gate and ownership expectations
-
-The explanation must stay aligned with existing Lisa rules:
-
-- If a build item is a parent/container or a childless Epic, explain the leaf-only gate and say direct build pickup is not allowed.
-- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
-- If a PRD is in a product-owned role such as `draft`, `shipped`, or `verified`, explain why intake or repair will not mutate it.
-- If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
-- If the source lane, tracker lane, repo/project scope, or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
-
-## PRD item role and repair diagnosis
-
-For PRD lifecycle items, run the same read-side checks that PRD intake and repair-intake use before they would claim, validate, roll up, or retry a PRD. This is still a read-only explanation: if execution intake would transition `ready -> in_review`, route a `ticketed` PRD through rollup, move a `blocked` PRD after new answers, or suppress repair because a `[lisa-repair-intake]` marker is still inside its backoff window, intake-explain reports that decision and does not mutate the PRD, comments, labels, parent page, project labels, or generated work.
-
-Resolve the source lane from `.lisa.config.json` `source` and the PRD lifecycle roles from the same vendor-specific config keys PRD intake and repair-intake use (`github.labels.prd.*`, `linear.labels.prd.*`, `notion.values.*`, or `confluence.parents.*`) with the usual defaults (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`, and `verified` equivalents). If the current item carries conflicting PRD lifecycle roles, lacks an adopted PRD namespace, or cannot be tied to the configured source lane, return `MISCONFIGURED` rather than guessing.
-
-For GitHub-backed PRDs, collect these reader signals before choosing a verdict:
-
-- current PRD lifecycle role label and any conflicting `prd-*` labels
-- source-lane role ownership: `draft`, `shipped`, and `verified` are product-owned or verification-owned; `ready`, `in_review`, `blocked`, and `ticketed` are Lisa-owned for intake, repair, or rollup purposes
-- provider-native timestamps (`updatedAt`) plus latest PRD comments, with special attention to comments after the most recent blocked or in-review marker
-- `[lisa-repair-intake]` marker comments, including state fingerprint, repair verdict, retry count, and backoff window when present
-- generated top-level work from native sub-issues first, then the `## Tickets` / `## Generated Work` section used by `prd-lifecycle-rollup`
-- generated child terminal status so `ticketed` PRDs can explain whether rollup is waiting on downstream work or ready for `/lisa:repair-intake`
-- clarifying-answer signals on `blocked` PRDs: new product comments, changed body text, changed blocker refs, or cleared dependencies compared with the last blocked/repair fingerprint
-
-Apply PRD verdicts in the same order as PRD intake and repair-intake:
-
-1. **Product-owned or verification-owned roles.** A PRD in `draft` returns `PRODUCT_OWNED_STATE`; the next action is manual product clarification or promotion to the configured `ready` role. A PRD in `shipped` returns `PRODUCT_OWNED_STATE` with `/lisa:verify-prd <item-ref>` as the next Lisa workflow because shipped-to-verified acceptance is outside PRD intake. A PRD in `verified` returns `PRODUCT_OWNED_STATE` or a terminal no-op explanation; normal intake and repair must not mutate it.
-2. **Ready PRD.** A PRD in the configured `ready` role returns `ELIGIBLE_FOR_INTAKE` when the source lane and lifecycle namespace resolve cleanly. The `Why:` line should say PRD intake would claim it into the configured `in_review` role and run the source-to-tracker dry-run validate-to-route pipeline.
-3. **In-review PRD.** A PRD in `in_review` is already Lisa-owned. Compare the newest activity signal against the resolved repair `stale_after` threshold (`$ARGUMENTS` override if present, `.lisa.config.json` `intake.repair.staleAfterHours`, then the 2h default). If provider activity, a progress comment, or a source edit is newer than `now - stale_after`, return `WAITING_ON_STALENESS` and name the activity timestamp. If no reliable timestamp exists, return `WAITING_ON_STALENESS` unless the caller explicitly uses the repair flow with `stale_after=0`; intake-explain should not imply automatic recovery from unknown freshness. If the item is stale and no repair-backoff marker suppresses retry, return `ELIGIBLE_FOR_REPAIR`.
-4. **Blocked PRD.** A PRD in `blocked` is Lisa-owned but repairable only when the next validate-to-route pass can materially differ. Treat new human answers after the blocking comment, body edits after the blocking marker, cleared blockers, changed blocker refs, or changed validator fingerprint as repair-enabling signals. If none are present, return `HELD_BY_BLOCKERS` or `WAITING_ON_STALENESS` depending on whether the decisive fact is an active blocker/unchanged clarification need or a still-fresh blocked marker. If the blocker/answer state changed and repair backoff is clear, return `ELIGIBLE_FOR_REPAIR`.
-5. **Ticketed PRD.** A PRD in `ticketed` is not ready for first intake. Read generated top-level work using the same `prd-lifecycle-rollup` boundary as PRD intake: top-level Epics and top-level Stories count; nested Stories and Sub-tasks do not. If any generated top-level child is non-terminal, return `PRODUCT_OWNED_STATE` or a waiting explanation that downstream build work is still in progress. If all generated top-level work is terminal but the PRD has not rolled up to `shipped`, return `ELIGIBLE_FOR_REPAIR` and recommend `/lisa:repair-intake <queue>` to reconcile rollup drift.
-6. **Repair backoff suppression.** Before returning `ELIGIBLE_FOR_REPAIR` for `in_review`, `blocked`, or `ticketed` PRDs, inspect `[lisa-repair-intake]` markers. If the latest marker's state fingerprint matches the current reader signals and its backoff window has not expired, return `WAITING_ON_STALENESS` with a `Why:` line that says repair-intake would suppress an unchanged retry to avoid a loop. If the fingerprint changed, the backoff expired, or a human uses repair-intake `force=true`, the item may be repair-eligible.
-
-Relevant `Signals:` should include the decisive context, not every field: for example `prd-blocked; new product comment after blocker`, `prd-in-review; last activity 2h ago; stale_after=2h`, `prd-ticketed; generated top-level work #12/#13 terminal`, or `[lisa-repair-intake] fingerprint unchanged; backoff until 2026-05-27T12:00:00Z`.
-
-## Build item gate diagnosis
-
-For build lifecycle items, run the same read-side checks that build intake runs before it would claim an issue. This is still a read-only explanation: if execution intake would stamp repo labels, split a cross-repo leaf, move a stale container from `ready` to `claimed`, or post a dependency-hold comment, intake-explain reports what intake would do but does not stamp, does not split, does not move labels, and does not comment.
-
-Resolve the current repo using the same repo-scope contract as build intake: local config `repo`, then `.lisa.config.json` `github.repo`, then the git remote basename. Resolve the build lifecycle roles from `.lisa.config.json` `github.labels.build.*` with the usual defaults (`status:ready`, `status:in-progress`, `status:blocked`, `status:done`, plus any configured env-specific done labels). If those signals cannot be resolved, return `MISCONFIGURED`.
-
-For GitHub build items, collect these reader signals before choosing a verdict:
-
-- current build lifecycle role label and any conflicting `status:*` labels
-- `repo:<current>` / `repo:<other>` labels, including whether the item is unlabeled for repo scope
-- type labels such as `type:Epic`, `type:Story`, `type:Spike`, `type:Bug`, `type:Task`, `type:Sub-task`, and `type:Improvement`
-- native GitHub sub-issues and their open/closed state
-- body parentage used by `github-read-issue`, including task-list child references and `Parent: #123` style references
-- explicit dependency holds from `Blocked by: #123`, comma-separated refs, `owner/repo#123`, and GitHub issue URLs
-- blocker issue state and blocker status labels
-
-Apply gate verdicts in the same order as build intake:
-
-1. **Repo-scope gate.** A build item carrying `repo:<other>` and not `repo:<current>` is outside this repo's pickup lane. Return `MISCONFIGURED` when repo scope is absent or contradictory enough that the current repo cannot be determined confidently; otherwise explain the repo-scope mismatch and recommend running intake in the target repo or fixing the `repo:<name>` label. For an unlabeled item whose target repo is obvious from the item body, report the inferred repo signal but stay read-only: execution intake would stamp `repo:<name>`, while intake-explain only says it would do so. A multi-repo leaf is not directly buildable; explain that execution intake would split it per `repo-scope-split`, but this read-only diagnosis does not split.
-2. **Leaf-only gate.** If the item has open child work from native GitHub sub-issues or body parentage, return `NON_LEAF_CONTAINER` and explain that direct build pickup is leaf-only per `leaf-only-lifecycle`. If it has no open children but carries `type:Epic`, also return `NON_LEAF_CONTAINER` because a childless Epic is a pure rollup container that still needs decomposition or reclassification. (A childless `type:Story` or `type:Spike` is a valid leaf per `leaf-only-lifecycle` and is NOT a `NON_LEAF_CONTAINER` — it is directly buildable.) The next action for a childless Epic is decomposition, moving `status:ready` to leaf children, or correcting the issue type. Execution build intake would move such a stale ready container out of the pickup queue; this read-only diagnosis must not perform that repair.
-3. **Dependency hold gate.** If a single-repo leaf for the current repo has explicit blockers, read each blocker. Closed blockers are clear. Open blockers are clear only when they carry a cleared build status such as `status:code-review`, `status:on-dev`, `status:on-stg`, `status:done`, or the configured done-equivalent labels. Open blockers with `status:ready`, `status:in-progress`, no cleared status label, or inaccessible state are active. Return `HELD_BY_BLOCKERS`, list the active blocker refs, and make the next action blocker resolution rather than `/lisa:intake`.
-4. **Ready leaf.** A build item in the configured ready role, scoped to the current repo, with no open child work and no active blockers returns `ELIGIBLE_FOR_INTAKE`. The `Why:` line should say it is a single-repo leaf for the current repo and that leaf-only, repo-scope, and dependency gates all pass.
-
-Relevant `Signals:` should include the decisive context, not every field: for example `repo:lisa; type:Sub-task; no open children`, `open children #12/#13`, `repo:api but current repo is web`, or `active blockers CodySwannGT/lisa#123`.
-
-## Rule explanation expectations
-
-The `Why:` line should name the decisive Lisa contract in plain English rather than only echoing a raw status label. Good explanations usually mention one of:
-
-- the lifecycle role boundary (`product-owned` versus `Lisa-owned`)
-- the leaf-only gate
-- the repo-scope gate
-- an active blocker or dependency hold
-- staleness or repair-backoff suppression
-- an unresolved config or lifecycle-adoption contract
-
-The `Next action:` line should stay small and specific. Prefer one actionable follow-up over a menu:
-
-- `/lisa:intake <queue>` when the item is ready for normal pickup
-- `/lisa:repair-intake <queue>` when Lisa-owned stuck work is now repairable
-- "resolve blocker `#123`" when a dependency hold is decisive
-- "decompose into leaf tickets" when the issue is a non-leaf container
-- "manual product clarification" when Lisa is not the current owner
-- "fix `.lisa.config.json` or lifecycle labels" when the problem is misconfiguration
-
-## Smoke fixtures and read-only assertions
-
-Intake-explain must keep representative smoke fixtures for both PRD and build lifecycles. These fixtures are contract examples for implementers and tests: they prove that lifecycle classification, dependency holds, staleness windows, and repair backoff map to the same verdict language operators see in real diagnosis output.
-
-Minimum PRD smoke fixtures:
-
-| Fixture | Decisive signals | Expected verdict |
-|---|---|---|
-| `prd-draft-product-owned` | PRD role `draft`; source lane resolved; no Lisa claim marker | `PRODUCT_OWNED_STATE` |
-| `prd-ready-actionable` | PRD role `ready`; source lane resolved; validation-ready content present | `ELIGIBLE_FOR_INTAKE` |
-| `prd-in-review-fresh` | PRD role `in_review`; newest Lisa or tracker activity is inside `stale_after` | `WAITING_ON_STALENESS` |
-| `prd-blocked-backoff` | PRD role `blocked`; latest `[lisa-repair-intake]` fingerprint is unchanged and inside the backoff window | `WAITING_ON_STALENESS` |
-| `prd-blocked-new-signal` | PRD role `blocked`; clarifying answer or blocker fingerprint changed after the last repair marker | `ELIGIBLE_FOR_REPAIR` |
-
-Minimum build smoke fixtures:
-
-| Fixture | Decisive signals | Expected verdict |
-|---|---|---|
-| `build-ready-leaf` | `status:ready`; `repo:<current>`; leaf type; no open children; no active blockers | `ELIGIBLE_FOR_INTAKE` |
-| `build-active-dependency` | otherwise actionable ready leaf; `Blocked by:` points at an open blocker without a cleared status | `HELD_BY_BLOCKERS` |
-| `build-cleared-dependency` | otherwise actionable ready leaf; blockers are closed or carry cleared build status | `ELIGIBLE_FOR_INTAKE` |
-| `build-open-children` | build lifecycle role present; native sub-issues or body parentage include open child work | `NON_LEAF_CONTAINER` |
-| `build-claimed-fresh` | `status:in-progress`; newest claim, PR, check, or issue activity is inside `stale_after` | `WAITING_ON_STALENESS` |
-| `build-blocked-backoff` | `status:blocked`; blocker fingerprint unchanged and repair-backoff marker still suppresses retries | `WAITING_ON_STALENESS` |
-| `build-blocked-cleared` | `status:blocked`; parsed blockers are now cleared or the blocker fingerprint changed | `ELIGIBLE_FOR_REPAIR` |
-
-Every smoke fixture must assert read-only behavior. A diagnosis may call vendor read APIs, inspect config, and render a verdict, but it must not call write APIs such as `gh issue edit`, `gh issue comment`, label creation, issue creation, transition endpoints, PR mutation, or tracker comment/update calls. If execution intake would stamp repo labels, split a multi-repo leaf, repair a stale container label, add a dependency-hold comment, or retry stuck work, the smoke fixture should assert that intake-explain only reports that action as the next step.
-
-## Output shape
-
-Use a stable grouped shape so one diagnosis is easy to scan:
-
-```text
-Item: <identity>
-Lifecycle: <PRD|BUILD>
-Role: <current role> (<product-owned|Lisa-owned>)
-Verdict: <VERDICT>
-Why: <rule or gate explanation>
-Next action: <smallest useful follow-up>
-```
-
-When helpful, include one short `Signals:` or `Relevant refs:` line for the exact blockers, staleness timestamps, parent/child classification, or repair markers that justify the verdict.
-
-One acceptable rendering pattern is:
-
-```text
-Item: CodySwannGT/lisa#123
-Lifecycle: BUILD
-Role: status:blocked (Lisa-owned)
-Verdict: ELIGIBLE_FOR_REPAIR
-Why: The issue is already in a Lisa-owned blocked lane, its last meaningful activity is stale, and no repair-backoff marker is suppressing a new repair pass.
-Next action: /lisa:repair-intake github
-Signals: blocker cleared; last activity 6d ago; repo:lisa
-```
-
-## Rules
-
-- Stay **read-only**. Never claim, relabel, transition, comment on, create, decompose, or repair work from this skill.
-- Keep the explanation repo-scoped to the current project rather than aggregating unrelated repos or trackers.
-- Reuse intake and repair-intake contract semantics so diagnosis and execution do not drift.
-- Prefer existing vendor read surfaces and validators over creating a second lifecycle engine.
-- If the current runtime or vendor surface cannot expose a needed signal, say that explicitly instead of guessing.

package/plugins/lisa/skills/intake-explain/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Intake Explain"
-short_description: "Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts"
-default_prompt:
-  - "Use $intake-explain: Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts."

package/plugins/lisa/skills/jam-access/SKILL.md

@@ -1,52 +0,0 @@
----
-name: jam-access
-description: "Vendor-neutral access layer for Jam. Jam triage rules and skills MUST delegate through this skill rather than calling Jam MCP tools directly. Resolves Jam MCP first when available, then falls back to the JAM_PAT-authenticated Jam CLI for headless routines."
-allowed-tools: ["Bash", "Read", "Skill"]
----
-
-# Jam Access: $ARGUMENTS
-
-Single chokepoint for Jam operations. Caller skills and rules MUST NOT call
-`mcp__Jam__*` tools directly.
-
-## Invocation Contract
-
-```text
-operation: get-trace url:<jam-url-or-id>
-operation: get-recording url:<jam-url-or-id>
-operation: get-bug-report url:<jam-url-or-id>
-```
-
-Return parsed JSON or a concise structured summary in a `<result>` block.
-
-## Substrate Selection
-
-Probe in order:
-
-1. Jam MCP, if the tool is available and authenticated.
-2. Jam CLI authenticated with `JAM_PAT`.
-
-Jam documents a PAT-authenticated CLI that is cleaner for remote routines than
-editing `.mcp.json` headers. The headless tier uses:
-
-```bash
-curl -fsSL https://native.jam.dev/install | bash
-export PATH="$HOME/.local/bin:$PATH"
-printf '%s' "$JAM_PAT" | jam auth login --token
-jam skills install
-```
-
-If neither tier works, fail with:
-
-```text
-Error: no Jam access substrate available. Authenticate the Jam MCP or set JAM_PAT.
-```
-
-## Invariants
-
-- Fallback is gated on `JAM_PAT`; do not retry Jam MCP failures blindly.
-- Never commit a Jam PAT into `.mcp.json` or any generated setup artifact.
-- Headless Jam access requires `native.jam.dev` for the installer and
-  `api.jam.dev` for CLI/API calls in any custom remote network allowlist.
-- If a requested operation is not yet mapped to the Jam CLI substrate, surface
-  that exact missing adapter instead of pretending the trace is unavailable.

package/plugins/lisa/skills/jam-access/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Jam Access"
-short_description: "Vendor-neutral access layer for Jam"
-default_prompt:
-  - "Use $jam-access: Vendor-neutral access layer for Jam."

package/plugins/lisa/skills/jira-add-journey/SKILL.md

@@ -1,121 +0,0 @@
----
-name: jira-add-journey
-description: "Add a Validation Journey section to an existing JIRA ticket by analyzing the change type and generating appropriate verification steps with evidence markers."
----
-
-# Add Validation Journey to Existing JIRA Ticket
-
-Read an existing JIRA ticket, analyze the change type, and generate a Validation Journey section with appropriate verification steps based on the project's verification patterns.
-
-## Arguments
-
-`$ARGUMENTS`: `<TICKET_ID>`
-
-- `TICKET_ID` (required): JIRA ticket key (e.g., `PROJ-123`)
-
-## Prerequisites
-
-- `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`)
-
-## Workflow
-
-### Step 1: Read the Ticket
-
-Use the Atlassian MCP or jira-cli to read the full ticket details:
-
-```bash
-jira issue view <TICKET_ID>
-```
-
-Extract: title, description, acceptance criteria, components, labels, linked tickets.
-
-### Step 2: Check for Existing Journey
-
-Run the parser to see if a Validation Journey already exists:
-
-```bash
-python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID> 2>&1
-```
-
-If the parser succeeds and returns steps, the ticket already has a journey. Report this to the user and stop.
-
-### Step 3: Analyze the Change Type
-
-Examine the ticket description, acceptance criteria, and codebase to determine the change type:
-
-1. **API/GraphQL changes** — New or modified endpoints, request/response schemas
-2. **Database migration** — Schema changes, new tables/columns, indexes
-3. **Background job/queue** — New job processors, queue consumers, event handlers
-4. **Library/utility** — Exported functions, shared modules, npm package changes
-5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
-6. **Authentication/authorization** — Role-based access, session management, tokens
-
-Use the Explore agent or read the codebase directly to understand which files are affected and what verification approach is appropriate.
-
-### Step 4: Map Change Type to Verification Pattern
-
-Based on the change type, generate verification steps using patterns from `verfication.md`:
-
-| Change Type | Verification Approach |
-|---|---|
-| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
-| Database migration | Migration execution + schema verification + rollback check |
-| Background job/queue | Enqueue + process + state change verification |
-| Library/utility | Test execution + build verification + export check |
-| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
-| Auth/authz | Multi-role verification with explicit status codes |
-
-### Step 5: Draft the Validation Journey
-
-Compose the journey with `[EVIDENCE: name]` markers at key verification points:
-
-```text
-h2. Validation Journey
-
-h3. Prerequisites
-- List required services, database, env vars
-
-h3. Steps
-1. Verify current state before changes
-2. Apply the change
-3. Verify expected new state [EVIDENCE: state-name]
-4. Test error/edge cases [EVIDENCE: error-case]
-5. Verify rollback if applicable [EVIDENCE: rollback]
-
-h3. Assertions
-- Describe what must be true after verification
-```
-
-### Guidelines for Drafting
-
-1. **2-5 evidence markers** — Focus on proving the change works and handles errors
-2. **Concrete, runnable steps** — "Run `curl -s localhost:3000/health | jq .status`" not "Check the endpoint"
-3. **Include environment setup** — Database connection, running services, env vars
-4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`
-5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
-6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
-7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the ticket's evidence manifest: validation gate S14 requires at least one, and the ticket cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
-
-### Step 6: Present to User for Approval
-
-Display the drafted Validation Journey to the user and ask for confirmation before appending it to the ticket.
-
-### Step 7: Append to Ticket Description
-
-After user approval, use the JIRA REST API to append the Validation Journey to the existing ticket description.
-
-### Step 8: Verify
-
-Run the parser again to confirm the journey was added correctly:
-
-```bash
-python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
-```
-
-## When to Use This Skill
-
-- Ticket was created before the Validation Journey convention was established
-- Ticket was created manually without following `lisa:jira-create` guidelines
-- Ticket needs a journey added or updated based on implementation progress
-- Before starting work on a ticket, to ensure verification steps are documented

package/plugins/lisa/skills/jira-add-journey/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Jira Add Journey"
-short_description: "Add a Validation Journey section to an existing JIRA ticket by analyzing the change type and generating appropriate verification steps with…"
-default_prompt:
-  - "Use $jira-add-journey: Add a Validation Journey section to an existing JIRA ticket by analyzing the change type and generating appropriate verification steps with…."