メニュー
Clean up a feature branch after verification: merge, create PR, keep, or discard. Follows conventional commits. Use when: a development branch has passed verification and needs merge, PR, keep, or discard handling.
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-finishing-a-development-branch |
| description | Clean up a feature branch after verification: merge, create PR, keep, or discard. Follows conventional commits. Use when: a development branch has passed verification and needs merge, PR, keep, or discard handling. |
| when_to_use | Finish a verified development branch by choosing merge, PR, keep, or discard handling. |
| argument-hint | <branch or spec_dir> |
| user-invocable | true |
loom-verification-before-completion 验证通过loom-index-update 索引已更新开始时宣布："我正在使用 loom-finishing-a-development-branch skill 来完成这项工作。"
git status
git diff --stat
构建/检查/测试命令
读取 .loom/rules/constitution.md 中的 BUILD_CMD/VET_CMD/TEST_CMD 并执行验证。
向用户展示以下选项：
## 分支完成选项
**1. Merge（合并）** - 直接合并到主分支
**2. Pull Request** - 创建 PR 供审查
**3. Keep（保留）** - 保持分支，稍后继续
**4. Discard（丢弃）** - 丢弃所有变更
请选择？
如果分支上还有未提交的变更，先提交：
git add <specific-files>
git commit -m "$(cat <<'EOF'
feat: <功能描述>
- 变更 1
- 变更 2
Co-Authored-By: AI Assistant
EOF
)"
git checkout <branch> && git merge --no-ff feature/<date>-<name> && git push origin <branch>git push -u origin feature/<date>-<name> → gh pr create --title "feat: <描述>" --body "..."git checkout <branch> && git branch -D feature/<date>-<name>Conventional Commits 格式
提交信息必须遵循 Conventional Commits 格式：<type>(<scope>): <subject>
禁止在主分支实现
没有明确用户同意，永远不要在 main/master 分支上开始实现。