Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions .augment-plugin/marketplace.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
{
"name": "auggie-marketplace",
"description": "Official Auggie plugin marketplace with code review and developer productivity tools",
"version": "1.0.0",
"author": {
"name": "Augment Code"
},
"homepage": "https://github.com/augmentcode/auggie",
"repository": "https://github.com/augmentcode/auggie",
"plugins": [
{
"name": "code-review",
"description": "Code review commands and agents for local code reviews powered by git diffs against origin/main",
"version": "1.0.0",
"source": "./plugin_marketplace/code-review",
"category": "code-quality",
"tags": ["code-review", "git", "commands", "agents"]
}
]
}
9 changes: 9 additions & 0 deletions plugin_marketplace/code-review/.augment-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
{
"name": "code-review",
"description": "Code review commands and agents for local code reviews",
"version": "1.0.0",
"author": {
"name": "Augment Code"
},
"keywords": ["code-review", "git", "commands", "agents"]
}
58 changes: 58 additions & 0 deletions plugin_marketplace/code-review/agents/local-analyzer.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
name: code-review-local-analyzer
description: Fetch local changes (diff against main) to perform code review
model: "code-review"
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

color: yellow
---

**IMPORTANT: This is a dry-run review. Do NOT post any comments to GitHub. Return all findings as a summary to the user.**

You are a specialized agent that gathers local changes and reviews the code

Scope:
- Fetch local git diff and changed files against origin/main.
- Perform code review of these changes

Tooling constraints:
- Allowed tools: `launch-process`, `view`
- Disallowed tools: `github-api`
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Steps

1. Run `git fetch origin main` to ensure accurate comparison
2. Run `git diff origin/main...HEAD` to get the full diff of committed changes
3. Run `git diff --stat origin/main...HEAD` to get file statistics
4. Run `git diff --name-only origin/main...HEAD` to list changed files
5. If there are uncommitted changes, include those as well:
- **Staged changes:** `git diff --staged` (changes staged in the index vs HEAD)
- **Unstaged changes:** `git diff` (working tree vs index)
- Note: These diffs are relative to the current HEAD/index, not origin/main. They represent work-in-progress that hasn't been committed yet.

## Output

Return the following to the parent agent:

```
## Local Changes Summary
Branch: [branch-name] | Base: origin/main | Commits: [N]
Files: [N] | +[additions] -[deletions]
[One sentence describing what this change set does]
## Review Findings
1. [file/path.ext]:[line(s)]
Severity: [low|medium|high]
[Description of issue and suggested fix]
2. [file/path.ext]:[line(s)]
Severity: [low|medium|high]
[Description of issue and suggested fix]
```

Focus on high-signal issues—bugs, security, logic errors. Skip style nitpicks.

**Do NOT post any comments to GitHub. Return findings as a summary only.**
82 changes: 82 additions & 0 deletions plugin_marketplace/code-review/commands/local.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
---
description: "Perform a thorough code review on local changes and return findings as a summary (no comments posted)"
model: "code-review"
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@akshayutture-augment akshayutture-augment Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name field is actually not used by the auggie plugin system for commands - so we can get rid of the name field here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Author Agent⚡ on behalf of @akshayutture-augment

Removed the name field from the command frontmatter. Fixed in 914f970.

---

**IMPORTANT: This is a dry-run review. Do NOT post any comments to GitHub. Return all findings as a summary to the user.**

Tooling constraints:
- Allowed tools: `launch-process`, `view`
- Disallowed tools: `github-api`

## Step 1: Gather Changes to Review

Run the following git commands to gather local changes:

1. Run `git fetch origin main` to ensure accurate comparison
2. Run `git diff origin/main...HEAD` to get the full diff of committed changes
3. Run `git diff --stat origin/main...HEAD` to get file statistics
4. Run `git diff --name-only origin/main...HEAD` to list changed files
5. If there are uncommitted changes, include those as well:
- **Staged changes:** `git diff --staged` (changes staged in the index vs HEAD)
- **Unstaged changes:** `git diff` (working tree vs index)
- Note: These diffs are relative to the current HEAD/index, not origin/main. They represent work-in-progress that hasn't been committed yet.
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### Changes Summary Format

After gathering the data, organize it as follows:

**Proposed Changes Summary:**
- [One sentence describing what this change set does]
- **Files changed:** [count]
- **Additions:** [+lines] | **Deletions:** [-lines]

## Step 2: Check for Custom Guidelines

Look for custom code review guidelines in the repository:
- Check if `.augment/code_review_guidelines.yaml` exists in the repository root
- If the file doesn't exist or can't be read, skip this step and proceed without custom guidelines
- If found, read the file and identify areas and rules relevant to the changed files:
- Match file paths from Step 1 against the `globs` patterns in each area
- Collect the matching rules to apply during review
- Do not apply custom guidelines to Augment internal files (`.augment/**/*.md`)

When referencing a custom guideline in your review findings, mention it using the format:
`(Guideline: <guideline_id>)`

## Step 3: Review the Changes

Analyze the diff and identify issues. Apply any custom guidelines loaded in Step 2. Focus on high confidence findings—bugs, security issues, logic errors. Skip low-severity issues unless they indicate a pattern.

## Step 4: Format the Review Summary

Present the review using this format:

```
## Local Changes Summary

Branch: [branch-name] | Base: origin/main | Commits: [N]
Files: [N] | +[additions] -[deletions]

[One sentence describing what this change set does]

## Review Findings

1. [file/path.ext]:[line(s)]

Severity: [low|medium|high]
[Description of issue and suggested fix]

2. [file/path.ext]:[line(s)]

Severity: [low|medium|high]
[Description of issue and suggested fix]
```

## Guidelines

- Be specific with file paths and line numbers
- Explain *why* something is problematic
- Skip style nitpicks if there are real bugs

**Do NOT post any comments to GitHub. Return findings as a summary only.**