SHUD-NWM

Create GitHub issues from PRDs, requirements, or feature descriptions, choosing between a single issue and an epic plus sub-issues using gh CLI labels and dependencies.

对一个已有的 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）。

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

本仓库 skills 的路由器——按你当前的处境指路：该用哪个 skill、走哪条流、下一步交给谁。手动调用（/ask-danker），模型不会自动触发。

把当前会话压缩成一份交接文档（handoff.md），让新会话或另一个 agent 无缝接续工作。 适用：上下文将满要开新会话、任务干到一半换 agent/换机器、issue 工作流跨会话续跑。 手动调用（/handoff），可带参数说明下个会话的重点。模型不会自动触发。

为目标项目安装 pack 之后，扫描项目并补全/对齐它自己的 CLAUDE.md 与 AGENTS.md。 推荐用 shared 源生成模式：项目维护 instructions/agents/{shared,claude,codex}.md， 本 skill 充当生成器拼接出两文件（shared 段单一事实源、零漂移），不给项目装脚本或 hook。 内容含项目自身约定、已装 pack/skill/agent 用法、可移植编排骨架。增量、绝不覆盖、写前出 diff。 触发词："补全项目指令"、"装完 pack 初始化 CLAUDE.md/AGENTS.md"、"bootstrap project instructions"。 不用于 my-agents 仓库自身的根指令（那是 instructions/root 生成的）。

设计文档 → OpenSpec change → subagent 并行审核 → 修复 → 实现就绪 GitHub issue 全流水线， tasks 拆为模块边界清晰、适合小 PR 审核的细粒度 issue。用于把设计/阶段文档变成审核过的 OpenSpec change 加 implementation-ready issues——"开始下一个阶段"、"设计到issue"、 "run the stage pipeline"。单个 issue 的实现/修复/合并走 subagent-workflow，不需要 OpenSpec change 与并行审核的普通 issue 不用本流水线。

GitHub issue → verified PR workflow: the orchestrator delegates implementation, cross-review, and finding verification to the implementer/reviewer/verifier subagents, with mandatory OpenSpec fixtures, risk-adaptive review, CI, and human-gated merge. Use to implement a GitHub issue or process the next DAG issue ("implement #XX", "处理下一个issue"). Not for docs/spec-only work, hotfixes that skip review, or Codex-implements-under-Claude-orchestration (use cc-cx-workflow).

Turn ambiguous implementation requests into actionable scope before execution. Use when asked to clarify requirements, disambiguate a request, or spec a change before building. Auto-activate only when an implementation request contains direct contradictions, is missing acceptance criteria that would materially change the build, or asks to proceed on documented assumptions. Not for direction-finding or brainstorming, nor for already-specific actionable tasks.

Review a change set for entropy: naming drift, pattern duplication and contagion, error-model and state-model splits, doc staleness. Consistency and drift only, not correctness. Invoke explicitly or via routing from review.

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.

Deep executable planning for complex implementation work — phases, dependencies, verification, rollback — after the direction is chosen. Invoke explicitly: by the user, the planner agent, or stage-change-pipeline.

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. Also use for the write modes: "bootstrap the control plane", "set up this repo for agents", "init AGENTS.md and guardrails", or fixing gaps from a prior audit (bootstrap/repair). Do NOT use for code review (use review), full-repo code/entropy scan (use repo-entropy-audit), general documentation work (use project-documentation), or reviewing a specific PR or diff (use review or entropy-review).

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.

Full-repository entropy scan across six axes: structure (dependency graph, layering, cycles), 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).

Govern a repository's docs/: restructure, consolidate overlapping pages, refresh stale docs after code changes, audit drift and dead links. Invoke explicitly — by the user or stage-change-pipeline. Not for READMEs or PR review.

Multi-perspective, risk-adaptive review for PRs, diffs, branches, OpenSpec changes, or stage artifacts — reviewers split across correctness, integration, security/performance, test evidence, spec compliance, or invariant/state-machine compatibility. Use on explicit asks for risk-adaptive, multi-perspective, parallel, cross-review, or high-risk PR review. Not for ordinary quick review.

Project-level workflow for implementing or finishing a GitHub issue in the NHMS/NWM repo under the local-edit + remote-test (双端) model across TWO role nodes: code is edited and committed locally (macOS), then pulled and verified on one of two remotes — node-22 (compute_control, frd_muziyao@…22:/scratch/frd_muziyao/NWM) owns the real PostgreSQL/TimescaleDB, Slurm, Docker, SHUD and is the backend/real-DB pytest oracle; node-27 (display_readonly, nwm@…27:/home/nwm/NWM) owns the read-only DB replica + published artifacts and is the display API / frontend-production / read-only-boundary live-receipt oracle. Codex orchestrates; fixes and reviews are delegated to dispatched subagents (the Agent tool), not codeagent-wrapper. Use this skill whenever the user wants to implement, fix, verify, review, or merge an issue/PR in this repo, or says things like "处理 issue", "完成 #XX", "跑工作流", "双端", "本地改远端测", "继续动作流", "派发 subagent 修/审", "远端验证", "node-27 开发", "27 上线", "display 验证", "前端生产化", "live receipt", or points at a PR and sa

Execute codeagent-wrapper for multi-backend AI code tasks. Supports Codex, Claude, and Gemini backends with file references (@syntax) and structured output.

End-to-end GitHub issue implementation workflow for Codex orchestration with codeagent-wrapper using the Codex backend. 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", "run the workflow", "codex-codeagent", "处理下一个issue", "跑工作流", "开始实现", "下一个该做什么", "do it", or "开干". Do NOT use for documentation-only/spec-only work without implementation, intentional emergency hotfixes that skip review, or pure brainstorming.

Use when the user explicitly asks for comprehensive, citation-backed research such as a deep dive, due diligence, market analysis, or a multi-source comparison/report. Do not activate for quick factual lookups, ordinary coding tasks, or routine content generation unless the user first asks for research or source verification.