SHUD-OpenMP

Manual-first brainstorming workflow for turning ambiguous ideas or competing directions into an approved decision before planning or implementation. Activate when the user explicitly asks to brainstorm, explore options, compare approaches, or pressure-test a direction. Do not activate for clarification, review, detailed planning, or straightforward execution once a direction is already chosen.

Hybrid workflow for turning ambiguous implementation requests into actionable scope before execution. Use explicitly when the user asks to clarify requirements, disambiguate a request, or spec a change before building it. Activate automatically only when an implementation-oriented request contains direct contradictions, missing acceptance criteria that would materially change the build, or an explicit request to proceed with documented assumptions. Do not activate for open-ended direction-finding, brainstorming, or already-specific actionable tasks.

Audit a repository's control-plane health and produce an actionable improvement report. Use when the user asks to "audit the repo", "check repo health", "assess control plane", "entropy audit for the control system", "check what's missing for agents", or wants to know what's missing in their instruction files, rules, and verification infrastructure. Do NOT use for code review (use review), dependency audit (use dependency-audit), general documentation work (use project-documentation), or reviewing a specific PR or diff (use review or entropy-review).

Review code changes for entropy introduction: naming drift, error-model splits, dependency violations, doc staleness, and pattern duplication. Activate when the user asks for "entropy review", "consistency check", "drift check on this PR", "check if this change introduces new patterns", or wants a review focused on naming, error handling, or structural consistency rather than correctness. Do NOT activate for general code review (use review), full repo audit (use repo-entropy-audit), control-plane audit (use control-plane-auditor), brainstorming, or implementation tasks.

Manual-first architecture methodology for system design and technology selection using problem-first framing, stack-agnostic trade-offs, uncertainty handling, and future-aware decision lenses. Use when a project needs architecture direction or selection decisions; do not use for pure implementation planning, narrow stack research, or review-only tasks.

Create GitHub issues from PRD or requirements. Auto-detects complexity - simple tasks create single issue, complex tasks create epic + sub-issues structure. Uses gh cli with unified labels.

Use when the user explicitly asks about `git worktree`, wants a parallel checkout or isolated branch work without stashing or recloning, needs help resolving a branch that is already checked out elsewhere, or wants to inspect, compare, clean up, or repair worktrees safely. Do not use for ordinary single-branch Git help, repo bootstrap tasks, or broader advanced-Git sessions where worktrees are only incidental.

对一个已有的 plan 或 design 做对抗式压测：沿决策树逐个分支追问，直到与用户达成共同理解。 一次只问一个问题，每个问题都给出你的推荐答案；能从 codebase 查到的就去查，不要问用户。 触发词："grill me"、"拷问我"、"压测这个计划"、"挑战我的设计"、"stress-test the plan"， 或用户希望在动手前把计划/设计的每个决策点逼到清晰。 不用于开放式头脑风暴、方向选型，或已经明确、无歧义的任务。

grill-me 的领域增强变体：在对抗式压测计划/设计的同时，对齐项目术语、用具体场景探边界、 与代码交叉核对，并把术语 inline 沉淀到 openspec/glossary.md、把够格的长期决策落到 docs/adr/。 触发词："grill with docs"、"对着领域模型压测"、"对齐术语"、"stress-test against the domain"， 或用户希望在压测计划的同时统一项目语言、沉淀长期决策。 不用于不需要术语/决策沉淀的轻量压测（用 grill-me），也不用于纯需求澄清（用 clarify）。

Manual-first heavy planning protocol for complex technical implementation work. Use when the user or the planner agent explicitly needs a deep executable plan for a feature, refactor, migration, or architecture change after the direction is already chosen. Do not use for brainstorming, choosing between competing directions, requirements clarification, business planning, generic project management, or code execution.

基于“深模块”哲学寻找架构改进点：扫描 codebase，对照 openspec/glossary.md 的领域术语与 docs/adr/ 的决策， 找出 shallow modules 并提出 deepening 重构（把浅模块变深，提升 testability 与 AI 可导航性）， 产出可视化 HTML 评审，再进入 grill 对话逐个落地。 触发词："improve architecture"、"找重构机会"、"合并紧耦合模块"、"让代码更可测"、"架构评审"。 不用于纯需求澄清（用 clarify）或纯方向选型（用 future-aware-architecture）。

Govern a repository's `docs/` directory or docs site by reorganizing structure, consolidating overlapping pages, refreshing stale docs after code changes, and auditing documentation for drift, dead links, duplication, and missing source-of-truth boundaries. Use when the user explicitly wants to clean up, restructure, maintain, or verify a docs set rather than write a README or review a PR. Do not use it for README-only requests, one-off root-level docs outside the docs set, deep external research, or generic PR/diff review.

Full-repository entropy scan across six axes: structure (dependency graph, layering, SCC), semantics (naming diversity, state model fragmentation), behavior (error model variants, boundary handling), context (doc freshness, instruction-file coverage), protocol (instruction-file consistency), and control (rule enforcement gaps). Produces a module-level heatmap, trend comparison, and prioritized cleanup targets. Activate when the user asks for "entropy audit", "repo health scan", "heatmap", "tech debt scan", or "full entropy report". Do NOT use for PR-level review (use entropy-review) or control-plane audit (use control-plane-auditor).

Structured review skill for PRs, diffs, commits, staged changes, code, documentation, API specs, database migrations, infrastructure config, and design documents. Activate for explicit, artifact-scoped review requests such as reviewing a PR, diff, commit, branch, staged changes, or named files, or phrases like "code review", "review my changes", "find bugs in", or "security review". Produces severity-graded findings with content-aware analysis, behavioral-change checks, and actionable fix directions. Do NOT activate for brainstorming, open-ended design feedback, governance/library audits, or general conversations about whether an approach seems good.

Run multi-perspective risk-adaptive reviews for PRs, diffs, branches, OpenSpec changes, or stage-change artifacts. Use when the user asks for a risk-adaptive review, multi-review, parallel review, cross-review, high-risk PR review, or wants reviewers split across correctness, integration, security/performance, test evidence, spec compliance, or invariant/state-machine compatibility. Do not use for ordinary quick review unless the user asks for multi-perspective or risk-adaptive depth.

End-to-end GitHub issue implementation workflow orchestrated by Claude Code or Codex, delegating implementation, fix passes, cross-review, and finding verification to subagents (implementer, reviewer, verifier). Covers issue selection, mandatory OpenSpec change fixture creation/review, risk-adaptive implementation review, verification, PR evidence, Chinese work-summary comment, CI, and default human-gated merge with explicit user pre-authorization for auto-merge. Use when the user wants to implement a GitHub issue, process the next DAG issue, run the workflow, or says triggers such as "implement #XX", "do the next issue", "subagent workflow", "处理下一个issue", "开始实现", or "下一个该做什么". Do NOT use for documentation-only/spec-only work without implementation, intentional emergency hotfixes that skip review, pure brainstorming, or when the user explicitly wants the cc-cx pipeline where Claude Code orchestrates and Codex implements (use cc-cx-workflow instead).

设计文档 → openspec change → subagent 并行审核 → 修复 → GitHub issue 全流水线。 将 tasks 拆为细粒度、模块边界清晰、适合小 PR 审核的 GitHub issue。 触发词："开始下一个阶段"、"stage change pipeline"、"设计到issue"、"阶段实施"、 "openspec审核"、"创建 M* change"，或用户指定一个开发阶段要求生成审核过的 issue。