Menü
Analyze uncommitted changes for categorization and risk assessment
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Review an open change thoroughly and against something outside the change itself: assess what work categories the diff contains, resolve each category's review treatment from the review-knowledge memory shelf, review each through its layers (objective linters, then design-grounding from committed sources for design-bearing categories), consolidate findings that each cite their basis, and stop at one decision gate resolved per gate-config — the reviewer owns the approve/reject verdict when the gate is on; when off the computed recommendation is recorded and posted as a clearly marked harness verdict. The gate (third step) of the end sequence in the ProductOS command model. Use when a PR is ready to be reviewed and a verdict is needed.
Diff-bounded single-pass quality evaluation for PR review. Classifies every changed path by ARTIFACT TYPE first (runtime code / deployable config / tests / docs-planning / garura prose / ProductOS model / STM evidence / wireframes — pure globs, first match wins), then evaluates standard-ID checks against the diff using mechanical match rules from the PR severity taxonomy — grep-based rules fire only on runtime-code/deployable-config/tests (a keyword in prose is not a security defect,
Merge an approved change — merge the PR, switch to main and pull the latest, and delete the feature branch (local and remote). The final step of the end sequence in the ProductOS command model. Use when a reviewed, approved PR is ready to land.
Compile a deterministic "play" (a multi-step, gated workflow recipe) from an intent. Interviews for the intent triple, generates the expectation, identifies the skills, scripts, and agents the play needs, selects a workflow structure, generates evals, and emits a compiled play (a SKILL.md plus bundled scripts for its mechanical work). Use this whenever the user wants to create, build, compile, or review a play — or says "create a play", "new play", "compile this into a play", "play-creator", "turn this intent into a play", or "review my play for gaps" — even if they don't say the word "play" explicitly but are describing a repeatable, multi-step, checkpoint-gated workflow they want captured as a runnable recipe.
Commit all uncommitted work on the feature branch, grouped by concern, with conventional messages that reference the issue — leaving a clean tree ready to raise. Commits only; does not push. The first step of the end sequence in the ProductOS change pipeline. Use when work is done and needs committing before propose-change.
Raise the current change for review — run a scope-and-quality self-review from the project's standards, push the branch, and open a pull request carrying that review and the issue reference. The second step of the end sequence in the ProductOS command model. Use when a committed change is ready to raise as a PR.
| name | analyze-changes |
| description | Analyze uncommitted changes for categorization and risk assessment |
| user-invocable | false |
| model | sonnet |
| allowed-tools | Bash, Read |
Model-invocable skill for analyzing uncommitted changes.
Analyze uncommitted changes and produce structured analysis for the calling agent.
You DO the analysis work. You do NOT make decisions about what to do with it.
Receive from agent:
Read State
git status --porcelain
git diff --name-only
git diff --stat
git diff
git branch --show-current
Categorize Each File
Load categories from: ~/.garura/core/memory/standards/rules/commits.md
Detect Risks
Load patterns from: reference/risks.md
Group by Issue
The primary grouping dimension is ISSUE, not component or file location.
Grouping rules (in priority order):
feature/95-foo → #95). All changes on a single-issue branch default to ONE group for that issue.feat files with a few docs files, the type is feat. Only split by type within an issue if the types are genuinely unrelated (e.g., a fix for issue #78 and a feat for issue #95).When to split within a single issue (rare):
chore (e.g., dependency bump) alongside feature workWrite the grouped analysis to the contract's outputs.analysis path as YAML in the
executor's schema — commit-change/scripts/execute_commits.py consumes this file
mechanically, so the schema is a hard contract, not a style. The exact shape (with field
notes) is in templates/analysis-output.md:
needs_judgment: false # always false on output — the judgment is now done
change_groups:
- id: <kebab-slug> # `id`, NOT `name`
issue: <n> # bare number, no '#'
commit_type: <type> # `commit_type`, NOT `type` — feat|fix|refactor|docs|chore|test
scope: <area>
subject: "<imperative subject>" # no issue suffix — the executor appends (#issue)
files: # PLAIN repo-relative paths only.
- <path> # a rename lists BOTH sides as separate entries
- <old-path> # (never "old -> new" in one string)
- <new-path>
exclusions: # carry the scan's exclusions through unchanged
- path: "<path>"
reason: "<why>"
blocking: false
risks:
sensitive_files: [] # paths that must block the run, [] when clean
Every changed file from the scan lands in exactly one group's files or in exclusions.
Any extra keys (notes, eval evidence, confidence) are tolerated but ignored by the
executor — never rename or omit the contract keys above.
IMPORTANT: This skill produces analysis data. The calling agent receives this output and decides what to do next. Do NOT instruct the agent to return or stop — the agent continues its workflow after receiving this analysis.
| Field | Value |
|---|---|
| Version | 1.0.0 |
| Category | analysis |