feat(plugins): add BoozeLee/awesome-mcode-local-skill

plugins/BoozeLee/awesome-mcode-local-skill/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 awesome-mcode contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

plugins/BoozeLee/awesome-mcode-local-skill/README.md

@@ -0,0 +1,105 @@
+# awesome-mcode-local-skill
+
+Four project skills from the
+[awesome-mcode](https://github.com/BoozeLee/awesome-mcode) starter, packaged so any
+MiniMax Code install can use them.
+
+| Skill | Trigger | Output |
+|---|---|---|
+| `project-onboarding` | "set up this project", "onboard this codebase" | AGENTS.md + entry-point map |
+| `code-review` | "review this", "is this safe to merge" | Severity-tagged review of the pending diff |
+| `git-workflow` | "commit this", "make a PR" | Conventional Commit, push, optional `gh pr create` |
+| `daily-standup` | "what did I do", "standup" | Yesterday / today / blockers from `git log` |
+
+Each Skill is a Markdown file with frontmatter that states what it does and when it should
+activate, so MiniMax Code can pick the right one from the request alone.
+
+## Try it
+
+```text
+Onboard this repository: read AGENTS.md, then map the entry points and give me a tour.
+```
+
+Expected result: a written orientation of the project — what it is, where the code starts,
+which commands build and test it, and any entry-point map worth keeping. If the repo already
+has a current `AGENTS.md`, the Skill says so instead of regenerating one.
+
+```text
+Review my pending changes against AGENTS.md and tell me if this is safe to merge.
+```
+
+Expected result: a structured review of the working-tree diff, each finding tagged by
+severity, with file and line references, and an explicit verdict.
+
+## Requirements
+
+- MiniMax Code 0.3 or newer.
+- `git` on `PATH`. `git-workflow` and `daily-standup` read history and stage commits; they
+  will report that the directory is not a git repository rather than failing.
+- `gh` on `PATH` — **only** if you want `git-workflow` to open a pull request. Without it the
+  Skill stops after the local commit and tells you the exact command to run yourself.
+- No accounts, no paid services, no API keys.
+
+Supported platforms: any platform with a POSIX shell and `git`. The Skills themselves are
+platform-neutral Markdown.
+
+## Data and network
+
+- **Network access: none.** The Plugin ships no MCP server and makes no requests. It reads
+  and writes only the files in the repository you point it at.
+- **Credentials: none required.** It never reads or writes your MiniMax configuration and
+  never reads tokens.
+- **Data handled:** local repository contents and `git` history. `daily-standup` reads commit
+  metadata for a date window; `code-review` reads the pending diff; `git-workflow` stages and
+  commits the changes you asked it to land, and pushes only after you confirm.
+- **Destructive actions are gated.** `git-workflow` will not push to a protected branch or
+  force-push without explicit confirmation. Nothing here deletes files.
+
+## Install
+
+This Plugin is not published to the `official` marketplace yet, so install it from a clone
+into the `local` marketplace, which is a plain directory:
+
+```bash
+git clone --branch feat/awesome-mcode-local-skill --single-branch \
+  https://github.com/BoozeLee/MiniMax-Code-Plugins.git
+cp -r MiniMax-Code-Plugins/plugins/BoozeLee/awesome-mcode-local-skill ~/.minimax/plugins/
+mcode plugin add awesome-mcode-local-skill@local
+mcode plugin list -m local
+```
+
+The `local` marketplace is `~/.minimax/plugins/`. The Plugin root must be a **physical
+directory** — MiniMax Code opens plugin roots with `rejectSymlink: true` and rejects a
+symlinked one with `PLUGIN_ROOT_SYMLINK`, which drops the Plugin from `mcode plugin list -m
+local` without a visible error. `cp -r`, not `ln -s`.
+
+If you already use the [awesome-mcode](https://github.com/BoozeLee/awesome-mcode) starter, it
+installs this Plugin for you with `./scripts/sync-skills.sh --install`.
+
+## Layout
+
+```
+awesome-mcode-local-skill/
+├── plugin.json
+├── README.md
+├── LICENSE
+└── skills/
+    ├── project-onboarding/SKILL.md
+    ├── code-review/SKILL.md
+    ├── git-workflow/SKILL.md
+    └── daily-standup/SKILL.md
+```
+
+`plugin.json` sits at the plugin root because that is the path the community registry
+validator reads. It deliberately carries no `skills`, `mcpServers`, or `apps` array: the
+validator's allowed-field list rejects those as unknown fields, and it discovers Skills from
+the filesystem instead. The Skill directory names match their frontmatter `name` fields,
+which the validator requires.
+
+Source of truth for the Skills is
+[github.com/BoozeLee/awesome-mcode/tree/main/skills](https://github.com/BoozeLee/awesome-mcode/tree/main/skills);
+this package mirrors them.
+
+## License
+
+MIT — see [LICENSE](LICENSE).

plugins/BoozeLee/awesome-mcode-local-skill/plugin.json

@@ -0,0 +1,21 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+  "name": "awesome-mcode-local-skill",
+  "version": "0.2.0",
+  "description": "Four project skills from the awesome-mcode starter: project-onboarding, code-review, git-workflow, daily-standup. Bundles the local-only workflow starters in a portable package for any mcode install.",
+  "author": {
+    "name": "BoozeLee"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/BoozeLee/awesome-mcode",
+  "repository": "https://github.com/BoozeLee/awesome-mcode",
+  "keywords": [
+    "awesome-mcode",
+    "starter",
+    "productivity",
+    "git",
+    "code-review",
+    "onboarding",
+    "standup"
+  ]
+}

plugins/BoozeLee/awesome-mcode-local-skill/skills/code-review/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: code-review
+description: |
+  Use when the user says "review this", "review my changes", "look at this
+  PR", "is this safe to merge", or asks the agent to evaluate pending code
+  before committing. Reads the diff, checks it against AGENTS.md, runs
+  relevant tests, and produces a structured review with severity-tagged
+  findings. Do NOT use for wholesale refactor suggestions — those are a
+  separate task.
+---
+
+# code-review
+
+Reviews uncommitted / unstaged changes or a pull request. Surfaces findings
+in priority order so the user can decide what to fix before commit or merge.
+
+## When to trigger
+
+- "review this", "review my changes", "PR review"
+- Before running `git commit` if the user asked for a sanity pass
+
+## When NOT to trigger
+
+- The change is one or two lines of trivial cleanup
+- The user explicitly says they want a refactor proposal (different task)
+- There are no changes (`git diff` is empty) — say so and stop
+
+## Procedure
+
+1. **Establish the diff.**
+   - Default: `git diff` (unstaged) + `git diff --staged` (staged).
+   - For a PR: `gh pr diff <number>` or `git diff main...HEAD`.
+   - If the diff is empty, stop and report.
+
+2. **Read the project rules.** Open `AGENTS.md` (or `CLAUDE.md` /
+   `CONTRIBUTING.md` in that order of preference). Capture: style tool,
+   test gate, error style, forbidden ops.
+
+3. **Run the gate.** Execute the project's lint + format + test commands
+   from AGENTS.md. Capture pass/fail and any output.
+
+4. **Read the diff carefully.** For each file, look for:
+   - **Correctness.** Off-by-one, null/undefined, race conditions, error
+     swallowing, partial writes, type mismatches.
+   - **Security.** Untrusted input → SQL/Command, secrets in code,
+     missing auth, path traversal, SSRF, prototype pollution.
+   - **Tests.** New code without a test; new branch without a case;
+     flaky-looking setup.
+   - **Style.** Imports, naming, formatting, dead code.
+   - **API surface.** Public exports changed without a doc update.
+   - **Performance.** O(n²) where O(n) is obvious, sync I/O in async
+     paths, missing indexes.
+
+5. **Tag each finding.** Use:
+   - 🔴 **blocker** — must fix before merge (bug, security, data loss)
+   - 🟠 **major** — should fix before merge (perf, correctness, tests)
+   - 🟡 **minor** — nit, style, optional cleanup
+   - 💬 **question** — needs author clarification
+
+6. **Produce the review.** Output structure:
+
+```markdown
+# Review: <branch / commit range>
+
+**Gate:** ✅ / ❌ / ⚠️ partial  (<commands run>)
+**Files:** <count>  **+/-:** <insertions>/<deletions>
+
+## Findings
+
+### 🔴 blockers
+- `<file>:<line>` — <issue> [suggested change]
+
+### 🟠 majors
+- ...
+
+### 🟡 minors
+- ...
+
+### 💬 questions
+- ...
+
+## Summary
+<one paragraph: ship it, fix-and-ship, or needs work>
+```
+
+7. **Hand off.** Ask: *"Want me to address the blockers, or leave them
+for the author?"*
+
+## Failure handling
+
+- **Diff is empty.** Report and stop.
+- **Gate fails.** Still produce the review but mark the gate ❌. Do not
+  attempt to fix the gate output automatically — surface it.
+- **AGENTS.md missing.** Fall back to defaults: lint = `npm run lint`
+  or repo equivalent; test = `npm test`. Note in the review that rules
+  were inferred.
+- **Reviewing a PR with >50 files.** Decline to "broad review" mode:
+  group by directory, only surface cross-cutting issues, and ask the
+  user to point at the risky areas first.
+
+## Acceptance bar
+
+Every blocker has a one-line fix proposal. Every major has either a fix
+or a question for the author. No "you might want to consider" mush.

plugins/BoozeLee/awesome-mcode-local-skill/skills/daily-standup/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: daily-standup
+description: |
+  Use when the user says "what did I do", "standup", "yesterday's work",
+  "give me the standup", "what did I ship today", or asks the agent to
+  produce a status update from git history. Reads `git log` for a date
+  window, groups by area (path / topic), and outputs a standup-shaped
+  summary. Skip if there is no git repo or no commits in the window.
+---
+
+# daily-standup
+
+Turns yesterday's (or N-day) commit history into a standup-shaped summary:
+**yesterday** (what shipped), **today** (what's open), **blockers** (what
+needs attention).
+
+## When to trigger
+
+- "what did I do", "standup", "yesterday", "give me my update"
+- Morning routine; end-of-day wrap-up
+
+## When NOT to trigger
+
+- No git repo (or no `.git`) — report and stop
+- No commits in the requested window — say so honestly
+- The user wants a project retrospective — that's a different task
+
+## Procedure
+
+1. **Find the window.** Default is the last 24 hours. If the user said
+   "this week", use 7 days. Parse `--since=<duration>` if the user gave a
+   spec (`2d`, `1w`, `2026-09-30`).
+
+2. **Collect commits.**
+   ```bash
+   git log --since="<window>" \
+           --pretty=format:"%h|%ad|%s|%an" \
+           --date=short \
+           --no-merges
+   ```
+   One commit per line: hash, date, subject, author.
+
+3. **Group by area.**
+   - First by **scope** inferred from the conventional-commit prefix
+     (`feat(scope):`, `fix(scope):`, etc.) if present.
+   - Otherwise by top-level dir of the changed files
+     (`git log --stat` + path prefix).
+   - Aim for 3–6 groups, no more. Combine "fix typo in x" and "fix typo in y"
+     into a single "fix: typos" group.
+
+4. **Pick today's open work.** Look at:
+   - `git status --porcelain` (uncommitted changes)
+   - `git log --oneline --since=<window> --grep='WIP\|WIP-stuff\|DOING'` (or any in-progress tag the team uses)
+   - The user can correct — surface them as drafts, not promises.
+
+6. **Compose the standalone writeup.** Output structure:
+
+```markdown
+# Standup — <human date>
+
+## Yesterday (<N> commits)
+
+### <Area 1>
+- <hash> <subject>
+- <hash> <subject>
+
+### <Area 2>
+- ...
+
+## Today
+- <open item 1>
+- <open item 2>
+
+## Blockers / Needs input
+- <if any; else open>
+```
+
+7. **Print the URL/commit list at the end** so the user can click through.
+
+## Failure handling
+
+- **No commits in window.** Be brief — *"0 commits in the last 24h."*
+  Don't invent.
+- **Single commit.** Don't group; just list it.
+- **Window crosses branches.** Default to `HEAD` only. If they want
+  multiple branches, accept `--branch <a>,<b>`.
+- **Dirty working tree.** Include a note in **Today** with `git status
+  --short` output.
+- **Not a git repo.** Stop. *"No git working tree here. Is there a
+  different repo you want me to look at?"*
+
+## Acceptance bar
+
+The user copies the **Yesterday** block into Slack/Discord/email without
+editing more than two words per line. **Today** lists real open work.
+**Blockers** are honest, not invented.