メニュー
Create an isolated git branch/worktree before coding begins. Verifies baseline tests pass. Use when: starting implementation work that should be isolated from the current branch or workspace.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Read-only cross-artifact consistency analysis after planning and before approval. Verifies that spec.md, requirements.json, plan.md, tasks/Tn.md, traceability.json are mutually consistent: no duplicate/ambiguous requirements, every behavior mapped to a task, no orphan tasks, no coverage gaps, no contradictions. Outputs artifact-analysis.json with coverage% and severity. CRITICAL/HIGH findings block the approval gate. Use when: planning produced plan.md + tasks + traceability.json, before the user approves the plan.
Explore 2-3 implementation options with trade-offs when the user describes a new feature or requirement. Use when: the user asks for a new feature design, implementation options, or technical trade-off analysis.
After implementation and before final verification, compare current code/tests against the intent inventory (requirements.json + traceability.json). Classify each requirement/behavior as covered, missing, partial, contradicts, or unrequested. Append missing/partial/contradicts as new tasks back to executing. Repeat until converged: zero blocker findings. Outputs convergence-report.json. Use when: executing produced test-report.md but before loom-verification-before-completion.
Expand each requirement into verifiable Behavior Obligations across 15 fixed dimensions (happy-path, boundary, invalid-input, authorization, state-transition, idempotency, concurrency, atomicity, external-failure, compatibility, security, performance, observability, recovery, forbidden-behavior) before planning. Use when: brainstorming produced requirements.json and spec is approved, but behaviors are still placeholders or only happy-path; before loom-writing-plans.
Read-only adversarial reviewer that looks for what SHOULD exist but doesn't, by cross-checking Behavior Obligations against code, tests, expected side effects, forbidden side effects, failure scenarios, and public API changes. Focuses on negative space: events that should not repeat, permissions that should not be bypassed, partial writes that should not happen, old APIs that should not change, swallowed exceptions, leaked secrets. Outputs findings.json. Use when: executing or converge needs an independent omission sweep.
Analyze user request + collect signals (file scope, keywords, worktree state, spec existence), then select pipeline steps via rule short-circuit / AI fallback / rule-based fallback. Select steps first, expose the choice to the user, and persist selected dynamic_steps only after explicit user confirmation; pipeline-plan.md is optional for manual review. Use when: user is unsure which pipeline type to pick, or wants AI to choose steps automatically.
| name | loom-using-git-worktrees |
| description | Create an isolated git branch/worktree before coding begins. Verifies baseline tests pass. Use when: starting implementation work that should be isolated from the current branch or workspace. |
| when_to_use | Create or verify an isolated branch/worktree before implementation begins. |
| argument-hint | <spec_dir or branch name> |
| user-invocable | true |
检测现有隔离 → 原生工具优先 → git worktree 作为兜底。
在创建任何东西之前，先检查当前是否已在 worktree 中：
# 检测 worktree
git rev-parse --git-dir
git rev-parse --git-common-dir
# 如果 GIT_DIR != GIT_COMMON，已在 worktree 中
# 检测 submodule
git rev-parse --show-superproject-working-tree
如果已在隔离环境中： 跳过创建，直接使用当前环境。
git status
specs/<date+feature>/plan.md 和 specs/<date+feature>/tasks/ 目录）优先使用平台原生工具：
WorktreeCreate 类工具git worktree add目录安全： 创建前确认 worktree 目录在 .gitignore 中，防止意外提交。
分支命名规范：
feature/<date>-<feature-name>
示例：
feature/2026-04-26-passport-listfeature/2026-04-26-user-auth# 兜底方案（原生工具不可用时）
git worktree add .worktree/<date>-<feature-name> -b feature/<date>-<feature-name>
自动检测项目类型并安装依赖，然后运行测试确保干净起点。
<读取 constitution.md 中的 TEST_CMD 并执行>
如果基线测试失败： 停止，报告问题，等用户确认是否继续。
git branch --show-current
确认分支已创建并切换成功。
Git 分支命名规范
分支命名格式：feature/<date>-<feature-name>（如 feature/2025-01-15-user-auth）
其他前缀：fix/<date>-<name>、refactor/<date>-<name>、docs/<date>-<name>
禁止在主分支实现
没有明确用户同意，永远不要在 main/master 分支上开始实现。
.gitignore 规则分支创建并验证测试基线。