fix(.claude): allow Skill tool + correct acli comment list syntax (DSPX-3302)

Headless dogfooding (runs 1 and 2 of scenario-from-ticket on DSPX-2719)
surfaced two real gaps:

- The `Skill` tool was denied on both runs because the allowlist didn't
  cover it, so the body of SKILL.md wasn't injected on invocation; the
  agent had to manually `Read` the skill file ~25 turns in, wasting time
  and biasing exploration toward grepping unrelated files first.
  Add `Skill(*)` to settings.json and per-skill `Skill(<name>)` entries
  to plugin.json (the latter enumerates exactly what downstream installs
  get, since they shouldn't inherit a wildcard).
- `acli jira workitem comment list` requires `--key <KEY>` (the
  subcommand differs from `view`, which takes the key positionally).
  Both scenario-from-ticket and feature-design had the wrong form;
  corrected, with a one-line note about the asymmetry so the next
  agent doesn't paraphrase.

Verified via run-3 on DSPX-2719: 41 turns / 5m16s / $1.07 (vs run-1's
48 turns / 6m44s / $1.27). Skill tool returned success on first call,
both acli commands ran cleanly, the Story/Task branch produced
`source.ref: main` pins correctly (no more incorrectly defaulting to
`dist: lts`), and the agent's `actual:` field correctly enumerated all
three test-infrastructure prerequisites including a `with_ecdsa_binding`
parameter that run-1's scenario missed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: dmihalcik-virtru

.claude/plugin/plugin.json

@@ -32,6 +32,13 @@
       "Bash(acli jira workitem attachment list *)",
       "Bash(acli jira workitem link list *)",
       "Bash(acli jira project view *)",
+      "Skill(feature-design)",
+      "Skill(scenario-from-ticket)",
+      "Skill(scenario-matrix)",
+      "Skill(scenario-up)",
+      "Skill(scenario-run)",
+      "Skill(scenario-tear-down)",
+      "Skill(instance-status)",
       "Write(xtest/scenarios/**)",
       "Write(xtest/features/**)",
       "Write(xtest/bug_*_test.py)",

.claude/settings.json

@@ -23,6 +23,7 @@
       "Bash(acli jira project view *)",
       "Bash(acli jira board view *)",
       "Bash(acli jira sprint view *)",
+      "Skill(*)",
       "Write(xtest/scenarios/**)",
       "Write(xtest/features/**)",
       "Write(xtest/bug_*_test.py)",

.claude/skills/feature-design/SKILL.md

@@ -22,11 +22,11 @@ Two ideas to internalize before reading the steps:
 
 ### Step 1 — Pull the Jira context
 
-If a Jira key was given, run both — comments often carry scope refinements that aren't in the description:
+If a Jira key was given, run both — `view` takes the key positionally, `comment list` requires `--key`; comments often carry scope refinements that aren't in the description:
 
 ```bash
 acli jira workitem view <JIRA-KEY> --fields '*all' --json
-acli jira workitem comment list <JIRA-KEY>
+acli jira workitem comment list --key <JIRA-KEY>
 ```
 
 Extract Issue Type, summary, description, status, and any comments about scope or implementation notes. If no Jira key, the user's description IS the spec input.

.claude/skills/scenario-from-ticket/SKILL.md

@@ -17,11 +17,11 @@ The Jira key also becomes the working **branch name** (`<JIRA-KEY>-repro` for Bu
 
 ## Step 1 — Pull the Jira ticket into context
 
-**Always run BOTH commands**. Don't skip the comment list — comments often carry the most recent reproduction status, "what changed" notes, or "fixed by PR #N" pointers that aren't in the original description:
+**Always run BOTH commands** — exactly as shown; the two subcommands take the key differently (`view` is positional, `comment list` requires `--key`). Don't skip the comment list — comments often carry the most recent reproduction status, "what changed" notes, or "fixed by PR #N" pointers that aren't in the original description:
 
 ```bash
 acli jira workitem view <JIRA-KEY> --fields '*all' --json
-acli jira workitem comment list <JIRA-KEY>
+acli jira workitem comment list --key <JIRA-KEY>
 ```
 
 From the JSON output of the first command, extract: