@mohammadhprp/system-prompt 0.12.3 → 0.12.5

package/framework/skills/ponytail/references/ponytail-mode.md

@@ -0,0 +1,33 @@
+# Ponytail mode
+
+Use this operation for `/ponytail`, `/ponytail lite`, `/ponytail full`,
+`/ponytail ultra`, or `/ponytail off`.
+
+Ponytail is active every response until the user says `stop ponytail`, `normal
+mode`, or `/ponytail off`. The default is **full**.
+
+## Levels
+
+| Level | Behavior |
+|---|---|
+| **lite** | Build what was asked, then name the lazier alternative in one line. |
+| **full** | Enforce the YAGNI → existing code → stdlib → native → installed dependency → one line → minimum ladder. Default. |
+| **ultra** | Delete before adding, challenge the requirement, and ship the smallest viable result. |
+
+Use the main skill's ladder and rules for the actual coding task. A mode switch
+does not itself change files or create configuration.
+
+## Configuration
+
+Default resolution is environment variable, then config file, then `full`:
+
+```bash
+export PONYTAIL_DEFAULT_MODE=ultra
+```
+
+Config file: `~/.config/ponytail/config.json` (Windows:
+`%APPDATA%\ponytail\config.json`).
+
+```json
+{ "defaultMode": "lite" }
+```

package/framework/skills/ponytail/references/ponytail-review.md

@@ -0,0 +1,27 @@
+# Ponytail review
+
+Use for `/ponytail-review` or a request to review changes for
+over-engineering. Review the current diff only. Do not apply fixes.
+
+Scope is complexity only; route correctness bugs, security holes, and
+performance issues to a normal review.
+
+Report one finding per line:
+
+`<file>:L<line>: <tag> <what to cut>. <replacement>.`
+
+Tags:
+
+- `delete:` dead code, unused flexibility, or speculative features; replacement
+  is nothing.
+- `stdlib:` hand-rolled functionality supplied by the standard library; name
+  the function.
+- `native:` a dependency or custom code doing what the platform already does;
+  name the native feature.
+- `yagni:` an abstraction with one implementation, unused configuration, or a
+  layer with one caller.
+- `shrink:` equivalent logic that can use fewer lines; show the shorter form.
+
+End with `net: -<N> lines possible.` If there is nothing to cut, say
+`Lean already. Ship.` Do not flag a single smoke test or assert-based
+self-check as bloat.

package/framework/skills/ponytail/references/ponytail-rules.md

@@ -0,0 +1,31 @@
+# Ponytail rules
+
+Lazy means efficient, not careless. The best code is the code never written.
+
+Before writing code, stop at the first rung that holds:
+
+1. Does this need to be built at all? (YAGNI)
+2. Does it already exist in this codebase? Reuse the helper, util, or pattern.
+3. Does the standard library already do this? Use it.
+4. Does a native platform feature cover it? Use it.
+5. Does an already-installed dependency solve it? Use it.
+6. Can this be one line? Make it one line.
+7. Only then: write the minimum code that works.
+
+The ladder runs after understanding the problem, not instead of it. Read the
+task and touched code, trace the real flow end to end, then choose the rung.
+
+For bug fixes, find every caller of the function being changed and fix the
+shared root cause once. Do not scatter symptom guards across callers.
+
+Do not simplify away input validation at trust boundaries, error handling that
+prevents data loss, security, accessibility, hardware calibration, or anything
+explicitly requested. Non-trivial lazy code leaves one runnable check behind;
+trivial one-liners need no test.
+
+Mark deliberate shortcuts with a `ponytail:` comment naming the ceiling and
+upgrade path, for example:
+
+```text
+# ponytail: global lock, per-account locks if throughput matters
+```

package/framework/skills/ponytail/references/principle-boundary-discipline.md

@@ -0,0 +1,7 @@
+# Boundary Discipline
+
+Validate and normalize untrusted data at the boundary, then pass typed and validated values into internal domain code.
+
+Relevant boundaries include FormRequests, route parameters, Artisan arguments, environment configuration, uploaded files, database rows, HTTP responses, CSV or Excel imports, and tenant context. Use existing requests, enums, rules, scopes, and service abstractions.
+
+Do not accept `tenant_id` from untrusted Admin input when authenticated context determines the tenant. Do not repeat defensive validation throughout trusted internal call chains. Keep controllers and framework adapters thin; keep pricing, order, import, and state logic in the established services, actions, pipes, and domain structures.

package/framework/skills/ponytail/references/principle-encode-lessons-in-structure.md

@@ -0,0 +1,13 @@
+# Encode Lessons In Structure
+
+When a rule is repeated, ask whether it belongs in a mechanism rather than another instruction.
+
+Prefer the strongest practical enforcement:
+
+- A type, enum, or database constraint
+- An architecture or security test
+- A canonical helper, scope, policy, or service
+- A runtime guard at the correct boundary
+- A concise project skill when the rule still requires judgment
+
+Examples include enforcing tenant access through existing scopes and middleware, preventing forbidden debugging calls through architecture tests, using unique keys for imports, and centralizing API response envelopes. Do not add a textual reminder when a reliable structural check can prevent the mistake.

package/framework/skills/ponytail/references/principle-fix-root-causes.md

@@ -0,0 +1,17 @@
+# Fix Root Causes
+
+When debugging, do not paper over symptoms. Trace every problem to its root cause and fix it there.
+
+**Why:** Symptom fixes accumulate. Each workaround makes the system harder to reason about, and the real bug remains. Root-cause fixes are slower upfront but reduce total debugging time.
+
+**Pattern:**
+- Reproduce first (if you can't reproduce it, you can't verify your fix)
+- Ask "why" until you hit the root cause
+- Resist the urge to add guards (adding a nil check to silence a crash is a symptom fix)
+- If a workaround needs a paragraph-long comment to justify it, the code is wrong (fix the code, not the comment)
+- Check for the pattern, not just the instance (grep for the same pattern, fix all instances)
+- When stuck, instrument. Don't guess (add logging, read the actual error)
+
+**Restart bugs: suspect state before code**
+
+Code doesn't change between runs. State does. When something "fails after restart," suspect stale persistent state first: config files, caches, lock files, serialized state. If clearing a state file restores behavior, prioritize state validation as the fix.

package/framework/skills/ponytail/references/principle-make-operations-idempotent.md

@@ -0,0 +1,12 @@
+# Make Operations Idempotent
+
+Design state-changing operations so repeated execution converges to the same correct state. Before changing a command, job, importer, pipeline step, or integration, answer:
+
+- What happens if it runs twice?
+- What happens if it crashes after each state change?
+- What happens when Laravel retries the job?
+- Can duplicate records, stock changes, notifications, or external requests occur?
+
+Apply this especially to `app/Imports`, `app/Console/Commands`, `app/Jobs`, order pipes, stock actions, and Rahkaran or Elasticsearch synchronization.
+
+Prefer stable external identifiers, unique database constraints, upserts, transactions, checkpointed progress, and safe retry behavior. Preserve tenant isolation while reconciling partial work. Test a successful run twice and test the important crash or retry boundary when practical.

package/framework/skills/ponytail/references/principle-model-the-domain.md

@@ -0,0 +1,7 @@
+# Model the Domain
+
+Represent domain rules in structures that make invalid states difficult to create instead of spreading conditions across files.
+
+Prefer existing enums, state services, policies, value objects, typed request data, registries, scopes, and pipeline data. For Chideli, inspect `OrderStatusEnum`, `OrderItemStatusEnum`, `OrderStateService`, `OrderPipelineData`, pricing services, and sale policy types before adding branches.
+
+Do not introduce an abstraction only to move code. Add one when it removes duplicated rules, contradictory states, or repeated conditionals. Preserve the existing ownership boundary and cover each meaningful state transition with tests.

package/framework/skills/ponytail/references/principle-prove-it-works.md

@@ -0,0 +1,27 @@
+# Prove It Works
+
+Verify every task output by checking the real thing directly. Do not infer from proxies, self-reports, or "it compiles."
+
+**Why:** Unverified work has unknown correctness. Indirect verification (file mtimes, output freshness, agent self-reports, cached screenshots) feels cheaper than direct observation. Acting on a wrong inference costs far more than checking the source.
+
+**Pattern:** After completing any task, ask: "how do I prove this actually works?"
+
+Check the real thing, not a proxy:
+- Check process liveness directly, not indirectly through derived state
+- Read the actual value, not a cached or derived representation
+- When verification fails, suspect the observation method before suspecting the system
+
+Code and features:
+1. Build it (necessary but not sufficient)
+2. Run it and exercise the actual feature path
+3. Check the full chain: does data flow from input to output?
+4. For integrations, test the full communication path end-to-end
+
+Delegation: trust artifacts, not self-reports.
+When verifying delegated work, inspect the actual output artifact (git diff, file contents, runtime behavior), not the delegate's summary. Agents report what they intended, not always what happened.
+
+## Script the check when you can
+
+The strongest proof is a deterministic script that re-runs the same comparison, not a one-time eyeball. Write the script, run it, and keep its output as an artifact a reviewer can re-run instead of trusting your word. A script comparing the old and new compiled output catches what a glance misses.
+
+Keep the artifact visible for the human. Commit it only for large or complex work where the trail has to be auditable later, like a big port or migration (the **show-me-your-work** skill). Most work just needs it visible, not committed.

package/framework/skills/ponytail/references/principle-sequence-verifiable-units.md

@@ -0,0 +1,7 @@
+# Sequence Work Into Verifiable Units
+
+Break broad work into small units, and verify each unit before starting the next. A unit may be one migration, one endpoint, one importer change, or one focused refactor with its tests.
+
+Start from a known-good state. Make one change. Run the narrowest relevant check. Inspect the result. Then continue. Do not batch many edits and postpone all verification until the end.
+
+When commits are requested, order them so a reviewer can follow the proof: prerequisite or regression test, implementation, cleanup, and final verification. Preserve migration order and tenant safety at every step.

package/framework/skills/pull-request/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: pull-request
+description: Create or update a GitHub pull request (PR) for the current branch using the gh CLI. Use this skill whenever the user asks to open, create, update, or prepare a GitHub PR or pull request.
+---
+
+# `pull-request` skill instructions
+
+Create or update a pull request for the current branch using `gh` CLI.
+
+## Process
+
+1. **Collect information**
+   - Get the current branch name: `git branch --show-current`
+   - Read the PR template from `.github/pull_request_template.md` if it exists.
+
+2. **Format PR title**
+   - Take the branch name, replace all `-` with spaces, and capitalize the first character.
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `develop`: `git log develop..HEAD --oneline`
+   - Read each commit message and convert it to a bullet list summarizing user-facing changes.
+   - Merge/squash related commits (for example, multiple commits for the same change).
+   - Keep the summary concise, with one bullet per logical change.
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3.
+   - Keep the Checklist section as-is.
+
+5. **Present plan and confirm** - Show the source branch, target branch (`develop`), title, and filled description. Ask: "Shall I create this PR?" Push the changes if the user says yes.
+
+6. **Create upon confirmation** - Use `gh pr create --title "<title>" --body "<body>" --base <target>` and show the resulting URL.

package/framework/skills/pull-request/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Build a PR title and concise summary from the current branch and commits, then show the complete body before asking for confirmation.
+- Preserve an existing `.github/pull_request_template.md` checklist while replacing only its summary content.
+- Push and create the GitHub PR only after the user approves the displayed plan.

package/framework/skills/release/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: release
+description: Create a software release by reviewing commits, determining the semantic version, updating the changelog and package versions, committing release metadata, and tagging the result. Use this skill whenever the user asks to cut, prepare, publish, or tag a release.
+---
+
+# `release` skill instructions
+
+Create a release from the current branch state.
+
+## Process
+
+1. **Review recent commits** - Run `git fetch --tags`, `git describe --tags --abbrev=0` to find the latest tag. Run `git log <latest-tag>..HEAD --oneline --format="%s"` to collect all conventional commits since the last release. Read any existing `CHANGELOG.md`.
+2. **Categorize commits** - Group commits by conventional commit type:
+   - `feat!:` or `BREAKING CHANGE:` → breaking change
+   - `feat:` → minor feature
+   - `fix:` → patch fix
+   - `perf:`, `refactor:`, `test:` → patch (if no features)
+   - `chore:`, `docs:`, `ci:` → filtered from changelog
+3. **Determine next version** - Based on the [`commit` skill](../commit/SKILL.md) semver convention:
+   - Breaking changes → increment major version (e.g., `1.2.3` → `2.0.0`)
+   - New features → increment minor version (e.g., `1.2.3` → `1.3.0`)
+   - Only fixes/refactors → increment patch version (e.g., `1.2.3` → `1.2.4`)
+   - If no previous tag exists, propose `0.1.0`
+4. **Present release plan** - Show the current version, new version, categorized changelog entries, and ask: "Shall I create this release (tag vX.Y.Z and update CHANGELOG.md)?"
+5. **Execute on confirmation**:
+   - Update `CHANGELOG.md`: create a new `## [vX.Y.Z]` section under `## Unreleased`, move categorized entries (excluding chore/docs/ci) into it, add the release date, and keep the `## Unreleased` section empty for future work.
+   - Update project version metadata such as `package.json` and `package-lock.json` when present.
+   - Run `git add CHANGELOG.md package.json package-lock.json` for files that exist and commit with `chore: release vX.Y.Z`.
+   - Run `git tag -a vX.Y.Z -m "vX.Y.Z"`.
+6. **Verify** - Run `git log --oneline -n 3` and `git tag --list --sort=-v:refname -n5` to confirm the release tag and commit are in place.

package/framework/skills/release/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Inspect tags and conventional commits, propose the next semantic version, and show the release plan before changing files.
+- Move categorized entries from `Unreleased` into a dated version section while leaving a clean `Unreleased` section.
+- Update available package version metadata, commit the release files, create the annotated tag, and verify both afterward.

package/framework/skills/review/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: review
+description: Review local Git changes, GitHub pull requests, or GitLab merge requests and produce a structured review.json artifact. Use this skill whenever the user asks for a code review, diff review, PR review, MR review, or production-readiness assessment. Use the gh skill for GitHub and the glab skill for GitLab; never publish review comments.
+---
+
+# Review Skill
+
+Review the requested change and write the result to `review.json`. The review is
+read-only: do not approve, request changes, comment, merge, push, or otherwise
+modify remote repositories.
+
+## Select the change source
+
+Use the source explicitly named by the user. If it is not named, inspect the
+current repository and ask when the target is ambiguous.
+
+### Local changes
+
+- Run `git status --short` and inspect staged and unstaged changes with
+  `git diff`, `git diff --cached`, and the relevant branch comparison when
+  needed.
+- Review the working tree as it exists; do not checkout, reset, stash, or amend
+  user changes.
+
+### GitHub pull requests
+
+- Read the `gh` skill before using GitHub commands.
+- Confirm repository context with `git remote -v` or use `--repo OWNER/REPO`.
+- Read metadata with `gh pr view NUMBER --json title,body,baseRefName,headRefName`.
+- Read the patch with `gh pr diff NUMBER`.
+- Use only read operations. Do not run `gh pr review`, `gh pr comment`, `gh api`
+  mutations, or any other publishing command.
+
+### GitLab merge requests
+
+- Read the `glab` skill before using GitLab commands.
+- Confirm repository context with `git remote -v` or use `-R OWNER/REPO`.
+- Read metadata with `glab mr view NUMBER --output=json`.
+- Read the patch with `glab mr diff NUMBER`.
+- Use only read operations. Do not run `glab mr approve`, `glab mr note`, merge,
+  or other mutating commands.
+
+## Review process
+
+1. Establish the change intent from the request, commit history, description,
+   and diff. Focus findings on changed files and lines.
+2. Read relevant repository guidance and contracts, including naming, testing,
+   security, and performance standards when available.
+3. Check correctness, edge cases, error handling, state transitions,
+   compatibility, security, and meaningful performance risks.
+4. Check maintainability, comments, and tests against the consuming
+   repository's conventions. Treat changed comments and tests as review items.
+5. Include only actionable findings. Put concerns about untouched code in the
+   top-level body rather than attaching them to changed lines.
+6. Classify findings as critical, important, suggestions, or nits. Do not block
+   for speculative improvements or cosmetic preferences.
+
+## Inline comments
+
+Use inline comments only when the exact changed path, side, and line are
+available in the reviewed diff. For annotated diffs, use `[OLD:n]` as `LEFT`,
+`[NEW:n]` as `RIGHT`, and `[OLD:n,NEW:m]` as `RIGHT` line `m`. If an exact
+location cannot be verified, put the finding in the top-level body.
+
+Every inline comment must begin with one of:
+
+- `🚨 [CRITICAL]`
+- `⚠️ [IMPORTANT]`
+- `💡 [SUGGESTION]`
+- `🧹 [NIT]` (only with a concrete suggestion)
+
+Keep comments concise, actionable, and limited to changed lines. Use a
+`suggestion` block only when the replacement is exact and safe.
+
+## Output contract
+
+Write exactly one `review.json` with this shape:
+
+```json
+{
+  "verdict": "APPROVE",
+  "body": "## Overview\n...\n\n## Concerns\n...\n\nFound: 0 critical, 0 important, 0 suggestions\n\nApprove",
+  "comments": []
+}
+```
+
+- `verdict` is required and must be `APPROVE` or `REJECT`.
+- `body` is required and must contain an overview, concerns, issue counts in
+  the form `Found: X critical, Y important, Z suggestions`, and a final
+  recommendation of `Approve`, `Approve with nits`, or `Request changes` that
+  agrees with `verdict`.
+- `comments` is required and must be an array. Use an empty array when no
+  verified inline comment is appropriate.
+- Paths are repository-relative. `side` and `start_side` are `LEFT` or
+  `RIGHT`; `start_line` is used only for a multi-line range.
+
+Before finishing, validate JSON and, when an annotated diff is available, run:
+
+```sh
+python3 .agents/skills/review/scripts/validate_review_json.py \
+  --review-json review.json --diff pr_diff.txt
+```
+
+If that path is unavailable, run the validator from this skill's `scripts/`
+directory. Then render the review for human inspection:
+
+```sh
+python3 .agents/skills/review/scripts/render_review.py \
+  --review-json review.json --output review.html
+```
+
+The renderer creates a self-contained Excalidraw-inspired dark HTML report.
+The final artifacts are `review.json` and `review.html`.

package/framework/skills/review/examples.md

@@ -0,0 +1,6 @@
+# Examples
+
+- Review staged and unstaged local changes, then write a structured `review.json`.
+- Review a GitHub pull request with `gh pr view` and `gh pr diff`, or a GitLab merge request with `glab mr view` and `glab mr diff`.
+- Check correctness, tests, performance, security, and maintainability; never publish comments or approvals.
+- Render the completed `review.json` to `review.html` for a visual, dark-mode review summary.

package/framework/skills/review/scripts/render_review.py

@@ -0,0 +1,95 @@
+#!/usr/bin/env python3
+"""Render a review.json file as a self-contained dark HTML report."""
+
+from __future__ import annotations
+
+import argparse
+import json
+from pathlib import Path
+
+
+PAGE = r"""<!doctype html>
+<html lang="en">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Code review</title>
+<style>
+:root { color-scheme: dark; --bg:#121212; --panel:#1b1b1b; --ink:#f4f4f0; --muted:#a9aaa5; --line:#3b3b3b; --blue:#8cc8ff; --red:#ff7d7d; --orange:#ffbf69; --green:#78dba9; --purple:#c7a6ff; }
+* { box-sizing:border-box; }
+body { margin:0; background:var(--bg); color:var(--ink); font:16px/1.55 ui-rounded, "Comic Sans MS", system-ui, sans-serif; }
+body:before { content:""; position:fixed; inset:0; pointer-events:none; opacity:.08; background-image:radial-gradient(#fff 0.7px,transparent .7px); background-size:13px 13px; }
+main { width:min(1060px, calc(100% - 32px)); margin:48px auto; }
+.eyebrow { color:var(--blue); font:700 12px/1 monospace; letter-spacing:.16em; text-transform:uppercase; }
+h1 { font-size:clamp(32px,6vw,62px); line-height:1; margin:10px 0 28px; letter-spacing:-.06em; }
+.hero, .panel { background:var(--panel); border:2px solid var(--line); border-radius:13px 10px 15px 9px; box-shadow:5px 5px 0 #080808; }
+.hero { padding:24px; display:flex; align-items:center; justify-content:space-between; gap:20px; }
+.copy-prompt { cursor:pointer; color:#121212; background:var(--blue); border:2px solid var(--blue); border-radius:8px 6px 9px 5px; padding:7px 10px; font:800 11px monospace; text-transform:uppercase; box-shadow:2px 2px 0 #080808; }
+.copy-prompt:hover { transform:translate(-1px,-1px); box-shadow:4px 4px 0 #080808; } .copy-status { color:var(--muted); font-size:12px; }
+.verdict { border:2px solid currentColor; border-radius:10px 8px 11px 7px; padding:11px 16px; font-weight:800; letter-spacing:.08em; }
+.approve { color:var(--green); } .reject { color:var(--red); }
+.stats { display:grid; grid-template-columns:repeat(4,1fr); gap:12px; margin:22px 0; }
+.stat { padding:16px; border:2px solid var(--line); border-radius:8px 11px 7px 10px; background:#171717; }
+.stat b { display:block; font-size:30px; line-height:1; } .stat span { color:var(--muted); font-size:12px; text-transform:uppercase; letter-spacing:.08em; }
+.panel { padding:22px; margin:22px 0; } h2 { margin:0 0 14px; font-size:22px; }
+.body { white-space:pre-wrap; color:#e4e4df; }
+.filters { display:flex; flex-wrap:wrap; gap:8px; margin:-2px 0 16px; }
+.filters button { cursor:pointer; color:var(--muted); background:#121212; border:1px solid var(--line); border-radius:7px 5px 8px 6px; padding:7px 11px; font:700 12px monospace; text-transform:uppercase; }
+.filters button.active, .filters button:hover { color:var(--ink); border-color:var(--blue); box-shadow:2px 2px 0 #080808; }
+.finding.hidden { display:none; }
+.finding { border-left:5px solid var(--line); padding:14px 16px 16px; margin:12px 0; background:#151515; border-radius:4px 10px 8px 5px; }
+.finding.critical { border-color:var(--red); } .finding.important { border-color:var(--orange); } .finding.suggestion { border-color:var(--blue); } .finding.nit { border-color:var(--purple); }
+.finding-head { display:flex; align-items:center; justify-content:space-between; gap:12px; margin-bottom:9px; }
+.location { color:var(--blue); font:700 13px monospace; overflow:hidden; text-overflow:ellipsis; white-space:nowrap; } .comment { white-space:pre-wrap; }
+.severity { display:inline-flex; align-items:center; gap:6px; color:var(--muted); font:700 11px monospace; letter-spacing:.08em; text-transform:uppercase; margin-bottom:7px; }
+.severity.critical { color:var(--red); } .severity.important { color:var(--orange); } .severity.suggestion { color:var(--blue); } .severity.nit { color:var(--purple); }
+.codeblock { overflow:auto; margin:10px 0 0; padding:13px; background:#0c0c0c; border:1px solid var(--line); border-radius:7px; color:#d7d7d0; font:13px/1.6 ui-monospace, SFMono-Regular, Consolas, monospace; white-space:pre; }
+.tok-keyword { color:#c7a6ff; } .tok-string { color:#a8d8a8; } .tok-number { color:#ffbf69; } .tok-comment { color:#777b78; font-style:italic; }
+@media (max-width:650px) { main{margin:24px auto}.hero{align-items:flex-start;flex-direction:column}.stats{grid-template-columns:repeat(2,1fr)} }
+</style>
+</head>
+<body><main>
+<div class="eyebrow">review artifact // visualized</div><h1>Code review</h1>
+<section class="hero"><div><div class="eyebrow">verdict</div><div id="verdict"></div></div><div id="summary"></div></section>
+<section class="stats" id="stats"></section>
+<section class="panel"><h2>Review notes</h2><div class="body" id="body"></div></section>
+<section class="panel"><h2>Inline findings</h2><div class="filters" id="filters"><button class="active" data-filter="all">All</button><button data-filter="critical">Critical</button><button data-filter="important">Important</button><button data-filter="suggestion">Suggestions</button><button data-filter="nit">Nits</button></div><div id="comments"></div></section>
+</main><script>
+const review = __REVIEW_DATA__;
+const esc = value => String(value ?? '').replace(/[&<>"']/g, c => ({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[c]));
+const comments = Array.isArray(review.comments) ? review.comments : [];
+const counts = { critical:0, important:0, suggestion:0, nit:0 };
+const kind = body => { const text=String(body||'').toLowerCase(); return text.includes('critical')?'critical':text.includes('important')?'important':text.includes('suggestion')?'suggestion':text.includes('nit')?'nit':'suggestion'; };
+const severity = { critical:['🚨','Critical'], important:['⚠️','Important'], suggestion:['💡','Suggestion'], nit:['🧹','Nit'] };
+const cleanBody = body => String(body || '').replace(/^[^\w\n]*\[(?:CRITICAL|IMPORTANT|SUGGESTION|NIT)\]\s*/i, '');
+const highlighted = code => { const pattern=/(\/\/.*|#.*|\/\*[\s\S]*?\*\/|"(?:\\.|[^"\\])*"|'(?:\\.|[^'\\])*'|`(?:\\.|[^`\\])*`|\b(?:const|let|var|function|return|if|else|for|while|class|new|throw|async|await|import|from|true|false|null|undefined)\b|\b\d+(?:\.\d+)?\b)/g; return String(code).split(pattern).map((part, i) => { if (i % 2 === 0) return esc(part); const cls=/^(\/\/|#|\/\*)/.test(part)?'tok-comment':/^["'`]/.test(part)?'tok-string':/^\d/.test(part)?'tok-number':'tok-keyword'; return `<span class="${cls}">${esc(part)}</span>`; }).join(''); };
+const formatBody = body => { const source=String(body||''), pattern=/```(?:[\w+-]+)?\n([\s\S]*?)```/g; let result='', last=0, match; while ((match=pattern.exec(source))) { result += esc(source.slice(last, match.index)); result += `<pre class="codeblock"><code>${highlighted(match[1])}</code></pre>`; last=pattern.lastIndex; } return result + esc(source.slice(last)); };
+comments.forEach(c => counts[kind(c.body)]++);
+const verdict = review.verdict === 'REJECT' ? 'REJECT' : 'APPROVE';
+document.title = `${verdict} · Code review`;
+document.querySelector('#verdict').innerHTML = `<div class="verdict ${verdict === 'REJECT' ? 'reject':'approve'}">${verdict}</div>`;
+document.querySelector('#summary').textContent = `${comments.length} inline ${comments.length === 1 ? 'finding':'findings'}`;
+document.querySelector('#body').textContent = review.body || 'No review body provided.';
+document.querySelector('#stats').innerHTML = Object.entries(counts).map(([name,count]) => `<div class="stat"><b>${count}</b><span>${name}</span></div>`).join('');
+document.querySelector('#comments').innerHTML = comments.length ? comments.map((c, i) => { const type=kind(c.body), [icon,label]=severity[type]; const location = `${esc(c.path || 'unknown file')}:${esc(c.line ?? '?')} · ${esc(c.side || '')}`; return `<article class="finding ${type}" data-kind="${type}"><div class="finding-head"><div><div class="location">${location}</div><div class="severity ${type}">${icon} ${label}</div></div><button class="copy-prompt" type="button" data-finding="${i}">Copy fix prompt</button></div><div class="comment">${formatBody(cleanBody(c.body))}</div><span class="copy-status" aria-live="polite"></span></article>`; }).join('') : '<div class="body">No inline findings.</div>';
+document.querySelector('#filters').addEventListener('click', event => { const button=event.target.closest('button'); if (!button) return; const filter=button.dataset.filter; document.querySelectorAll('#filters button').forEach(item => item.classList.toggle('active', item === button)); document.querySelectorAll('.finding').forEach(item => item.classList.toggle('hidden', filter !== 'all' && item.dataset.kind !== filter)); });
+const fixPrompt = finding => `You are fixing one code review finding. Apply the smallest necessary change in the repository; do not weaken behavior or remove coverage.\n\nReview verdict: ${verdict}\n\nReview context:\n${review.body || 'No review body provided.'}\n\nTarget finding:\n[${String(finding.body || '').split(' ')[1] || 'FINDING'}] ${finding.path || 'unknown file'}:${finding.line ?? '?'} (${finding.side || 'RIGHT'})\n${finding.body || ''}\n\nAfter fixing this finding, run the relevant tests and summarize the change and test result.`;
+const copyText = async (text, status) => { try { await navigator.clipboard.writeText(text); } catch (_) { const area=document.createElement('textarea'); area.value=text; area.style.position='fixed'; area.style.opacity='0'; document.body.append(area); area.select(); document.execCommand('copy'); area.remove(); } status.textContent='Copied'; setTimeout(() => { status.textContent=''; }, 2200); };
+document.querySelector('#comments').addEventListener('click', event => { const button=event.target.closest('[data-finding]'); if (!button) return; const finding=comments[Number(button.dataset.finding)]; copyText(fixPrompt(finding), button.parentElement.parentElement.querySelector('.copy-status')); });
+</script></body></html>"""
+
+
+def main() -> None:
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument("--review-json", default="review.json")
+    parser.add_argument("--output", default="review.html")
+    args = parser.parse_args()
+    review = json.loads(Path(args.review_json).read_text(encoding="utf-8"))
+    data = json.dumps(review, ensure_ascii=False, separators=(",", ":"))
+    data = data.replace("<", "\\u003c").replace(">", "\\u003e").replace("&", "\\u0026")
+    html = PAGE.replace("__REVIEW_DATA__", data)
+    Path(args.output).write_text(html, encoding="utf-8")
+
+
+if __name__ == "__main__":
+    main()