ur-agent 1.23.3 → 1.24.1

package/plugins/core/powerpoint/skills/deck-craft/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: Deck Craft (PowerPoint)
+description: Conventions for professional PowerPoint decks — layouts over text boxes, one idea per slide, sparse text with detail in notes, visual hierarchy, charts, templates, and accessibility. Use when building, converting, reviewing, or theming .pptx files.
+version: 0.1.0
+---
+
+# Deck Craft (PowerPoint)
+
+Slides support a talk; they are not the document. Put the argument on the slide,
+the detail in the notes.
+
+## One idea per slide
+
+- Each content slide makes a single point; its title states that point as a
+  sentence where possible (`Latency dropped 40% after caching`, not `Results`).
+- If a slide needs two ideas, it is two slides.
+
+## Sparse text
+
+- Aim for one level of bullets and few words per line. The classic guide is
+  roughly six bullets and six words each — treat it as a ceiling, not a target.
+- Anything you would read aloud verbatim belongs in the speaker notes.
+
+## Layouts over text boxes
+
+- Use the slide master's layouts and placeholders (title, content, two-content,
+  section header). Off-template floating boxes drift and break theming.
+- Re-theming should remap content into placeholders, not nudge boxes.
+
+## Visual hierarchy
+
+- One focal point per slide. Size, weight, and position guide the eye to it.
+- Align to a grid; consistent margins read as "designed".
+
+## Charts and tables
+
+- Prefer a chart to a table when the point is a trend or comparison.
+- Label axes and series; do not make the audience decode a legend.
+- Show the takeaway in the title, the evidence in the chart.
+
+## Templates
+
+- Start from a `.potx`/template deck to inherit theme colors, fonts, and layouts.
+- Keep brand styling in the template; keep content in the slides.
+
+## Accessibility
+
+- Sufficient contrast; never rely on color alone to convey meaning.
+- Alt text on images and charts; slide numbers on; a sensible reading order.
+
+## Flow
+
+- Open with the point, not a long agenda. Use section headers to segment.
+- Close with the takeaway and the next step, not "Thank you / Questions" alone.
+
+## Guardrails
+
+- Restyle without rewriting: preserve each slide's message and order.
+- Push prose into notes rather than shrinking the font to fit.
+- State plainly when a template cannot be applied automatically.

package/plugins/core/release-notes/.ur-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "release-notes",
+  "version": "0.1.0",
+  "description": "Adds /release-notes — drafts release notes from git log since the last tag.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/release-notes",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["release", "notes", "changelog", "git"]
+}

package/plugins/core/release-notes/README.md

@@ -0,0 +1,28 @@
+# release-notes
+
+Adds `/release-notes` — drafts release notes by grouping commits since the
+last tag (or a given ref) into Features / Fixes / Documentation / Other.
+
+## Use
+
+```text
+/release-notes
+/release-notes v1.3.0
+/release-notes HEAD~30
+```
+
+With no argument, the plugin uses `git describe --tags --abbrev=0` to
+find the most recent tag. If there are no tags, falls back to `HEAD~20`.
+
+## What it returns
+
+A markdown release-notes draft. Categories with no entries are omitted.
+The footer reports how many commits were grouped and what percentage fell
+into "Other" — a high "Other" percentage hints that the project would
+benefit from conventional-commit messages.
+
+## Install
+
+```text
+/plugin install release-notes@ur-plugins-official
+```

package/plugins/core/release-notes/commands/release-notes.md

@@ -0,0 +1,56 @@
+---
+description: Draft release notes by grouping commits since the last tag (or a given ref).
+argument-hint: "[since-ref] (default: last tag)"
+---
+
+Determine the base ref:
+
+- If `$ARGUMENTS` is non-empty, use it.
+- Otherwise run `git describe --tags --abbrev=0` to find the most recent
+  tag and use that.
+- If there are no tags, fall back to `HEAD~20`.
+
+Get the commit list:
+
+```sh
+git log <base>..HEAD --pretty=format:'%h %s'
+```
+
+If the result is empty, say "No new commits since `<base>`." and stop.
+
+Otherwise group commits by category. Decide category from the commit
+message itself, in this order of preference:
+
+1. Conventional-commit prefix (`feat:`, `fix:`, `docs:`, `chore:`,
+   `refactor:`, `test:`, `perf:`, `style:`).
+2. Keyword in the subject (`add`, `new`, `introduce` → feature;
+   `fix`, `bug`, `correct` → fix; `doc`, `readme` → docs).
+3. Otherwise → "Other".
+
+Render a markdown draft:
+
+```md
+## <next-version-or-today>
+
+### Features
+- <one-line per feature commit, short SHA in backticks at the end>
+
+### Fixes
+- ...
+
+### Documentation
+- ...
+
+### Other
+- ...
+```
+
+If the project has a `package.json` with a `version`, use it for the
+header (`## <version> — <YYYY-MM-DD>`). Otherwise just use today's
+date.
+
+Omit any section that has no entries — do not show empty headers.
+
+End with one line: how many commits total were grouped and what
+percentage fell into "Other". A high "Other" percentage signals the
+project would benefit from conventional-commit messages.

package/plugins/core/skill-forge/.ur-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "skill-forge",
+  "version": "0.1.0",
+  "description": "Have the agent author complete skills for you: describe what you want, and the active model writes a ready-to-use SKILL.md (frontmatter, steps, success criteria) and saves it to your skills directory.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/skill-forge",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["skill", "authoring", "generator", "automation", "meta"]
+}

package/plugins/core/skill-forge/README.md

@@ -0,0 +1,37 @@
+# skill-forge
+
+Have the agent build skills for you. Describe what you want and the **currently
+selected model** authors a complete, ready-to-use `SKILL.md` — frontmatter,
+triggers, steps, and success criteria — then saves it to your skills directory.
+
+This complements the built-in `/create-skill`, which only scaffolds an empty
+template. `skill-forge` writes the real content.
+
+## Commands
+
+| Command | Argument | What it does |
+| --- | --- | --- |
+| `/forge-skill` | `<what it should do> [--project]` | Author a full skill from your description and save it. |
+| `/skill-refine` | `<name> : <change>` | Improve or extend an existing skill. |
+
+A bundled `skill-authoring` skill defines the conventions both commands follow
+(frontmatter, trigger design, step structure, tool scoping).
+
+## Setup
+
+```sh
+/plugin install skill-forge@ur-plugins-official
+/forge-skill a skill that drafts release notes from the git log since the last tag
+```
+
+The commands run as prompts, so they use whatever model your session is on — no
+configuration. Skills are saved to `~/.ur/skills/<name>/` by default, or
+`./.ur/skills/<name>/` with `--project`. Existing skills are never overwritten.
+
+## How it works
+
+`/forge-skill` reads your brief, designs the skill (name, `when_to_use` triggers,
+arguments, minimal `allowed-tools`, inline vs fork, steps with success criteria),
+shows you the `SKILL.md` for a one-tap confirmation, then writes it — adding
+helper scripts beside it when the task warrants. After saving, invoke it like any
+skill: `/<name>`.

package/plugins/core/skill-forge/commands/forge-skill.md

@@ -0,0 +1,47 @@
+---
+description: Author a complete, reusable skill from your description and save it to your skills directory.
+argument-hint: "<what the skill should do> [--project]"
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir:*), AskUserQuestion
+---
+
+Author a new UR skill from `$ARGUMENTS`, following the conventions in the
+`skill-authoring` skill. You — the active session model — do the writing; this
+is not a template scaffold.
+
+**1. Get the brief.**
+- If `$ARGUMENTS` describes a skill, treat it as the brief.
+- If `$ARGUMENTS` is empty, offer to capture what this session just did, or ask
+  for a one-line description. Do not proceed without a brief.
+- Note whether `--project` was passed (it controls the save location).
+
+**2. Design it.** From the brief, decide:
+- a kebab-case `name` and a one-line `description`;
+- `when_to_use` — the trigger phrases and example user messages that should
+  auto-invoke it (the most important field; start with "Use when…");
+- whether it takes `arguments` (with an `argument-hint`);
+- the minimum `allowed-tools`, as narrow patterns (`Bash(gh:*)`, not bare `Bash`);
+- `inline` (default) vs `context: fork` (self-contained, no mid-run input);
+- the ordered steps, each with an explicit **Success criteria**.
+
+Keep simple skills simple — do not over-engineer a two-step process or
+interrogate the user for one. Ask focused AskUserQuestion rounds only when the
+brief is genuinely ambiguous.
+
+**3. Draft and confirm.** Output the complete `SKILL.md` as a fenced `yaml`
+block so the user can review it, then ask one concise AskUserQuestion — "Save
+this skill?" Do not add a "needs tweaking" option; the freeform Other covers
+edits.
+
+**4. Save.** Resolve the directory:
+- global (default): `~/.ur/skills/<name>/`
+- project (`--project`): `./.ur/skills/<name>/`
+
+Never overwrite an existing `SKILL.md` — if one exists, pick a new name or point
+the user to `/skill-refine`. Create the directory (`mkdir -p`) and write
+`SKILL.md`. If the skill needs helper scripts or reference material, create them
+under the skill directory and reference them from the body (progressive
+disclosure) rather than inlining everything.
+
+**5. Report.** Print the saved path, how to invoke it (`/<name> [args]`), and
+that it can be edited directly. If it does not appear immediately, a new session
+will pick it up.

package/plugins/core/skill-forge/commands/skill-refine.md

@@ -0,0 +1,19 @@
+---
+description: Improve or extend an existing skill — sharpen triggers, add steps, scripts, or success criteria.
+argument-hint: "<skill-name> : <what to change or add>"
+allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion
+---
+
+Refine an existing skill.
+
+1. Split `$ARGUMENTS` into a skill name and the change request (separated by
+   `:`). If the name is missing, list the skills under `~/.ur/skills` and
+   `./.ur/skills` and ask which one to refine.
+2. Locate its `SKILL.md` — project `./.ur/skills/<name>/` takes precedence over
+   global `~/.ur/skills/<name>/`. If none exists, say so and offer `/forge-skill`.
+3. Read it, then apply the requested change while keeping the `skill-authoring`
+   conventions: a sharp `when_to_use`, minimal `allowed-tools`, and a
+   **Success criteria** on every step. Preserve everything not being changed.
+4. Show the updated `SKILL.md` (or a diff of the changed sections) and confirm
+   with one AskUserQuestion before writing.
+5. Save in place and report exactly what changed.

package/plugins/core/skill-forge/skills/skill-authoring/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: Skill Authoring
+description: Conventions for writing a high-quality UR skill — frontmatter fields, trigger design, step structure with success criteria, tool scoping, and storage locations. Use when authoring, generating, or refining a SKILL.md.
+when_to_use: Use when creating or improving a skill — e.g. "make a skill that…", "turn this into a skill", "forge a skill", or editing a SKILL.md.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir:*), AskUserQuestion
+---
+
+# Skill Authoring
+
+A skill is a reusable prompt UR auto-invokes when its triggers match. Quality
+lives in two places: a `when_to_use` sharp enough to fire at the right time, and
+steps concrete enough to execute without re-deriving the process.
+
+## Storage
+
+- **Project**: `./.ur/skills/<name>/SKILL.md` — workflows specific to this repo.
+- **Personal**: `~/.ur/skills/<name>/SKILL.md` — follows the user across repos.
+
+`<name>` is kebab-case. The file is `SKILL.md`. Supporting scripts and reference
+files live beside it in the same directory.
+
+## Frontmatter
+
+```yaml
+---
+name: <kebab-case-name>
+description: <one line: what it does>
+when_to_use: Use when <situation>. Examples: "<trigger phrase>", "<another>".
+allowed-tools: Read, Write, Bash(gh:*)        # minimum, narrow patterns
+argument-hint: "<arg placeholders>"           # only if it takes arguments
+arguments:                                    # only if it takes arguments
+  - <arg_name>
+context: fork                                 # omit for inline (the default)
+---
+```
+
+- **`when_to_use` is the most important field.** It tells the model when to
+  auto-invoke. Start with "Use when…" and include real trigger phrases and
+  example user messages. A vague `when_to_use` means the skill never fires.
+- **`allowed-tools`**: grant the minimum. Prefer scoped patterns like
+  `Bash(gh:*)` over bare `Bash`.
+- **`context: fork`** only for self-contained skills that need no mid-run input;
+  otherwise leave it inline so the user can steer.
+- **`arguments` / `argument-hint`**: include only if the skill takes parameters.
+  Reference them in the body as `$arg_name`.
+
+## Body structure
+
+```markdown
+# <Skill Title>
+One-line statement of what this skill accomplishes.
+
+## Inputs
+- `$arg_name`: what it is.
+
+## Goal
+The end state, with concrete artifacts or criteria for "done".
+
+## Steps
+
+### 1. <Step name>
+What to do — specific and actionable, with commands where useful.
+**Success criteria**: how we know this step is done. REQUIRED on every step.
+```
+
+### Per-step annotations (optional, add only when they matter)
+
+- **Success criteria** — required on every step; the signal it is safe to move on.
+- **Execution** — `Direct` (default), `Task agent`, `Teammate` (parallel), or
+  `[human]` when the user must act.
+- **Artifacts** — data a step produces that later steps consume (PR number, SHA).
+- **Human checkpoint** — pause for confirmation before irreversible actions
+  (merging, sending messages, deleting).
+- **Rules** — hard constraints; the user's mid-session corrections belong here.
+
+Steps that can run concurrently use sub-numbers (3a, 3b).
+
+## Principles
+
+- Keep simple skills simple — a two-step skill needs no annotations.
+- Be concrete: name commands, paths, and success signals, not vague advice.
+- Progressive disclosure: put long references or scripts in sibling files and
+  link them, rather than bloating the SKILL.md.
+- Don't over-interview the user; infer a strong draft, then confirm once.

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

@@ -0,0 +1,26 @@
+{
+  "name": "word",
+  "version": "0.1.0",
+  "description": "Create, convert, review, and edit Microsoft Word documents from UR — through the Office Word MCP server (python-docx, ~54 tools) with a pandoc / python-docx fallback.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/UR"
+  },
+  "homepage": "https://github.com/Maitham16/UR/tree/master/plugins/core/word",
+  "repository": "https://github.com/Maitham16/UR",
+  "license": "LicenseRef-UR-AGENT-Non-Commercial-Self-Responsibility",
+  "keywords": ["word", "docx", "document", "office", "mcp"],
+  "mcpServers": {
+    "word": {
+      "command": "uvx",
+      "args": ["--from", "office-word-mcp-server", "word_mcp_server"]
+    }
+  },
+  "userConfig": {
+    "DOCX_DIR": {
+      "type": "directory",
+      "title": "Default documents directory",
+      "description": "Where new .docx files are written when no path is given. Defaults to the current working directory."
+    }
+  }
+}

package/plugins/core/word/README.md

@@ -0,0 +1,37 @@
+# word
+
+Create, convert, review, and edit Microsoft Word documents from any UR session.
+Backed by the **Office Word MCP server** (python-docx, ~54 tools), with a
+`pandoc` / `python-docx` fallback so the commands still work headless.
+
+## Commands
+
+| Command | Argument | What it does |
+| --- | --- | --- |
+| `/docx-new` | `<brief \| outline.md>` | Create a styled document from a brief or outline. |
+| `/docx-from-md` | `<file.md> [out.docx]` | Convert Markdown to a styled `.docx`. |
+| `/docx-review` | `<file.docx>` | Report structure, styling, and accessibility issues with a verdict. |
+| `/docx-edit` | `<file.docx> — <change>` | Apply targeted edits while preserving styles. |
+
+A bundled `document-craft` skill defines the styling and accessibility
+conventions all commands follow.
+
+## Setup
+
+```sh
+/plugin install word@ur-plugins-official
+```
+
+The MCP server runs via `uvx`, so install **uv** once
+(`curl -LsSf https://astral.sh/uv/install.sh | sh`). UR launches
+`uvx --from office-word-mcp-server word_mcp_server` on demand — no manual clone.
+Optionally set **DOCX_DIR** as the default output folder.
+
+Fallbacks use `pandoc` (Markdown → docx) and `python-docx`
+(`pip install python-docx`); install either if you want the commands to work
+without `uvx`.
+
+## Security
+
+The server operates on local files only. Edits preserve existing styles, and
+in-place overwrites can keep a backup on request.

package/plugins/core/word/commands/docx-edit.md

@@ -0,0 +1,18 @@
+---
+description: Apply targeted edits to a Word document — find/replace, add sections, restyle.
+argument-hint: "<path/to/file.docx> — <what to change>"
+---
+
+Edit the `.docx` named in `$ARGUMENTS`. Split the argument into the file path and
+the change instruction (separated by `—`, `:`, or a newline). If either is
+missing, ask for it and stop.
+
+1. Read the document so edits respect its existing structure and styles.
+2. Apply only the requested change: find/replace text, insert or remove a
+   heading/section, restyle a range, update a table, refresh the TOC. Preserve
+   every unrelated paragraph and its style exactly.
+3. Save in place. Before overwriting, note that a copy can be kept on request.
+
+Prefer the `word` MCP tools (`find_and_replace`, `add_heading`, `format_text`,
+...). If unavailable, fall back to `python-docx`. Report a concise diff of what
+changed — sections touched, replacements made — not the whole document.

package/plugins/core/word/commands/docx-from-md.md

@@ -0,0 +1,19 @@
+---
+description: Convert a Markdown file into a styled Word document.
+argument-hint: "<path/to/file.md> [output.docx]"
+---
+
+Convert a Markdown file to `.docx`.
+
+1. Read the source Markdown at the first argument. If missing, ask for a path
+   and stop.
+2. Map structure to Word styles: `#`→Title or Heading 1, `##`/`###`→Heading 2/3,
+   lists→list styles, fenced code→a monospace style, tables→Word tables, images
+   →embedded with the alt text preserved.
+3. Write to the second argument if given, else the same basename with a `.docx`
+   extension in `${user_config.DOCX_DIR}` or the current directory.
+
+Prefer the `word` MCP tools. If unavailable, use `pandoc -o <out>.docx <in>.md`
+when pandoc is installed; otherwise fall back to `python-docx` for headings,
+paragraphs, lists, and tables. Report the path and note anything that did not
+map cleanly.

package/plugins/core/word/commands/docx-new.md

@@ -0,0 +1,22 @@
+---
+description: Create a new Word document from a brief or an outline.
+argument-hint: "<topic / brief> or <path/to/outline.md>"
+---
+
+Create a `.docx` from `$ARGUMENTS`. If empty, ask for a topic or outline and stop.
+
+1. Gather the brief: if `$ARGUMENTS` is a path to a file, read it as the outline;
+   otherwise treat the text as the brief and propose a structure first.
+2. Plan the document: a title, optional subtitle/author, a logical heading
+   hierarchy, and the sections to write. Confirm a long structure before writing
+   if it is non-trivial.
+3. Build the document using real Word styles — `Title`, `Heading 1/2/3`, body —
+   never manual bold/size as a substitute for styles. Add a table of contents
+   field if there are three or more H1s.
+4. Save to `${user_config.DOCX_DIR}` if set, else the current directory, with a
+   slugged filename.
+
+Prefer the `word` MCP tools (`create_document`, `add_heading`, `add_paragraph`,
+`add_table`, ...). If the server is unavailable, fall back to `python-docx` via
+Bash. Apply the `document-craft` conventions. Report the path and the final
+outline.

package/plugins/core/word/commands/docx-review.md

@@ -0,0 +1,29 @@
+---
+description: Review a Word document's structure, styling, and accessibility.
+argument-hint: "<path/to/file.docx>"
+---
+
+Review the `.docx` at `$ARGUMENTS`. If empty, ask for a path and stop.
+
+Read the document and report, skipping any section with no findings:
+
+### Structure
+Heading hierarchy sanity (no skipped levels, one Title), section/page breaks,
+presence and correctness of a table of contents.
+
+### Styling
+Manual formatting used where a style belongs, inconsistent fonts or sizes,
+direct color use, hard line breaks faking spacing.
+
+### Accessibility
+Images without alt text, tables without header rows, low-contrast text, links
+with bare URLs instead of descriptive text.
+
+### TL;DR
+End with exactly one of:
+- `TL;DR: Clean.`
+- `TL;DR: Minor fixes.`
+- `TL;DR: Needs structural work.`
+
+Prefer the `word` MCP tools to read the document; otherwise inspect it with
+`python-docx`. Do not modify the file — this command only reports.

package/plugins/core/word/skills/document-craft/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: Document Craft (Word)
+description: Conventions for producing professional Microsoft Word documents — styles over manual formatting, heading hierarchy, tables of contents, templates, track changes, tables, and accessibility. Use when creating, converting, reviewing, or editing .docx files.
+version: 0.1.0
+---
+
+# Document Craft (Word)
+
+A Word document is a structured object, not formatted text. Edit the structure;
+let styles carry the look.
+
+## Styles over manual formatting
+
+- Use `Title`, `Heading 1/2/3`, `Normal`, `Quote`, and list styles. Never fake a
+  heading with bold + larger font — it breaks navigation, the TOC, and
+  accessibility.
+- Change appearance by editing the style once, not each paragraph.
+- One font family for body, one for headings. Avoid per-paragraph color and size.
+
+## Heading hierarchy
+
+- Exactly one `Title`. Do not skip levels (no H1 → H3).
+- Headings are an outline: a reader should grasp the document from them alone.
+
+## Table of contents
+
+- Insert a TOC **field**, not a typed list, so it updates with the headings.
+- Add one when the document has three or more H1 sections.
+
+## Templates
+
+- Start from a `.dotx` template for repeated document types to inherit styles,
+  margins, and a title block. Keep brand styling in the template, not the content.
+
+## Track changes and comments
+
+- For review cycles, enable track changes so edits are visible and reversible.
+- Use comments for questions and suggestions; resolve them before finalizing.
+
+## Tables
+
+- Mark the first row as a header row (repeats across pages, aids accessibility).
+- Use table styles for banding; avoid manual cell shading per row.
+
+## Accessibility
+
+- Every image needs alt text.
+- Links use descriptive text, not a bare URL.
+- Maintain reading order and sufficient contrast; do not encode meaning in color
+  alone.
+
+## Page setup
+
+- Set margins, headers/footers, and page numbers via section settings, not blank
+  paragraphs and tabs.
+
+## Guardrails
+
+- Preserve existing styles when editing; do not restyle untouched content.
+- Offer to keep a copy before overwriting a document in place.
+- Do not flatten styled content to plain paragraphs during conversion.

package/plugins/examples/README.md

@@ -0,0 +1,12 @@
+# UR-AGENT plugin examples
+
+This directory contains templates for local UR-AGENT plugins. Copy an example
+directory, edit its `.ur-plugin/plugin.json`, and install it with:
+
+```bash
+ur --plugin-dir ./plugins/examples/command-template
+```
+
+Production first-party plugins live in `plugins/core/`. Community plugins can
+be staged under `plugins/community/` before being promoted into the official
+marketplace manifest.

package/plugins/examples/command-template/.ur-plugin/plugin.json

@@ -0,0 +1,12 @@
+{
+  "name": "command-template",
+  "displayName": "Command Template",
+  "version": "0.1.0",
+  "description": "Minimal UR-AGENT plugin template that contributes one slash command.",
+  "author": {
+    "name": "UR-AGENT"
+  },
+  "commands": {
+    "example": "./commands/example.md"
+  }
+}

package/plugins/examples/command-template/README.md

@@ -0,0 +1,9 @@
+# Command Template
+
+Minimal local UR-AGENT plugin template.
+
+```bash
+ur --plugin-dir ./plugins/examples/command-template
+```
+
+Edit `commands/example.md` to change the command behavior.

package/plugins/examples/command-template/commands/example.md

@@ -0,0 +1,7 @@
+---
+description: Demonstrate a minimal UR-AGENT plugin command.
+argument-hint: "[optional context]"
+---
+
+Reply with a short, factual confirmation that the command-template plugin is
+loaded. If `$ARGUMENTS` is present, include it as the user-provided context.