ur-agent 1.23.3 → 1.24.1

package/plugins/core/code-review/commands/code-review.md

@@ -0,0 +1,47 @@
+---
+description: Review the working diff against a base ref. Returns a structured report.
+argument-hint: "[base-ref] (default: main)"
+---
+
+Determine the base ref: if `$ARGUMENTS` is non-empty, use it; otherwise use
+`main` if it exists, otherwise `master`, otherwise `HEAD~5`.
+
+Run the diff:
+
+```sh
+git diff <base>...HEAD
+```
+
+If the diff is empty, say "No changes to review against `<base>`." and stop.
+
+Otherwise produce a markdown report with these sections, in order. Skip any
+section that has no findings rather than padding it.
+
+### Correctness
+Logic errors, missed edge cases, null / empty / boundary handling, off-by-one,
+concurrency bugs, error paths that don't propagate. For each, name the file
+and line and quote the problematic snippet.
+
+### Style and consistency
+Inconsistent naming with the rest of the file, dead or unreachable code,
+duplicated logic, abstraction that obscures rather than clarifies, comments
+that contradict the code.
+
+### Test coverage
+Was test-shaped code touched? Are there tests for the new behaviour? Flag
+any change to public surface area with no matching test change.
+
+### Security
+Injection risks (SQL, shell, path), secret / token leakage in logs or
+errors, unsafe deserialization, missing input validation at trust
+boundaries, permissive permission grants.
+
+### TL;DR
+End with one line, exactly one of:
+
+- `TL;DR: Looks good.` — no findings or only nits, nothing blocking.
+- `TL;DR: Has nits.` — one or more cosmetic findings, nothing blocking.
+- `TL;DR: Has blockers.` — at least one correctness or security finding
+  that should be fixed before merging.
+
+Do not editorialize about the author. Review the code, not the person.

package/plugins/core/engineering-discipline/.ur-plugin/plugin.json

@@ -0,0 +1,33 @@
+{
+  "name": "engineering-discipline",
+  "version": "0.1.0",
+  "description": "Reference plugin for UR's marketplace extensibility: a CI/release command, executable skill, agent template, verifier validator, and language/LSP adapter metadata.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/engineering-discipline",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["workflow", "ci", "release", "validator", "template", "language-adapter"],
+  "skills": "./skills",
+  "templates": "./templates",
+  "validators": "./validators",
+  "languageAdapters": {
+    "markdown": {
+      "extensions": [".md", ".mdx"],
+      "engine": "lsp",
+      "lspServerName": "markdown"
+    }
+  },
+  "lspServers": {
+    "markdown": {
+      "command": "markdown-language-server",
+      "args": ["--stdio"],
+      "extensionToLanguage": {
+        ".md": "markdown",
+        ".mdx": "markdown"
+      }
+    }
+  }
+}

package/plugins/core/engineering-discipline/README.md

@@ -0,0 +1,21 @@
+# engineering-discipline
+
+Reference plugin for UR's marketplace extensibility.
+
+It demonstrates how a marketplace plugin can add more than a slash command:
+
+- command: `/discipline-check`
+- skill: `engineering-discipline:reproducible-release`
+- agent template: `release-verifier`
+- validator: `release-gate`
+- language adapter: Markdown/MDX through an LSP declaration
+
+## Install
+
+```sh
+/plugin install engineering-discipline@ur-plugins-official
+```
+
+The validator is intentionally conservative and mirrors the release gate used
+for production readiness. The language adapter only activates when the matching
+Markdown language server is installed locally.

package/plugins/core/engineering-discipline/commands/discipline-check.md

@@ -0,0 +1,25 @@
+---
+description: "Check whether a change is ready for reproducible release: plan, patch, tests, verifier evidence, docs, benchmark notes, and rollback path."
+argument-hint: "[changed area or release target]"
+allowed-tools:
+  - "Bash(git status:*)"
+  - "Bash(git diff:*)"
+  - "Bash(bun run typecheck:*)"
+  - "Bash(bun run lint:*)"
+  - "Bash(bun test:*)"
+  - "Bash(bun run release:check:*)"
+---
+
+Audit the current change as a reproducible engineering workflow.
+
+Check whether the work has a clear plan, scoped patch, executed tests, verifier
+evidence, documentation updates, benchmark or eval notes when relevant, and a
+rollback path. Prefer command evidence over claims. Do not mark the change ready
+unless the required commands were actually executed and passed.
+
+Return:
+
+1. Status: READY, BLOCKED, or NEEDS-EVIDENCE.
+2. Evidence commands observed.
+3. Missing evidence.
+4. Release or rollback risk.

package/plugins/core/engineering-discipline/skills/reproducible-release/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: Reproducible Release
+description: Use when preparing a UR-style engineering change for release. Enforces spec -> plan -> patch -> test -> verify -> document -> benchmark -> reproduce, with explicit command evidence and rollback notes.
+version: 0.1.0
+---
+
+# Reproducible Release
+
+Use this skill when a change must be ready for production, npm packaging, or a
+research/demo artifact.
+
+## Workflow
+
+1. State the intended release surface and affected commands.
+2. Inspect the diff and list public API, generated-file, and safety risks.
+3. Run the smallest relevant compile/test/lint checks, then broaden to the full
+   release gate when risk warrants it.
+4. Record command evidence exactly: command, exit code, stdout/stderr summary,
+   and next action.
+5. Confirm documentation and marketplace files are updated when user-facing
+   behavior changes.
+6. Produce a PR-style report with summary, changed files, tests run, risks,
+   rollback command, and remaining TODOs.
+
+## Hard Rules
+
+- Never claim tests passed without command evidence.
+- Never hide a failed command or skipped gate.
+- Never edit generated/vendor files unless the task explicitly requires it.
+- Never publish or tag until the release gate passes and the user explicitly
+  asks for publishing.

package/plugins/core/engineering-discipline/templates/release-verifier.md

@@ -0,0 +1,18 @@
+---
+name: release-verifier
+description: Reviews whether a change is releasable, auditable, and rollback-ready.
+color: green
+effort: high
+permissionMode: default
+memory: project
+---
+
+You are a release verification agent.
+
+Review the current change as if it were going to production. Demand command
+evidence for compile, lint, tests, bundle, smoke, package, and secret scan when
+the change touches release or runtime behavior. Inspect docs and generated
+artifacts. Report findings first, then summarize the release readiness state.
+
+Do not approve a release if the production bundle is stale, tests were not run,
+or publishing would not be gated by successful CI.

package/plugins/core/engineering-discipline/validators/release-gate.json

@@ -0,0 +1,7 @@
+{
+  "name": "release-gate",
+  "command": "bun run typecheck && bun run lint && bun test && bun run release:check",
+  "when": "always",
+  "patterns": ["src/**", "test/**", "package.json", "bunfig.toml", "docs/**", "README.md"],
+  "timeoutMs": 120000
+}

package/plugins/core/evaluate-response/.ur-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "evaluate-response",
+  "version": "0.1.0",
+  "description": "Adds /evaluate-response — adversarial self-evaluation of the most recent assistant turn.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/evaluate-response",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["quality", "self-evaluation", "verifier"]
+}

package/plugins/core/evaluate-response/README.md

@@ -0,0 +1,42 @@
+# evaluate-response
+
+Adds `/evaluate-response` — adversarial self-evaluation of the most recent
+assistant response.
+
+## Use
+
+```text
+/evaluate-response
+```
+
+Invoke right after the agent finishes a task to catch hallucinated
+completions, missed sub-questions, factual drift, or narrated-but-not-done
+work.
+
+## What it returns
+
+A markdown report against five criteria — Completeness, Accuracy, Tool
+use vs narration, Honesty about completion, Clarity — plus a mandatory
+one-line verdict:
+
+```
+QUALITY: HIGH | MEDIUM | LOW — <rationale>
+```
+
+And one concrete, specific improvement (not generic advice).
+
+## How it pairs with the verifier
+
+The verifier subsystem catches structural problems automatically (no Write
+call but claimed "created the file", same Bash call 3 times in a row, the
+build doesn't compile). `/evaluate-response` is for the harder cases the
+verifier can't see: did the response actually answer the question, were the
+facts right, was the tone honest.
+
+Useful as a manual cross-check before committing what the agent produced.
+
+## Install
+
+```text
+/plugin install evaluate-response@ur-plugins-official
+```

package/plugins/core/evaluate-response/commands/evaluate-response.md

@@ -0,0 +1,61 @@
+---
+description: Adversarially evaluate the most recent assistant response. Be ruthless.
+---
+
+You are about to evaluate your own most recent response — the assistant
+message immediately before this command was invoked. Your goal is to catch
+your own mistakes, not to defend your own work.
+
+Look at the most recent assistant turn in the transcript. Read both the
+text and the tool calls. Then evaluate it against these criteria. Be
+specific. "Looks fine" is not an answer.
+
+### Completeness
+
+Did the response actually answer every part of the user's question? List
+any sub-question or sub-task that was skipped, glossed over, or deferred
+without explicit acknowledgement.
+
+### Accuracy
+
+Are factual claims and code references correct? Spot-check at least one
+file path or symbol name the response mentioned by reading it with the
+Read tool. Report any drift.
+
+### Tool use vs narration
+
+Did the response use tools where appropriate, or did it narrate work it
+should have actually performed? A response that says "I would edit X to
+do Y" without calling Edit is a tool-use failure. Flag specifically.
+
+### Honesty about completion
+
+Did the response claim work that was not actually performed? Cross-check
+"I created / edited / ran X" claims against actual tool calls in the same
+turn. If a claim has no matching successful tool result, that is a
+hallucinated completion — call it out.
+
+### Clarity and concision
+
+Was the response well structured for the user to skim? Or did it bury the
+useful information under filler? One sentence each on structure and length.
+
+### Verdict
+
+End with exactly one line in this format:
+
+```
+QUALITY: HIGH | MEDIUM | LOW — <one-sentence rationale>
+```
+
+- **HIGH**: complete, accurate, honest, used tools where needed, easy to
+  read. No criterion failed.
+- **MEDIUM**: one or two minor issues. Useful but not great.
+- **LOW**: a criterion failed in a way that would mislead the user
+  (hallucinated completion, factually wrong claim, missed a question).
+
+Then list one specific, concrete improvement the response could have made.
+Not generic advice — a precise sentence the response should have included
+or a tool call it should have made.
+
+Do not soften findings. The point of this command is signal, not comfort.

package/plugins/core/explain-error/.ur-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "explain-error",
+  "version": "0.1.0",
+  "description": "Adds /explain-error — re-runs a failing command and diagnoses the error in plain English.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/explain-error",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["debug", "error", "troubleshooting"]
+}

package/plugins/core/explain-error/README.md

@@ -0,0 +1,32 @@
+# explain-error
+
+Adds `/explain-error` — diagnose a failing command, in plain English, with
+two concrete next steps to try.
+
+## Use
+
+```text
+/explain-error bun test
+/explain-error
+```
+
+With a command argument, re-runs that command and analyzes the failure.
+Without an argument, looks back through the transcript for the most recent
+failing Bash call.
+
+## What it returns
+
+Three short sections:
+
+- **What the error means** — plain-English decoding of the message.
+- **Most likely cause** — the single most plausible root cause given the
+  project context.
+- **Next steps** — two concrete things to try, ordered by likelihood.
+
+Stays specific to the error in front of it. Does not lecture about debugging.
+
+## Install
+
+```text
+/plugin install explain-error@ur-plugins-official
+```

package/plugins/core/explain-error/commands/explain-error.md

@@ -0,0 +1,37 @@
+---
+description: Diagnose a failing command. Re-runs it, explains the error, suggests next steps.
+argument-hint: "<command-to-rerun>"
+---
+
+If `$ARGUMENTS` is non-empty, treat it as the command to investigate. Re-run
+it via the Bash tool exactly as given and capture stdout, stderr, and the
+exit code.
+
+If `$ARGUMENTS` is empty, scan the most recent transcript turns for the last
+failing Bash command (non-zero exit) and use that one. If you cannot find a
+recent failure, ask the user to paste the failing command and stop.
+
+Then produce a short, structured diagnosis:
+
+### What the error means
+
+One or two sentences in plain English. Decode jargon. If the error message
+is generic ("Error: 1"), say so and rely on the stderr context.
+
+### Most likely cause
+
+The single most likely root cause, given the project context (read
+`package.json`, `UR.md`, or relevant config files only if it sharpens
+the diagnosis — do not spelunk for the sake of it).
+
+### Next steps
+
+Two concrete next things to try, ordered by likelihood. Each step is a
+shell command or a one-line action, not a paragraph of advice.
+
+If the error is genuinely opaque, list commands that would gather more
+information (e.g. re-run with a verbosity flag, check a log file, inspect
+the relevant file's mode) instead of guessing.
+
+Do not lecture about general debugging methodology. Stay specific to this
+error.

package/plugins/core/git-summary/.ur-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "git-summary",
+  "version": "0.1.0",
+  "description": "Adds /git-summary — a one-paragraph factual summary of the working tree and recent history.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/git-summary",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["git", "summary", "standup", "workflow"]
+}

package/plugins/core/git-summary/README.md

@@ -0,0 +1,29 @@
+# git-summary
+
+Adds `/git-summary` — a one-paragraph factual summary of the working tree
+and the last few commits.
+
+## Use
+
+```text
+/git-summary
+```
+
+Useful before standup, before opening a PR, before clocking out.
+
+## What it does
+
+Runs three git commands in parallel:
+
+- `git status --short`
+- `git diff --stat`
+- `git log -5 --oneline`
+
+Then asks the model to produce a 3–5 sentence factual summary plus a
+one-line branch / clean status footer.
+
+## Install
+
+```text
+/plugin install git-summary@ur-plugins-official
+```

package/plugins/core/git-summary/commands/git-summary.md

@@ -0,0 +1,27 @@
+---
+description: Summarize the working tree and recent commits in one paragraph.
+---
+
+Run these three Bash commands in parallel:
+
+1. `git status --short`
+2. `git diff --stat`
+3. `git log -5 --oneline`
+
+If any of those commands fail (not a git repo, no commits yet, etc.) say so
+plainly and stop.
+
+Otherwise, write a single paragraph (3–5 sentences) that covers:
+
+- What files are modified, added, or deleted (by category, not file-by-file
+  unless there are five or fewer).
+- The total scope of changes (insertions and deletions).
+- Context from the five most recent commits — what direction the work has
+  been moving in.
+
+Do not editorialize. Do not project intent onto the changes. Stick to what
+the commands actually returned.
+
+End with one short line: the current branch and whether the working tree
+is clean. Use the format `branch: <name> — clean` or
+`branch: <name> — N files dirty`.

package/plugins/core/github/.ur-plugin/plugin.json

@@ -0,0 +1,31 @@
+{
+  "name": "github",
+  "version": "0.1.0",
+  "description": "Drive GitHub from UR: review and open pull requests, triage issues, and check repo health — through GitHub's official remote MCP server or the gh CLI.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/github",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["github", "pull-request", "issues", "ci", "devops", "mcp"],
+  "mcpServers": {
+    "github": {
+      "type": "http",
+      "url": "https://api.githubcopilot.com/mcp/",
+      "headers": {
+        "Authorization": "Bearer ${user_config.GITHUB_TOKEN}"
+      }
+    }
+  },
+  "userConfig": {
+    "GITHUB_TOKEN": {
+      "type": "string",
+      "title": "GitHub token",
+      "description": "Fine-grained or classic personal access token used by the official GitHub MCP server. Scope it to the repositories and toolsets you want UR to reach. The gh CLI uses its own gh auth login session and does not read this value.",
+      "required": true,
+      "sensitive": true
+    }
+  }
+}

package/plugins/core/github/README.md

@@ -0,0 +1,37 @@
+# github
+
+Drive GitHub from any UR session: review and open pull requests, triage issues,
+and check repository health. Backed by GitHub's official remote MCP server, with
+the `gh` CLI as a fallback.
+
+## Commands
+
+| Command | Argument | What it does |
+| --- | --- | --- |
+| `/gh-pr-review` | `[pr-number \| url]` | Structured review of a PR with a TL;DR verdict. |
+| `/gh-pr-create` | `[base-branch]` | Open a PR from the current branch with a generated title and body. |
+| `/gh-issues` | `[label \| query]` | Cluster, label, and prioritize open issues. |
+| `/gh-repo-health` | `[owner/repo]` | One-screen snapshot of PRs, issues, CI, and releases. |
+
+A bundled `github-workflow` skill documents toolsets, the `gh` cheatsheet, token
+scopes, and guardrails.
+
+## Setup
+
+```sh
+/plugin install github@ur-plugins-official
+```
+
+On enable, set **GITHUB_TOKEN** — a fine-grained or classic personal access
+token for the official MCP server (`https://api.githubcopilot.com/mcp/`). Scope
+it to the repositories and toolsets you want UR to reach.
+
+The `gh` CLI uses its own `gh auth login` session and does not read this token;
+the commands work through whichever path is available.
+
+## Security
+
+The token is stored in secure storage (keychain / credentials file), never in
+plaintext settings. Mutating actions — opening PRs, labeling, closing — are
+proposed, not taken, unless you ask for them. Force-pushing protected branches
+and merging are never done automatically.

package/plugins/core/github/commands/gh-issues.md

@@ -0,0 +1,19 @@
+---
+description: Triage open GitHub issues — cluster, label, and propose next actions.
+argument-hint: "[label | search query] (optional)"
+---
+
+List open issues for the current repository, filtered by `$ARGUMENTS` if given.
+
+Then triage:
+
+1. Cluster the issues into 2–5 themes (bug, feature, docs, question, etc.).
+2. For each issue, propose: a label, the single next action, and a priority
+   (P0 blocking / P1 soon / P2 later) with a one-line reason.
+3. Call out duplicates and stale issues (no activity in a long time).
+
+End with the three issues most worth doing next and why.
+
+Prefer the `github` MCP tools; otherwise use `gh issue list`. If neither is
+configured, point the user to the README and stop. Propose changes only — do not
+label, close, or comment unless explicitly asked.

package/plugins/core/github/commands/gh-pr-create.md

@@ -0,0 +1,19 @@
+---
+description: Open a GitHub pull request from the current branch with a generated title and body.
+argument-hint: "[base-branch] (default: repo default branch)"
+---
+
+Open a pull request for the current branch.
+
+1. Determine the base: `$ARGUMENTS` if given, else the repository default branch.
+2. Confirm the branch is pushed to the remote; if not, push it.
+3. Collect the commits between base and HEAD and any diff stat.
+4. Draft the PR:
+   - **Title**: one Conventional-Commit-style line summarizing the change.
+   - **Body**: `## Summary` (what and why, 2–4 bullets), `## Changes` (grouped),
+     `## Test plan` (how it was verified).
+5. Create the PR against the base branch and print its URL.
+
+Prefer the `github` MCP tools; otherwise use `gh pr create`. If neither is
+configured, point the user to the README and stop. Never merge — creating the PR
+is the end state. Do not include secrets in the title or body.

package/plugins/core/github/commands/gh-pr-review.md

@@ -0,0 +1,37 @@
+---
+description: Review a GitHub pull request and return a structured verdict.
+argument-hint: "[pr-number | url] (default: PR for the current branch)"
+---
+
+Resolve the PR: if `$ARGUMENTS` names a number or URL, use it; otherwise find
+the open PR for the current branch.
+
+Fetch the diff and metadata, then review it. Produce a markdown report with
+these sections, skipping any with no findings:
+
+### Correctness
+Logic errors, missed edge cases, null / boundary handling, races, error paths
+that swallow failures. Name the file and line and quote the snippet.
+
+### Style and consistency
+Naming that fights the surrounding code, dead code, duplicated logic, comments
+that contradict the code.
+
+### Test coverage
+Was test-shaped code touched? Is the new behaviour tested? Flag changes to
+public surface area with no matching test.
+
+### Security
+Injection (SQL/shell/path), secret leakage, unsafe deserialization, missing
+validation at trust boundaries, over-broad permissions.
+
+### TL;DR
+End with exactly one of:
+- `TL;DR: Looks good.`
+- `TL;DR: Has nits.`
+- `TL;DR: Has blockers.`
+
+Prefer the `github` MCP tools (pull request read + diff). If they are not
+available, use the `gh` CLI (`gh pr view`, `gh pr diff`), which uses its own
+`gh auth login` session. If neither is configured, point the user to the plugin
+README and stop. Do not post a review comment unless explicitly asked.

package/plugins/core/github/commands/gh-repo-health.md

@@ -0,0 +1,23 @@
+---
+description: One-screen health snapshot of a GitHub repository.
+argument-hint: "[owner/repo] (default: current repository)"
+---
+
+Build a health snapshot for `$ARGUMENTS` if given, else the current repository.
+
+Gather and summarize:
+- Open pull requests: count, and any that are stale or have failing checks.
+- Open issues: count and rough theme breakdown.
+- Latest CI runs: pass/fail of the most recent runs on the default branch.
+- Branches: stale branches merged or long inactive.
+- Releases: the latest release/tag and how long ago it shipped.
+
+Keep it to one screen. End with a verdict line, exactly one of:
+- `HEALTH: GREEN — nothing demands attention.`
+- `HEALTH: YELLOW — a few things to watch.`
+- `HEALTH: RED — needs attention now.`
+followed by the single highest-priority item.
+
+Prefer the `github` MCP tools; otherwise use `gh` (`gh pr list`, `gh issue list`,
+`gh run list`, `gh release view`). If neither is configured, point the user to
+the README and stop.