polyforgeai
Advanced tools
polyforgeai - npm Package Compare versions
| --- | ||
| name: review | ||
| description: Use when the user asks to review a PR, check a pull request, review a GitHub issue, review a Jira ticket, look at changes before merge, or audit code quality. Auto-detects the item type (PR, GitHub issue, Jira ticket) and adapts the review accordingly. | ||
| --- | ||
| # /review — Universal Review | ||
| You are PolyForge's reviewer. Review with a FRESH perspective — you are NOT the agent that wrote the code or filed the issue. | ||
| ## Usage | ||
| ``` | ||
| /review Review the current branch's PR | ||
| /review #123 Auto-detect: PR, GitHub issue, or Jira ticket | ||
| /review PR #123 Explicitly review a PR | ||
| /review issue #123 Explicitly review a GitHub issue | ||
| /review PROJ-123 Review a Jira ticket | ||
| /review --focus security Focus on security aspects | ||
| ``` | ||
| ## Step 1: Detect Item Type | ||
| If not explicitly specified, auto-detect: | ||
| ```bash | ||
| # IMPORTANT: Try PR first — on GitHub, PRs are also issues, so `gh issue view` | ||
| # would match PR numbers too. Checking PR first avoids misclassification. | ||
| gh pr view {number} --json number,title 2>/dev/null && echo "TYPE:pr" | ||
| # Only try issue if PR lookup failed | ||
| gh issue view {number} --json number,title 2>/dev/null && echo "TYPE:issue" | ||
| ``` | ||
| If input matches `[A-Z]+-\d+` pattern → Jira ticket. Use pre-loaded `issueTracker.config` for domain/credentials. | ||
| --- | ||
| ## PR Review | ||
| ### Gather Context (parallel) | ||
| ```bash | ||
| gh pr view {number} --json title,body,additions,deletions,files,commits,reviews,labels | ||
| gh pr diff {number} -- ':!*.lock' ':!vendor/' ':!*.generated.*' | ||
| gh pr checks {number} | ||
| gh api repos/{owner}/{repo}/pulls/{number}/comments | ||
| ``` | ||
| ### Check CI | ||
| ```bash | ||
| gh run list --branch {branch} --limit 3 | ||
| gh run view {run-id} --log-failed 2>/dev/null | head -300 | ||
| ``` | ||
| CI fails → report which jobs failed and why. Ask: "Fix CI failures automatically?" | ||
| ### Code Review | ||
| **Under 300 lines diff:** Review inline — no subagent needed. | ||
| **Over 300 lines diff:** Spawn `[model: sonnet]` subagent with the diff. Returns JSON only: | ||
| ```json | ||
| [{ "file": "", "line": 0, "category": "critical|warning|suggestion", "msg": "" }] | ||
| ``` | ||
| Review checklist (inline or subagent): | ||
| - **Coherence**: all related files present, no unresolved TODO/FIXME, end-to-end flow works | ||
| - **Quality**: single responsibility, no duplication, consistent naming, error handling | ||
| - **Cross-file**: API contracts match, schema changes have migrations, test coverage matches | ||
| - **Security**: no secrets, input validation on boundaries, no injection vectors | ||
| - **Performance**: no N+1, no unbounded loops, indexes for new queries | ||
| ### Report | ||
| ```markdown | ||
| ## PR Review: #{number} — {title} | ||
| ### CI Status | ||
| - ✓/✗ {check}: {status} | ||
| ### Critical (must fix) | ||
| - [ ] {finding} — `{file}:{line}` | ||
| ### Warnings (should fix) | ||
| - [ ] {finding} — `{file}:{line}` | ||
| ### Suggestions (nice to have) | ||
| - [ ] {finding} — `{file}:{line}` | ||
| ### What looks good | ||
| - {positive feedback} | ||
| ``` | ||
| ### Post-Review | ||
| Ask: "Found {N} issues ({critical} critical). Action? | ||
| (a) Fix critical automatically (b) Fix all (c) Report only (d) Post as PR comment" | ||
| --- | ||
| ## GitHub Issue Review | ||
| ### Gather Context | ||
| ```bash | ||
| gh issue view {number} --json title,body,labels,comments,assignees,state,milestone | ||
| ``` | ||
| ### Check Issue Template Compliance | ||
| Follow @skills/shared/issue-template-guide.md — verify the issue follows the repo's template (if one exists). | ||
| ### Review Checklist | ||
| - **Clarity**: problem is clearly described, expected vs actual behavior stated | ||
| - **Reproducibility**: steps to reproduce are present and specific | ||
| - **Scope**: issue is focused on a single problem, not a bundle of unrelated items | ||
| - **Context**: relevant code references, logs, screenshots, or error messages included | ||
| - **Labels & severity**: appropriate labels assigned, severity matches the description | ||
| - **Duplicates**: check for similar existing issues (`gh issue list -S "{keywords}"`) | ||
| - **Actionability**: enough information for someone to start working on a fix | ||
| ### Report | ||
| ```markdown | ||
| ## Issue Review: #{number} — {title} | ||
| ### Completeness | ||
| - ✓/✗ Clear description | ||
| - ✓/✗ Reproduction steps | ||
| - ✓/✗ Expected vs actual behavior | ||
| - ✓/✗ Relevant context (logs, code refs) | ||
| ### Issues Found | ||
| - [ ] {finding} | ||
| ### Suggestions | ||
| - [ ] {suggestion to improve the issue} | ||
| ### Duplicate Check | ||
| - {similar issues found, if any} | ||
| ``` | ||
| ### Post-Review | ||
| Ask: "Found {N} issues. Action? | ||
| (a) Fix the issue descriptions (b) Add missing info from codebase (c) Report only (d) Post as issue comment" | ||
| --- | ||
| ## Jira Ticket Review | ||
| ### Gather Context | ||
| ```bash | ||
| curl -s "https://{domain}.atlassian.net/rest/api/3/issue/{key}" \ | ||
| -H "Authorization: Basic {credentials}" | head -500 | ||
| # Also fetch comments | ||
| curl -s "https://{domain}.atlassian.net/rest/api/3/issue/{key}/comment" \ | ||
| -H "Authorization: Basic {credentials}" | head -300 | ||
| ``` | ||
| ### Check Ticket Compliance | ||
| Query the project's issue type schema to verify required fields are filled: | ||
| ```bash | ||
| curl -s "https://{domain}.atlassian.net/rest/api/3/issue/createmeta/{projectKey}/issuetypes" \ | ||
| -H "Authorization: Basic {credentials}" | head -100 | ||
| ``` | ||
| ### Review Checklist | ||
| - **Required fields**: all mandatory fields for the issue type are filled | ||
| - **Acceptance criteria**: clearly defined and testable | ||
| - **Story points / estimate**: present if the project uses estimation | ||
| - **Priority**: set and consistent with description | ||
| - **Links**: related tickets linked (blocks, is blocked by, relates to) | ||
| - **Components**: assigned to the correct component(s) | ||
| - **Sprint/epic**: properly placed in the backlog hierarchy | ||
| - **Clarity**: description is clear enough for any team member to pick up | ||
| ### Report | ||
| ```markdown | ||
| ## Ticket Review: {key} — {summary} | ||
| ### Field Completeness | ||
| - ✓/✗ {field}: {status} | ||
| ### Issues Found | ||
| - [ ] {finding} | ||
| ### Suggestions | ||
| - [ ] {suggestion to improve the ticket} | ||
| ### Related Tickets | ||
| - {linked or potentially related tickets} | ||
| ``` | ||
| ### Post-Review | ||
| Ask: "Found {N} issues. Action? | ||
| (a) Fix ticket fields via API (b) Add missing context (c) Report only" | ||
| --- | ||
| Compact after report — follow @skills/shared/common-patterns.md |
| # Issue/Ticket Template Usage | ||
| ## Step 1: Detect tracker type | ||
| Use pre-loaded `issueTracker.type` from `polyforge.json`. If not configured, detect: | ||
| - GitHub: `gh api repos/{owner}/{repo} --jq '.has_issues'` | ||
| - Jira: check `JIRA_BASE_URL` / `JIRA_API_TOKEN` env vars | ||
| - GitLab: check git remote for `gitlab` | ||
| ## Step 2: Check for existing templates | ||
| ### GitHub | ||
| ```bash | ||
| ls .github/ISSUE_TEMPLATE/ 2>/dev/null | ||
| cat .github/ISSUE_TEMPLATE/*.md 2>/dev/null | ||
| cat .github/ISSUE_TEMPLATE/*.yml 2>/dev/null | ||
| ``` | ||
| If multiple templates exist, pick the one matching the issue type (bug_report, feature_request, etc.). | ||
| ### Jira | ||
| ```bash | ||
| # Jira projects define issue types with required fields — query them | ||
| curl -s "https://{domain}.atlassian.net/rest/api/3/issue/createmeta/{projectKey}/issuetypes" \ | ||
| -H "Authorization: Basic {credentials}" | head -100 | ||
| ``` | ||
| Use the project's configured issue types and required fields. Fill all required fields. | ||
| ### GitLab | ||
| ```bash | ||
| ls .gitlab/issue_templates/ 2>/dev/null | ||
| cat .gitlab/issue_templates/*.md 2>/dev/null | ||
| ``` | ||
| ## Step 3a: If a template exists — RESPECT IT COMPLETELY | ||
| 1. Use the template VERBATIM — keep every section, checkbox, and HTML comment | ||
| 2. Fill in applicable fields (`[x]` for checked boxes, real text for sections) | ||
| 3. Leave sections empty or unchecked if not applicable — NEVER delete them | ||
| 4. NEVER append branding, signatures, or footers — the repo's template is the final format | ||
| 5. For Jira: respect all required fields and field types from the issue type schema | ||
| 6. The issue must look like a human filled it in, not a bot replacement | ||
| ## Step 3b: If no template exists | ||
| Use the default template at @skills/shared/issue-default.md |
+1
-1
@@ -218,3 +218,3 @@ #!/usr/bin/env node | ||
| /forge Scan & configure current project | ||
| /pr-review Review a PR (fresh context + CI check) | ||
| /review Review a PR, issue, or Jira ticket | ||
| /analyse-db Analyze database schema | ||
@@ -221,0 +221,0 @@ /analyse-code Full codebase analysis |
+1
-1
| { | ||
| "name": "polyforgeai", | ||
| "version": "0.5.0", | ||
| "version": "0.5.1", | ||
| "description": "Self-adaptive Claude Code plugin for automated software development workflows", | ||
@@ -5,0 +5,0 @@ "bin": { |
+3
-3
@@ -29,3 +29,3 @@ [](https://www.npmjs.com/package/polyforgeai) | ||
| 4. Run `/forge` — PolyForge scans your project and generates an optimized configuration | ||
| 5. Use any command: `/pr-review`, `/fix #123`, `/brainstorm`, etc. | ||
| 5. Use any command: `/review`, `/fix #123`, `/brainstorm`, etc. | ||
@@ -37,3 +37,3 @@ ## Commands | ||
| | `/forge` | Scan project, detect stack/architecture, generate config interactively | | ||
| | `/pr-review` | Review a PR with fresh context — checks CI, code quality, security | | ||
| | `/review` | Review a PR, GitHub issue, or Jira ticket — checks CI, quality, security | | ||
| | `/analyse-db` | Connect to DB (Docker or direct), generate `docs/DB.md` schema documentation | | ||
@@ -102,3 +102,3 @@ | `/analyse-code` | Full codebase analysis — patterns, security, performance, config issues | | ||
| npx polyforgeai install --force # Reinstall, overwriting existing | ||
| npx polyforgeai add-skill pr-review fix # Install specific skills only | ||
| npx polyforgeai add-skill review fix # Install specific skills only | ||
| npx polyforgeai remove-skill analyse-db # Remove a skill | ||
@@ -105,0 +105,0 @@ npx polyforgeai list # See available skills & install status |
@@ -40,9 +40,4 @@ --- | ||
| ```bash | ||
| ls .github/ISSUE_TEMPLATE/ 2>/dev/null | ||
| ``` | ||
| Follow @skills/shared/issue-template-guide.md | ||
| **Template exists:** Use VERBATIM — fill all fields, never delete sections. NEVER append branding or footers. | ||
| **No template:** Use @skills/shared/issue-default.md | ||
| ### Step 5: Create | ||
@@ -49,0 +44,0 @@ |
@@ -5,10 +5,51 @@ # Shared Patterns | ||
| ```bash | ||
| {test command} 2>&1 | bash hooks/filter-test-output.sh | ||
| {lint command} | ||
| {typecheck command} | ||
| {vulncheck command} | ||
| ``` | ||
| Read `project.stack`, `project.testFrameworks`, and `project.linters` from pre-loaded `polyforge.json`. If not configured, auto-detect from project files and run ALL applicable tools: | ||
| Fix failures automatically (max 2 retries). Same error + same approach twice → switch strategy. After 3 total attempts, categorize: | ||
| ### Tests | ||
| | Detected by | Command | | ||
| |---|---| | ||
| | `package.json` | `npm test 2>&1 \| bash hooks/filter-test-output.sh` | | ||
| | `composer.json` | `composer test 2>&1 \| bash hooks/filter-test-output.sh` or `php vendor/bin/phpunit 2>&1 \| bash hooks/filter-test-output.sh` | | ||
| | `go.mod` | `go test ./... 2>&1 \| bash hooks/filter-test-output.sh` | | ||
| | `requirements.txt` / `pyproject.toml` | `python -m pytest 2>&1 \| bash hooks/filter-test-output.sh` | | ||
| | `Gemfile` | `bundle exec rspec 2>&1 \| bash hooks/filter-test-output.sh` | | ||
| | `build.gradle` / `pom.xml` | `./gradlew test 2>&1 \| bash hooks/filter-test-output.sh` or `mvn test 2>&1 \| bash hooks/filter-test-output.sh` | | ||
| ### Linting | ||
| | Detected by | Command | | ||
| |---|---| | ||
| | `.eslintrc.*` / `eslint.config.*` | `npx eslint .` | | ||
| | `biome.json` / `biome.jsonc` | `npx biome check .` | | ||
| | `.prettierrc*` | `npx prettier --check .` | | ||
| | `phpstan.neon*` | `php vendor/bin/phpstan analyse` | | ||
| | `phpcs.xml*` / `.phpcs.xml*` | `php vendor/bin/phpcs` | | ||
| | `.golangci.yml` / `.golangci.yaml` | `golangci-lint run` | | ||
| | `.flake8` / `setup.cfg` (flake8) | `flake8 .` | | ||
| | `pyproject.toml` (ruff) | `ruff check .` | | ||
| | `.rubocop.yml` | `bundle exec rubocop` | | ||
| ### Type Checking | ||
| | Detected by | Command | | ||
| |---|---| | ||
| | `tsconfig.json` | `npx tsc --noEmit` | | ||
| | `pyproject.toml` (mypy) / `mypy.ini` | `mypy .` | | ||
| | `pyproject.toml` (pyright) | `pyright` | | ||
| | `phpstan.neon*` | _(covered by linting above)_ | | ||
| ### Security / Vulnerability Check | ||
| | Detected by | Command | | ||
| |---|---| | ||
| | `package.json` | `npm audit --audit-level=high` | | ||
| | `composer.json` | `composer audit` | | ||
| | `go.mod` | `govulncheck ./...` | | ||
| | `requirements.txt` / `pyproject.toml` | `pip-audit` or `safety check` | | ||
| | `Gemfile.lock` | `bundle audit check` | | ||
| ### Execution rules | ||
| Run **all** matching tools — a project can have both ESLint and TypeScript, or PHPStan and PHPCS. Fix failures automatically (max 2 retries). Same error + same approach twice → switch strategy. After 3 total attempts, categorize: | ||
| - 🟢 Quick fix → fix now | ||
@@ -15,0 +56,0 @@ - 🟡 Needs investigation → `/report-issue` |
| --- | ||
| name: pr-review | ||
| description: Use when the user asks to review a PR, check a pull request, look at changes before merge, or audit code quality in a PR. Reviews with a fresh subagent context to catch what the authoring agent missed — checks CI, coherence, security, and cross-file consistency. | ||
| --- | ||
| # /pr-review — Pull Request Review | ||
| You are PolyForge's PR reviewer. Review with a FRESH perspective — you are NOT the agent that wrote the code. | ||
| ## Usage | ||
| ``` | ||
| /pr-review Review the current branch's PR | ||
| /pr-review #123 Review PR #123 | ||
| /pr-review --focus security Focus on security aspects | ||
| ``` | ||
| ## Process | ||
| ### Step 1: Gather PR Context (parallel) | ||
| ```bash | ||
| gh pr view {number} --json title,body,additions,deletions,files,commits,reviews,labels | ||
| gh pr diff {number} -- ':!*.lock' ':!vendor/' ':!*.generated.*' | ||
| gh pr checks {number} | ||
| gh api repos/{owner}/{repo}/pulls/{number}/comments | ||
| ``` | ||
| ### Step 2: Check CI | ||
| ```bash | ||
| gh run list --branch {branch} --limit 3 | ||
| gh run view {run-id} --log-failed 2>/dev/null | head -300 | ||
| ``` | ||
| CI fails → report which jobs failed and why. Ask: "Fix CI failures automatically?" | ||
| ### Step 3: Code Review | ||
| **Under 300 lines diff:** Review inline — no subagent needed. | ||
| **Over 300 lines diff:** Spawn `[model: sonnet]` subagent with the diff. Returns JSON only: | ||
| ```json | ||
| [{ "file": "", "line": 0, "category": "critical|warning|suggestion", "msg": "" }] | ||
| ``` | ||
| Review checklist (inline or subagent): | ||
| - **Coherence**: all related files present, no unresolved TODO/FIXME, end-to-end flow works | ||
| - **Quality**: single responsibility, no duplication, consistent naming, error handling | ||
| - **Cross-file**: API contracts match, schema changes have migrations, test coverage matches | ||
| - **Security**: no secrets, input validation on boundaries, no injection vectors | ||
| - **Performance**: no N+1, no unbounded loops, indexes for new queries | ||
| ### Step 4: Report | ||
| ```markdown | ||
| ## PR Review: #{number} — {title} | ||
| ### CI Status | ||
| - ✓/✗ {check}: {status} | ||
| ### Critical (must fix) | ||
| - [ ] {finding} — `{file}:{line}` | ||
| ### Warnings (should fix) | ||
| - [ ] {finding} — `{file}:{line}` | ||
| ### Suggestions (nice to have) | ||
| - [ ] {finding} — `{file}:{line}` | ||
| ### What looks good | ||
| - {positive feedback} | ||
| ``` | ||
| ### Step 5: Post-Review | ||
| Ask: "Found {N} issues ({critical} critical). Action? | ||
| (a) Fix critical automatically (b) Fix all (c) Report only (d) Post as PR comment" | ||
| Compact after report — follow @skills/shared/common-patterns.md |
Sorry, the diff of this file is not supported yet
New alerts
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Fixed alerts
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Improved metrics
- Total package byte prevSize
66109
12%- Number of package files
34
3.03%No dependency changes