edsger 0.76.0 → 0.78.0

package/assets/skills/benchmark/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: benchmark
+description: >
+  Score the current repository against industrial-grade engineering standards
+  (security, maintainability, testing, documentation, delivery, and
+  language-specific quality) and write a graded report. Use when the user asks to
+  benchmark, score, grade, audit, or assess the quality/health of a repo.
+---
+
+# Benchmark a repository
+
+You will score the repository in the current working directory against the
+edsger benchmark rubric and produce a 0–100 score with a graded, evidence-backed
+report.
+
+## 1. Prefer the CLI if it is installed
+
+If the `edsger` CLI is available, it produces a deterministic weighted score —
+use it:
+
+```bash
+command -v edsger >/dev/null 2>&1 && edsger benchmark || echo "no-cli"
+```
+
+If it ran, summarise `.edsger/benchmark/report.md` for the user and stop.
+Otherwise continue with the native flow below.
+
+## 2. Detect the language(s)
+
+Look for manifest files to decide which overlays apply: `package.json`/`tsconfig.json`
+→ typescript; `pyproject.toml`/`requirements.txt` → python; `go.mod` → go;
+`*.csproj`/`*.sln` → csharp; `pom.xml`/`build.gradle` → java; `pubspec.yaml` → dart.
+A repo may match several.
+
+## 3. Load the rubric
+
+Read the base rubric and any matching language overlays from this plugin:
+
+- `${CLAUDE_PLUGIN_ROOT}/benchmark/base.yaml` (always)
+- `${CLAUDE_PLUGIN_ROOT}/benchmark/<language>.yaml` (for each detected language)
+
+Merge overlays onto the base **by id**: a category/criterion with the same `id`
+extends the base one; new ids are added. If the repo has a `.edsger/benchmark/`
+directory, those files override the bundled rubric (same id-merge rules).
+
+## 4. Score every criterion
+
+For each criterion, gather **concrete evidence** from the actual code/config
+before assigning a score from 0 to `scoreScale` (default 4; 0 = absent/harmful,
+4 = exemplary), guided by the level anchors in the rubric. Use read-only
+exploration (read files, grep, `ls`, `git log`). Do **not** modify the repo.
+
+Absence of evidence for a practice means a low score — do not give credit for
+things you cannot verify.
+
+## 5. Aggregate and report
+
+- Normalise category weights to sum to 100.
+- Category score = weighted average of its criteria fractions (`raw / scoreScale`).
+- Overall = Σ(categoryWeight% × categoryFraction), rounded to 0–100.
+- Grade: A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 60, else F.
+
+Write `.edsger/benchmark/report.md` containing: the overall score and grade, a
+short summary, a category table (weight, score, weighted points), strengths,
+weaknesses, prioritised recommendations, and per-criterion findings with the
+evidence paths you used. Then give the user a concise summary.

package/assets/skills/pr-resolve/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: pr-resolve
+description: >
+  Resolve a GitHub pull request by addressing reviewer feedback (or a specific
+  instruction), editing the code, running the tests, and optionally committing
+  and pushing. Use when the user asks to fix, resolve, or address comments on a
+  PR, or to make a PR mergeable.
+---
+
+# Resolve a pull request
+
+You will address the open items on a GitHub pull request by editing the code,
+verifying the change, and reporting what you did. The user identifies the PR; ask
+for the target repo if ambiguous, and confirm before pushing.
+
+## 1. Prefer the CLI if it is installed
+
+```bash
+command -v edsger >/dev/null 2>&1 && echo "have-cli"
+```
+
+If present you may run `edsger pr-resolve <pr>` (add `--push` only when the user
+wants the result pushed). Otherwise continue natively. You need `gh` authenticated.
+
+## 2. Get on the right branch and gather feedback
+
+```bash
+gh pr checkout <pr>
+gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate   # inline review comments
+gh api repos/{owner}/{repo}/issues/{number}/comments --paginate  # conversation comments
+```
+
+Collect the primary instruction from the user (e.g. "fix the failing test") and
+the reviewer feedback. If both exist, the explicit instruction takes priority.
+
+## 3. Make minimal, correct edits
+
+For each item: locate the relevant code, understand the request, and make the
+**smallest correct change** that addresses it. Match the existing conventions and
+style of the surrounding code.
+
+Rules:
+- Never weaken, skip, or delete tests just to make them pass.
+- Never introduce secrets or credentials.
+- Add or update tests when you change behaviour or fix a bug.
+
+## 4. Verify
+
+Run the project's tests and linters (e.g. `npm test`, `pytest`, `go test ./...`,
+`dotnet test`, `mvn test`, `dart test`) to confirm your changes pass. Iterate
+until green or until you hit something you cannot resolve.
+
+## 5. Report and (optionally) push
+
+Summarise: what changed (by file), how you verified it, and anything still
+unresolved. Leave the changes in the working tree for the user to inspect. Only
+commit and push when the user explicitly asks — then use a clear message and push
+to the PR's head branch.

package/assets/skills/pr-review/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: pr-review
+description: >
+  Review a GitHub pull request against industrial-grade review standards
+  (correctness, security, tests, design, performance) and post or preview a
+  structured review with inline comments. Use when the user asks to review a PR,
+  do a code review, or critique a pull request.
+---
+
+# Review a pull request
+
+You will review a GitHub pull request against the edsger review standard and
+produce a structured review: a verdict, a summary, and specific, actionable
+findings (ideally as inline comments).
+
+The user will identify the PR (a number, URL, or branch). Confirm the target
+repo if it is ambiguous.
+
+## 1. Prefer the CLI if it is installed
+
+```bash
+command -v edsger >/dev/null 2>&1 && echo "have-cli"
+```
+
+If present, you may run `edsger pr-review <pr>` (add `--post` only when the user
+explicitly wants it submitted). Otherwise continue natively. Either way you need
+GitHub access via `gh` (`gh auth status`).
+
+## 2. Gather the change
+
+```bash
+gh pr view <pr> --json number,title,body,author,baseRefName,headRefName,files
+gh pr diff <pr>
+```
+
+Read surrounding code in the working tree for context where the diff is not
+self-explanatory. Review **only what the PR changes**, but judge it in context.
+
+## 3. Load the review standard
+
+- `${CLAUDE_PLUGIN_ROOT}/review/base.yaml` (always)
+- `${CLAUDE_PLUGIN_ROOT}/review/<language>.yaml` (per detected language of the changed files)
+
+Merge overlays onto the base by `id`. A repo-local `.edsger/review/` overrides
+the bundled standard.
+
+## 4. Evaluate
+
+For each focus area, check the change against its guidance and checklist. For
+each issue, record: focus area, **severity** (critical/high/medium/low/info),
+file path, the 1-based line in the **new** file (when it maps to a changed
+line), a clear explanation of why it matters, and a concrete suggested fix.
+
+Priorities: confirm the change does what its description claims; flag security
+issues and missing tests for new logic first; prefer high-signal findings over
+style nitpicks (prefix optional nits with "nit:"). Be specific and kind.
+
+## 5. Decide and deliver
+
+- Verdict: if any finding is at a blocking severity (default critical/high) →
+  **request changes**; otherwise approve or comment.
+- Respect `policy.maxComments` (default 25) — surface the most important findings
+  inline and roll the rest into the summary.
+
+Present the review to the user. Only submit it to GitHub (e.g. via
+`gh pr review` / the reviews API) when the user explicitly asks you to post it.