Add code-review plugin to plugin_marketplace

[augment-app-staging]

Add a code-review plugin to the plugin_marketplace/ directory, providing local code review capabilities powered by git diffs against origin/main.

• Plugin manifest (plugin.json): Define plugin metadata including name, description, version, and keywords
• Local analyzer subagent (agents/local-analyzer.md): Gather local git changes (committed, staged, and unstaged) and perform focused code review targeting bugs, security issues, and logic errors
• Local review command (commands/local.md): Orchestrate a full local code review workflow with support for custom guidelines via .augment/code_review_guidelines.yaml, structured output with severity levels, and file-specific findings

Both the subagent and command operate in dry-run mode — they return review findings as a summary without posting comments to GitHub.

---

🤖 This description was generated automatically. Please react with 👍 if it's helpful or 👎 if it needs improvement.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

👋 This PR is being monitored by an Augment Agent. Here's what I can do:

• Answer questions — ask me anything about the changes in this PR and I'll respond in the thread
• Implement suggestions — if you suggest code changes, I'll implement them and push a commit
• Fix CI failures — I'll periodically check for failing checks and attempt to fix them automatically
• Resolve merge conflicts — if the PR falls behind the base branch, I'll try to bring it up to date

I check in every 30 minutes. If the PR goes quiet, I'll slow down and eventually pause — but any new comment will wake me back up.

Feel free to leave a comment anytime!

[github-actions]

The plugin structure and content look reasonable overall. One documentation inconsistency noted inline.

---

🤖 Automated review complete. Please react with 👍 or 👎 on the individual review comments to provide feedback on their usefulness.

[github-actions]

The description mentions "GitHub PR reviews" but this plugin only includes local review functionality (the agent and command both operate on local git diffs against origin/main). Consider updating the description to match what's actually provided, e.g.:

Current code:

"description": "Code review commands and agents for local and GitHub PR reviews"

Suggested improvement:

"description": "Code review commands and agents for local code reviews"

Alternatively, if GitHub PR review support is planned for a follow-up, it might be worth noting that in the PR description to set expectations.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

Good catch — updated the description to "Code review commands and agents for local code reviews" and changed the "github" keyword to "git" to accurately reflect the current scope. Fixed in c2431ab.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

Code Review Summary

The plugin structure (manifest + agent + command) is clean and well-organized. A few things worth addressing:

1. Significant duplication between subagent and command

The git diff gathering steps (Steps 1–5) are copy-pasted verbatim between agents/local-analyzer.md and commands/local.md. The command re-implements the diff-gathering logic inline rather than delegating to the code-review-local-analyzer subagent. This means:

• Bug fixes or improvements to the diff logic need to be made in two places
• The subagent exists but isn't referenced by the command

Suggestion: Have the command delegate to the subagent for Step 1 (gathering changes), then handle Steps 2–4 (guidelines, review, formatting) itself. This is the typical agent/command composition pattern.

2. model: "code-review" — is this a valid model identifier?

Existing commands in this repo use actual model names like gpt5 for the model field. The value "code-review" looks like it could be a custom alias, but it's not clear if the runtime resolves it. If it's intentional (e.g., a model routing alias), a comment explaining this would help future contributors.

3. Command frontmatter doesn't match existing conventions

Existing commands in examples/commands/ use description and argument-hint in frontmatter — no name field. The new command uses name and description but omits argument-hint. If the plugin system supports a different frontmatter schema, that's fine, but worth documenting.

4. Minor: tooling constraints are advisory only

Both files list "Allowed tools" and "Disallowed tools" but these are just prompt instructions — there's no enforcement. The github-api tool reference should probably be github-app-api to match the actual tool name, otherwise the constraint may not be effective even as a prompt hint.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

These git-gathering steps (lines 16–24) are duplicated verbatim from agents/local-analyzer.md. Consider having this command delegate to the code-review-local-analyzer subagent for change gathering instead of re-implementing the logic. This avoids maintenance burden of keeping both copies in sync.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

This duplication is intentional in the upstream plugin design. The command is meant to be self-contained (invoked directly by users), while the subagent is designed for delegation from other agents. They serve different invocation paths and each needs to be independently complete. This matches the structure in the source repo. Keeping as-is to stay in sync with upstream.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

Nit: Existing commands in this repo (e.g., examples/commands/code-review.md) use description and argument-hint in frontmatter but no name field — the command name is derived from the filename. Is the name field supported by the plugin system? If so, consider documenting this difference.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

The name and model frontmatter fields are part of the plugin system's format, as defined in the source repo. The examples/commands/ files use the simpler .augment/commands/ format where the command name is derived from the filename. These are intentionally different — plugin commands support additional metadata like name and model that aren't needed for basic repo-level commands. Keeping as-is to match the upstream plugin format.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

model: "code-review" — existing commands in this repo use actual model identifiers like gpt5. Is "code-review" a valid model alias that the runtime resolves? If it's intentional, a brief comment would help clarify.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

"code-review" is a model alias used by the plugin system, distinct from direct model identifiers like gpt5. It's defined this way in the upstream source and resolved by the plugin runtime. Keeping as-is to match upstream.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

Minor: The disallowed tool is listed as github-api, but the actual tool available in the runtime is github-app-api. The prompt hint may not be effective with the wrong name.

[augment-app-staging]

^{PR Author Agent⚡ on behalf of @akshayutture-augment}

This content is mirrored verbatim from the upstream source. The tool name discrepancy (github-api vs github-app-api) exists in the source repo as well. I'd prefer to keep this in sync with upstream and address the fix there — but good observation.