ur-agent 1.23.2 → 1.24.0

package/marketplace-plugins/obsidian/commands/vault-search.md

@@ -0,0 +1,20 @@
+---
+description: Answer a question strictly from the vault, with citations to notes.
+argument-hint: "<query>"
+---
+
+Answer a question using only what the vault contains, with citations.
+
+Query = `$ARGUMENTS`. If empty, ask for one and stop.
+
+1. Search `${user_config.OBSIDIAN_VAULT_PATH}` across filenames, tags, and full
+   text for notes relevant to the query.
+2. Read the top matches and synthesize a direct answer in 3–6 sentences.
+3. Cite every claim with the note it came from as a `[[wikilink]]`. If notes
+   disagree, say so and cite both.
+4. If the vault does not answer the question, say so plainly — do not fill the
+   gap from general knowledge unless asked. Offer to capture a note with
+   `/second-brain`.
+
+Prefer the `obsidian` MCP search tools when available; otherwise grep the vault
+files directly. End with a `Notes searched: N` line.

package/marketplace-plugins/obsidian/skills/second-brain/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: Second Brain (Obsidian)
+description: Conventions for building and maintaining a durable Obsidian knowledge base — atomic and evergreen notes, Zettelkasten linking, PARA structure, Maps of Content, frontmatter, and daily notes. Use when creating, organizing, linking, or searching notes in an Obsidian vault.
+version: 0.1.0
+---
+
+# Second Brain (Obsidian)
+
+A second brain is a network of notes, not a folder of documents. Its value is
+in the links, not the storage. Optimize for future retrieval and connection.
+
+## Principles
+
+- **Atomic.** One note, one idea. If a note needs "and" in its title, split it.
+- **Evergreen.** Write notes you can reuse, not log entries. Phrase titles as
+  claims (`Caching trades freshness for latency`), so the title alone carries
+  the idea.
+- **Your own words.** Restate, never paste. Quotes go under `## Source`.
+- **Link first.** A note with no links is lost. Connect every new note to at
+  least one existing note while the context is fresh.
+- **Concept over category.** Prefer a link to a tag, and a tag to a folder.
+
+## Note types
+
+- **Fleeting** — quick capture, lives in the daily note, processed within a day.
+- **Literature** — your summary of one external source, with the citation.
+- **Permanent** — one durable idea in your own words, densely linked. The core
+  of the vault.
+
+## Frontmatter
+
+```md
+---
+title: <declarative idea>
+created: <YYYY-MM-DD>
+tags: [<topic>]
+type: permanent      # fleeting | literature | permanent | moc
+---
+```
+
+## Naming and IDs
+
+Zettelkasten timestamp prefix keeps notes unique and stable under renames:
+`<YYYYMMDDHHmm> <slug>.md`. The human title lives in frontmatter and the `# H1`.
+
+## Structure (PARA, lightly)
+
+- `Projects/` — notes tied to an active outcome with a deadline.
+- `Areas/` — ongoing responsibilities with no end date.
+- `Resources/` — topic notes and references (most permanent notes live here).
+- `Archive/` — inactive items.
+- `Daily/` — dated notes. `MOCs/` — index notes.
+
+Folders are for lifecycle, not topic. Topic lives in links and tags.
+
+## Maps of Content (MOCs)
+
+When a topic exceeds ~7 notes, make a `<Topic> MOC` that links them under a few
+sub-themes and lists open threads. MOCs are the table of contents you grow into;
+they replace deep folder trees.
+
+## Tags vs links
+
+- **Links** (`[[note]]`) connect specific ideas. Prefer them.
+- **Tags** (`#status/draft`, `#topic/edge`) slice across notes by state or theme.
+  Keep a small, controlled tag set; an unbounded tag list is noise.
+
+## Daily notes
+
+The daily note is the inbox and the journal: capture fleeting thoughts, log what
+happened, link out to permanent notes. Process fleeting notes out of it regularly
+so it never becomes the place ideas go to die.
+
+## Maintenance
+
+- After capture, always backlink.
+- Weekly: empty fleeting notes, promote the keepers to permanent, refresh MOCs.
+- Treat orphan notes (zero links) as a backlog to wire in, not as done.
+
+## Anti-patterns
+
+- Pasting a source verbatim and calling it a note.
+- Noun-titled notes that collect unrelated facts.
+- Deep folder hierarchies used as a substitute for linking.
+- Tag sprawl: a new tag per note.
+- Capturing without ever linking or revisiting.

package/marketplace-plugins/powerpoint/.ur-plugin/plugin.json

@@ -0,0 +1,26 @@
+{
+  "name": "powerpoint",
+  "version": "0.1.0",
+  "description": "Build, convert, review, and theme PowerPoint decks from UR — through the Office PowerPoint MCP server (python-pptx, ~32 tools, templates) with a python-pptx fallback.",
+  "author": {
+    "name": "Maitham Al-rubaye",
+    "url": "https://github.com/Maitham16/ur-agent"
+  },
+  "homepage": "https://github.com/Maitham16/ur-agent/tree/master/marketplace-plugins/powerpoint",
+  "repository": "https://github.com/Maitham16/ur-agent",
+  "license": "LicenseRef-UR-Agent-Non-Commercial-Self-Responsibility",
+  "keywords": ["powerpoint", "pptx", "slides", "presentation", "office", "mcp"],
+  "mcpServers": {
+    "powerpoint": {
+      "command": "uvx",
+      "args": ["--from", "office-powerpoint-mcp-server", "ppt_mcp_server"]
+    }
+  },
+  "userConfig": {
+    "PPTX_DIR": {
+      "type": "directory",
+      "title": "Default decks directory",
+      "description": "Where new .pptx files are written when no path is given. Defaults to the current working directory."
+    }
+  }
+}

package/marketplace-plugins/powerpoint/README.md

@@ -0,0 +1,35 @@
+# powerpoint
+
+Build, convert, review, and theme PowerPoint decks from any UR session. Backed by
+the **Office PowerPoint MCP server** (python-pptx, ~32 tools with templates and
+themes), with a `python-pptx` fallback so the commands still work headless.
+
+## Commands
+
+| Command | Argument | What it does |
+| --- | --- | --- |
+| `/pptx-new` | `<brief \| outline.md>` | Build a deck from a brief or outline, with speaker notes. |
+| `/pptx-from-md` | `<outline.md> [out.pptx]` | Convert a Markdown outline to a sparse deck. |
+| `/pptx-review` | `<file.pptx>` | Critique density, consistency, and design with a verdict. |
+| `/pptx-theme` | `<file.pptx> [template]` | Apply a template/theme and normalize to layouts. |
+
+A bundled `deck-craft` skill defines the design conventions all commands follow.
+
+## Setup
+
+```sh
+/plugin install powerpoint@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-powerpoint-mcp-server ppt_mcp_server` on demand — no manual
+clone. Optionally set **PPTX_DIR** as the default output folder.
+
+The fallback uses `python-pptx` (`pip install python-pptx`); install it if you
+want the commands to work without `uvx`.
+
+## Security
+
+The server operates on local files only. Re-theming preserves slide content and
+order; reviews never modify the deck.

package/marketplace-plugins/powerpoint/commands/pptx-from-md.md

@@ -0,0 +1,18 @@
+---
+description: Convert a Markdown outline into a PowerPoint deck.
+argument-hint: "<path/to/outline.md> [output.pptx]"
+---
+
+Convert a Markdown outline to `.pptx`.
+
+1. Read the source at the first argument. If missing, ask for a path and stop.
+2. Map structure to slides: `#`→title slide, each `##`→a new slide title,
+   bullets→slide bullets (one level of nesting max on screen), a fenced
+   `notes:` block or HTML comment→speaker notes, image links→slide images,
+   tables→a table or a chart where it reads better.
+3. Keep slides sparse — push prose into the notes, not onto the slide.
+4. Write to the second argument if given, else the same basename with `.pptx` in
+   `${user_config.PPTX_DIR}` or the current directory.
+
+Prefer the `powerpoint` MCP tools; otherwise fall back to `python-pptx`. Report
+the path and the slide count, and flag any slide that ended up text-heavy.

package/marketplace-plugins/powerpoint/commands/pptx-new.md

@@ -0,0 +1,21 @@
+---
+description: Build a PowerPoint deck from a brief or an outline.
+argument-hint: "<topic / brief> or <path/to/outline.md>"
+---
+
+Build a `.pptx` from `$ARGUMENTS`. If empty, ask for a topic or outline and stop.
+
+1. Gather the brief: a path → read it as the outline; text → treat as the brief
+   and propose a slide outline first for anything non-trivial.
+2. Plan the deck: title slide, an agenda if there are five or more content
+   slides, one idea per content slide, and a clear closing/next-steps slide.
+3. Build with the deck's layouts and placeholders — title, content, two-content,
+   section header — not free-floating text boxes. Keep one idea, few words, and a
+   readable type size per slide. Add speaker notes with the detail that does not
+   belong on the slide.
+4. Save to `${user_config.PPTX_DIR}` if set, else the current directory.
+
+Prefer the `powerpoint` MCP tools (`create_presentation`, `add_slide`,
+`add_textbox`, `add_chart`, templates). If the server is unavailable, fall back
+to `python-pptx` via Bash. Apply the `deck-craft` conventions. Report the path
+and the slide outline.

package/marketplace-plugins/powerpoint/commands/pptx-review.md

@@ -0,0 +1,32 @@
+---
+description: Critique a PowerPoint deck for density, consistency, and design.
+argument-hint: "<path/to/file.pptx>"
+---
+
+Review the `.pptx` at `$ARGUMENTS`. If empty, ask for a path and stop.
+
+Read every slide and report, skipping any section with no findings:
+
+### Density
+Slides over ~6 bullets or ~36 words, walls of text that belong in notes, fonts
+smaller than is readable from the back of a room.
+
+### Consistency
+Inconsistent titles, fonts, colors, or bullet styles across slides; misaligned
+elements; off-template text boxes where a placeholder belongs.
+
+### Design and accessibility
+Low text/background contrast, color used as the only signal, charts without
+labels, images without alt text, missing slide numbers.
+
+### Flow
+Missing agenda or closing, abrupt section changes, a buried key message.
+
+### TL;DR
+End with exactly one of:
+- `TL;DR: Ready to present.`
+- `TL;DR: Minor polish.`
+- `TL;DR: Needs a rework.`
+
+Prefer the `powerpoint` MCP tools to read the deck; otherwise inspect it with
+`python-pptx`. Do not modify the file — this command only reports.

package/marketplace-plugins/powerpoint/commands/pptx-theme.md

@@ -0,0 +1,18 @@
+---
+description: Apply a template or theme to a deck and normalize it to the layouts.
+argument-hint: "<file.pptx> [template.pptx | .potx]"
+---
+
+Re-theme the deck named first in `$ARGUMENTS`.
+
+1. Identify the source deck and, if given, the template (`.pptx`/`.potx`) to
+   apply. With no template, normalize the deck to its own slide master and
+   layouts instead.
+2. Apply the theme: move free-floating text into the matching layout
+   placeholders, unify fonts and colors to the theme, and keep content intact.
+3. Preserve every slide's message and order — this restyles, it does not rewrite.
+
+Prefer the `powerpoint` MCP tools (template/theme application, layout mapping).
+If unavailable, do what `python-pptx` allows and clearly state what could not be
+remapped automatically. Report which slides changed and any that need a manual
+pass.

package/marketplace-plugins/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/marketplace-plugins/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-agent"
+  },
+  "homepage": "https://github.com/Maitham16/ur-agent/tree/master/marketplace-plugins/release-notes",
+  "repository": "https://github.com/Maitham16/ur-agent",
+  "license": "LicenseRef-UR-Agent-Non-Commercial-Self-Responsibility",
+  "keywords": ["release", "notes", "changelog", "git"]
+}

package/marketplace-plugins/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/marketplace-plugins/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/marketplace-plugins/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-agent"
+  },
+  "homepage": "https://github.com/Maitham16/ur-agent/tree/master/marketplace-plugins/skill-forge",
+  "repository": "https://github.com/Maitham16/ur-agent",
+  "license": "LicenseRef-UR-Agent-Non-Commercial-Self-Responsibility",
+  "keywords": ["skill", "authoring", "generator", "automation", "meta"]
+}

package/marketplace-plugins/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/marketplace-plugins/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/marketplace-plugins/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/marketplace-plugins/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/marketplace-plugins/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-agent"
+  },
+  "homepage": "https://github.com/Maitham16/ur-agent/tree/master/marketplace-plugins/word",
+  "repository": "https://github.com/Maitham16/ur-agent",
+  "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."
+    }
+  }
+}