traiage-review
starsforks
How to install traiage-review?
neolabhq/context-engineering-kit/traiage-review
$npx -y skills add NeoLabHQ/context-engineering-kit --skill traiage-reviewThis skill should be used when need prioritize what changed code in repository human must review.
SKILL.md
| 1 | # Traiage Review |
| 2 | |
| 3 | ## Goal |
| 4 | |
| 5 | The goal of this skill is to help human prioritize specific files in repository that require attention over the entire list of changes. |
| 6 | |
| 7 | CRITICAL: Human attention and time is limited. Reviewer cannot check all existing changes in repository. Your job is not to find all changes that require attention, you job is to build exhaustive list of files from whole pool of changes, that probably will cause this change to fail review! |
| 8 | |
| 9 | ## Rules |
| 10 | |
| 11 | - You are orcestrator agent, you only launch agents and pass them data. You do not do any other work. |
| 12 | - You ARE allowed to run the following read-only commands yourself, and ONLY these: |
| 13 | - The random sample script (see "## Random Sample Script"). |
| 14 | - Read-only git detection commands needed for review-mode and default-branch detection: `git status`, `git diff --name-only`, `git branch`, `git symbolic-ref`, `git rev-parse`. |
| 15 | - Read-only commit commands needed for commit-mode detection and latest-commit resolution: `git rev-parse HEAD` (resolve the latest commit), `git show --name-only`, `git diff` (commit-diff inspection). |
| 16 | - You MUST NOT do any implementation work, read source files, or run any mutation git command (commit, stash, push, checkout, reset, revert, add, merge, rebase, etc.). If you try to read source files or run any command outside the allowed read-only list above, you will be killed! Your life is at stake! |
| 17 | |
| 18 | ## Process |
| 19 | |
| 20 | 1. Determine the review mode BEFORE launching agents: |
| 21 | - If a `commit` param was passed to the skill → use the **commit workflow** directly (this takes precedence over the local-changes/branch auto-detection below): |
| 22 | - If a concrete commit hash was given (`commit <commit-hash>`) → use that hash. |
| 23 | - If no hash was given (`commit` or `latest commit`) → resolve the latest commit with `git rev-parse HEAD` and use the resolved concrete hash. |
| 24 | - Record the resolved concrete commit hash for use in the commit-mode prompt and the random sample script. |
| 25 | - Else, if a `branch` param was passed to the skill → use the **branch-diff workflow** directly. |
| 26 | - Else, check for local changes with a read-only command: |
| 27 | `git status --porcelain` (non-empty output means staged, unstaged, or untracked changes exist). |
| 28 | - If local changes exist → use the **local-changes workflow** (default behavior). |
| 29 | - If there are NO local changes → detect the default branch (see below) and check whether the current branch IS the default: |
| 30 | - Current branch: `git rev-parse --abbrev-ref HEAD`. |
| 31 | - If the current branch is NOT the default → use the **branch-diff workflow** (diff current branch against the detected default branch). |
| 32 | - If the current branch IS the default → STOP and report to the user that there are no local changes and the current branch is the default branch, so there is nothing to compare against. |
| 33 | - **Default-branch detection** (read-only, robust): |
| 34 | - Primary: `git symbolic-ref --short refs/remotes/origin/HEAD` → strip the `origin/` prefix to get `main` or `master`. |
| 35 | - Fallback (if primary fails): `git rev-parse --verify origin/main` — if it succeeds, default is `main`; otherwise try `git rev-parse --verify origin/master` — if it succeeds, default is `master`. |
| 36 | - Record the detected default ref as `origin/<default-branch>` (e.g. `origin/main`) for use in the branch-mode prompt and the random sample script. |
| 37 | 2. Launch 4 parallel agents, to build his own list of files that require attention based on specific process for each agent. Pass the mode-appropriate agent prompt (see "## Agents"): the local-changes prompt for the local-changes workflow, the branch-mode prompt (with the detected `origin/<default-branch>` filled in) for the branch-diff workflow, or the commit-mode prompt (with the resolved concrete `<commit-hash>` filled in) for the commit workflow. |
| 38 | - change-story-agent |
| 39 | - change-impact-agent |
| 40 | - change-failure-agent |
| 41 | - change-expectation-agent |
| 42 | 3. Each agent will produce lists of key files by his opinition. On top of that Change Expectation Agent will produce list of declarative files. |
| 43 | 4. Parse all lists of key files, and build final list of files that require attention. |
| 44 | - Pick top 5 files from each agent. If some of them are the same, pick more from each agent that have higher scores across all criteria and high enough confidency. At this stage your job is to build list until it reach 20 files. (ignore declarative files for this stage) |
| 45 | 5. Run python script to pick 20 random files from whole batch of changed files. Pick 5 files from this list and add it to final list, if some of them are already in final list, pick more from this list. |
| 46 | 6. Report final list of files that require attention, with key fact summary from Change Story agent, list of random sample files and list of declar |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
