plugins/lisa-agy/skills/lisa-jira-evidence/SKILL.md
Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md.
npx skillsauth add codyswanngt/lisa lisa-jira-evidenceInstall 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.
The post-build review status is read from .lisa.config.json jira.workflow.review (or jira.workflow.code_review). review is optional; when unset, the ticket stays in claimed until done and this skill skips the transition. Never transition to a status that is not named in config.jira.workflow. If the configured status is not a valid transition from the current state, log a warning and skip.
REVIEW=""
if [ -f .lisa.config.json ]; then
_cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
[ -n "$_cfg" ] && REVIEW="$_cfg"
fi
if [ -f .lisa.config.local.json ]; then
_local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
[ -n "$_local" ] && REVIEW="$_local"
fi
Upload captured evidence and generated templates to GitHub PR description and JIRA ticket. This skill is the posting step — it assumes evidence files and comment templates already exist in the evidence directory.
$ARGUMENTS: <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>
TICKET_ID (required): JIRA ticket key (e.g., PROJ-123)EVIDENCE_DIR (required): Directory containing evidence and templates (e.g., ./evidence)PR_NUMBER (required): GitHub PR number to update descriptionJIRA_API_TOKEN environment variable set.lisa/jira-cli/.config.yml if the setup-jira-cli
SessionStart hook wrote one, otherwise ~/.config/.jira/.config.yml. server
and login are read from whichever is used, and the fallback is announced on
stderr rather than taken silently.gh CLI authenticatedNN-name.txt or NN-name.json text evidence files (e.g., 01-health-check.json)comment.txt — JIRA wiki markup (generated by generate-templates.py)comment.md — GitHub markdown (generated by generate-templates.py)Before posting or updating anything, check the evidence body (comment.md, and comment.txt where this skill uses it):
## Not established heading. That heading is never omitted and never blank — when nothing is outstanding it still renders None outstanding — reviewed; otherwise it names, in plain operator language, what the verification did not prove.not_established_reviewed: true (the list may be empty; the flag may never be omitted).## Artifact identity heading carrying values, not placeholders — the repository, the head_sha the verification observed, the environment, and per artifact its sha256 digest and captured_at. Refuse to post a body whose identity heading is absent or unpopulated, or whose recorded artifact_head_sha disagrees with the verdict's artifact.head_sha — report the evidence id and both SHAs. Definition: the claim-evidence-mapping rule.If either is missing, refuse to post: stop and report the missing Not-established review to the caller instead of publishing. Composing the body is lisa-tracker-evidence's job (see its UI Evidence Checklist); this skill only refuses to publish one that omits the section. The section is defined by the claim-evidence-mapping rule and generalizes lisa-improve-harness's required, never-empty Known limits field.
bash .claude/skills/jira-evidence/scripts/post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>
bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 42
$PROJECT_DIR/.lisa/jira-cli/.config.yml first, then ~/.config/.jira/.config.yml, announcing the fallback) and reads server and login from it dynamically — no hardcoded values. Exits 1 naming both paths when neither exists. The same resolved path is then passed to jira issue move as --config, so the CLI cannot end up on a different config than the one this script parsed.pr-assets release — Uploads evidence files via gh release upload --clobber## Evidence section in the PR bodycomment.txt as a new comment (wiki markup with code blocks)$REVIEW (default: Code Review).Text evidence files are named: {NN}-{evidence-name}.txt or {NN}-{evidence-name}.json
evidence/
01-health-check.json uploaded
02-schema-after-migration.txt uploaded
03-rate-limit-response.txt uploaded
comment.txt used for JIRA comment
comment.md used for PR description
Evidence files must be in the pr-assets GitHub release. If the release does not exist:
gh release create pr-assets --title "PR Assets" --notes "CDN for PR evidence"
Ensure JIRA_API_TOKEN is set and login in the resolved jira-cli config (.lisa/jira-cli/.config.yml, else ~/.config/.jira/.config.yml) matches your Atlassian account email.
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.