plugins/lisa-copilot/skills/lisa-prd-source-write/SKILL.md
Vendor-neutral wrapper for creating (or idempotently updating) a PRD in the configured PRD source. The PRD-side sibling of lisa-tracker-write. Resolves `source` from .lisa.config.local.json first (then .lisa.config.json — local overrides global) and dispatches to lisa-notion-write-prd, lisa-confluence-write-prd, lisa-github-write-prd, or lisa-linear-write-prd. Callers (notably lisa-research) MUST invoke this skill instead of a vendor PRD writer directly — that is what makes the PRD source switchable per project. Accepts an `initial_role` of `draft` (default) or `ready` so a freshly created PRD either waits for human promotion or is immediately picked up by lisa-intake; and a stable dedupe marker so re-runs reference the existing PRD instead of creating a duplicate. The PRD lives in the source — there is no separate document artifact.
npx skillsauth add codyswanngt/lisa lisa-prd-source-writeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Thin dispatcher. Resolves the configured PRD source and delegates to the matching vendor PRD
writer, which owns the concrete create/update, the lifecycle-role application, and the marker-based
dedupe. When the supplied PRD body already contains the canonical ## Lisa Usage ledger, the
vendor writer must preserve that managed section on update instead of dropping it or reformatting it
ad hoc. This skill only routes — it never talks to a source API itself.
See the config-resolution rule for the full configuration schema and the PRD lifecycle roles.
Callers pass a single structured spec:
operation: create_or_update # the only operation; create unless the marker already exists
title: "<PRD title>"
body: "<full PRD markdown — the entire spec>"
initial_role: draft | ready # default: draft. ready = picked up by lisa-intake's PRD scan
dedupe_key: "<stable-key>" # e.g. project-ideation's idea key
marker: "[lisa-project-ideation] idea=<stable-key>" # embedded in the PRD body for dedupe
origin: { tool: project-ideation | research | manual }
source_ref: "<optional existing PRD ref to force an update>"
ideation_ledger_payload: # optional; forwarded unchanged to the vendor writer
selected_marker: "<same value as marker>"
automation_id: "<Codex/Claude automation id or unavailable>"
automation_memory_path: "<path or unavailable>"
repo: "<org>/<repo or detected repo identity>"
prd_ready: true|false
persona_names: ["<derived persona name>"]
persona_evidence_refs: ["<file/doc/table/release ref>"]
selected_idea: "<selected idea title/key>"
rejected_overlap_candidates: ["<issue refs/titles considered and rejected>"]
expected_empirical_verification_artifact: "<artifact ref or unavailable>"
initial_role semantics are uniform across vendors (the role STRINGS resolve per vendor from
config-resolution):
draft (default) → the PRD is created in the source's draft PRD role. It waits for a human
(or a later ready promotion) before any intake claims it.ready → the PRD is created in the source's ready PRD role (prd-ready), so the PRD-side of
lisa-intake / the *-prd-intake scanner auto-claims it on the next cycle.Omitted means draft — the not-ready default. This matches the ticket-side build_ready contract
in ready-role-filing: on both sides of the pipeline, entering a queue is an explicit claim and
omission is the safe direction. (The ticket side reached that position by removing a per-vendor
legacy default; the PRD side never had one to remove.)
Resolve the source. Read .lisa.config.local.json first (if present), then
.lisa.config.json. Local overrides global per key. Use jq — never hand-parse JSON.
local_source=$(jq -r '.source // empty' .lisa.config.local.json 2>/dev/null)
global_source=$(jq -r '.source // empty' .lisa.config.json 2>/dev/null)
source="${local_source:-${global_source}}"
if [ -z "$source" ]; then
echo "Error: 'source' is not set in .lisa.config.json. A PRD source (notion / confluence / github / linear) is required to create a PRD. Run /lisa:setup:notion (or :confluence, :github, :linear)." >&2
exit 1
fi
Validate the value and dispatch (pass the spec verbatim):
notion → confirm notion.workspaceId and notion.prdDatabaseId are present, then invoke
lisa-notion-write-prd.confluence → confirm atlassian.cloudId and (confluence.spaceKey or
confluence.parents.draft/.ready) are present, then invoke lisa-confluence-write-prd.github → confirm github.org and github.repo are present, then invoke
lisa-github-write-prd.linear → confirm linear.workspace (and team for project placement) is present, then invoke
lisa-linear-write-prd.jira → stop and fail loudly: "source=jira is not a supported PRD source — config-resolution defines no JIRA PRD lifecycle roles. Use notion / confluence / github / linear, or set source accordingly." (JIRA is a destination tracker, not a PRD source.)file) → stop and report: "Unknown PRD source '<value>'. Expected one of: notion, confluence, github, linear."Surface the vendor writer's output unchanged. It returns the created/reused PRD ref + URL,
the applied role (draft/ready), the dedupe marker, and whether it was created or reused.
Downstream callers (research, project-ideation) parse this — do not paraphrase.
When ideation_ledger_payload is present, this shim still does not render or interpret it. Forward
the object verbatim to the selected vendor writer so source-specific rendering remains behind the
configured writer and the dispatch layer never bypasses source selection.
*-write-prd skill directly defeats the
per-project source switch (exactly the tracker-write discipline, mirrored).## Lisa Usage section. Writer-specific preservation
and fallback behavior belongs in the vendor writers and follows the lisa-lisa-usage-accounting contract.{notion, confluence, github, linear}. jira and file fail loudly.ideation_ledger_payload; it is a pass-through payload for
the configured writer.config-resolution per vendor.development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.