@codyswann/lisa 2.189.6 → 2.189.8

package/plugins/lisa-agy/skills/confluence-to-tracker/SKILL.md

@@ -1,362 +0,0 @@
----
-name: confluence-to-tracker
-description: >
-  Break down a Confluence PRD page into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json). Use this skill whenever the
-  user shares a Confluence PRD URL and wants it converted into tracker tickets, or asks to "break down
-  this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into tickets",
-  or similar. This skill mirrors `lisa:notion-to-tracker` for projects whose PRDs live in Confluence —
-  the workflow, gates, dry-run mode, and validation rules are identical; only the source-of-truth tool
-  surface differs (Confluence MCP instead of Notion MCP).
-allowed-tools: ["Skill", "Bash"]
----
-
-# Confluence PRD to Tracker Breakdown
-
-All Atlassian operations in this skill go through `lisa:atlassian-access`. Do not call MCP tools or `acli` directly.
-
-Convert a Confluence PRD into a structured ticket hierarchy in the configured destination tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json): Epics > Stories > Sub-tasks.
-Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
-
-This skill is the Confluence counterpart of `lisa:notion-to-tracker`. The two skills share the same
-phases, gates, dry-run contract, and per-ticket validation logic. Only the PRD-side fetch / comment
-tools differ. When changing workflow logic, change BOTH skills together so the two source vendors
-stay behaviorally identical.
-
-## Modes
-
-This skill supports two modes, controlled by a `dry_run` flag in `$ARGUMENTS`:
-
-- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:tracker-write`, run the preservation gate, report.
-- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:tracker-validate` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:confluence-prd-intake`) can decide whether to proceed.
-
-Dry-run output format is identical to `lisa:notion-to-tracker`'s. Reuse the same fields, including
-`prd_anchor` and `prd_section`. The only difference: `prd_anchor` is the inline-comment anchor text
-that `lisa:atlassian-access` `operation: comment-page kind: inline` accepts (typically the full
-selected substring; truncate if it exceeds the substrate's max anchor length and emit `null` if no
-resolvable anchor exists).
-
-```text
-## confluence-to-tracker dry-run: <PRD title>
-
-### Planned hierarchy
-- Epic: <summary>
-  prd_section: "<heading text from the PRD that produced this epic>"
-  prd_anchor: "<inline-comment anchor text>"   # null if no specific section
-  - Story 1.1: <summary>
-    prd_section: "<heading or user-story line>"
-    prd_anchor: "<anchor>"
-    - Sub-task [<repo>]: <summary>
-      prd_section: "<heading or AC bullet>"
-      prd_anchor: "<anchor>"
-    - ...
-  - Story 1.2: ...
-
-### Per-ticket validation
-- <ticket-id>: PASS | FAIL — <count> failures
-  prd_section: "<heading text>"
-  prd_anchor: "<anchor>"
-  failures:
-    - gate: <gate-id>
-      category: <category from validator>
-      product_relevant: <true|false>
-      what: <plain-language description from validator>
-      recommendation: <1–3 candidate resolutions from validator>
-
-### Verdict: PASS | FAIL
-### Total failures: <n>
-```
-
-The dry-run mode never writes to the destination tracker. It also never modifies the source Confluence
-page, never re-parents the PRD between lifecycle parents, and never posts comments — that is the
-orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
-
-## PRD lifecycle is parent-page-based on Confluence
-
-Unlike GitHub and Linear (which use labels for PRD lifecycle state), Confluence encodes PRD lifecycle as **parent-page placement**: each lifecycle role (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`) corresponds to a dedicated parent page in the project's Confluence space, listed in `.lisa.config.json` under `confluence.parents.<role>`. A PRD's current state is determined by which of those parents it sits under; a "transition" is a `PUT /wiki/api/v2/pages/{id}` that swaps `parentId`.
-
-This skill itself does NOT transition the PRD between lifecycle parents — that is the orchestrating skill's job (`lisa:confluence-prd-intake`). This skill consumes the PRD content and produces tickets; lifecycle state changes (`ready` → `in_review`, `in_review` → `ticketed` / `blocked`) happen in the orchestrator, before and after this skill runs.
-
-Why parent-page-based, not label-based: scoped Atlassian API tokens cannot write Confluence labels via the v1 endpoint, and the v2 Label API group has no POST endpoint at all. Parent-id transitions, by contrast, are first-class in v2 and work with `write:page:confluence` scope. See `config-resolution` rule, section "Confluence PRD lifecycle uses parent pages, not labels," for the full rationale.
-
-## Hard Rule: All Writes Go Through `lisa:tracker-write`
-
-**Every ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:tracker-write` skill. Never invoke `lisa:atlassian-access` write operations (`write-ticket`, `link`, `comment`, `transition`) directly from this skill or from any sub-agent it spawns.**
-
-`lisa:tracker-write` enforces gates this skill does not:
-- 3-audience description (Context / Technical Approach / Acceptance Criteria)
-- Gherkin acceptance criteria
-- Epic parent validation
-- Explicit issue-link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
-- Single-repo scope check on Bug / Task / Sub-task / Improvement
-- Sign-in account and target environment recorded in description
-- Post-create verification
-
-Bypassing `lisa:tracker-write` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. Read operations on Atlassian (ticket reads, JQL search, Confluence page reads, comment fetches) are still performed in this skill — but ONLY via `lisa:atlassian-access` (`operation: read-ticket | search-issues | read-page | search-pages | list-sites`), never via direct MCP tool calls or `acli`.
-
-## Input
-
-A Confluence PRD page URL or page ID. The PRD is expected to have:
-- A main page with context, problems, and child pages for each Epic
-- Epic child pages with User Stories and functional/non-functional requirements
-- Page comments (footer + inline) with engineering notes and product decisions
-
-URL parsing — Confluence URLs come in two common shapes:
-
-```text
-https://<host>/wiki/spaces/<SPACE>/pages/<PAGE-ID>/<slug>
-https://<host>/wiki/spaces/<SPACE>/pages/<PAGE-ID>
-```
-
-Extract `<PAGE-ID>` (the numeric segment after `/pages/`). If only a space URL is provided
-(`/wiki/spaces/<SPACE>` with no `/pages/...`), stop and report — single-PRD mode requires a specific
-page. The caller wanted `lisa:confluence-prd-intake` (batch mode).
-
-## Configuration
-
-This skill reads project configuration from `.lisa.config.json` (with `.lisa.config.local.json` overriding per key) and operational E2E test config from environment variables. See the `config-resolution` rule for the full schema.
-
-### From `.lisa.config.json`
-
-This skill is a **PRD source** (Confluence); destination tracker resolution is handled by `lisa:tracker-write` and `lisa:tracker-validate` internally — this skill does NOT read `tracker` directly. The relevant config for the source side:
-
-| Field | Purpose | Required when |
-|-------|---------|---------------|
-| `atlassian.cloudId` | Atlassian Cloud site UUID for Confluence MCP calls | always |
-| `confluence.spaceKey` | Confluence space hosting PRDs | invoked without an explicit page URL (batch / arg-less mode) and `confluence.parentPageId` is unset |
-| `confluence.parentPageId` | Confluence parent page under which PRDs live | invoked without an explicit page URL (batch / arg-less mode) and `confluence.spaceKey` is unset |
-
-### From environment variables (E2E test config — operational, not tracker)
-
-| Variable | Purpose | Example |
-|----------|---------|---------|
-| `E2E_TEST_PHONE` | Test user phone number for verification plans | `0000000099` |
-| `E2E_TEST_OTP` | Test user OTP code | `555555` |
-| `E2E_TEST_ORG` | Test organization name | `Arsenal` |
-| `E2E_BASE_URL` | Frontend base URL for Playwright tests | `https://dev.example.io/` |
-| `E2E_GRAPHQL_URL` | GraphQL API URL for curl verification | `https://gql.dev.example.io/graphql` |
-
-If env vars are not available, ask the user to provide them explicitly before proceeding. Do not retrieve credentials from repository files or local agent settings.
-
-## Workflow
-
-### Phase 1: Fetch & Analyze the PRD
-
-1. **Confirm the configured Atlassian site** by invoking `lisa:atlassian-access` `operation: list-sites` (it enforces connection match against `.lisa.config.json`).
-2. **Fetch the main PRD page** by invoking `lisa:atlassian-access` `operation: read-page id: <PAGE-ID>`. Capture body, parent page id (used by `lisa:confluence-prd-intake` to determine the PRD's lifecycle state — see "PRD lifecycle is parent-page-based" below), and child page references.
-3. **Identify all Epic child pages** by invoking `lisa:atlassian-access` `operation: read-page-descendants id: <PAGE-ID>` (one level deep first; recurse if the PRD nests epics under a "Specs" parent). If `atlassian-access` does not yet expose `read-page-descendants`, request its addition (see report at bottom).
-4. **Fetch all Epic pages** in parallel via `lisa:atlassian-access` `operation: read-page id: <EPIC-PAGE-ID>`.
-5. **Fetch full comments** for the main page and every epic page in parallel via `lisa:atlassian-access`:
-   - `operation: read-page-comments id: <PAGE-ID> kind: footer` — page-level threaded comments (equivalent to Notion's page-level discussions)
-   - `operation: read-page-comments id: <PAGE-ID> kind: inline` — block-anchored comments tied to specific text spans
-   - For any comment with replies, walk the tree via `operation: read-comment-children id: <COMMENT-ID>` until exhausted
-   (If any of these read-comment operations is not yet in `atlassian-access`'s dispatch table, request their addition — they are intentionally listed here so the access skill can be extended.)
-6. **Synthesize decisions and blockers** from the PRD content + all comments:
-   - Decisions already confirmed by the team (look for agreement in comment threads)
-   - Open questions that need product/engineering input
-   - Engineering comments (prefixed with "Engineering:" or wrench emoji) that identify technical constraints
-   - Cross-PRD dependencies (references to other features or shared infrastructure)
-
-### Phase 1.5: Extract Source Artifacts
-
-PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, peer Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.
-
-1. **Scan the PRD main page, all Epic child pages, and every fetched comment thread** for:
-   - URLs to design/prototype tools (Figma, FigJam, Figma Make, Lovable, Framer, Penpot)
-   - URLs to recording/walkthrough tools (Loom, YouTube, Vimeo, Descript)
-   - URLs to collaborative docs (Google Docs/Slides/Sheets, peer Confluence pages, Notion peer pages)
-   - URLs to code sandboxes (CodeSandbox, StackBlitz, Replit, GitHub permalinks/gists)
-   - URLs to diagramming tools (Miro, Mural, Excalidraw, Mermaid Live, draw.io, Lucid)
-   - URLs to data/observability tools (Grafana, Datadog, Sentry, Metabase, Looker)
-   - Embedded images and file attachments on the page itself
-   - Fenced code blocks with example data (JSON, SQL, GraphQL, cURL request/response)
-
-2. **Classify each artifact and apply taxonomy rules** by invoking the `lisa:tracker-source-artifacts` skill. That skill is the single source of truth for: domains (`ui-design` / `ux-flow` / `data` / `ops` / `reference`), per-tool classification rules (Figma `/proto/` vs design, Lovable as `ux-flow`, Loom, screenshots), and coverage smells. Do not restate the rules here — invoke the skill so any drift in the rules propagates uniformly.
-
-3. **Build an `artifacts` map** keyed by domain. Each entry: `{ url, title, domain, source_page, source_page_url, classification_reason }`. The `classification_reason` makes disambiguation auditable. The `source_page` lets you trace each reference back to where it appeared in the PRD.
-
-4. **Surface coverage smells** as defined in `lisa:tracker-source-artifacts` §5. Record any detected smells on the epic.
-
-### Phase 1.6: Source Precedence & Conflict Resolution
-
-Source precedence rules and cross-axis conflict handling are defined in `lisa:tracker-source-artifacts` §3 and §4. Apply them during ticket synthesis: every conflict between artifacts must be recorded under `## Open Questions` on the affected ticket, never silently reconciled.
-
-The existing-component reuse expectation is defined in `lisa:tracker-source-artifacts` §7. Encode it on every UI-touching story.
-
-### Phase 2: Codebase + Live Product Research
-
-Identical to `lisa:notion-to-tracker` Phase 2. Two complementary inputs ground PRD analysis: the **code** (what's there to reuse / extend) and the **live product** (what users see today). Skipping either produces tickets that misjudge the change.
-
-**2a. Codebase research.** If the session doesn't already have codebase context, explore the repos to understand what exists. Use Explore agents for repos not yet examined.
-
-**2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill against `E2E_BASE_URL` using the test user from config.
-
-Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist in dev/prod.
-
-Walkthrough findings are attached to the originating Confluence PRD as a **footer comment** (Confluence has no general "page-level discussion attached to a heading" — footer comments are the page-level equivalent), via `lisa:atlassian-access` `operation: comment-page id: <PAGE-ID> kind: footer body: "..."`. Title the comment "Current product walkthrough — `<route>`". Inherited onto the resulting epic / stories under a `## Current Product` subsection.
-
-### Phase 3: Create Epics
-
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:tracker-validate --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
-
-For each PRD epic, **invoke the `lisa:tracker-write` skill** (do not invoke `lisa:atlassian-access` write operations directly). Pass it everything it needs to enforce its quality gates:
-
-- `project_key`: resolved by `lisa:tracker-write` from `.lisa.config.json`
-- `issue_type`: `Epic`
-- `summary`: epic title from the PRD
-- `description_body`: a draft of the 3-audience description containing:
-  - **Context / Business Value**: epic summary from the PRD, originating Confluence URL, business outcome
-  - **Technical Approach**: cross-cutting integration points and constraints surfaced in Phase 2 codebase research
-  - List of user stories the epic contains
-  - Key decisions from comments (with attribution)
-  - Blockers and open questions
-  - Dependencies on other epics or PRDs
-  - A **Source Artifacts** section listing every artifact extracted in Phase 1.5 (grouped by domain)
-- `artifacts`: the full Phase 1.5 artifact list — every artifact, regardless of domain. The epic is the canonical hub. No filtering at the epic level.
-- `priority`, `labels`, `components`, `fix_version`: as appropriate
-
-**Leaf-only build-ready (`leaf-only-lifecycle`)**: an Epic is a container, not a leaf work unit. Do NOT mark it build-ready — `lisa:tracker-write` must not be passed `status:ready` for an Epic, and the Epic's lifecycle state rolls up from its children. The build-ready label is applied only in Phase 5.
-
-Capture the returned epic key — Phase 4 needs it as the parent for stories.
-
-### Phase 4: Create Stories
-
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft each story spec and validate it with `lisa:tracker-validate --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
-
-For each Epic, plan two kinds of stories:
-- **One "X.0 Setup" story** for data model and infrastructure prerequisites
-- **One story per user story** from the PRD (numbered to match the PRD)
-
-**Story naming convention**: Prefix the summary with a short code derived from the PRD title (e.g., `[CU-1.1]` for "Contract Upload").
-
-For each story, **invoke `lisa:tracker-write`** with:
-
-- `project_key`: resolved by `lisa:tracker-write` from `.lisa.config.json`
-- `issue_type`: `Story`
-- `epic_parent`: the Epic key captured in Phase 3 (mandatory)
-- `summary`: prefixed per the naming convention above
-- `description_body`: 3-audience description as in `lisa:notion-to-tracker` Phase 4
-- `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below
-
-| Story type | Inherits domains |
-|------------|------------------|
-| Frontend / UI | `ui-design`, `ux-flow`, `reference` |
-| Backend / API / data model | `data`, `reference` |
-| Infrastructure | `ops`, `reference` |
-| Mixed / setup ("X.0") | All domains |
-
-**Leaf-only build-ready (`leaf-only-lifecycle`)**: a Story is a container (it has child Sub-tasks), not a leaf work unit. Do NOT mark it build-ready — never pass `status:ready` to `lisa:tracker-write` for a Story. Its lifecycle state rolls up from its Sub-tasks. The build-ready label is applied only in Phase 5.
-
-Capture each returned story key — Phase 5 needs it as the parent for sub-tasks.
-
-### Phase 5: Create Sub-tasks
-
-**Auto-split cross-repo work before delegation.** For each candidate sub-task, apply `lisa:task-decomposition` step 1.5: if the work touches more than one repo, split it into one sub-task per repo under the same parent Story (e.g., `[backend-api] Add field` + `[mobile-app] Display field`), and encode the producer-before-consumer ordering via dependencies. Work units that may span repos (Epic, Story, Spike) stay as planned; work units that must be single-repo (Bug, Task, Sub-task, Improvement) are split now. Splitting is this skill's responsibility — the validator's S10 gate is `product_relevant: false` because cross-repo failures are decomposition errors caught here, not product questions sent back to the PRD.
-
-**S10 hard gate repair loop.** Dry-run validation is not advisory. Before any Phase 5 write, every planned leaf spec MUST pass `lisa:tracker-validate --spec-only` for S10 Single-repo scope. If any Bug / Task / Sub-task / Improvement fails S10 (missing `Repository`, more than one repo, or cross-repo AC), stop the write path, auto-split or restamp the spec using `lisa:task-decomposition` step 1.5, add the repo bracket and `## Repository` / `h2. Repository` section, then re-run `lisa:tracker-validate --spec-only`. If S10 still fails after repair, abort the ticket write and record an internal Error in the dry-run report; do not create the ticket, do not bypass with direct vendor writes, and do not surface the `product_relevant: false` failure as a product clarification.
-
-Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may invoke `lisa:atlassian-access` write operations directly.**
-
-Each sub-task MUST:
-1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]` and in the description's `## Repository` / `h2. Repository` section
-2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking
-
-**Leaf-only build-ready (`leaf-only-lifecycle`)**: Sub-tasks are the **leaf work units** of the decomposition — they are the ONLY items in the hierarchy that receive the build-ready label. `lisa:tracker-write` applies `status:ready` here so downstream build intake (`lisa:tracker-build-intake`) claims the leaves and never the Epic or Stories. Apply `status:ready` to each Sub-task; never to its parent Story or Epic (Phases 3–4). `lisa:tracker-write` enforces the same invariant on the write side, so a Sub-task split into per-repo children (the cross-repo case above) carries build-ready on the children, not on any intermediate parent that gains child work.
-
-Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not pass the same artifact list to every sub-task.
-
-### Phase 5.5: Artifact Preservation Gate (mandatory)
-
-Run the preservation gate defined in `lisa:tracker-source-artifacts` §8 against the artifacts extracted in Phase 1.5 and the tickets just created. Do NOT restate or modify the gate logic here — invoke the rules from `lisa:tracker-source-artifacts`.
-
-To run the gate, this skill must:
-
-1. Pull the remote links of every epic and story created in this run via `lisa:tracker-read (vendor-neutral; dispatches to jira-read-ticket or github-read-issue)`.
-2. Apply the §8 preservation matrix and verdict rules.
-3. If the gate fails: list each dropped/misrouted artifact and either re-attach via `lisa:tracker-write` (UPDATE mode) or stop and ask the human.
-4. If the gate passes: print the matrix compactly and proceed to Phase 6.
-
-This gate is not optional.
-
-### Phase 6: Report Results
-
-After all tickets are created, present a summary table to the user:
-- All Epics with keys and URLs
-- All Stories grouped by Epic
-- All Sub-tasks grouped by Story with repo tags
-- Repo distribution
-- **Artifact Preservation Matrix**
-- Blockers list with recommendations and alternatives
-- Cross-PRD dependencies
-
-### Phase 7: PRD Back-link
-
-> **Mode guard**: In `dry_run: true` mode, skip this phase entirely — no tickets exist to link.
-
-After Phase 6, invoke the `lisa:prd-backlink` skill to write a `## Tickets` section back into the source Confluence PRD page. The section becomes the canonical anchor for the **Debrief** flow once the initiative ships.
-
-Invoke `lisa:prd-backlink` with:
-
-- `source_type: "confluence"`
-- `source_ref`: the original Confluence page URL
-- `tickets`: the full list created in Phases 3–5, each entry as `{ key, title, type, url, parent_key }`
-
-If `lisa:prd-backlink` fails (page permission denied, Confluence unreachable), surface the error in the Phase 6 report rather than aborting — the tickets are already created. Recommend the user re-run `lisa:prd-backlink` standalone once the source is reachable.
-
-## Handling Ambiguities and Blockers
-
-When you encounter something the PRD + comments + codebase can't resolve:
-
-1. **Don't guess** — mark the ticket with a BLOCKER section
-2. **Include your recommendation** with rationale
-3. **List 2-3 alternatives** so the user/product can choose
-4. **State what's needed to unblock**
-
-## Agent Prompt Template for Sub-task Creation
-
-When delegating to agents, provide this context. **The "MUST invoke lisa:tracker-write" instruction is load-bearing — do not edit it out when adapting this template.**
-
-```text
-Create sub-tasks in the [PROJECT] project.
-
-CRITICAL: For each sub-task, invoke the `lisa:tracker-write` skill via the Skill tool.
-Do NOT invoke `lisa:atlassian-access` write operations (write-ticket / link / comment /
-transition) directly. The `lisa:tracker-write` skill enforces required quality gates
-(Gherkin acceptance criteria, 3-audience description, single-repo scope,
-sign-in/environment fields, post-create verification). Bypassing it produces broken
-tickets that downstream skills (triage, journey, evidence) cannot use.
-
-For each sub-task, invoke `lisa:tracker-write` with:
-- issue_type: "Sub-task"
-- parent: the parent story key
-- project_key: [PROJECT]
-- summary: prefixed with the repo in brackets, e.g. "[backend-api] Add audit log table"
-- description_body: a 3-section draft (Context / Technical Approach / Acceptance Criteria) plus `h2. Repository` naming exactly one repo
-- gherkin_acceptance_criteria: derived from the story's functional requirements
-- sign_in_account: [test user credentials from config — name + role + how to obtain]
-- target_environment: "dev"
-- empirical_verification_plan: real user-like verification (curl + auth token,
-  Playwright browser flow, CLI check after deploy) using the test credentials.
-  NOT unit tests, linting, or typechecking.
-
-Each sub-task must:
-1. Be scoped to ONE repo only — repo named in brackets in the summary and in `h2. Repository`
-2. Include the Empirical Verification Plan in the description
-3. Be created via `lisa:tracker-write`, not via direct `lisa:atlassian-access` write operations
-
-If `lisa:tracker-write` rejects a sub-task, fix the input and re-invoke. Do NOT fall back
-to a direct `lisa:atlassian-access` `operation: write-ticket` call to bypass the gate.
-
-Test user info: [credentials from config]
-
-[Then list all sub-tasks grouped by parent story with details]
-```
-
-## Cross-PRD Shared Infrastructure
-
-Track tickets that are shared across PRDs to avoid duplication. When a sub-task overlaps with an existing ticket, reference it instead of creating a duplicate. Search JIRA for existing tickets in the project before creating new ones for shared infrastructure.
-
-## Confluence-specific notes
-
-- **Page bodies** come back from `getConfluencePage` as either Atlassian Document Format (ADF / storage format) or rendered HTML depending on flags. Treat headings (`<h1>`–`<h3>`) as section markers for `prd_section`. For ADF, walk the document tree.
-- **Inline comment anchors**: `prd_anchor` is the inline-comment selection text (the exact substring `createConfluenceInlineComment` will match). If the section is too long for an inline anchor (Confluence has a practical upper bound on selection length), pick the first sentence of the section. If the section has no stable anchor (e.g., a generated table cell), set `prd_anchor: null` and the caller will fall back to a footer comment.
-- **Comment threading**: Confluence has separate footer and inline comment streams. When fetching comments in Phase 1, merge both into the analysis — they are equally authoritative for capturing decisions and engineering notes.

package/plugins/lisa-agy/skills/confluence-write-prd/SKILL.md

@@ -1,109 +0,0 @@
----
-name: confluence-write-prd
-description: "Creates or idempotently updates a PRD as a Confluence page parented under the configured lifecycle parent page (the draft parent by default, or the ready parent when initial_role is ready so lisa:confluence-prd-intake auto-claims it). The Confluence PRD-source writer behind lisa:prd-source-write. Confluence models PRD state by PARENT PAGE (not labels), per config-resolution. Dedupes by a stable marker embedded in the page body, found via CQL (matched by marker, never by title). All Atlassian access goes through lisa:atlassian-access."
-allowed-tools: ["Skill", "Bash"]
----
-
-# Write Confluence PRD: $ARGUMENTS
-
-Create (or update) a PRD page in Confluence. Invoked by `lisa:prd-source-write` when
-`source = confluence`; do not call directly from a vendor-neutral caller. **All Confluence
-operations go through `lisa:atlassian-access`** — never call the Atlassian API/MCP or `acli` directly.
-
-Confluence's PRD lifecycle uses **parent pages**, not labels (scoped API tokens can't write
-Confluence labels — see `config-resolution` "Confluence PRD lifecycle uses parent pages"). A PRD's
-state is which lifecycle parent it lives under; "promote to ready" = re-parent to the ready parent.
-
-`$ARGUMENTS` carries the `lisa:prd-source-write` spec: `title`, `body` (full PRD markdown),
-`initial_role` (`draft` | `ready`, default `draft`), `dedupe_key`, `marker`, optional `source_ref`.
-
-## Phase 1 — Resolve lifecycle parents
-
-```bash
-read_g() { local lv gv; lv=$(jq -r "$1 // empty" .lisa.config.local.json 2>/dev/null); gv=$(jq -r "$1 // empty" .lisa.config.json 2>/dev/null); echo "${lv:-${gv:-$2}}"; }
-SPACE=$(read_g '.confluence.spaceKey' '')
-CLOUDID=$(read_g '.atlassian.cloudId' '')
-[ -z "$CLOUDID" ] && { echo "Error: atlassian.cloudId not set in .lisa.config.json."; exit 1; }
-# Resolve the FULL set of lifecycle parents from config (never hard-code) — needed for the target
-# parent, the past-ready reverse-lookup, and to derive the space when spaceKey is absent.
-DRAFT_PARENT=$(read_g '.confluence.parents.draft' '')
-READY_PARENT=$(read_g '.confluence.parents.ready' '')
-IN_REVIEW_PARENT=$(read_g '.confluence.parents.in_review' '')
-BLOCKED_PARENT=$(read_g '.confluence.parents.blocked' '')
-TICKETED_PARENT=$(read_g '.confluence.parents.ticketed' '')
-SHIPPED_PARENT=$(read_g '.confluence.parents.shipped' '')
-VERIFIED_PARENT=$(read_g '.confluence.parents.verified' '')
-# "Progressed past ready" parents (never re-parent a PRD down from these):
-PROGRESSED_PARENTS=("$IN_REVIEW_PARENT" "$BLOCKED_PARENT" "$TICKETED_PARENT" "$SHIPPED_PARENT" "$VERIFIED_PARENT")
-```
-
-Resolve the target parent from `initial_role`: `ready` → `$READY_PARENT`, otherwise `$DRAFT_PARENT`.
-If the needed parent id is unset, stop and report that `/lisa:setup:confluence` must provision the
-lifecycle parent pages — do not create a PRD outside the lifecycle scaffolding.
-
-**Resolve the space (config allows parent-page-only setups with no `spaceKey`).** If `$SPACE` is
-empty, derive it from the target lifecycle parent: `lisa:atlassian-access` `operation: read-page id:
-<target parent>` and read its space key from the response. If neither `confluence.spaceKey` is set nor
-a space can be derived from the parent, **stop and report** that a space could not be established —
-do not attempt a CQL search or create without it.
-
-## Phase 2 — Dedupe by marker (CQL search before create)
-
-The `marker` is embedded in the page body. Find an existing PRD page carrying it — match the marker,
-**never** the title:
-
-```text
-lisa:atlassian-access  operation: search-pages  cql: 'space = "<SPACE>" AND text ~ "<marker>"'
-```
-
-If `source_ref` was passed, target that page directly. If a page with the marker exists → **update**;
-else → **create**.
-
-## Phase 3 — Create or update
-
-**Storage-format body + marker (both paths).** Convert the PRD markdown to Confluence **storage
-format** (XHTML): `#`/`##`/`###` → `<h1>/<h2>/<h3>`, paragraphs → `<p>`, lists → `<ul>/<ol><li>`,
-fenced code → `<ac:structured-macro ac:name="code">`. Embed the marker as a storage comment
-(`<!-- $MARKER -->`) or a small `<p>` so future CQL dedupe finds it. The body must always contain
-**exactly one** marker; never write a markerless page (CREATE or UPDATE). If the live page body
-already contains the canonical managed `## Lisa Usage` section, preserve it verbatim unless the
-caller intentionally supplied an updated canonical section; use the shared `usage-accounting`
-serializer/merge path rather than hand-editing ledger rows in storage XHTML.
-
-**CREATE:** `lisa:atlassian-access` `operation: write-page` (create form) with a payload that sets:
-- `title`: `$TITLE`
-- `space`: `$SPACE` (resolved in Phase 1)
-- `ancestors`/`parentId`: the resolved lifecycle parent (`$DRAFT_PARENT` or `$READY_PARENT`)
-- `body`: the storage-format, marker-normalized body above.
-
-**UPDATE** (existing page or `source_ref`):
-1. **GET-then-PUT** (load-bearing, as `confluence-prd-intake` documents): first `operation: read-page
-   id: <page-id>` to read the current `version.number`, then `operation: write-page` (edit form) with
-   the marker-normalized storage body and `version.number` bumped to current+1. A PUT without the
-   current version is rejected; never drop the marker or an existing managed `## Lisa Usage` section
-   on the edit.
-2. Re-parent to the target lifecycle parent if the role changed — **unless** the page's current
-   parent is in the resolved `${PROGRESSED_PARENTS[@]}` set (already past `ready`). If so, leave it
-   and report `reused (already past ready)`. Reverse-lookup the current parent in
-   `confluence.parents.*` to determine its role before re-parenting.
-
-## Phase 4 — Return
-
-```yaml
-ref: "<confluence-page-id>"
-url: "<page url>"
-role: draft | ready          # derived from the lifecycle parent the page now lives under (or its current role when reused past ready)
-marker: "<MARKER>"
-outcome: created | reused
-```
-
-## Rules
-
-- All access via `lisa:atlassian-access`; never call Atlassian directly.
-- State is the parent page, not a label — never attempt Confluence label writes (they 401 on scoped
-  tokens; see `config-resolution`).
-- Match dedupe by marker, never by title.
-- Preserve an existing canonical `## Lisa Usage` section on update; never append a second usage
-  section or silently drop ledger rows.
-- Never re-parent a PRD already past `ready` down to draft/ready.
-- Resolve parents from config (`confluence.parents.{draft,ready}`) — never hardcode page ids.

package/plugins/lisa-agy/skills/cross-pollinate/SKILL.md

@@ -1,175 +0,0 @@
----
-name: cross-pollinate
-description: "Detect a host project's locally-authored coding-agent definitions (skills, subagents, rules, commands, hooks, MCP) and make each available in the formats of the OTHER agents the project supports, as declared in .lisa.config.json. Any-to-any, provenance-tracked, idempotent, never clobbers hand-edited output."
-allowed-tools: ["Bash", "Read", "Write", "Edit", "Glob", "Grep"]
-argument-hint: "[path] [--dry-run] [--write]"
----
-
-# Cross-Pollinate: $ARGUMENTS
-
-A host project that installs Lisa may hand-author a definition for **one** coding
-agent — a `.claude/skills/foo`, a `.cursor/rules/bar.mdc`, an MCP server only
-Claude sees. `/lisa:cross-pollinate` detects those locally-authored definitions
-and regenerates each in the formats of the **other** agents the project supports,
-so the whole fleet stays in parity with what a developer wrote for any single one.
-
-## The model
-
-```
-any agent's format  ->  Claude-format IR  ->  every OTHER configured agent
-```
-
-Claude format is the canonical intermediate representation (IR) because every
-Lisa generator already sources from it. So translation is always: **normalize
-the detected definition up to Claude-format IR, then fan that IR out** to each
-target agent using the documented mappings below. Never translate format A → B
-directly — that multiplies error and loses fidelity on every hop.
-
-The agents a project supports come from `.lisa.config.json` `harness`
-(`claude` | `codex` | `cursor` | `agy` | `copilot` | `opencode` | `both` | `fleet`;
-`all` is an alias for `fleet`). Only emit to agents that harness includes.
-
-## Provenance is authoritative — the lockfile, not file paths
-
-`.lisa/cross-pollination.lock.json` (committed) is the source of truth for what
-this skill generated. Location heuristics **cannot** work: a generated Cursor
-rule sits in the same `.cursor/rules/` directory as a hand-authored one. The
-lockfile is the only reliable way to enforce the four invariants:
-
-1. **No loops** — a path recorded as a `target` is NEVER treated as a source on
-   the next run. Without this, today's output becomes tomorrow's input and
-   translations ping-pong forever.
-2. **Garbage collection** — when a source is deleted/renamed, its now-orphaned
-   targets are removed.
-3. **Never clobber edits (Chesterton's fence)** — if a target's on-disk hash
-   differs from the recorded `generatedHash`, a human edited it. Stop and report;
-   do not overwrite. They may have intentionally diverged, or want to adopt the
-   edit as a new source.
-4. **Idempotent** — unchanged source + intact targets => no-op. (This is why it
-   is safe to also run during `lisa apply`.)
-
-Lockfile shape:
-
-```json
-{
-  "version": 1,
-  "entries": {
-    "skill:security-review": {
-      "source":  { "agent": "claude", "path": ".claude/skills/security-review", "hash": "…" },
-      "targets": [ { "agent": "codex", "path": ".claude/skills/security-review/agents/openai.yaml", "generatedHash": "…" } ]
-    }
-  }
-}
-```
-
-The `logicalId` is `<kind>:<name>` — stable across formats. It links a source to
-its targets and detects **collisions**: the same `logicalId` authored
-independently in two agents (neither generated). On a collision, NEVER
-auto-translate over either side — report it and let the human pick the source of
-truth.
-
-## How to run
-
-The deterministic core (scan, provenance, loop/GC/drift/conflict detection, and
-the skill + MCP emitters) is a bundled engine. **Always run it first** — it does
-the safe, mechanical work and tells you exactly what is left for you to translate
-by hand.
-
-```bash
-# dry-run (default): report only, writes nothing
-node "${CLAUDE_PLUGIN_ROOT}/scripts/cross-pollinate.mjs" "$PROJECT_ROOT" --json
-# apply the deterministic emits + update the lockfile
-node "${CLAUDE_PLUGIN_ROOT}/scripts/cross-pollinate.mjs" "$PROJECT_ROOT" --write
-```
-
-In the Lisa source repo itself the path is
-`node plugins/lisa/scripts/cross-pollinate.mjs` (built) or
-`node plugins/src/base/scripts/cross-pollinate.mjs` (source).
-
-The JSON report has four lists you act on:
-
-- `emits` — already handled by `--write` (skills, MCP). Verify, don't redo.
-- `conflicts` — STOP. Report each to the user; do not translate.
-- `orphans` — GC'd by `--write`. Confirm the removals look right.
-- `pending` — **your job.** Definitions whose target format the engine does not
-  emit deterministically. Translate each per the mappings below, then record
-  provenance (see "Recording provenance").
-
-## Per-agent format mappings (for `pending` translation)
-
-Normalize the source to Claude-format IR first, then emit per target:
-
-### Rules
-- **Claude ↔ Cursor**: handled deterministically by the engine. Claude reads
-  `.claude/rules/<name>.md`; Cursor reads `.cursor/rules/<name>.mdc` with YAML
-  frontmatter (`description` from the first H1, `alwaysApply: true`) and intra-rule
-  link extensions rewritten. You do not translate these — verify the engine's
-  emits.
-- **Codex / OpenCode / agy** (`pending`): project rules are delivered via
-  `AGENTS.md`, not a per-rule file. MERGE the rule content into `AGENTS.md` under a
-  stable marked section rather than writing a separate file (so re-runs replace,
-  not append). agy never gets a duplicate rule file (rules-once).
-- **Copilot** (`pending`): `.github/copilot-instructions.md` (inline). Merge into a
-  marked section, don't scatter.
-
-### Subagents
-- **Claude / agy / Cursor / OpenCode**: `agents/<name>.md` (or `.claude/agents/`).
-- **Copilot**: `agents/<name>.agent.md` (note the `.agent.md` suffix).
-- **Codex**: does not consume agent files. Report as **dropped — unsupported**,
-  do not invent a target.
-
-### Commands
-- **Claude / Cursor / Copilot**: markdown command files (`.claude/commands/…`).
-- **Codex / agy**: auto-derive commands from skills; no separate command file.
-  Report as **dropped — derived-from-skill**.
-
-### Hooks (lossy — drop-and-report, never fake support)
-- Event-name casing differs per agent (`PreToolUse`→`preToolUse`/`beforeSubmitPrompt`,
-  `UserPromptSubmit`→`userPromptSubmitted`, `Stop`→`agentStop`/`stop`, …).
-- **agy** lacks `SessionStart`/`SubagentStart` — only `PreToolUse` (e.g.
-  block-no-verify) is portable. Everything else: dropped — unsupported.
-- **Codex** plugin hooks do not fire in `codex exec` — install into
-  `~/.codex/hooks.json`, not a bundled file.
-- **Copilot** rejects the entire hooks config if a `SubagentStart`/empty-matcher
-  entry is present — drop that event wholesale.
-- For every hook you cannot faithfully translate to a target, REPORT it with the
-  reason. Do not silently omit (no silent caps).
-
-### MCP (handled by the engine for Claude↔Cursor; report others)
-- **Claude**: `.mcp.json`. **Cursor**: `.cursor/mcp.json` (same JSON shape).
-- **Copilot**: inline `mcpServers` object in the plugin manifest (bundled
-  `.mcp.json` is ignored). **Codex**: TOML / `.codex-plugin` pointer.
-  **agy/OpenCode**: user-global installer / `.opencode`. The engine reports these
-  as pending; translate per the target's documented shape or report dropped.
-
-## Recording provenance for hand-translated `pending` items
-
-After you write a target by hand, it MUST be recorded in
-`.lisa/cross-pollination.lock.json` or the next run will treat it as a source
-(loop) or fail to GC it. Re-run the engine after staging your translated files —
-on its next pass it adopts and hashes any target already referenced — OR add the
-entry yourself following the lockfile shape above (compute `generatedHash` as the
-sha256 of the written file/dir). Prefer the engine; only hand-edit the lock if
-the engine cannot infer the mapping.
-
-## Output
-
-Report, concisely:
-- harness + resolved target agents
-- counts: detected sources, written, skipped-drift, GC'd
-- every conflict (with the agents involved)
-- every pending item you translated, and every hook/agent/command you **dropped**
-  with its reason
-- confirm `.lisa/cross-pollination.lock.json` was updated and the working tree
-  otherwise contains only intended changes
-
-## Rules
-
-- Treat the lockfile as authoritative; never infer "mine vs theirs" from paths.
-- Never overwrite a drifted (hand-edited) target — report it.
-- Never auto-resolve a collision — report it.
-- Only emit to agents the project's `harness` includes.
-- Drop-and-report any translation a target genuinely cannot support; never fake
-  a location you are unsure of.
-- This skill is additive — it does not delete a human's source definitions, only
-  its own orphaned generated targets.