feat(pipeline): migrate to skills/ structure + add standalone skills

.claude/agents/backend-agent.md

@@ -34,7 +34,7 @@ Every `{TEMP_ROOT}`, `{REPO}`, etc. below refers to these runtime values.
 
 1. Read the spec in full.
 2. Read the dispatch plan — note exactly which files you own and any constraints.
-3. Read `.claude/commands/imagify-architecture.md` and `.claude/commands/compliance.md`.
+3. Read `.claude/skills/imagify-architecture/SKILL.md` and `.claude/skills/compliance/SKILL.md`.
 4. Read each PHP file you are responsible for in full.
 
 ---
@@ -82,7 +82,7 @@ Follow the spec's **Implementation Plan** for backend files only. Do not touch J
 
 ### Step 2.5 — Documentation update
 
-Invoke the `docs` skill inline (`.claude/commands/docs.md`).
+Invoke the `docs` skill inline (`.claude/skills/docs/SKILL.md`).
 
 Pass the explicit list of PHP files you changed in Step 2 — the skill needs this rather than inferring from git.
 
@@ -96,13 +96,13 @@ Record: `docs.status`, `docs.files_updated`, `docs.files_created`.
 
 ### Step 3b — DOD L1 (self-check)
 
-Invoke the `dod` skill inline (`.claude/commands/dod.md`) with `layer: "1"`.
+Invoke the `dod` skill inline (`.claude/skills/dod/SKILL.md`) with `layer: "1"`.
 
 The skill runs the 6 checks: manual validation, automated tests, documentation, PR description, CI (local commands at this layer), and file-scope compliance. It returns `overall: "PASS" | "WARN"` plus per-check evidence.
 
 **Self-correct any FAIL before committing.** Common fixes:
 - `automated-tests` FAIL → write the missing test, fix the failing assertion
-- `ci` FAIL (PHPCS/PHPStan) → fix the violations using the patterns in `.claude/commands/compliance.md` and `specs/phpcs/`
+- `ci` FAIL (PHPCS/PHPStan) → fix the violations using the patterns in `.claude/skills/compliance/SKILL.md` and `specs/phpcs/`
 - `documentation` FAIL → re-run the docs skill, ensure the public-API change is documented
 - `pr-description` FAIL → not applicable at L1 (no PR yet)
 
@@ -117,7 +117,7 @@ The skill runs the 6 checks: manual validation, automated tests, documentation,
 | Integration tests | `composer test-integration` |
 | Full test suite | `composer run-tests` |
 
-**PHPCS / PHPCS-changed note:** `composer phpcs-changed` is preferred for incremental checks during implementation. Run `composer phpcs` (full) only when needed. Fix all violations — do NOT add `phpcs:ignore` inline unless the compliance spec explicitly permits it (see `.claude/commands/compliance.md` and `specs/phpcs/` for correct remediation patterns).
+**PHPCS / PHPCS-changed note:** `composer phpcs-changed` is preferred for incremental checks during implementation. Run `composer phpcs` (full) only when needed. Fix all violations — do NOT add `phpcs:ignore` inline unless the compliance spec explicitly permits it (see `.claude/skills/compliance/SKILL.md` and `specs/phpcs/` for correct remediation patterns).
 
 **PHPCS excluded sniffs** (already suppressed in `phpcs.xml` — do not add ignores for these):
 - `WordPress.Security.NonceVerification.Missing`

.claude/agents/frontend-agent.md

@@ -34,7 +34,7 @@ Every `{TEMP_ROOT}`, `{REPO}`, etc. below refers to these runtime values.
 
 1. Read the spec in full.
 2. Read the dispatch plan — note exactly which files you own and any constraints.
-3. Read `.claude/commands/imagify-frontend-architecture.md` and `.claude/commands/compliance.md`.
+3. Read `.claude/skills/imagify-frontend-architecture/SKILL.md` and `.claude/skills/compliance/SKILL.md`.
 4. Read each JS/SCSS/HTML file you are responsible for in full.
 
 ---
@@ -78,7 +78,7 @@ Mark `automated-tests` as `N/A` in DOD L1 unless the spec explicitly adds a JS u
 
 ### Step 2.5 — Documentation update
 
-Invoke the `docs` skill inline (`.claude/commands/docs.md`).
+Invoke the `docs` skill inline (`.claude/skills/docs/SKILL.md`).
 
 Pass the explicit list of JS/SCSS/HTML files you changed in Step 2 — the skill needs this rather than inferring from git.
 
@@ -92,7 +92,7 @@ Record: `docs.status`, `docs.files_updated`, `docs.files_created`.
 
 ### Step 3b — DOD L1 (self-check)
 
-Invoke the `dod` skill inline (`.claude/commands/dod.md`) with `layer: "1"`.
+Invoke the `dod` skill inline (`.claude/skills/dod/SKILL.md`) with `layer: "1"`.
 
 For frontend changes, the relevant checks are:
 - `automated-tests` → No JS unit suite is configured for Imagify. Mark as `N/A`. Playwright E2E is handled by the QA agent, not here.

.claude/agents/grooming-agent.md

@@ -106,7 +106,7 @@ Use the knowledge graph first, then read files.
 
 If the issue describes a current behavior that you want to verify *before* writing the
 spec — for example, "the cache header is missing on logged-in users" — invoke the `e2e`
-skill (`.claude/commands/e2e.md`) with `tier: "basic"` to reproduce against the
+skill (`.claude/skills/e2e/SKILL.md`) with `tier: "basic"` to reproduce against the
 local environment at `http://localhost:8888` (admin: admin / password).
 
 Use this only when an assumption needs verification. Skip it for changes where the
@@ -143,11 +143,11 @@ This is a separate question from where the fix goes — ask it first.
   - Option B: move/refactor — state effort, risk, and the architectural improvement gained.
 
 **d. Project-specific architecture checks:**
-Read `.claude/commands/{ARCH_SKILL}.md` and verify the candidate solution complies with all coding rules defined there. In particular:
+Read `.claude/skills/{ARCH_SKILL}/SKILL.md` and verify the candidate solution complies with all coding rules defined there. In particular:
 - New classes must be PSR-4 under `classes/` with `declare(strict_types=1)`.
 - Hooks must use `SubscriberInterface` in a `ServiceProvider::get_subscribers()` — not `add_action`/`add_filter` calls scattered in constructors.
 - Nonce action names follow the convention `imagify_<feature>_<action>`.
-- PHPCS excluded sniffs (NonceVerification.Missing, NonceVerification.Recommended) are excluded for a reason — do not add blanket `phpcs:ignore`; instead use the correct remediation patterns from `.claude/commands/compliance.md`.
+- PHPCS excluded sniffs (NonceVerification.Missing, NonceVerification.Recommended) are excluded for a reason — do not add blanket `phpcs:ignore`; instead use the correct remediation patterns from `.claude/skills/compliance/SKILL.md`.
 - Strauss prefixes vendored deps into `Imagify\Dependencies\` — reference the prefixed namespace, not the original vendor namespace.
 
 **e. Are there edge cases the issue does not mention?**

.claude/agents/lead-reviewer.md

@@ -102,11 +102,11 @@ These findings are the class of issue most likely missed in a diff-only review.
 Check every changed file against:
 
 Load the project rule files using the Read tool:
-- `.claude/commands/{ARCH_SKILL}.md`
-- `.claude/commands/compliance.md`
+- `.claude/skills/{ARCH_SKILL}/SKILL.md`
+- `.claude/skills/compliance/SKILL.md`
 
 If `{FRONTEND_SKILL}` is not null and the diff contains frontend files, also load:
-- `.claude/commands/{FRONTEND_SKILL}.md`
+- `.claude/skills/{FRONTEND_SKILL}/SKILL.md`
 
 Verify every changed file complies with all rules defined in those files, then also check:
 

.claude/agents/release-agent.md

@@ -96,7 +96,7 @@ attempt force-push without explicit instruction.
 ### Step 3 — Initialize PR draft
 
 ```bash
-bash .claude/commands/issue-workflow/scripts/init-pr-draft.sh <N>
+bash .claude/skills/issue-workflow/scripts/init-pr-draft.sh <N>
 ```
 
 This creates `{TEMP_ROOT}/issues/<N>/pull.md` from the template.

.claude/skills/challenge/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: challenge
+description: Adversarially review a grooming spec before implementation starts. Finds hidden risks, unvalidated assumptions, and missing dependencies. Standalone entry point for the challenger agent.
+argument-hint: <issue-number>
+---
+
+# Challenge
+
+Standalone adversarial spec review. Runs the full challenger analysis on an existing
+grooming spec and outputs a verdict (APPROVED / NEEDS_REVISION / BLOCKED) with
+MoSCoW-classified findings. Posting to the GitHub issue is your choice — you are
+prompted at the end.
+
+## Step 1 — Load config and locate files
+
+Read project config from the orchestrator's `## Project Config` block:
+
+```bash
+ORCHESTRATOR=".claude/skills/orchestrator/SKILL.md"
+REPO=$(grep '^REPO=' "$ORCHESTRATOR" | cut -d= -f2)
+TEMP_ROOT=$(grep '^TEMP_ROOT=' "$ORCHESTRATOR" | cut -d= -f2)
+```
+
+Use `$ARGUMENTS` as the issue number `N`. Verify both files exist:
+- Issue file: `{TEMP_ROOT}/issues/<N>/issue.md`
+- Spec file: `{TEMP_ROOT}/issues/<N>/spec.md`
+
+If the spec does not exist, tell the user: "No spec found for issue #N. Run `/groom <N>`
+first to produce one." Stop here.
+
+If only the issue file is missing, sync it:
+```bash
+bash .claude/skills/issue-workflow/scripts/issue-sync.sh <N>
+```
+
+## Step 2 — Invoke the challenger agent
+
+Invoke the `challenger` sub-agent with:
+- Issue number `N`
+- Issue file path: `{TEMP_ROOT}/issues/<N>/issue.md`
+- Spec file path: `{TEMP_ROOT}/issues/<N>/spec.md`
+- `plan_version`: 1 (or detect from the spec's `Plan v<N>` header if present)
+- `CURRENT_MODEL`: "standalone"
+- `session_learnings`: read Section 13 of `AGENTS.md` if it exists, else pass empty string
+- Runtime values: `TEMP_ROOT={TEMP_ROOT}`, `REPO={REPO}`
+
+> **STANDALONE MODE** — one difference from the normal pipeline run:
+> **Skip the StructuredOutput JSON return.** Output the full human-readable verdict
+> (APPROVED / NEEDS_REVISION / BLOCKED) and findings in a section titled
+> `## Challenge Report`, using the same format the orchestrator would receive
+> (verdict, MoSCoW-classified findings, alternative suggestions).
+
+## Step 3 — Offer to post
+
+After the agent responds, display its `## Challenge Report` and ask:
+
+> **Post this challenge report as a comment on issue #\<N\>?**
+> Reply `yes` to post, `no` to finish here.
+
+**If yes** — post with dedup:
+```bash
+EXISTING_ID=$(gh api repos/{REPO}/issues/<N>/comments \
+  --jq '[.[] | select(.body | contains("<!-- ai-pipeline:challenge -->"))] | last | .id // empty')
+```
+Update with PATCH if found, otherwise post a new comment. Body always starts with
+`<!-- ai-pipeline:challenge -->`.
+
+**If no** — finish. Remind the user: if the verdict is NEEDS_REVISION, update the spec at
+`{TEMP_ROOT}/issues/<N>/spec.md` before running `/groom <N>` again or starting implementation.

.claude/commands/docs.md → .claude/skills/docs/SKILL.md

@@ -100,5 +100,5 @@ For each gap:
 ## Notes
 
 - The docs root is `docs/`. The README at the repo root is for users; developer docs live in `docs/`.
-- For new capabilities, add them to the Project Config block in `.claude/commands/orchestrator.md` under the `CAPABILITIES` entry so the `compliance` skill and PHPCS do not flag future uses.
+- For new capabilities, add them to the Project Config block in `.claude/skills/orchestrator/SKILL.md` under the `CAPABILITIES` entry so the `compliance` skill and PHPCS do not flag future uses.
 - For database schema changes, document the migration version and upgrade path.

.claude/commands/dod.md → .claude/skills/dod/SKILL.md

@@ -124,7 +124,7 @@ Read the repo's PR template:
 cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null
 ```
 
-(Falls back to `.claude/commands/issue-workflow/refs/pr-template.md` if no GitHub
+(Falls back to `.claude/skills/issue-workflow/refs/pr-template.md` if no GitHub
 template exists — same content.)
 
 Then fetch the PR body:

.claude/skills/groom/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: groom
+description: Groom a single GitHub issue — produce an implementation spec and optionally post the grooming summary as a GitHub comment. Standalone entry point for the grooming-agent.
+argument-hint: <issue-number>
+---
+
+# Groom
+
+Standalone grooming for a single issue. Runs the full grooming analysis and writes the spec
+to disk. Posting to GitHub is your choice — you are prompted at the end.
+
+## Step 1 — Load config
+
+Read project config from the orchestrator's `## Project Config` block:
+
+```bash
+ORCHESTRATOR=".claude/skills/orchestrator/SKILL.md"
+REPO=$(grep '^REPO=' "$ORCHESTRATOR" | cut -d= -f2)
+TEMP_ROOT=$(grep '^TEMP_ROOT=' "$ORCHESTRATOR" | cut -d= -f2)
+```
+
+## Step 2 — Sync the issue
+
+Ensure the issue file exists at `{TEMP_ROOT}/issues/<N>/issue.md`. Run:
+
+```bash
+bash .claude/skills/issue-workflow/scripts/issue-sync.sh <N>
+```
+
+If the file already exists and is recent (less than 5 minutes old), skip the sync.
+
+## Step 3 — Invoke the grooming agent
+
+Invoke the `grooming-agent` sub-agent with the following invocation context:
+
+> Issue number: `<N>`
+> Runtime values (do not read any config file — use these directly):
+> - `TEMP_ROOT` = `{TEMP_ROOT}`
+> - `REPO` = `{REPO}`
+> complexity_signal: derive from the issue content yourself
+>
+> **STANDALONE MODE** — two differences from the normal pipeline run:
+> 1. **Skip Step 5 (posting to GitHub).** Instead, include the full comment body you would
+>    have posted in a section titled `## Grooming Comment Draft` at the end of your response.
+>    Use exactly the same format the pipeline would post (including the
+>    `<!-- ai-pipeline:grooming-plan -->` marker), so it is ready to post as-is.
+> 2. **Skip Step 6 (StructuredOutput JSON).** Return a short human-readable summary instead:
+>    effort, risk, complexity, and any open questions.
+
+The spec file is still written to `{TEMP_ROOT}/issues/<N>/spec.md` as normal.
+
+## Step 4 — Offer to post
+
+After the agent responds, display its `## Grooming Comment Draft` to the user, then ask:
+
+> **Post this as a comment on issue #\<N\>?**
+> Reply `yes` to post as-is, `no` to finish without posting, or paste edited text to post a
+> modified version.
+
+**If yes** — check for an existing grooming comment first (dedup):
+
+```bash
+EXISTING_ID=$(gh api repos/{REPO}/issues/<N>/comments \
+  --jq '[.[] | select(.body | contains("<!-- ai-pipeline:grooming-plan -->"))] | last | .id // empty')
+```
+
+Update with PATCH if found, otherwise post a new comment.
+
+**If no** — confirm the spec was written to `{TEMP_ROOT}/issues/<N>/spec.md` and finish.
+
+**If edited** — use the user-provided text as the comment body and post.

.claude/commands/issue-workflow.md → .claude/skills/issue-workflow/SKILL.md

@@ -31,8 +31,8 @@ Use shell commands as the primary approach. The GitHub MCP (`mcp_github_*`) may
 
 | Operation | Shell (primary) | GitHub MCP (if connected) |
 |---|---|---|
-| Issue fetch | `bash .claude/commands/issue-workflow/scripts/issue-sync.sh <N>` | `mcp_github_github_issue_read` |
-| Branch creation | `bash .claude/commands/issue-workflow/scripts/make-issue-branch.sh` | — |
+| Issue fetch | `bash .claude/skills/issue-workflow/scripts/issue-sync.sh <N>` | `mcp_github_github_issue_read` |
+| Branch creation | `bash .claude/skills/issue-workflow/scripts/make-issue-branch.sh` | — |
 | Staging & committing | `git add` / `git commit` | — |
 | Pushing | `git push -u origin <branch>` | — |
 | PR creation | `gh pr create` | `mcp_github_github_create_pull_request` |
@@ -42,7 +42,7 @@ Use shell commands as the primary approach. The GitHub MCP (`mcp_github_*`) may
 
 1. **Extract** the issue number from the user's message.
 
-2. **Fetch the issue** — run `bash .claude/commands/issue-workflow/scripts/issue-sync.sh <N>` (or use the MCP equivalent). Read the resulting file at `.ai/issues/<N>/issue.md`.
+2. **Fetch the issue** — run `bash .claude/skills/issue-workflow/scripts/issue-sync.sh <N>` (or use the MCP equivalent). Read the resulting file at `.ai/issues/<N>/issue.md`.
 
 3. **Check for parent epics** — if `Parent Epic (GitHub)` or `Parent Epics (Task List)` has entries, sync each parent with `issue-sync.sh <epic-N>` and read those files at `.ai/issues/<epic-N>/issue.md` for context.
 

.claude/commands/issue-workflow/scripts/init-pr-draft.sh → .claude/skills/issue-workflow/scripts/init-pr-draft.sh

@@ -28,7 +28,7 @@ fi
 TEMP_ROOT=".ai"
 
 # Template path and output location.
-TEMPLATE="${ROOT_DIR}/.claude/commands/issue-workflow/refs/pr-template.md"
+TEMPLATE="${ROOT_DIR}/.claude/skills/issue-workflow/refs/pr-template.md"
 OUT_DIR="${ROOT_DIR}/${TEMP_ROOT}/issues/${ISSUE_NUMBER}"
 OUT_FILE="${OUT_DIR}/pull.md"
 

.claude/commands/orchestrator.md → .claude/skills/orchestrator/SKILL.md

@@ -159,7 +159,7 @@ Path: `.ai/issues/<N>/workflow-log.html`
 
 - **Create** the log at startup with just the header and an empty event list.
 - **Rewrite the full file** after every action — the event list grows with each update.
-- See `.claude/commands/orchestrator/html-log-format.md` for the full HTML structure and event patterns. Load it on demand (not at session start) to keep context lean.
+- See `.claude/skills/orchestrator/html-log-format.md` for the full HTML structure and event patterns. Load it on demand (not at session start) to keep context lean.
 
 ---
 
@@ -329,7 +329,7 @@ parallel (non-blocking). Main pipeline continues immediately. Log PARALLEL event
 ### Step 4 — Branch creation
 
 ```bash
-bash .claude/commands/issue-workflow/scripts/make-issue-branch.sh <N> "<title>" <prefix> <base_branch>
+bash .claude/skills/issue-workflow/scripts/make-issue-branch.sh <N> "<title>" <prefix> <base_branch>
 ```
 
 Log AGENT event.
@@ -386,7 +386,7 @@ git worktree add .ai/issues/<N>/worktrees/backend <branch>
 git worktree add .ai/issues/<N>/worktrees/frontend <branch>
 ```
 
-**Call the Workflow tool** — read `.claude/commands/orchestrator/workflows/implementation.js` with the Read tool, then call the Workflow tool with:
+**Call the Workflow tool** — read `.claude/skills/orchestrator/runners/implementation.js` with the Read tool, then call the Workflow tool with:
 - `script`: the file contents
 - `args`:
   ```json
@@ -443,7 +443,7 @@ CI is monitored by DOD L2 Check 5 in both modes.
 - **Lead Review** — skip if `effort IN [XS, S]` AND `risk_level == LOW`. Set `skipLeadReview: true`.
 - **QA** — skip only for purely internal refactors. Set `skipQa: true`. For `domains` `frontend` or `both`, or `ui_visible: true` (PHP renders visible admin output), pass `uiVisible: true` so the qa-agent prioritises Strategy B.
 
-**Call the Workflow tool** — read `.claude/commands/orchestrator/workflows/quality-gates.js` with the Read tool, then call the Workflow tool with:
+**Call the Workflow tool** — read `.claude/skills/orchestrator/runners/quality-gates.js` with the Read tool, then call the Workflow tool with:
 - `script`: the file contents
 - `args`:
   ```json
@@ -672,6 +672,6 @@ verifying that downstream agents comply:
 
 ## HTML log format
 
-See `.claude/commands/orchestrator/html-log-format.md` for the complete HTML structure,
+See `.claude/skills/orchestrator/html-log-format.md` for the complete HTML structure,
 CSS, event type patterns, and per-agent detail panel guidelines. Load it on demand when
 you need to write or update a log event — not at session start.

.claude/commands/orchestrator/workflows/quality-gates.js → .claude/skills/orchestrator/runners/quality-gates.js

@@ -93,7 +93,7 @@ const dodPrompt = [
   `Base branch: ${baseBranch}`,
   `Temp root: ${tempRoot}`,
   '',
-  'Read .claude/commands/dod.md for the complete check instructions, then run all Layer 2 checks.',
+  'Read .claude/skills/dod/SKILL.md for the complete check instructions, then run all Layer 2 checks.',
   'This is a fresh, independent read — do not assume Layer 1 caught everything.',
   'When finished, you MUST call the StructuredOutput tool with your results — do not end your turn without calling it.',
 ].join('\n')