mcpField
T
the-sit-down

the-sit-down

github.com/kucherenko开发8545 次安装1 天前更新
代码仓库

关于 the-sit-down

the-sit-down 是在实施前起草并审批约束性项目规格的规划技能。它比较不同方案、审查 Contract 的完整性，并禁止在规划阶段生成代码。

主要功能

  1. 01整合项目输入材料
  2. 02提出不同的解决方案
  3. 03起草约束性 Contract
  4. 04检查歧义与完整性
  5. 05规划阶段禁止生成代码

适用场景

  1. 01在实施前选择方案
  2. 02根据项目需求起草规格
  3. 03审查并批准项目 Contract

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/kucherenko/gangsta --skill the-sit-down

安装后在 Claude Code 中输入/the-sit-down确认已加载。

详细介绍

碰头会：规划与规格草拟

概述

碰头会是 Don、Consigliere 和 Underboss 最终敲定 Contract 的环节——它是 Heist 的约束性规格。这是一个“计划优先”阶段，严格禁止生成代码。

触发条件

在 Don 批准 Grilling 共识后调用（Grilling 完成）。

绝对规则

碰头会期间不得生成代码。

不得有伪代码，不得有“示例片段”，不得有“草拟实现”。任何看起来像代码的内容都不行。如果发现自己正在写代码，立即停止。你违反了 Omerta Law 5。

Contract 描述的是内容和原因。实现细节（方式）应放在资源开发期间创建的工作包中。

流程

digraph sit_down {
    "Synthesize inputs\n(Dossier + Grilling + Constitution)" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Don approves approach?" [shape=diamond];
    "Draft the Contract" [shape=box];
    "Consigliere review\n(contradiction, ambiguity, completeness)" [shape=box];
    "Consigliere verdict?" [shape=diamond];
    "Don signs Contract?" [shape=diamond];
    "Invoke gangsta:resource-development" [shape=doublecircle];

    "Synthesize inputs\n(Dossier + Grilling + Constitution)" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Don approves approach?";
    "Don approves approach?" -> "Propose 2-3 approaches" [label="revise"];
    "Don approves approach?" -> "Draft the Contract" [label="approved"];
    "Draft the Contract" -> "Consigliere review\n(contradiction, ambiguity, completeness)";
    "Consigliere review\n(contradiction, ambiguity, completeness)" -> "Consigliere verdict?";
    "Consigliere verdict?" -> "Draft the Contract" [label="REJECT"];
    "Consigliere verdict?" -> "Don signs Contract?" [label="APPROVE"];
    "Don signs Contract?" -> "Draft the Contract" [label="changes requested"];
    "Don signs Contract?" -> "Invoke gangsta:resource-development" [label="signed"];
}

流程说明

第 1 步：综合输入

收集并充分理解所有可用情报：

  • Reconnaissance Dossier
  • Grilling 共识或当前最佳共识
  • Project Constitution（诫命与负面约束）
  • 相关 Ledger 条目
第 2 步：提出 2-3 种方案

在撰写任何规格之前，Underboss 必须向 Don 提出 2-3 种彼此不同且可行的方案。每种方案都必须涵盖：

### Approach A: <Name>
<One-sentence description>

**Pros:** <key advantages>
**Cons:** <key trade-offs>
**Risk:** HIGH / MEDIUM / LOW
**Best when:** <conditions that favour this approach>

规则：

  • 方案必须真正不同，不能只是同一想法的细微变化
  • 至少提供一种保守／安全方案和一种更大胆的方案
  • 不得包含代码或伪代码，只能说明架构和理由

提出所有方案后，询问：“您想采用哪种方案，还是希望调整？”

通过平台原生交互式选择工具展示这些选项（OpenCode question、Claude Code AskUserQuestion）——不要只把列表作为纯文本输出后等待。只有在没有此类工具时，才使用纯文本。

在 Don 明确选择之前，不要撰写任何内容。

  • Don 选择／批准 → 进入第 3 步
  • Don 要求修改 → 更新方案并重新展示
第 3 步：Underboss 起草 Contract

以获批方案为架构基础，起草正式规格。

Contract 必须包含：

---
heist: <heist-name>
date: YYYY-MM-DD
status: draft
signatories: []
---

# Contract: <Heist Name>

## Objective
<What is being built, in one paragraph>

## Requirements
### Functional Requirements
1. <FR-001> <Requirement>
2. <FR-002> <Requirement>
...

### Non-Functional Requirements
1. <NFR-001> <Requirement (performance, security, accessibility, etc.)>
...

## Architectural Decisions
<Key decisions from the Grilling consensus, with rationale>

## Grilling Conclusions
### Key Decisions
- <Decision>: <rationale>

### Rejected Alternatives
- <Alternative>: <why rejected>

### Unresolved Objections
- <Objection> — Risk: HIGH/MEDIUM/LOW — Mitigation: <if any>

## Applicable Constitution Rules
### Commandments
- <Commandment text> — Source: insights/<file>

### Negative Constraints
- NEVER <constraint> — Source: fails/<file>

## Acceptance Criteria
<How do we know the Heist is complete? Specific, testable criteria.>

## Out of Scope
<What this Heist explicitly does NOT cover>

## Open Risks
<From the Grilling — any unresolved objections with assessed risk>
第 4 步：Consigliere 审查

调用 gangsta:the-consigliere 进行规格完整性审查：

  • 检查矛盾
  • 检查歧义
  • 审计完整性
  • 检查与 Constitution 的一致性
  • 安全审查

Consigliere 将给出以下裁定之一：APPROVE、APPROVE WITH CONCERNS 或 REJECT。

如果被拒绝：Underboss 根据 Consigliere 的反馈修改，然后重新审查。

第 5 步：Don 签署 Contract

向 Don 展示 Contract：

“Heist ‘’ 的 Contract 已准备好供您审阅。Consigliere 的裁定：[裁定]。[如有顾虑，请列出。]您批准吗？”

Don 可以：

  • 签署 — Contract 即具约束力。立即调用 gangsta:resource-development——不要询问 Don 下一步要做什么，不要暂停，也不要请求确认。必须自动进入下一阶段。
  • 要求修改 — Underboss 进行修改。返回第 4 步（由 Consigliere 重新审查）。
  • 终止 Heist — 中止，不再进入后续阶段。

更新 Contract 的 frontmatter：

status: signed
signatories: [Don, Consigliere, Underboss]

输出

保存到：docs/gangsta/<heist-name>/specs/YYYY-MM-DD-contract.md

检查点

---
heist: <heist-name>
phase: the-sit-down
status: completed
timestamp: <ISO 8601>
next-action: Proceed to Resource Development
artifacts:
  - docs/gangsta/<heist-name>/specs/YYYY-MM-DD-contract.md
---

Omerta 合规性

  • 规格即法律：Contract 成为约束性规格——所有后续阶段都必须追溯到它
  • 真实原则：所有需求都引用 Dossier 调查结果或 Grilling 共识
  • 可用性原则：Contract 和检查点已保存到文件
  • 不得有代码：确认 Contract 中没有任何代码块

评论

支持 Markdown