@groupby/ai-dev 0.5.8 → 0.5.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.8",
+  "version": "0.5.9",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {

package/teams/agentic-checkout/prompts/AGENTS.md

@@ -0,0 +1,103 @@
+# AGENTS.md - Brain Checkout Component Instructions
+
+These instructions apply to Brain Checkout component repositories under `components/`.
+
+## Scope
+
+In scope: `bc-agent`, `bc-mcp`, `bc-api`, `bc-pay`, `bc-pay-stripe`, `bc-magento`, `bc-salesforce`, `bc-shopify`,
+`bc-webhooks`, and `bc-lens`. Files outside `components/` are out of component scope unless explicitly requested.
+
+Platform flow: user/assistant -> `bc-lens` -> `bc-agent` -> `bc-mcp` -> `bc-api` -> RabbitMQ -> platform integrations
+and webhook/payment components. See `README.md` for component descriptions and `docs/dependencies.md` for local service
+details.
+
+## Working Rules
+
+- Start with the target component's `.github/copilot-instructions.md` when present.
+- Use only the framework repository-local `tmp/` directory for scratch files, generated temporary files, PR/comment body
+  files, command captures, and other temporary artifacts. Never use `/tmp`, `/var/tmp`, or temp directories outside this
+  framework checkout for project work.
+- Avoid generated/dependency/cache outputs when reading/searching: `tmp/`, `node_modules/`, `.next/`, `out/`, `dist/`,
+  `coverage/`, `build/`, `.gradle/`, `target/`, `_build/`, `deps/`, virtualenv/cache directories, and `__pycache__/`.
+- Let Copilot CLI ask for the user's approval before shell commands. Do not enable `/allow-all` or auto-approve command
+  prompts.
+- Keep secrets out of git. Use `secret-safety` before commits/pushes/PRs/config/log changes and run
+  `scripts/check-secrets <repo-path>`.
+- Do not add infrastructure/dependencies unless required and already consistent with the component.
+- Keep changes incremental, behavior-preserving, and scoped to affected components.
+
+## Deterministic Workflow Routing
+
+- For component sync, use the `sync-components` skill, which runs `scripts/sync-components`; do not manually orchestrate
+  clone/fetch/checkout/rebase unless the script fails and the user approves recovery.
+- Sync must preserve dirty component repos. Ask before destructive cleanup.
+- For routine summaries of sync, dependency start/status/log/stop, secret scan, hook install, git status, diff stat, or
+  workspace inventory, prefer deterministic output or `scripts/local-report <kind>` over hosted-model summarization.
+- Local fast model usage is controlled by `BC_FORGE_LOCAL_FAST_MODEL_MODE=auto|always|off`, normally exported by
+  `bin/bc-forge --local-fast-model=<mode>`. In `always`, local setup is required and should not fall back to hosted.
+- If local fast model setup/reporting says it is unavailable, tell the user local summarization is unavailable and the
+  hosted model is being used for that summary.
+- Never use the local fast model for planning, implementation, code/spec/contract review, debugging, PR review, failure
+  analysis, or raw secret/log output that may contain credentials.
+
+## Model Policy
+
+- Planning workflows: use the current Copilot session model unless the user requests another model.
+- Implementation workflows: use the current Copilot session/default model unless the user requests another model.
+- Review workflows: Claude Sonnet 4.6 (`claude-sonnet-4.6`).
+- Implementation/check sub-agents: use the current session/default model unless the user requests another model.
+- Do not hard-code planning or implementation model IDs in framework workflows.
+
+## Jira and Plans
+
+- For Jira-driven component work, identify the Jira ID before editing and use/create that branch in each affected
+  component.
+- Save AI implementation plans at `<component>/.stories/<JIRA-ID>/plan.md` and include them in component commits.
+- Plans are spec-first: review affected specs/contracts before runtime code and list required contract changes.
+- Follow approved plans exactly; update and re-approve plans before scope changes.
+
+## Contracts
+
+Specs/contracts are source of truth:
+
+- `bc-agent/specs/*.yaml`
+- `bc-mcp/specs/*.json`
+- `bc-api/doc/api.doc.yaml`, `bc-api/specs/*.json`
+- `bc-pay/specs/*.json`, `bc-pay-core/src/main/java/com/rezolve/bc/pay/core/messaging/event`
+- `bc-pay-stripe/specs/*.json`
+- Java event/model classes under `src/main/java/com/rezolve/bc/rabbitmq/event`
+
+When APIs/events/config/payment/webhook payloads change, update specs and check producers/consumers before finishing.
+Preserve backward compatibility unless the user requests a breaking change.
+
+## Verification Matrix
+
+Run checks from the affected component directory. Use `component-verification` to choose the narrowest sufficient checks.
+
+| Component | Install/Sync | Test | Build/Lint |
+|---|---|---|---|
+| `bc-agent` | `uv sync` | `uv run pytest test/ -v` | `uv run python -m compileall app` |
+| `bc-lens` | `cd web && npm install` | `cd web && npm run type-check` | `cd web && npm run lint && npm run build` |
+| `bc-mcp` | `uv sync` | `uv run pytest test/ -v` | `uv run python -m compileall mcp` |
+| `bc-api` | `mix deps.get` | `mix test` | `mix format --check-formatted` |
+| `bc-pay` | `./gradlew dependencies` | `./gradlew :bc-pay-core:test` | `./gradlew :bc-pay-api:build :bc-pay-core:build && ./gradlew spotlessCheck` |
+| `bc-pay-stripe` | `./gradlew dependencies` | `./gradlew test --no-daemon` | `./gradlew shadowJar --no-daemon && ./gradlew spotlessCheck --no-daemon` |
+| Java integrations | `./gradlew dependencies` | `./gradlew test` | `./gradlew shadowJar` |
+
+Java integrations are `bc-magento`, `bc-salesforce`, `bc-shopify`, and `bc-webhooks`.
+
+`bc-pay` is a library: after changing `bc-pay-api` or `bc-pay-core`, publish updated artifacts and bump matching
+`bc-pay-stripe/gradle.properties` versions before downstream tests.
+
+## Local Dependencies
+
+Use `scripts/start-deps`, `scripts/status-deps`, `scripts/logs-deps`, and `scripts/stop-deps`. See
+`docs/dependencies.md` for endpoints and component startup details.
+
+## Cross-Component Checklist
+
+- Event payload/routing/type changed: check `bc-api`, Java services, `bc-agent`, `bc-mcp`.
+- Cart API changed: check `bc-api`, `bc-mcp`, specs, tests.
+- MCP/A2A behavior changed: update specs, models, handlers/tools, tests.
+- Payment event/config/PSP behavior changed: check `bc-pay`, `bc-pay-stripe`, `bc-api`, specs, fixtures.
+- Webhook behavior changed: update handler/mapper specs and tests.

package/teams/agentic-checkout/prompts/create-plan.md

@@ -0,0 +1,103 @@
+# Create Component Implementation Plan
+
+Create an implementation plan for a Brain Checkout component task.
+
+## Inputs
+
+Use the user's task description and inspect the repository as needed.
+
+Planning is spec-first: before proposing tasks, identify the affected component specs/contracts and determine required
+additions, changes, or removals so the plan preserves spec/code synchronization.
+
+Always take the `tdd` skill into account while planning. Read and apply the skill when the task asks for TDD, test-first development, regression-test-first bug fixing, or behavior that should be proven by tests. If TDD is not appropriate for the task, say so briefly in the plan's test strategy and provide the focused verification approach instead.
+
+Always use the `grill-me` skill before creating the plan. Run the full stress-test question flow first, resolve every open decision branch with the user, and only then draft and save `plan.md`.
+
+Hard gate: do not create, update, or save any plan file until the `grill-me` flow is complete and all questions are answered.
+
+## Plan Location
+
+For Jira or ticket-driven work, identify the Jira ID before writing the plan.
+
+If one or more Brain Checkout components are affected, save the plan inside each affected component repository under `.stories/`, with a folder named exactly after the Jira ID:
+
+```text
+<component>/.stories/<JIRA-ID>/plan.md
+```
+
+This folder and plan file are part of the component change and must be included in that component's commit as evidence that the work was developed using AI.
+
+If the Jira task does not require changes in any component repository, save the plan in the current session folder using the session plan path (`<session-folder>/plan.md`) provided in session context.
+
+If the task is Jira-driven but no Jira ID can be determined, stop and ask for it before writing the plan.
+
+## Plan Format
+
+```markdown
+# Plan: {short title}
+
+## Plan Metadata
+- Model used: `{model-name}`
+- Git commit SHA: `{current-git-sha}`
+
+## Summary
+{2-3 sentences}
+
+## Affected Components
+- `{component}` - {why}
+
+## Contract Impact
+{none | describe schema/event/API changes and consumers}
+
+## Test Strategy
+{TDD red/green approach, or why TDD is not applicable and the focused verification approach}
+
+## Tasks
+
+### Task 1: {title}
+Goal:
+- {single, testable outcome for this task}
+Files:
+- `{path}` - {change}
+Tests:
+- {failing test to add/update first when using TDD, plus test command}
+Dependencies:
+- {None | Task N}
+
+### Task 2: {title}
+...
+
+## Verification
+- `{command}`
+
+## Risks
+- {risk or "None identified"}
+```
+
+## Rules
+
+- Keep plans to 3-7 tasks.
+- Break work into small, isolated tasks that can be implemented and verified independently.
+- Each task should have one clear outcome and a narrow file scope; avoid mixing unrelated changes in a single task.
+- Prefer an execution order with minimal dependencies between tasks; declare explicit task dependencies when unavoidable.
+- Start from specs/contracts first, then derive implementation tasks from those required contract updates.
+- Backend/API/event contracts before callers.
+- Use the `grill-me` skill before creating every plan.
+- Do not create, update, or save `plan.md` until all `grill-me` questions are answered and every decision branch is resolved.
+- If `grill-me` is still in progress, continue asking the next single question and do not produce plan content yet.
+- Always consider the `tdd` skill while planning and reflect that decision in `Test Strategy`.
+- When the user asks for TDD, test-first development, or regression-test-first bug fixing, use the `tdd` skill while planning.
+- For TDD plans, include the first failing test or test file in each implementation task before production-code changes.
+- Add a `Plan Metadata` section that records the model used to create or update the plan.
+- Add the current git commit SHA to `Plan Metadata` (for component plans, use that component repository SHA; for session-folder plans, use the harness checkout SHA).
+- Keep the plan limited to the affected Brain Checkout components.
+- When no component repository is affected, store the Jira plan in the session plan file (`<session-folder>/plan.md`) instead of component paths.
+- Do not store Jira implementation plans only in the harness checkout; use component `.stories/<JIRA-ID>/plan.md` paths when components are affected.
+## Response Output (Required)
+
+After saving or updating `plan.md`, respond with:
+
+1. A brief summary paragraph (2-3 sentences) covering affected components, contract impact, and test strategy.
+2. The saved file path(s) for each affected component.
+
+Do not render the full plan in the chat response; the saved file is the authoritative source.

package/teams/agentic-checkout/prompts/create-pull-request.md

@@ -0,0 +1,157 @@
+# Create Pull Request to Main
+
+Create a GitHub pull request from the current branch to `main`.
+
+## Goal
+
+Inspect the current branch, summarize the change, push the branch if needed, and create a pull request targeting `main`.
+
+## Required Checks
+
+Run these checks before creating the PR:
+
+```bash
+git status --short
+git branch --show-current
+git remote -v
+gh --version
+gh auth status
+git fetch origin main
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git diff --name-only origin/main...HEAD
+```
+
+Use the `secret-safety` skill and run the harness scanner for the repository being pushed:
+
+```bash
+if [ -x scripts/check-secrets ]; then
+  scripts/check-secrets .
+else
+  ../../scripts/check-secrets .
+fi
+```
+
+Stop and ask the user before continuing if:
+
+- The current branch is `main`.
+- There are uncommitted changes.
+- There are no commits ahead of `origin/main`.
+- The repository has no GitHub remote.
+- `gh` is not installed or the user is not authenticated.
+- The secret scan reports potential credentials or secret-bearing files.
+
+## Review Before PR
+
+Inspect the changed files and identify:
+
+- Components affected
+- Contract or schema changes
+- Secret/config/logging risk
+- Tests or verification commands already run
+- Reasonable remaining risk
+
+If no verification was run in the current session, say that in the PR body.
+
+## Rebase Against Main (Required)
+
+Before creating the PR, update `main` and rebase the current branch on top of it.
+
+If multiple component repositories are affected, do this in **each affected component repository** before creating its
+PR.
+
+```bash
+CURRENT_BRANCH="$(git branch --show-current)"
+git checkout main
+git pull --ff-only origin main
+git checkout "$CURRENT_BRANCH"
+git rebase main
+```
+
+If rebase conflicts occur, stop and ask the user how to proceed.
+
+After a successful rebase, recompute the ahead/diff checks against `origin/main`.
+
+## Push Branch
+
+If the current branch has no upstream, push it:
+
+```bash
+git push -u origin HEAD
+```
+
+If it already has an upstream, push normally:
+
+```bash
+git push
+```
+
+## PR Title
+
+Use this priority order:
+
+1. Existing ticket key in branch name plus concise summary.
+2. Conventional commit-style title inferred from commits.
+3. Concise imperative summary of the diff.
+
+Examples:
+
+```text
+BC-123 Add Shopify cart quantity handling
+Update Brain Checkout dependency startup docs
+Fix webhook mapper payload validation
+```
+
+## PR Body
+
+Delegate drafting to a Haiku sub-agent (see `AGENTS.md` model policy). Pass it `git diff --stat origin/main...HEAD`, `git log --oneline origin/main..HEAD`, and any verification commands run in the session. Have it fill this template:
+
+```markdown
+## Summary
+
+- {high-level change}
+- {important implementation detail}
+
+## Affected Components
+
+- `{component}` - {reason}
+
+## Verification
+
+- `{command}` - {result}
+
+## Notes
+
+- {contract impact, deployment note, or "None"}
+```
+
+Keep the body factual. Do not include generic boilerplate.
+
+## Create PR
+
+Create the PR targeting `main`:
+
+```bash
+gh pr create --base main --head "$(git branch --show-current)" --title "{title}" --body-file "{body-file}"
+```
+
+Use a temporary body file under the harness repository-local `tmp/` directory and remove it after PR creation.
+
+## Request Copilot Review
+
+After creating the PR, request a GitHub Copilot review:
+
+```bash
+gh pr edit "$(gh pr view --json number --jq .number)" --add-reviewer "@copilot"
+```
+
+## Final Response
+
+Report:
+
+- PR URL
+- Source branch
+- Target branch: `main`
+- Title
+- Verification included in the PR body
+- Copilot review requested

package/teams/agentic-checkout/prompts/fix-pr-comments.md

@@ -0,0 +1,170 @@
+# Fix Pull Request Comments
+
+Automatically process review feedback on the current GitHub pull request: collect unresolved comments, implement fixes, verify changes, push updates, and post a completion note.
+
+## Goal
+
+For the branch currently checked out, find its PR, read unresolved review feedback, apply concrete code fixes, run relevant verification, and push a commit that addresses the comments.
+
+## Required Checks
+
+Run these checks before making any changes:
+
+```bash
+git status --short
+git branch --show-current
+git remote -v
+gh --version
+gh auth status
+```
+
+Stop and ask the user before continuing if:
+
+- The current branch is `main`.
+- There are uncommitted changes.
+- The repository has no GitHub remote.
+- `gh` is not installed or the user is not authenticated.
+
+## Discover PR
+
+Resolve the PR for the current branch:
+
+```bash
+gh pr view --json number,title,url,headRefName,baseRefName
+```
+
+Stop and ask the user if no PR is found for the current branch.
+
+## Collect Review Feedback
+
+Delegate the fetch + parse to a Haiku sub-agent (see `AGENTS.md` model policy). The sub-agent should run the GraphQL query, filter to **unresolved, in-scope** comments only, and return a compact JSON list of `{path, line, body, url}` for the session model to act on.
+
+Query template:
+
+```bash
+gh api graphql -f query='
+query($owner:String!, $repo:String!, $number:Int!) {
+  repository(owner:$owner, name:$repo) {
+    pullRequest(number:$number) {
+      comments(first:100) {
+        nodes {
+          author { login }
+          body
+          url
+        }
+      }
+      reviewThreads(first:100) {
+        nodes {
+          isResolved
+          comments(first:100) {
+            nodes {
+              author { login }
+              body
+              path
+              outdated
+              url
+            }
+          }
+        }
+      }
+    }
+  }
+}' -F owner=<owner> -F repo=<repo> -F number=<number>
+```
+
+## Prioritization Rules
+
+Process in this order:
+
+1. Functional bugs and regressions
+2. Contract/schema/API mismatches
+3. Test reliability and missing coverage
+4. Maintainability and readability issues
+5. Style-only comments
+
+Mark for clarification instead of guessing when comments are conflicting or ambiguous.
+
+## Implementation Rules
+
+- Apply minimal, targeted changes per comment.
+- Keep changes scoped to the PR intent.
+- Do not perform unrelated refactors.
+- If behavior changes, update or add tests.
+- If contract/schema changes, update corresponding docs/specs.
+- Use the `secret-safety` skill and do not commit or push secrets from review feedback, logs, config, or examples.
+
+## Verification
+
+Run relevant checks for modified components.
+
+Examples (run only what applies):
+
+```bash
+pytest -q
+mix test
+./gradlew test
+npm test
+```
+
+If full verification is too expensive, run focused checks for touched areas and state this explicitly.
+
+## Commit And Push
+
+After fixes and verification:
+
+```bash
+git status --short
+git diff --stat
+git add -- <files modified for the review fix>
+if [ -x scripts/check-secrets ]; then
+  scripts/check-secrets .
+else
+  ../../scripts/check-secrets .
+fi
+git commit -m "Address PR review comments"
+git push
+```
+
+Stage only the files modified for the review fix. Do not use `git add -A` or `git add .` — these can accidentally stage untracked secrets or generated files. If new files were created as part of the fix, list them explicitly in the `git add` command.
+
+If there are no code changes after analysis, do not create an empty commit; report that no actionable fixes were found.
+
+## Post PR Update
+
+Post a concise PR comment summarizing:
+
+- Fixed items
+- Any items needing clarification (with reason)
+- Verification commands and results
+
+Example structure:
+
+```markdown
+Addressed review feedback:
+
+- Fixed: {item 1}
+- Fixed: {item 2}
+- Needs clarification: {item 3}
+
+Verification:
+- `{command}` - {result}
+- `{command}` - {result}
+```
+
+Use:
+
+```bash
+gh pr comment <number> --body-file <body-file>
+```
+
+Use a temporary file under the harness repository-local `tmp/` directory and remove it after posting.
+
+## Final Response
+
+Report to the user:
+
+- PR URL
+- Number of comments reviewed
+- Number of comments fixed
+- Clarifications needed
+- Commands executed for verification and their outcomes

package/teams/agentic-checkout/prompts/fix-review-findings.md

@@ -35,18 +35,7 @@ Process findings in this order:
 
 ## Verification
 
-Run relevant checks for touched components:
-
-```bash
-uv run pytest test/ -v              # bc-agent, bc-mcp
-mix test                            # bc-api
-mix format --check-formatted        # bc-api
-./gradlew :bc-pay-core:test         # bc-pay
-./gradlew spotlessCheck             # bc-pay
-./gradlew test --no-daemon          # bc-pay-stripe
-./gradlew spotlessCheck --no-daemon # bc-pay-stripe
-./gradlew test                      # bc-magento, bc-salesforce, bc-shopify, bc-webhooks
-```
+Use the `component-verification` skill to run relevant checks for touched components using the canonical verification matrix in `AGENTS.md`.
 
 If full verification is too expensive, run focused checks for touched areas and state what was not run.
 

package/teams/agentic-checkout/prompts/implement-task.md

@@ -0,0 +1,62 @@
+# Implement Component Plan
+
+Implement the full set of tasks from a Brain Checkout component plan in one workflow. Do not start implementation until
+the plan exists in the affected component repository.
+
+## Required Context
+
+Read:
+
+- affected component README (`components/<name>/README.md`)
+- affected component `.github/copilot-instructions.md` if present (`components/<name>/.github/copilot-instructions.md`)
+- relevant specs and tests
+
+## Branch Preparation
+
+Before editing, identify the Jira ID for the task. In each affected component repository, make sure a branch exists for
+that Jira ID and check it out:
+
+- Use the existing local branch when present.
+- If the branch exists on the remote, check it out with tracking.
+- Otherwise create it from the component's default branch.
+- Stop and ask for the Jira ID if the task is ticket-driven but no Jira ID can be determined.
+
+## Plan Preparation
+
+Before editing implementation files, create or verify the plan:
+
+- If `.stories/<JIRA-ID>/plan.md` does not exist in an affected component repository, execute the plan creation workflow from
+  `prompts/create-plan.md` first.
+- Save the plan at `.stories/<JIRA-ID>/plan.md` inside each affected component repository.
+- Read the plan before implementation and use it as the source for the task scope.
+- Treat any model note or `Plan Metadata` entry in the plan as informational only; it must not change task scope, implementation choices, or verification.
+- Include the plan file in the component commit as AI-development evidence.
+- Do not proceed with implementation until the plan exists.
+- If the plan has a TDD test strategy, use the `tdd` skill and follow the planned failing-test step before editing
+  production code.
+- Use the `approval-gated-task-execution` skill for the implementation workflow.
+
+## Implementation Rules
+
+- Follow the approved plan exactly and execute every planned task using the `approval-gated-task-execution` skill.
+- Make only the changes needed for the plan scope.
+- Update schemas/contracts before runtime models.
+- Keep specs/contracts in sync with code at all times; never skip required spec updates.
+- Do not finish implementation while any known spec/code drift remains.
+- Add or update focused tests.
+- Preserve existing formatting and component patterns.
+- Do not add unrelated dependencies.
+- Do not edit out-of-scope folders.
+
+## Verification
+
+Use the `component-verification` skill to run relevant checks from the affected component using the canonical verification matrix in `AGENTS.md`.
+
+If `bc-pay-api` or `bc-pay-core` source changed, also publish the updated library so `bc-pay-stripe` and other consumers
+can resolve it:
+
+```bash
+GITHUB_ACTOR=<user> GITHUB_TOKEN=<pat> ./gradlew publish
+```
+
+Report checks run, failures fixed, and any checks skipped.

package/teams/agentic-checkout/prompts/new-workspace.md

@@ -0,0 +1,12 @@
+# New Workspace
+
+Use for a fresh Brain Checkout workspace.
+
+1. If this is a resumed session (`--resume` was used at startup), skip `/clear` and go to step 2. Otherwise, run `/clear` first.
+2. Ask whether to attach a Jira task ID. If provided, load key Jira details; if loading fails, keep the ID and continue.
+3. Forget previous task context unless the new Jira ID was provided.
+4. Sync with exactly one command: use `scripts/local-fast-report sync` when a summary is useful, otherwise use
+   `scripts/sync-components` for raw output. Label the local summary run as using the local fast model. Do not run both or
+   reimplement sync. Ask before destructive cleanup for each `skipped-dirty` component.
+5. Keep setup lightweight: no dependency install, source inspection, tests/builds/formatters/linters, branches, or plans.
+6. Report Jira context, sync results, skipped-dirty components, and failures. Then wait for the next task or confirmation.

package/teams/agentic-checkout/prompts/orchestrate-component-change.md

@@ -0,0 +1,25 @@
+# Orchestrate Brain Checkout Component Change
+
+Use this prompt with Copilot CLI from the repository root to coordinate an end-to-end component change by delegating to the canonical planning, implementation, verification, review, and PR workflows.
+
+## Approval Gates
+
+This is an approval-gated workflow. After each numbered step, summarize what was done or discovered, ask the user whether to continue, and wait for approval. If the user stops, report current state, files changed, and what remains.
+
+## Steps
+
+1. Identify affected components from `components.txt` and `AGENTS.md`. Keep scope to those components unless a shared API/event/config/payment contract crosses boundaries. Mapping changed paths to components is a good candidate for a Haiku sub-agent (see `AGENTS.md` model policy).
+2. Prepare the task branch in each affected component per the Jira/branch rules in `AGENTS.md`. Stop and ask for the Jira ID if it cannot be determined.
+3. Load component context: README and `.github/copilot-instructions.md` (when present). Defer spec/contract reading to step 4.
+4. Create or update the implementation plan via `prompts/create-plan.md`.
+5. Implement the approved plan via `prompts/implement-task.md` (uses the `approval-gated-task-execution` skill).
+6. Verify with the `component-verification` skill. For contract changes, also apply the cross-component checklist in `AGENTS.md`.
+7. Review via `prompts/review-change.md`. If actionable findings need code changes, run `prompts/fix-review-findings.md`.
+8. Create the PR via `prompts/create-pull-request.md` when requested.
+9. Report: Jira branch per component, plan file paths, files changed, checks run and skipped (with reasons), remaining risks.
+
+## Constraints
+
+- Do not introduce unrelated dependencies or services.
+- Keep edits limited to affected components unless the task expands scope.
+- Do not duplicate detailed rules from delegated workflows; the referenced prompt or skill is the source of truth.