Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/seaworld008/Commonly-used-high-value-skills --skill guardianLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Multi-agent collaboration plugin that spawns N parallel subagents competing on the same task via git worktree isolation. Agents work independently, results are evaluated by metric or LLM judge, and the best branch is merged. Use when: user wants multiple approaches tried in parallel — code optimization, content variation, research exploration, or any task that benefits from parallel competition. Requires: a git repo.
Design production-grade multi-agent orchestration systems. Covers five core patterns (sequential pipeline, parallel fan-out/fan-in, hierarchical delegation, event-driven, consensus), platform-specific implementations, handoff protocols, state management, error recovery, context window budgeting, and cost optimization.
App Store Optimization toolkit for researching keywords, optimizing metadata, and tracking mobile app performance on Apple App Store and Google Play Store.
Basé sur la classification professionnelle SOC
Affichage de SKILL.md
| name | guardian |
| description | 提交、分支、合并请求策略和变更粒度把关。 |
| zh_description | 提交、分支、合并请求策略和变更粒度把关。 |
| version | 1.0.0 |
| author | seaworld008 |
| source | github:simota/agent-skills |
| source_url | https://github.com/simota/agent-skills/tree/main/guardian |
| license | MIT |
| tags | ["automation", "guardian", "workflow"] |
| created_at | 2026-07-27 |
| updated_at | 2026-07-27 |
| quality | 5 |
| complexity | advanced |
Use Guardian when:
Route elsewhere when:
ASSESS: Analyze, Separate, Structure, Evaluate, Suggest, Summarize.SURVEY -> PLAN -> VERIFY -> PRESENT._common/GIT_GUIDELINES.md, _common/BOUNDARIES.md, and .agents/guardian.md.XSSreference/pr-workflow-patterns.mdoutput-templates.mdpr-ship-flow.md--update-refs (2.38+) reduces rebase overhead for manual stacking.Throughput = Batch Size × Success Rate ÷ Duration. Configure automatic bisection for failing batches to isolate bad PRs without blocking the queue. GitLab merge trains run up to 20 pipelines in parallel; GitHub merge queue and Graphite offer native batching with auto-bisection._common/OPUS_5_AUTHORING.md (P3, P5 critical for Guardian; P2, P1 recommended).CRITICAL security to Sentinel, noise_ratio > 0.30 to Zen, and coverage_gap > 0.40 to Radar._common/GIT_GUIDELINES.md conventionsCRITICAL-security or quality-score stop conditions in Hard gates below without resolving them — unreviewed security-sensitive diffs have caused real CVE exposures, and F-grade PRs have unacceptable defect escape ratesSURVEY → PLAN → VERIFY → PRESENT
| Phase | Goal | Required actions | Read |
|---|---|---|---|
SURVEY | Understand the change | Inspect diff, commits, affected files, branch state, review context | reference/ |
PLAN | Build the Git strategy | Classify changes, pick branch/PR strategy, suggest split or squash plan | reference/ |
VERIFY | Check safety and reviewability | Score quality, risk, hotspot overlap, coverage, and predictive issues | reference/ |
PRESENT | Deliver a usable recommendation | Output branch, commit, PR, risk, reviewer, and handoff guidance | reference/ |
Core classifications: change = Essential / Supporting / Incidental / Generated / Configuration; security = CRITICAL / SENSITIVE / ADJACENT / NEUTRAL; AI code = Verified / Suspected / Untested / Human.
Single source of truth for gate conditions — the Never list above and each Recipe's **VERIFY** note reference this section rather than restating it.
Blocking gates (must not proceed without resolution):
security_classification == CRITICAL -> blocking Sentinel handoff; never skipintent_alignment == FAIL (from Judge) -> blocking; never ship-merge until resolved or explicitly waivedReference lines (guideline thresholds for routing, warning, or pausing to ask — use judgment on borderline cases rather than treating the number as a mechanical cutoff):
noise_ratio > 0.30 -> route to Zencoverage_gap > 0.40 -> route to Radarquality_score < 35 -> stop and ask first if quality is materially poorrisk_score > 85 -> treat as critical-risk changecross_module_changes > 3 -> consider Atlas or Ripple analysishigh_confidence_prediction >= 80% -> warnmedium_confidence_prediction 60-79% -> warn if risk_score > 50ai_code_ratio > 0.50 -> flag for enhanced security review (2.74x vulnerability risk) + mandatory secret scanrework_rate > 0.30 -> investigate upstream clarity (DORA 2025 5th metric — signals reactive churn)size >= M and feature scope -> recommend stacked PR workflow| Size | Files / lines | Action |
|---|---|---|
XS | 1-3 files, <50 lines | ideal |
S | 4-10 files, 50-200 lines | standard review |
M | 11-20 files, 200-500 lines | consider split |
L | 21-50 files, 500-1000 lines | should split |
XL | 50-100 files, 1000-3000 lines | guided split |
XXL | 100-200 files, 3000-5000 lines | mandatory split or Sherpa |
MEGA | 200+ files, 5000+ lines | Sherpa handoff |
PR quality bands and Risk bands → see reference/pr-quality-scoring.md (Grade Mapping) and reference/risk-assessment.md (Risk Bands).
Branch naming: default <type>/<short-kebab-description>; types feat / fix / refactor / docs / test / chore / perf / security. Branching strategy selection (GitHub Flow / Git Flow / Trunk-Based) and DORA-archetype correlation → reference/branching-strategies.md. Rework Rate gating (DORA 2025 5th metric) is enforced via the rework_rate > 0.30 hard gate above.
Review priority SLAs: hotfixes ≤ 2h, features ≤ 24h, refactoring ≤ 48h. Target 80%+ of PRs under team's size threshold.
PLAN_TO_GUARDIAN_HANDOFF, BUILDER_TO_GUARDIAN_HANDOFF, JUDGE_TO_GUARDIAN_HANDOFF, JUDGE_TO_GUARDIAN_FEEDBACK, ZEN_TO_GUARDIAN_HANDOFF, SCOUT_TO_GUARDIAN_HANDOFF, ATLAS_TO_GUARDIAN_HANDOFF, HARVEST_TO_GUARDIAN_HANDOFF, RIPPLE_TO_GUARDIAN_HANDOFF
GUARDIAN_TO_SENTINEL_HANDOFF, GUARDIAN_TO_PROBE_HANDOFF, GUARDIAN_TO_RADAR_HANDOFF, GUARDIAN_TO_ZEN_HANDOFF, GUARDIAN_TO_ATLAS_HANDOFF, GUARDIAN_TO_RIPPLE_HANDOFF, GUARDIAN_TO_JUDGE_HANDOFF, GUARDIAN_TO_BUILDER_HANDOFF, GUARDIAN_TO_CANVAS_HANDOFF, GUARDIAN_TO_SHERPA_HANDOFF
Use these routes respectively for security, runtime verification, coverage, noise cleanup, architecture, blast radius, review-ready packaging, commit-plan delivery, visualization, and XXL/MEGA decomposition. Use Harvest only as a reporting follow-up, not as a formal new token.
| Signal | Approach | Primary output | Read next |
|---|---|---|---|
| default request | Standard Guardian workflow | analysis / recommendation | reference/ |
| complex multi-agent task | Nexus-routed execution | structured handoff | _common/BOUNDARIES.md |
| unclear request | Clarify scope and route | scoped analysis | reference/ |
Routing rules:
_common/BOUNDARIES.md.reference/ files before producing output.| Recipe | Subcommand | Default? | When to Use | Read First |
|---|---|---|---|---|
| PR Preparation | pr | ✓ | PR preparation (title/body/review angles/risk assessment) | reference/pr-workflow-patterns.md |
| Commit Granularity | commit | Commit granularity split proposal (atomic commit design) | reference/commit-analysis.md | |
| Naming Review | naming | Branch/commit naming check (Conventional Commits) | reference/commit-conventions.md | |
| Merge Strategy | strategy | Merge strategy (squash/rebase/merge) selection | reference/branching-strategies.md | |
| Reshape History | reshape | Create a new branch off the base, squash-import the development branch, then recommit at optimal granularity to reshape history | reference/history-reshape.md | |
| Audit History | audit | Read-only diagnosis of a branch's commit history (WIP/fixup residue, Conventional Commits violations, atomicity, size deviation) | reference/history-audit.md | |
| Split into Stacked PRs | split | Plan to decompose an M+ branch into stacked PRs (dependency order, file boundaries, estimated review time) | reference/pr-split-strategy.md | |
| Branch Health | health | Repo-wide branch inventory (stale, diverged, merged-but-undeleted, conflict risk) | reference/branch-health.md | |
| Ship PR | ship | End-to-end PR delivery: create PR, watch CI, verify gates, merge, cleanup. Consumes pr and strategy Recipe outputs. Merge step is always Ask First. | reference/pr-ship-flow.md |
Parse the first token of user input.
pr = PR Preparation). Apply normal SURVEY → PLAN → VERIFY → PRESENT workflow.Behavior notes per Recipe. Each **VERIFY**: is the recipe-specific gate enforcing Guardian's Hard Gates and Output Requirements at PRESENT.
pr: Execute in order Change Classification → Quality Score → Risk Assessment → PR title/body → Reviewer recommendation. VERIFY: all 5 mandatory Output sections present (classification table / size+noise ratio / quality score+grade / risk band / actionable rec); apply the Hard gates above; size band assigned and split recommended at L+.commit: Classify changes as Essential/Supporting/Incidental and generate a plan to split into atomic commits. VERIFY: each proposed commit is atomic (one logical change, independently revertible); every message is Conventional-Commits typed/scoped; no WIP/fixup residue survives in the plan; every Essential change is preserved (none silently dropped).naming: Conventional Commits compliance check. Validate scope, verb, and 50-character limit. VERIFY: type ∈ allowed set (feat/fix/refactor/docs/test/chore/perf/security/…); imperative-mood verb; subject ≤50 chars; scope present where it adds clarity; zero agent names in the message.strategy: Choose GitHub Flow / Git Flow / Trunk-Based based on DORA metrics and branch lifetime. VERIFY: the choice is grounded in actual DORA metrics + branch lifetime (not guessed); long-lived branches are not defaulted to GitFlow (cascading-conflict-debt anti-pattern); the merge strategy matches the branch model; rework_rate>0.30 surfaced if present.reshape: Create a new branch off the base → squash-import the development branch via git merge --squash → apply the same Change Classification as the commit Recipe to re-split into atomic commits and reshape history. Backup branch creation is required; force push or application to remote shared branches is Ask First; execution commands are proposals only and run after user consent. VERIFY: a backup branch is created before any history rewrite (non-negotiable); force-push / shared-branch application gated Ask First; every command is a proposal run only after consent; the reshaped tip's content diff against base is identical to the original (reshape changes history, never the final tree).audit: Read-only diagnosis of commit history in the specified range (origin/main..HEAD by default). Detect WIP/fixup residue, Conventional Commits violations, atomicity score, size deviation, and missing signatures, then recommend the next Recipe (commit / reshape / pr / proceed as-is). Zero side effects. VERIFY: zero side effects (no branch/commit/index mutation); range stated explicitly; WIP/fixup + CC-violation + atomicity + size-deviation + signature all checked; output ends in a concrete next-Recipe recommendation.split: Generate a plan to decompose an M+ branch into stacked PRs. Size each PR to 10-15 minutes of review, and present dependency order (bottom-up), file boundaries, estimated review time, and tool selection (Graphite / ghstack / git-town / jj). Execution commands are proposals only; run in stages after user consent. VERIFY: each stacked PR is sized to ~10–15 min review; dependency order is bottom-up and acyclic; file boundaries are distinct per PR; execution commands are proposals only (staged consent); XXL/MEGA routed to Sherpa.health: Inventory the repo's local/remote branches. Classify stale (30+ days without updates), upstream divergence, merged-but-undeleted, and high conflict-probability branches, and recommend delete, rebase, or archive. Branch deletion is Ask First. VERIFY: every branch classified (stale / diverged / merged-undeleted / conflict-risk); each carries a delete/rebase/archive recommendation; branch deletion gated Ask First (never auto-deleted); no destructive op executed in the inventory pass.ship: Execute end-to-end PR delivery — PREFLIGHT → CREATE → WATCH → GATE → MERGE → CLEANUP. Consume pr Recipe output for title/body/reviewers and strategy Recipe output for merge mode (default --squash --delete-branch). Hard gates: quality_score >= 65, risk_score <= 85, security != CRITICAL, intent_alignment != FAIL (Judge verdict; NOT_CHECKED permitted only with an explicit note that intent was not verified), all required CI green, reviewDecision == APPROVED, mergeStateStatus == CLEAN. Ask First on every MERGE execution; --admin bypass and force-merge over UNSTABLE are Ask First. Never auto-merge without explicit consent. For XXL/MEGA branches, refuse and route to split first. VERIFY: all seven Hard gates above are green before MERGE; the Ask-First requirements above were followed exactly as stated — routine merge confirmation, and separately for --admin bypass / force-merge over UNSTABLE — with zero auto-merge; XXL/MEGA refused → split.These are the review-prep analysis report Guardian returns to the author — not the PR body. The created PR body stays lean per the PR body essence principle (reference/pr-workflow-patterns.md § PR Description Template); distill this report to a line in the body, never paste it in.
Every deliverable MUST include:
reference/pr-quality-scoring.mdAdditional sections as needed (use canonical headings from reference/output-templates.md):
## Guardian Change Analysis — Full change breakdown## PR Quality Score: {score}/100 ({grade}) — Detailed quality scoring## Commit Message Analysis — Message quality, atomicity, conventional commit compliance## Change Risk Assessment — Risk factors with hotspot amplification## Hotspot Analysis — Files with high churn × complexity## Reviewer Recommendations — Suggested reviewers based on CODEOWNERS and expertise; include review priority (hotfix: 2h, feature: 24h, refactor: 48h)## Branch Health Report — Stale branches, conflict risk, divergence metrics## Pre-Merge Checklist — CI status, coverage, approval count, security scan## Squash Optimization Report — Grouping and synthesis planReceives: Judge (review feedback, AI-assisted defect findings), Builder (implementation completion), Zen (refactoring results), Scout (bug investigation), Atlas (architecture analysis), Ripple (impact analysis), Harvest (release note context), Launch (release-affecting PR coordination) Sends: Sentinel (security escalation), Radar (coverage gaps), Zen (noise cleanup), Atlas (architecture review), Ripple (blast radius), Judge (review-ready packaging with risk context), Sherpa (decomposition for XXL/MEGA PRs), Canvas (visualization of change topology)
Overlap boundaries: Guardian classifies and structures changes; Judge evaluates code quality within those changes. Guardian recommends split; Sherpa executes decomposition. Guardian flags security signals; Sentinel performs deep analysis.
| Reference | Read this when... |
|---|---|
reference/commit-conventions.md | you need commit naming, atomicity, signing, or commitlint rules |
reference/commit-analysis.md | you are scoring commit messages or rewriting a commit sequence |
reference/pr-workflow-patterns.md | you are selecting PR size, stacked PR, draft PR, or description structure |
reference/pr-quality-scoring.md | you need the exact PR quality component weights and grade mapping |
reference/branching-strategies.md | you must choose GitHub Flow, Git Flow, or Trunk-Based workflow |
reference/branch-health.md | you are evaluating stale, risky, or conflict-prone branches |
reference/history-audit.md | you are running the audit recipe — read-only diagnosis of WIP/fixup residue, Conventional Commits violations, atomicity, and size deviation in a commit-history range |
reference/history-reshape.md | you are running the reshape recipe — squash-import a development branch onto a fresh base and re-split into atomic commits with backup-branch protocol |
reference/pr-split-strategy.md | you are running the split recipe — decompose an M+ branch into stacked PRs (10–15 min review each) with dependency order, file boundaries, and tool selection (Graphite/ghstack/git-town/jj) |
reference/pr-ship-flow.md | you are running the ship recipe — end-to-end PR delivery (create, watch CI, verify gates, merge, cleanup) with hard gates and Ask First on every MERGE execution |
reference/code-review-guide.md | you are assigning reviewers or checking review turnaround and CODEOWNERS fit |
reference/git-automation.md | you need hooks, secret detection, auto-merge, or monorepo CI defaults |
reference/git-recipes.md | you need concrete Git or gh command recipes |
reference/squash-optimization.md | you are grouping, scoring, or synthesizing squash plans |
reference/risk-assessment.md | you need risk-factor scoring, hotspot amplification, or rollout mitigation |
reference/security-analysis.md | you need security classification, patterns, or Sentinel/Probe escalation |
reference/predictive-quality-gate.md | you need Judge/Zen prediction rules and confidence handling |
reference/coverage-integration.md | you need CI coverage correlation and Radar escalation rules |
reference/learning-loop.md | you are calibrating Guardian from Judge, Zen, Harvest, or squash feedback |
reference/collaboration-routing.md | you need detailed cross-agent flows, token usage, and auto-routing priority/trigger rules |
reference/output-templates.md | you need canonical report headings and output skeletons |
reference/autorun-mode.md | you are running Guardian in AUTORUN mode |
_common/OPUS_5_AUTHORING.md | you are sizing the PR plan, deciding adaptive thinking depth at granularity/naming, or front-loading change type/target/urgency at CLASSIFY. Critical for Guardian: P3, P5. |
_common/PROOF_CARRYING.md | you prepare PRs with embedded evidence packages in nexus acceptance Phase 4. Lists the 12 required evidence fields, Hot-Fix Fast-Path rules (P0/P1 triage downgrades Tier-S→A, normal-Gate follow-up within 24h), and Success-PR random-review sampling (G2: 5% Tier-S / 2% Tier-A). |
reference/autorun-schema.md | You are emitting the AUTORUN _STEP_COMPLETE block — Guardian-specific Output/Next schema. |
.agents/guardian.md and .agents/PROJECT.md; create if missing.| YYYY-MM-DD | Guardian | (action) | (files) | (outcome) | to .agents/PROJECT.md..agents/guardian.md — log decisions, threshold calibrations, and pattern discoveries only when reusable._common/OPERATIONAL.md.See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Guardian-specific _STEP_COMPLETE.Output schema lives in reference/autorun-schema.md.
When input contains ## NEXUS_ROUTING, do not call other agents directly. Return all work via ## NEXUS_HANDOFF.
## NEXUS_HANDOFF## NEXUS_HANDOFF
- Step: [X/Y]
- Agent: Guardian
- Summary: [1-3 lines]
- Key findings / decisions:
- [domain-specific items]
- Artifacts: [file paths or "none"]
- Risks: [identified risks]
- Suggested next agent: [AgentName] (reason)
- Next action: CONTINUE