diff --git a/.claude/agents/backend-agent.md b/.claude/agents/backend-agent.md index 606c1244..7c05d1ce 100644 --- a/.claude/agents/backend-agent.md +++ b/.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` diff --git a/.claude/agents/frontend-agent.md b/.claude/agents/frontend-agent.md index ce70eca7..ff3a4258 100644 --- a/.claude/agents/frontend-agent.md +++ b/.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. diff --git a/.claude/agents/grooming-agent.md b/.claude/agents/grooming-agent.md index d576a927..e0579fac 100644 --- a/.claude/agents/grooming-agent.md +++ b/.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__`. -- 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?** diff --git a/.claude/agents/lead-reviewer.md b/.claude/agents/lead-reviewer.md index b3d334fb..7e51447f 100644 --- a/.claude/agents/lead-reviewer.md +++ b/.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: diff --git a/.claude/agents/release-agent.md b/.claude/agents/release-agent.md index 105db11d..6cafc3a2 100644 --- a/.claude/agents/release-agent.md +++ b/.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 +bash .claude/skills/issue-workflow/scripts/init-pr-draft.sh ``` This creates `{TEMP_ROOT}/issues//pull.md` from the template. diff --git a/.claude/skills/challenge/SKILL.md b/.claude/skills/challenge/SKILL.md new file mode 100644 index 00000000..9f2e59a5 --- /dev/null +++ b/.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: +--- + +# 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//issue.md` +- Spec file: `{TEMP_ROOT}/issues//spec.md` + +If the spec does not exist, tell the user: "No spec found for issue #N. Run `/groom ` +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 +``` + +## Step 2 — Invoke the challenger agent + +Invoke the `challenger` sub-agent with: +- Issue number `N` +- Issue file path: `{TEMP_ROOT}/issues//issue.md` +- Spec file path: `{TEMP_ROOT}/issues//spec.md` +- `plan_version`: 1 (or detect from the spec's `Plan v` 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 #\?** +> Reply `yes` to post, `no` to finish here. + +**If yes** — post with dedup: +```bash +EXISTING_ID=$(gh api repos/{REPO}/issues//comments \ + --jq '[.[] | select(.body | contains(""))] | last | .id // empty') +``` +Update with PATCH if found, otherwise post a new comment. Body always starts with +``. + +**If no** — finish. Remind the user: if the verdict is NEEDS_REVISION, update the spec at +`{TEMP_ROOT}/issues//spec.md` before running `/groom ` again or starting implementation. diff --git a/.claude/commands/compliance.md b/.claude/skills/compliance/SKILL.md similarity index 100% rename from .claude/commands/compliance.md rename to .claude/skills/compliance/SKILL.md diff --git a/.claude/commands/docs.md b/.claude/skills/docs/SKILL.md similarity index 96% rename from .claude/commands/docs.md rename to .claude/skills/docs/SKILL.md index f179a643..2d8084a0 100644 --- a/.claude/commands/docs.md +++ b/.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. diff --git a/.claude/commands/dod.md b/.claude/skills/dod/SKILL.md similarity index 99% rename from .claude/commands/dod.md rename to .claude/skills/dod/SKILL.md index 7cc3489d..2ad0cea0 100644 --- a/.claude/commands/dod.md +++ b/.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: diff --git a/.claude/commands/e2e.md b/.claude/skills/e2e/SKILL.md similarity index 100% rename from .claude/commands/e2e.md rename to .claude/skills/e2e/SKILL.md diff --git a/.claude/skills/groom/SKILL.md b/.claude/skills/groom/SKILL.md new file mode 100644 index 00000000..682cc363 --- /dev/null +++ b/.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: +--- + +# 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//issue.md`. Run: + +```bash +bash .claude/skills/issue-workflow/scripts/issue-sync.sh +``` + +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: `` +> 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 +> `` 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//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 #\?** +> 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//comments \ + --jq '[.[] | select(.body | contains(""))] | last | .id // empty') +``` + +Update with PATCH if found, otherwise post a new comment. + +**If no** — confirm the spec was written to `{TEMP_ROOT}/issues//spec.md` and finish. + +**If edited** — use the user-provided text as the comment body and post. diff --git a/.claude/commands/issue-workflow.md b/.claude/skills/issue-workflow/SKILL.md similarity index 88% rename from .claude/commands/issue-workflow.md rename to .claude/skills/issue-workflow/SKILL.md index b928c7ab..ebcc78f5 100644 --- a/.claude/commands/issue-workflow.md +++ b/.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 ` | `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 ` | `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 ` | — | | 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 ` (or use the MCP equivalent). Read the resulting file at `.ai/issues//issue.md`. +2. **Fetch the issue** — run `bash .claude/skills/issue-workflow/scripts/issue-sync.sh ` (or use the MCP equivalent). Read the resulting file at `.ai/issues//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 ` and read those files at `.ai/issues//issue.md` for context. diff --git a/.claude/commands/issue-workflow/refs/pr-template.md b/.claude/skills/issue-workflow/refs/pr-template.md similarity index 100% rename from .claude/commands/issue-workflow/refs/pr-template.md rename to .claude/skills/issue-workflow/refs/pr-template.md diff --git a/.claude/commands/issue-workflow/scripts/init-pr-draft.sh b/.claude/skills/issue-workflow/scripts/init-pr-draft.sh similarity index 95% rename from .claude/commands/issue-workflow/scripts/init-pr-draft.sh rename to .claude/skills/issue-workflow/scripts/init-pr-draft.sh index 73f64ba0..4a61f3e1 100755 --- a/.claude/commands/issue-workflow/scripts/init-pr-draft.sh +++ b/.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" diff --git a/.claude/commands/issue-workflow/scripts/issue-sync.sh b/.claude/skills/issue-workflow/scripts/issue-sync.sh similarity index 100% rename from .claude/commands/issue-workflow/scripts/issue-sync.sh rename to .claude/skills/issue-workflow/scripts/issue-sync.sh diff --git a/.claude/commands/issue-workflow/scripts/make-issue-branch.sh b/.claude/skills/issue-workflow/scripts/make-issue-branch.sh similarity index 100% rename from .claude/commands/issue-workflow/scripts/make-issue-branch.sh rename to .claude/skills/issue-workflow/scripts/make-issue-branch.sh diff --git a/.claude/commands/knowledge-graph.md b/.claude/skills/knowledge-graph/SKILL.md similarity index 100% rename from .claude/commands/knowledge-graph.md rename to .claude/skills/knowledge-graph/SKILL.md diff --git a/.claude/commands/orchestrator.md b/.claude/skills/orchestrator/SKILL.md similarity index 97% rename from .claude/commands/orchestrator.md rename to .claude/skills/orchestrator/SKILL.md index 4957bba2..2a6bc928 100644 --- a/.claude/commands/orchestrator.md +++ b/.claude/skills/orchestrator/SKILL.md @@ -159,7 +159,7 @@ Path: `.ai/issues//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 "" <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. diff --git a/.claude/commands/orchestrator/html-log-format.md b/.claude/skills/orchestrator/html-log-format.md similarity index 100% rename from .claude/commands/orchestrator/html-log-format.md rename to .claude/skills/orchestrator/html-log-format.md diff --git a/.claude/commands/orchestrator/workflows/implementation.js b/.claude/skills/orchestrator/runners/implementation.js similarity index 100% rename from .claude/commands/orchestrator/workflows/implementation.js rename to .claude/skills/orchestrator/runners/implementation.js diff --git a/.claude/commands/orchestrator/workflows/quality-gates.js b/.claude/skills/orchestrator/runners/quality-gates.js similarity index 98% rename from .claude/commands/orchestrator/workflows/quality-gates.js rename to .claude/skills/orchestrator/runners/quality-gates.js index 1493e125..e43fd476 100644 --- a/.claude/commands/orchestrator/workflows/quality-gates.js +++ b/.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') diff --git a/.claude/skills/qa/SKILL.md b/.claude/skills/qa/SKILL.md new file mode 100644 index 00000000..1300416d --- /dev/null +++ b/.claude/skills/qa/SKILL.md @@ -0,0 +1,68 @@ +--- +name: qa +description: Run QA validation on a pull request — boots the local environment, tests acceptance criteria, and optionally posts the report as a PR comment. Standalone entry point for the qa-engineer agent. +argument-hint: <PR-number-or-URL> +--- + +# QA + +Standalone QA run for any PR. Boots the local environment, validates every acceptance +criterion, and produces a test report. 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) +BOOT_CMD=$(grep '^BOOT_CMD=' "$ORCHESTRATOR" | cut -d= -f2-) +LOCAL_URL=$(grep '^LOCAL_URL=' "$ORCHESTRATOR" | cut -d= -f2) +``` + +## Step 2 — Resolve the PR + +Use `$ARGUMENTS` as the PR number or URL. If empty, resolve from the current branch: + +```bash +gh pr list --head "$(git branch --show-current)" --json number,url -q '.[0] | "\(.number) \(.url)"' +``` + +If no PR is found, tell the user and stop. + +Get the base branch: +```bash +gh pr view <PR_NUMBER> --json baseRefName -q .baseRefName +``` + +## Step 3 — Invoke the qa-engineer agent + +Invoke the `qa-engineer` sub-agent with: +- PR number and PR URL +- Base branch from Step 2 +- Runtime values: `TEMP_ROOT={TEMP_ROOT}`, `REPO={REPO}`, `E2E_BOOT={BOOT_CMD}`, + `E2E_URL={LOCAL_URL}` + +> **STANDALONE MODE** — two differences from the normal pipeline run: +> 1. **Skip Step 6 (posting the PR comment).** Instead, output the full QA report as +> formatted Markdown in your response, in a section titled `## QA Report`. Use the same +> format the pipeline would post (including the `<!-- ai-pipeline:qa-report -->` marker). +> 2. **Skip the StructuredOutput JSON return.** Output a short human-readable summary +> instead: overall result, pass/fail per criterion, and any blockers. + +All other steps run normally — the environment is booted (`{BOOT_CMD}`), acceptance +criteria are tested, and the full validation is performed. + +## Step 4 — Offer to post + +After the agent responds, display its `## QA Report` and ask: + +> **Post this QA report to PR #\<PR_NUMBER\>?** +> Reply `yes` to post, `no` to finish here. + +**If yes** — post with dedup: check for an existing `<!-- ai-pipeline:qa-report -->` comment, +update it with PATCH if found, otherwise create a new comment. + +**If no** — confirm the QA run is complete and finish. diff --git a/.claude/skills/review/SKILL.md b/.claude/skills/review/SKILL.md new file mode 100644 index 00000000..fa121e58 --- /dev/null +++ b/.claude/skills/review/SKILL.md @@ -0,0 +1,79 @@ +--- +name: review +description: Run a lead code review on the current branch or a given PR. Standalone entry point for the lead-reviewer agent. +argument-hint: [PR-number-or-URL] +--- + +# Review + +Standalone code review for any PR. Runs the full lead-reviewer analysis against the spec +and project standards. Posting inline comments and the summary 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 — Resolve the PR + +If `$ARGUMENTS` is provided, use it as the PR number or URL. + +Otherwise resolve from the current branch: +```bash +gh pr list --head "$(git branch --show-current)" --json number,url -q '.[0] | "\(.number) \(.url)"' +``` + +If no PR is found, tell the user and stop. + +Get the base branch from the PR: +```bash +gh pr view <PR_NUMBER> --json baseRefName,body -q '{base: .baseRefName, body: .body}' +``` + +Extract the linked issue number from the PR body (`Fixes #N`, `Closes #N`, or a GitHub +issue URL). + +## Step 3 — Locate the spec + +If a linked issue number was found, check for a spec at: +`{TEMP_ROOT}/issues/<N>/spec.md` + +If it exists, pass its path to the agent. +If it does not exist, inform the user: "No grooming spec found — the review will check +against project standards only (spec compliance section will be skipped)." + +## Step 4 — Invoke the lead-reviewer agent + +Invoke the `lead-reviewer` sub-agent with: +- Issue number (if known) and spec path (if found, else omit) +- Base branch from Step 2 +- PR number +- `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** — two differences from the normal pipeline run: +> 1. **Skip Step 5 (inline PR comments) and Step 5b (summary PR comment).** Instead, output +> the full review report — findings table, blockers, nice-to-haves — as formatted Markdown +> in your response, in a section titled `## Review Report`. +> 2. **Skip Step 6 (StructuredOutput JSON).** Return a short human-readable verdict summary +> instead: overall verdict, blocker count, and any open questions. + +## Step 5 — Offer to post + +After the agent responds, display its `## Review Report` and ask: + +> **Post this review to PR #\<PR_NUMBER\>?** +> Reply `yes` to post inline comments + summary, `no` to finish here. + +**If yes** — the agent posts inline comments (Step 5) and the summary comment (Step 5b) +using the normal dedup flow. The `<!-- ai-pipeline:lead-review -->` marker ensures a +later pipeline re-run updates in place rather than duplicating. + +**If no** — confirm the review is complete and finish.