Version: 0.8.4

Applications — how the plugin gets consumed, and the CI demos

Scope: this document has two jobs. §1 explains the two ways the jira-sdlc plugin can be installed. §2 onward is a guide to the demo GitHub Actions workflows shipped under .github/workflows/ at the marketplace repo root — worked examples of running the three skills in CI, meant to be read next to the workflow files and copied into other repos. They are not this repo's own development procedure (human-driven, see SDLC.md).

1. Summary — two ways to use the plugin

Mode	How it works	When to use
Claude Code marketplace plugin	Add the marketplace, then `/plugin install jira-sdlc@<marketplace-name>` via the `/plugin` command. The three skills become available as `/jira-sdlc:jira-task-assigner`, `/jira-sdlc:jira-task-executor`, `/jira-sdlc:jira-task-reviewer`.	Default path — skills stay versioned with the marketplace release, upgrade with a reinstall.
Loose skillset	Copy `plugins/jira-sdlc/skills/` into a project's own skills folder (e.g. `.claude/skills/`). Invoke unprefixed — `/jira-task-assigner`, etc.	When you want to fork/edit the skills directly, or the target environment doesn't support the marketplace mechanism. Note the local-dev-loop caveat in CLAUDE.md: a marketplace install is a cached snapshot, so edits to a clone don't show up there until reinstalled — this is why active skill development should point `--plugin-dir` at a working copy instead.

Both modes read the same configuration: .jst/jira-sdlc-tools.env (team-shared) and .jst/jira-sdlc-tools.local.env (machine-specific, gitignored) in the target project's root. See INSTALLATION.md and project-config.md for what each <TOKEN> resolves to.

2. Usage applications

2a. Classic — interactive, on your own machine

You run the skills manually, one at a time, from a terminal alongside your coding assistant. Taking the simplest case — a single-step task, where the assigner decides the work is cohesive enough to stay one issue:

1. Plan it — creates the Jira issue, its branch, and its worktree:

/jira-sdlc:jira-task-assigner "Add CSV export to the reports page"

2. Implement it — cd into the worktree the assigner created and start your assistant there:

cd <WORKTREES_DIR>/worktree-<KEY> && claude
> /jira-sdlc:jira-task-executor

No key argument — it's derived from that worktree's own branch (feature/<KEY>-<slug>). The executor implements, tests, commits, pushes, and opens a PR into <DEFAULT_BASE_BRANCH>.

3. Review it — from the same worktree, once that PR is open:

> /jira-sdlc:jira-task-reviewer

Also no key argument. On a single-step issue there are no sub-tasks to iterate, so the reviewer reviews that one PR into the base branch directly and posts its verdict to GitHub and Jira. It never merges — that stays a human act.

A multistep task is the same three skills, just fanned out: the assigner creates a parent issue plus a sub-task per parallelizable piece, each with its own branch and worktree, you run one executor per sub-task worktree, and the reviewer then runs from the parent worktree to sweep the whole set. See the README's usage walkthrough for that version worked through end to end.

Either way you answer the assigner's clarifying questions, and approve or fix the reviewer's findings before merging — full interactive turn at every step.

2b. CI usage — GitHub Actions demos

This repo ships several demo workflows under .github/workflows/ showing how to run the skills headlessly in CI. Each is self-contained and meant to be copy-pasted into another repo.

Workflow file	Trigger	What it does
`demo-claude-reviewer.yml`	Comment `/review` on a PR	Reviewer only, against an already-open PR — a standalone review gate. Deep dive: ci-review-pr-demo.md.
`demo-claude-issue-to-task.yml`	Comment `/make-task` on an issue	Assigner only — turns the commented GitHub issue into a Jira Task + branch + worktree on the runner. Stops there (nothing persists past the job on a hosted runner). Deep dive: ci-issue-to-task-demo.md.
`demo-claude-issue-to-bug.yml`	Comment `/make-bug` on an issue	Assigner only — the byte-identical `/make-bug` twin of the row above; same run, producing a Jira Bug instead of a Task. Deep dive: ci-issue-to-task-demo.md.
`demo-claude-feature-flow.yml`	Comment `/make-feature` on an issue	Full feature flow: assigner → executor → reviewer, chained, one manual-approval gate per skill. Branch `feature/<KEY>-<slug>` off `<DEFAULT_BASE_BRANCH>`; PR targets `<DEFAULT_BASE_BRANCH>`. Deep dive: ci-feature-flow-demo.md.
`demo-claude-hotfix-flow.yml`	Comment `/make-hotfix` on an issue	Full hotfix flow, same three-job chain and gating. Branch `hotfix/<KEY>-<slug>` off `origin/<PRODUCTION_BRANCH>`; PR targets `<PRODUCTION_BRANCH>`. Deep dive: ci-hotfix-flow-demo.md.
`demo-fcc-nvidia-nim-feature-flow.yml`	Comment `/fcc-make-feature` on an issue	Same three-job feature flow, but on Free Claude Code + NVIDIA NIM as the model backend instead of the Claude Code CLI — shows how to swap the LLM provider. Deliberately a different trigger word than `/make-feature` so the two workflows don't both fire off one comment.
`demo-fcc-nvidia-nim-reviewer.yml`	Comment `/fcc-review` on a PR	Reviewer-only, FCC + NVIDIA NIM backend — the provider-swap counterpart to `demo-claude-reviewer.yml`.
`demo-fcc-nvidia-nim-reviewer-workflow-dispatch.yml`	Manual `workflow_dispatch` (model picker)	Reviewer-only, FCC + NVIDIA NIM — the dispatch twin of `demo-fcc-nvidia-nim-reviewer.yml`: same reviewer run with no comment trigger, and the NIM model picked from the dispatch dropdown instead of pinned.
`demo-kimi-openrouter-reviewer.yml`	Manual `workflow_dispatch`	Smoke test — despite the filename, it invokes no skill: it installs Kimi Code, points `extra_skill_dirs` at this plugin, and runs one hand-written review prompt over `gh pr diff`, posting the result to the PR. No worktree, no Jira write, no environment gate. Deep dive: ci-smoke-test-demo.md.

Common patterns across the CI demos

One job per skill, each a fresh runner VM, each under its own Jira identity (assigner/executor/reviewer email + token).
No shared disk — WORKTREES_DIR is rebuilt per job under $RUNNER_TEMP/worktrees. Jobs 2/3 reconstruct a linked worktree from the branch job 1 pushed; the executor and reviewer skills hard-stop unless they're running in a linked worktree on a feature/* or hotfix/* branch.
Environment-gated approvals — every demo except the smoke test and the two issue-to-* twins declares environment: production on its skill jobs. That always scopes their secrets, and additionally makes GitHub pause for a human before each job if the environment has Required reviewers enabled. The issue-to-task/bug twins are the exception (see the next bullet): they dropped the gate, so the OWNER comment guard is their only boundary. See §3.1–3.2.
Secrets are environment secrets on production (named exactly as the .jst/jira-sdlc-tools.local.env keys they become — this is what lets a job's bootstrap step be a single loop over a KEYS list instead of a hand-mapped one), except the issue-to-task/bug twins, which dropped environment: production so their secrets resolve from the repo level instead — until redistributed from the production environment (JST-225 AC#4) their bootstrap fails loud. See §3.5 and ci-issue-to-task-demo.md.
No GH_TOKEN/GITHUB_TOKEN exported into skill steps — statuscheck logs gh in from GITHUB_PAT_TOKEN read out of the env file; exporting either token variable into the environment makes gh auth login refuse, since it insists the variable be cleared first.
Headless, no questions — skills run with -p --dangerously-skip-permissions. A run where the assigner would normally ask a clarifying question produces no branch and fails loud (the guard checks for exactly one new branch).
Self-review — the reviewer posts its verdict as a PR comment (APPROVED — … / CHANGES REQUESTED — …, never gh pr review --approve) because the same gh identity opened the PR and GitHub blocks self-approval.
Reporting back to the issue — each job comments its transcript on the triggering issue (collapsed <details>, tail capped to stay under GitHub's comment size limit).

2c. The same demos, by scenario

The table in §2b lists one row per file. This one lists one row per scenario — the flow being demonstrated — with the workflows that implement it. Several scenarios ship more than once: same skills, same job shape, different model backend behind them. Pick the row for the flow you want, then the implementation whose backend you have credentials for.

Scenario	What the flow does	Trigger	Approval	Implementations
Feature flow	Full three-skill chain: assigner → executor → reviewer. GitHub issue becomes a Jira issue + `feature/<KEY>-<slug>` branch off `<DEFAULT_BASE_BRANCH>`, gets implemented, and ends as an open reviewed PR into `<DEFAULT_BASE_BRANCH>`. Nothing is merged.	comment — bare or with prose	Up to 3 — `environment: production` on every job (assigner, executor, reviewer)	• `demo-claude-feature-flow.yml` — Claude Code CLI · `/make-feature` • `demo-fcc-nvidia-nim-feature-flow.yml` — Free Claude Code + NVIDIA NIM · `/fcc-make-feature`
Hotfix flow	The same three-skill chain on the emergency path: `hotfix/<KEY>-<slug>` cut off `origin/<PRODUCTION_BRANCH>`, PR targets `<PRODUCTION_BRANCH>`, and the assigner is forced single-step (no sub-tasks).	comment — bare or with prose	Up to 3 — `environment: production` on every job (assigner, executor, reviewer)	• `demo-claude-hotfix-flow.yml` — Claude Code CLI · `/make-hotfix`
Review a PR	Reviewer skill alone, against an already-open PR. Rebuilds a linked worktree for the PR branch, reviews the diff, and posts the verdict to GitHub (as a comment) and Jira. Merges nothing.	comment — bare or with prose, or manual `workflow_dispatch`	Up to 1 — `environment: production` on the reviewer job; the gating job runs before it, ungated	• `demo-claude-reviewer.yml` — Claude Code CLI · `/review` • `demo-fcc-nvidia-nim-reviewer.yml` — Free Claude Code + NVIDIA NIM · `/fcc-review` • `demo-fcc-nvidia-nim-reviewer-workflow-dispatch.yml` — Free Claude Code + NVIDIA NIM · `workflow_dispatch` (model-pickable, no comment)
Issue to task / bug	Assigner alone. A commented GitHub issue becomes a Jira Task (`/make-task`) or Bug (`/make-bug`) with its branch and worktree, and the run stops there — no implementation, no PR.	comment — bare or with prose	None — the OWNER comment guard is the only gate; `environment: production` was dropped. ⚠️ Secrets moved from the `production` environment to repo-level, pending redistribution (JST-225 AC#4) — until done the bootstrap fails loud.	• `demo-claude-issue-to-task.yml` — Claude Code CLI · `/make-task` • `demo-claude-issue-to-bug.yml` — Claude Code CLI · `/make-bug`
Smoke test	No skill is invoked. Installs a coding assistant on the runner, points its config at this plugin's `skills/`, and drives one plain inference to prove the backend is wired up — the plumbing check you run before trusting a new client or model with a real flow. Answers "does this assistant install, authenticate, find the skills, and return a completion in CI?", nothing more.	manual	None — declares no `environment`, so it never pauses and reads no environment secrets	• `demo-kimi-openrouter-reviewer.yml` — Kimi Code + OpenRouter · `workflow_dispatch` — installs Kimi, writes a `config.toml` whose `extra_skill_dirs` points at the plugin, then runs one hand-written review prompt over `gh pr diff` and posts the result to the PR

"Up to" is doing real work in that column. environment: production in a workflow file does two separable things, and only one of them is automatic:

Always — it scopes which secrets the job can read. A job without it sees empty strings for every environment secret and fails its own up-front check.
Only if you ask for it — it pauses for a human. The pause comes from the Required reviewers protection rule on the environment itself (§3.3), not from the workflow file. Leave that box unchecked and every one of these runs start to finish with no approval prompt at all, still correctly scoped to the environment's secrets.

So the counts above are the number of jobs that would pause — one gate per gated job — once Required reviewers is enabled. Toggling that one checkbox is what turns these demos from unattended to fully gated, with no workflow edit.

Four more things the matrix makes visible:

The smoke test is the odd one out, and that's the point. The first four rows all invoke skills; the last deliberately doesn't. It's the rung below them — when a run fails on a new backend, the smoke test tells you whether the assistant is even installed and answering before you go looking for a bug in the skills. Run it first on any client you haven't used here before.
Backend coverage is uneven, deliberately. The feature flow and the PR review exist on more than one backend because those are the two flows worth proving portable; the hotfix and issue-to-* demos ship Claude-only. A missing cell is an un-built demo, not an unsupported combination — the skills themselves don't know which model is driving them.
The trigger word encodes the backend, not the flow. /make-feature and /fcc-make-feature run the same scenario on different models. They're deliberately different words so that one comment doesn't start both workflows at once on a repo where both are installed.
The trigger comment can carry prose, and the prose steers the run. Every comment-triggered demo above accepts its command bare or followed by a space or a newline and free-form text:
```
/make-feature split this into sub-tasks per service, and skip the docs
```
The workflow strips the command token and hands the remainder to the skill — appended to the assigner's prompt as a labelled EXTRA DIRECTION FOR THIS RUN section (the GitHub issue stays the task description), or passed to the reviewer as its skill argument, which jira-task-reviewer reads as free-form notes about the run. A bare command behaves exactly as it always has.

What this does not loosen is the gate: the author check (OWNER) and the issue-vs-PR check are untouched and still live in the job-level if:, the prose is never gating input, and the command still has to be the first token followed by a separator — /reviewer-anything and a mid-sentence mention both stay inert.

3. The two-gate convention for assistant workflows

Every workflow that executes a coding assistant declares two separable gates to control when and by whom the assistant can be invoked. The convention is named and linkable so every new workflow added to this repo gets both gates by construction rather than by someone remembering.

3.1 Rule 1: Environment gate — scopes secrets and pauses for approval

Every job that executes a coding assistant declares environment: production. That does two separable things:

Always — it scopes which secrets the job can read. A job without it sees empty strings for every environment secret and fails its own up-front check.
Only if you ask for it — it pauses for a human. The pause comes from the Required reviewers protection rule on the environment itself (see §3.3 below), not from the workflow file. Leave that box unchecked and every one of these runs start to finish with no approval prompt at all, still correctly scoped to the environment's secrets.

The exception that proves the rule: precheck and gating jobs (e.g., check_pr_exists, check_branch, and equivalents) stay ungated and secret-free deliberately. They must run before the environment gate so a bad trigger is rejected without asking a human to approve anything and without spending a model token.

3.2 Rule 2: Owner-only author gate — cheap precheck before the environment gate

Every workflow reachable by someone other than the repository owner carries an owner-only author gate on a cheap, secret-free precheck job that runs before the environment gate. The predicate depends on the trigger:

issue_comment — github.event.comment.author_association == 'OWNER'. MEMBER is not accepted — a single merged PR earns MEMBER association, which is too loose for a trigger that runs an LLM with write permissions.
workflow_dispatch — github.triggering_actor == github.repository_owner, because there is no comment and therefore no author_association. Prefer triggering_actor over actor so a non-owner cannot re-run an owner's earlier dispatch.

3.3 Create the environment

Repo Settings → Environments → New environment.
Name it production — this exact name is hardcoded in the workflows.
(Optional, but the point of the demos) Check Required reviewers and add the approver(s). This is the step the approval gates come from — with it unchecked the workflows still run, just unattended. Steps 1–2 alone only give the jobs access to the environment's secrets.
Click Save protection rules.

3.4 What each gate buys you

Assuming Required reviewers is enabled on the production environment:

Job	Pauses before	What you can inspect at that point
Assigner	Job starts	Nothing yet created — first chance to decide the issue is even worth turning into work.
Executor	Job starts	Jira issue exists, `feature/`/`hotfix/` branch is pushed — inspect before any code gets written.
Reviewer	Job starts	Implementation is pushed, PR is open — eyeball the diff before spending review tokens on it.

One production environment reused by every job is enough — the rule fires per job, so it still yields one checkpoint per skill.

3.5 Environment secrets

All credentials live as environment secrets on production, not repo-level secrets — a job that forgets environment: production reads empty strings and fails its own up-front secret check rather than silently running with the wrong identity. The issue-to-task/bug twins are the one exception: they read repo-level secrets (the gate is gone), pending the redistribution from production called out in ci-issue-to-task-demo.md.

Secret	Used by	Notes
`JIRA_ACCOUNT_URL`	every job	e.g. `<your-site>.atlassian.net`, no scheme.
`JIRA_ASSIGNER_EMAIL` / `JIRA_ASSIGNER_TOKEN`	assigner job	Assigner's own Jira identity.
`JIRA_EXECUTOR_EMAIL` / `JIRA_EXECUTOR_TOKEN`	executor job (+ `_EMAIL` also read by the assigner job, as the assignment target, not a credential)	Executor's own Jira identity.
`JIRA_REVIEWER_EMAIL` / `JIRA_REVIEWER_TOKEN`	reviewer job	Reviewer's own Jira identity.
`CLAUDE_CODE_OAUTH_TOKEN`	every job on the Claude-Code-backed demos	Read by the `claude` CLI from the environment — never written into the env file. Not used by the FCC + NVIDIA NIM demos, which authenticate to NIM instead (see below).
`NVIDIA_NIM_API_KEY`	`demo-fcc-nvidia-nim-feature-flow.yml`, `demo-fcc-nvidia-nim-reviewer.yml`, `demo-fcc-nvidia-nim-reviewer-workflow-dispatch.yml`	The FCC + NIM demos' equivalent of `CLAUDE_CODE_OAUTH_TOKEN` — model backend credential instead of the Claude Code CLI's.

GITHUB_PAT_TOKEN is not a secret to create here: every workflow always populates it from the runner's built-in secrets.GITHUB_TOKEN, which can push, open a PR, and comment given each job's permissions: block. It stays an env-file key (see "Common patterns across the CI demos" above) because the skills' statuscheck reads it from .jst/jira-sdlc-tools.local.env to log gh in — a real PAT is only needed there, for local/dev use. One limitation of the built-in token carries over unchanged in CI: PRs it opens don't trigger other workflows.

3.6 Setting secrets via GitHub CLI

gh secret set JIRA_ACCOUNT_URL      --repo <OWNER>/<REPO> --body "<your-site>.atlassian.net" --env production
gh secret set JIRA_ASSIGNER_EMAIL   --repo <OWNER>/<REPO> --body "<assigner-identity-email>"  --env production
gh secret set JIRA_ASSIGNER_TOKEN   --repo <OWNER>/<REPO> --body "<assigner-api-token>"        --env production
gh secret set JIRA_EXECUTOR_EMAIL   --repo <OWNER>/<REPO> --body "<executor-identity-email>"  --env production
gh secret set JIRA_EXECUTOR_TOKEN   --repo <OWNER>/<REPO> --body "<executor-api-token>"        --env production
gh secret set JIRA_REVIEWER_EMAIL   --repo <OWNER>/<REPO> --body "<reviewer-identity-email>"  --env production
gh secret set JIRA_REVIEWER_TOKEN   --repo <OWNER>/<REPO> --body "<reviewer-api-token>"        --env production
gh secret set CLAUDE_CODE_OAUTH_TOKEN --repo <OWNER>/<REPO> --body "<claude-code-oauth-token>" --env production
# Only for the FCC + NVIDIA NIM demos, in place of CLAUDE_CODE_OAUTH_TOKEN
gh secret set NVIDIA_NIM_API_KEY    --repo <OWNER>/<REPO> --body "<nvidia-nim-api-key>"         --env production

--env production scopes each secret to that environment, so it's only readable from jobs that declare environment: production. The issue-to-task and issue-to-bug twins are the exception — those jobs dropped environment: production, so set the same keys as repo secrets (drop the --env production) rather than environment ones, until the redistribution called out by JST-225 AC#4 is done.

3.7 Copy-pasteable gate snippets

For `issue_comment`-triggered workflows

jobs:
  check_comment:
    name: guard — comment gate
    runs-on: ubuntu-latest
    # No environment: production — this is the precheck gate
    outputs:
      should_run: ${{ steps.guard.outputs.should_run }}
    steps:
      - id: guard
        if: >-
          contains(github.event.comment.body, '/make-feature') &&
          (github.event.comment.author_association == 'OWNER') &&
          (github.event.issue.pull_request == null)
        run: echo "should_run=true" >> $GITHUB_OUTPUT

  assign:
    name: assigner
    needs: check_comment
    if: needs.check_comment.outputs.should_run == 'true'
    runs-on: ubuntu-latest
    environment: production  # ← environment gate here
    steps:
      # ... skill steps

For `workflow_dispatch`-triggered workflows

on:
  workflow_dispatch:

jobs:
  check_actor:
    name: guard — dispatch gate
    runs-on: ubuntu-latest
    # No environment: production — this is the precheck gate
    outputs:
      should_run: ${{ steps.guard.outputs.should_run }}
    steps:
      - id: guard
        if: github.triggering_actor == github.repository_owner
        run: echo "should_run=true" >> $GITHUB_OUTPUT

  assign:
    name: assigner
    needs: check_actor
    if: needs.check_actor.outputs.should_run == 'true'
    runs-on: ubuntu-latest
    environment: production  # ← environment gate here
    steps:
      # ... skill steps

3.1 Create the environment

Repo Settings → Environments → New environment.
Name it production — this exact name is hardcoded in the workflows.
(Optional, but the point of the demos) Check Required reviewers and add the approver(s). This is the step the approval gates come from — with it unchecked the workflows still run, just unattended. Steps 1–2 alone only give the jobs access to the environment's secrets.
Click Save protection rules.

3.2 What each gate buys you

Assuming Required reviewers is enabled:

Job	Pauses before	What you can inspect at that point
Assigner	Job starts	Nothing yet created — first chance to decide the issue is even worth turning into work.
Executor	Job starts	Jira issue exists, `feature/`/`hotfix/` branch is pushed — inspect before any code gets written.
Reviewer	Job starts	Implementation is pushed, PR is open — eyeball the diff before spending review tokens on it.

One production environment reused by every job is enough — the rule fires per job, so it still yields one checkpoint per skill.

3.3 Environment secrets

Secret	Used by	Notes
`JIRA_ACCOUNT_URL`	every job	e.g. `<your-site>.atlassian.net`, no scheme.
`JIRA_ASSIGNER_EMAIL` / `JIRA_ASSIGNER_TOKEN`	assigner job	Assigner's own Jira identity.
`JIRA_EXECUTOR_EMAIL` / `JIRA_EXECUTOR_TOKEN`	executor job (+ `_EMAIL` also read by the assigner job, as the assignment target, not a credential)	Executor's own Jira identity.
`JIRA_REVIEWER_EMAIL` / `JIRA_REVIEWER_TOKEN`	reviewer job	Reviewer's own Jira identity.
`CLAUDE_CODE_OAUTH_TOKEN`	every job on the Claude-Code-backed demos	Read by the `claude` CLI from the environment — never written into the env file. Not used by the FCC + NVIDIA NIM demos, which authenticate to NIM instead (see below).
`NVIDIA_NIM_API_KEY`	`demo-fcc-nvidia-nim-feature-flow.yml`, `demo-fcc-nvidia-nim-reviewer.yml`, `demo-fcc-nvidia-nim-reviewer-workflow-dispatch.yml`	The FCC + NIM demos' equivalent of `CLAUDE_CODE_OAUTH_TOKEN` — model backend credential instead of the Claude Code CLI's.

3.4 Setting secrets via GitHub CLI

gh secret set JIRA_ACCOUNT_URL      --repo <OWNER>/<REPO> --body "<your-site>.atlassian.net" --env production
gh secret set JIRA_ASSIGNER_EMAIL   --repo <OWNER>/<REPO> --body "<assigner-identity-email>"  --env production
gh secret set JIRA_ASSIGNER_TOKEN   --repo <OWNER>/<REPO> --body "<assigner-api-token>"        --env production
gh secret set JIRA_EXECUTOR_EMAIL   --repo <OWNER>/<REPO> --body "<executor-identity-email>"  --env production
gh secret set JIRA_EXECUTOR_TOKEN   --repo <OWNER>/<REPO> --body "<executor-api-token>"        --env production
gh secret set JIRA_REVIEWER_EMAIL   --repo <OWNER>/<REPO> --body "<reviewer-identity-email>"  --env production
gh secret set JIRA_REVIEWER_TOKEN   --repo <OWNER>/<REPO> --body "<reviewer-api-token>"        --env production
gh secret set CLAUDE_CODE_OAUTH_TOKEN --repo <OWNER>/<REPO> --body "<claude-code-oauth-token>" --env production
# Only for the FCC + NVIDIA NIM demos, in place of CLAUDE_CODE_OAUTH_TOKEN
gh secret set NVIDIA_NIM_API_KEY    --repo <OWNER>/<REPO> --body "<nvidia-nim-api-key>"         --env production

4. Quick reference — which demo to start from

Goal	Start with
See a full feature flow in CI with approval gates	`demo-claude-feature-flow.yml` + ci-feature-flow-demo.md
See a hotfix flow targeting production	`demo-claude-hotfix-flow.yml` + ci-hotfix-flow-demo.md
Just want automated PR review on a comment	`demo-claude-reviewer.yml`
Turn a commented issue into a Jira Task (or Bug) with the assigner alone	`demo-claude-issue-to-task.yml` / `demo-claude-issue-to-bug.yml` + ci-issue-to-task-demo.md
Try a different LLM backend on the feature flow	`demo-fcc-nvidia-nim-feature-flow.yml`
Try a different LLM backend on review only	`demo-fcc-nvidia-nim-reviewer.yml`
Review a PR on FCC + NIM with the model picked at dispatch time	`demo-fcc-nvidia-nim-reviewer-workflow-dispatch.yml`
Just confirm a new client installs, finds the skills, and can infer at all	`demo-kimi-openrouter-reviewer.yml` (the smoke-test scenario)

5. What these demos are not

Not a replacement for this repo's own SDLC — work here is human-driven end to end (SDLC.md).
Not production incident response — the hotfix demo exercises the branch semantics of a hotfix, not an actual incident process.
Not a durable pipeline on hosted runners — worktrees don't persist across jobs; each job explicitly rebuilds what it needs from the pushed branch.
Not a composite action — bootstrap steps are deliberately duplicated across workflow files so each one stays copy-pasteable into another repo without pulling in a shared helper file.

Document	Covers
ci-feature-flow-demo.md	Deep dive on `demo-claude-feature-flow.yml`
ci-hotfix-flow-demo.md	Deep dive on `demo-claude-hotfix-flow.yml`
ci-review-pr-demo.md	Deep dive on the review-a-PR scenario and its implementations
ci-issue-to-task-demo.md	Deep dive on `demo-claude-issue-to-task.yml` and its `/make-bug` twin `demo-claude-issue-to-bug.yml`
ci-smoke-test-demo.md	The no-skill backend check — `demo-kimi-openrouter-reviewer.yml`
SDLC.md	This repo's actual release/hotfix procedure
CI.md	Workflow-by-workflow CI reference
INSTALLATION.md	Installing the plugin / loose skills
project-config.md	Every `<TOKEN>` resolved from `.jst/jira-sdlc-tools.env`

1. Summary — two ways to use the plugin​

2. Usage applications​

2a. Classic — interactive, on your own machine​

2b. CI usage — GitHub Actions demos​

Common patterns across the CI demos​

2c. The same demos, by scenario​

3. The two-gate convention for assistant workflows​

3.1 Rule 1: Environment gate — scopes secrets and pauses for approval​

3.2 Rule 2: Owner-only author gate — cheap precheck before the environment gate​

3.3 Create the environment​

3.4 What each gate buys you​

3.5 Environment secrets​

3.6 Setting secrets via GitHub CLI​

3.7 Copy-pasteable gate snippets​

For issue_comment-triggered workflows​

For workflow_dispatch-triggered workflows​

3.1 Create the environment​

3.2 What each gate buys you​

3.3 Environment secrets​

3.4 Setting secrets via GitHub CLI​

4. Quick reference — which demo to start from​

5. What these demos are not​

6. Related docs​