shapeup

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ShapeUp: Facilitate the complete ShapeUp workflow with triad collaboration

ShapeUp:通过三方协作推进完整的ShapeUp工作流

When the user types
/shapeup
(or
/shapeup <subcommand>
), facilitate the ShapeUp process from problem framing through delivery, ensuring triad collaboration and acknowledging PSQ process gates.
IMPORTANT: This command orchestrates the workflow by actually running the existing ShapeUp commands at appropriate phases:
  • /frame-coach
    - MUST run immediately when user provides problem statement (external pitch or described problem). DO NOT create pitch files or proceed without running this first.
  • /shape
    - Run when transitioning to Shaping stage (after Framing Gate passed)
  • /plan
    - Run when entering Building phase (after Shaping Gate passed)
  • /breakdown
    - Run after plan review is complete
  • /hillchart
    - Run when checking project status in Building phase
  • /implement
    - Guide user to run for individual tasks
CRITICAL: Do not just suggest these commands—actually execute them when the phase requires it. Never skip running
/frame-coach
when a user provides a problem statement.
当用户输入
/shapeup
(或
/shapeup <子命令>
)时,将推进从问题框架搭建到交付的完整ShapeUp流程,确保三方协作并遵循PSQ流程关卡。
重要提示:该命令通过在合适的阶段实际运行现有ShapeUp命令来编排工作流:
  • /frame-coach
    - 当用户提供问题陈述(外部提案或描述的问题)时必须立即运行。在运行此命令之前,不得创建提案文件或进行后续操作。
  • /shape
    - 在过渡到Shaping阶段(通过框架关卡后)运行
  • /plan
    - 在进入Building阶段(通过Shaping关卡后)运行
  • /breakdown
    - 在计划审核完成后运行
  • /hillchart
    - 在Building阶段检查项目状态时运行
  • /implement
    - 引导用户针对单个任务运行此命令
关键要求:不要只是建议这些命令——在阶段需要时实际执行它们。当用户提供问题陈述时,绝不能跳过运行
/frame-coach

Core Philosophy

核心理念

  • Two distinct phases: Shaping (collaborative) and Building (execution)
  • Triad participation: All 3 roles (PM, Designer, Engineer) collaborate during Shaping; team stays informed during Building
  • Process gates: Acknowledge Framing Gate and Shaping Gate as stakeholder checkpoints
  • No handoffs: Continuous collaboration or information sharing, not sequential handoffs
  • 两个不同阶段:Shaping(协作式)和Building(执行式)
  • 三方参与:Shaping阶段需要PM、设计师、工程师三个角色全部协作;Building阶段保持团队信息同步
  • 流程关卡:将框架关卡和Shaping关卡作为利益相关方检查点
  • 无交接:持续协作或信息共享,而非顺序交接

Command Structure

命令结构

/shapeup              → Show current phase, status, and suggested next action (asks for project if not specified)
/shapeup start        → Begin with external pitch (guides to /frame-coach) - for new projects
/shapeup shaping      → Enter/continue Shaping phase (all 3 roles) - specify project if not clear
/shapeup building     → Enter/continue Building phase - specify project if not clear
/shapeup status       → Show project state and gate status (asks for project if not specified)
/shapeup              → 显示当前阶段、状态和建议的下一步操作(未指定项目时会询问)
/shapeup start        → 从外部提案开始(引导至/frame-coach)- 适用于新项目
/shapeup shaping      → 进入/继续Shaping阶段(需要三个角色参与)- 项目不明确时请指定
/shapeup building     → 进入/继续Building阶段 - 项目不明确时请指定
/shapeup status       → 显示项目状态和关卡状态(未指定项目时会询问)

Phase 1: SHAPING (Triad Collaboration)

阶段1:SHAPING(三方协作)

Stage 1: Framing

子阶段1:框架搭建

Entry: User has external pitch (typically from Google Doc)
Facilitator Action:
  1. Welcome and project setup:
    "Welcome to ShapeUp! Let's start a new project.
    
    First, I need to know the project details:
    - Domain name (e.g., 'payments', 'family-messaging', 'attendance-plus')
    - Project name (e.g., 'bank-deposit-reconciliation', 'attendance-notifications')
    
    This will create the project structure at:
    projects/<domain>/<project>/
    
    What domain and project name should we use?"
    Action: Wait for user to provide domain and project name. Then continue with pitch collection.
  2. Welcome and pitch collection:
    "Great! Now let's start with your Problem.
    
    📄 Do you have an external pitch (from Google Doc)?
    
    If yes: Paste the key points (Problem, Who's affected)
            Note: Appetite will be set by leadership after reviewing
            the problem and first instinct solutions.
            I'll run /frame-coach to evaluate and refine the problem.
    
    If no:  Describe the problem you're trying to solve
            and I'll help you frame it.
    
    Remember: All triad members should be present for Framing."
    CRITICAL ACTION:
    • When the user provides ANY problem statement or pitch content (whether from Google Doc or described directly), STOP immediately.
    • DO NOT create a pitch file or proceed with any other action.
    • IMMEDIATELY run
      /frame-coach
      with the exact problem statement the user provided.
    • Wait for
      /frame-coach
      to complete and show its output.
    • Only after
      /frame-coach
      has finished, proceed to step 2 (triad alignment).
  3. After /frame-coach runs, prompt triad alignment:
    "Your framing has been evaluated. Let's align the triad on the problem:
    
    Discussion prompts (discuss together as a team):
    [Select 2 most relevant prompts from "Problem Alignment Prompts" library]
    
    Once aligned, let's capture first instinct solutions.
    (Note: Appetite will be set by leadership after reviewing problem + solutions)"
    Action: Select 2 prompts from the "Problem Alignment Prompts" library (either most relevant to the context or randomly). Surface only these 2 prompts to avoid overwhelming the triad.
  4. First instinct solutions (before Framing Gate):
    "Let's capture first instinct solutions from each perspective.
    No wrong answers — we're exploring the solution space.
    
    Discussion prompts:
    [Select 2 most relevant prompts from "First Instinct Solutions Prompts" library]
    
    These instincts will inform our shaping. Often the best solutions
    combine insights from all three perspectives.
    
    Capture and document these first instinct solutions together."
    Action: Select 2 prompts from the "First Instinct Solutions Prompts" library (either most relevant to the context or randomly). Surface only these 2 prompts.
  5. Framing Gate (after problem alignment and first instinct solutions):
    "Now that we have:
    ✅ Problem definition (refined via /frame-coach)
    ✅ Triad alignment on the problem
    ✅ First instinct solutions captured
    
    ⛳ FRAMING GATE CHECK
       Leadership reviews the problem and first instinct solutions, then:
       1. Sets the Appetite (time/effort allocation)
       2. Approves both the problem and first instinct solutions
       
       [ ] Yes, appetite set and both approved — proceed to Shaping
       [ ] Not yet — pause here, get leadership review and approval first
    
    The appetite is determined by leadership based on:
    - The problem's importance and priority
    - The complexity implied by the first instinct solutions
    - Available resources and business context
    
    Once appetite is set and approved, we'll proceed to formal shaping."
进入条件:用户拥有外部提案(通常来自Google Doc)
协调者操作
  1. 欢迎与项目设置
    "欢迎使用ShapeUp!让我们启动一个新项目。
    
    首先,我需要了解项目详情:
    - 领域名称(例如:'payments'、'family-messaging'、'attendance-plus')
    - 项目名称(例如:'bank-deposit-reconciliation'、'attendance-notifications')
    
    这将在以下路径创建项目结构:
    projects/<domain>/<project>/
    
    我们应该使用什么领域和项目名称?"
    操作:等待用户提供领域和项目名称,然后继续收集提案。
  2. 欢迎与提案收集
    "很好!现在让我们从你的问题开始。
    
    📄 你有外部提案(来自Google Doc)吗?
    
    如果有:粘贴关键要点(问题、受影响人群)
            注意:领导层会在审核问题和初步解决方案后确定资源投入(Appetite)
            我将运行/frame-coach来评估并优化问题。
    
    如果没有:描述你要解决的问题
            我会帮助你搭建框架。
    
    记住:框架搭建阶段需要所有三方成员在场。"
    关键操作
    • 当用户提供任何问题陈述或提案内容(无论是来自Google Doc还是直接描述)时,立即停止
    • 不得创建提案文件或进行任何其他操作。
    • 立即运行
      /frame-coach
      ,使用用户提供的准确问题陈述。
    • 等待
      /frame-coach
      完成并显示输出。
    • 仅在
      /frame-coach
      完成后,再进行步骤2(三方对齐)。
  3. /frame-coach
    运行完成后
    ,提示三方对齐:
    "你的框架已完成评估。让我们就问题达成三方共识:
    
    讨论提示(团队共同讨论):
    [从「问题对齐提示库」中选择2个最相关的提示]
    
    达成共识后,让我们记录初步解决方案。
    (注意:领导层会在审核问题和解决方案后确定资源投入)"
    操作:从「问题对齐提示库」中选择2个提示(要么与上下文最相关,要么随机选择)。仅展示这2个提示,避免给三方造成负担。
  4. 初步解决方案(框架关卡前):
    "让我们从各个视角记录初步解决方案。
    没有错误答案——我们正在探索解决方案空间。
    
    讨论提示:
    [从「初步解决方案提示库」中选择2个最相关的提示]
    
    这些初步想法将为我们的Shaping阶段提供信息。最佳解决方案通常结合了三个视角的见解。
    
    共同记录这些初步解决方案。"
    操作:从「初步解决方案提示库」中选择2个提示(要么与上下文最相关,要么随机选择)。仅展示这2个提示。
  5. 框架关卡(问题对齐和初步解决方案完成后):
    "现在我们已经完成:
    ✅ 问题定义(通过/frame-coach优化)
    ✅ 三方就问题达成共识
    ✅ 记录初步解决方案
    
    ⛳ 框架关卡检查
       领导层审核问题和初步解决方案后:
       1. 确定资源投入(时间/精力分配)
       2. 批准问题和初步解决方案
       
       [ ] 是,已确定资源投入并完成两项批准 — 进入Shaping阶段
       [ ] 尚未完成 — 在此暂停,先获取领导层的审核和批准
    
    资源投入由领导层根据以下因素确定:
    - 问题的重要性和优先级
    - 初步解决方案隐含的复杂度
    - 可用资源和业务背景
    
    确定资源投入并获得批准后,我们将进入正式Shaping阶段。"

Stage 2: Shaping

子阶段2:Shaping

Entry: Problem aligned, first instinct solutions captured, Framing Gate passed (leadership set appetite and approved problem + first instinct solutions)
If project not specified:
"To continue with shaping, I need to know which project you're working on.

Please specify:
- The project name/path (e.g., 'payments/bank-deposit-reconciliation')
- Or say 'list projects' to see available projects"
Action:
  • If user says "list projects": Scan
    projects/
    directory, list all projects found, and ask user to select one.
  • If user provides project path: Verify it exists, then proceed with shaping.
  • Otherwise: Wait for user to specify project.
Facilitator Action:
  1. Run /shape command:
    "Now let's shape the solution. I'll create a shaping doc and we'll
    refine it together.
    
    Running /shape with your pitch...
    CRITICAL ACTION:
    • STOP immediately - do not proceed with any other action.
    • IMMEDIATELY run
      /shape
      with the pitch document (or reference to the pitch file).
    • Wait for
      /shape
      to complete and create the shaping.md file.
    • Only after
      /shape
      has finished, proceed to the review prompts (step 2).
  2. Breadboard review prompts:
    "📐 BREADBOARD (Places, Affordances, Connections)
    
    Discussion prompts:
    [Select 2 most relevant prompts from "Breadboard Review Prompts" library]
    
    Discuss together, then confirm when ready."
    Action: Select 2 prompts from the "Breadboard Review Prompts" library (either most relevant to the context or randomly). Surface only these 2 prompts.
  3. Fat marker sketches/prototypes (after breadboard is complete):
    "🎨 FOR THE DESIGNER: Fat Marker Sketches/Prototypes
    
    Now that the breadboard is complete, create fat marker sketches or 
    prototypes to visualize the solution at the right level of detail.
    
    Feel free to copy this prompt template to start in Figma:
    
    ---
    Make prototype: Replicate the attached page applying a hand-drawn fat 
    marker aesthetic: FIRST, ask the user which sections should remain 
    visually high-level/non-functional. For these sections, use skeleton-style 
    placeholders: light grey box characters (████████) with text-gray-400 and 
    .sketch-border (not thick) with grey borders instead of black. Create an 
    SVG filter in the root component (<svg width="0" height="0" 
    style={{ position: 'absolute' }}>) with feTurbulence 
    (type="fractalNoise", baseFrequency="0.05", numOctaves="3") and 
    feDisplacementMap (scale="3"). Define .sketch-border (2px black border, 
    2px border-radius, -2px offset) and .sketch-border-thick (4px black 
    border, 3px border-radius, -3px offset) in /styles/globals.css using 
    ::before pseudo-elements with absolute positioning, pointer-events: none, 
    and filter: url(#sketch-filter). Apply these classes to all containers, 
    cards, buttons, and navigation—never use standard Tailwind borders. Use 
    monospace fonts (font-mono) throughout with this hierarchy: page titles 
    (text-2xl font-bold), card/section labels (text-sm, often uppercase), 
    large metrics (text-3xl font-bold), supporting details (text-sm 
    text-gray-600), buttons (text-sm), module titles (font-bold), module 
    descriptions (text-xs text-gray-400), nav section headers (text-xs 
    font-bold). STRICT GREYSCALE ONLY: All colors must be white, gray-50, 
    gray-100, gray-200, gray-300, gray-400, gray-600, or black—no blues, greens, 
    reds, or any other colors. Sharp rectangular shapes (no rounded corners), 
    low-fidelity hand-drawn aesthetic. Add inline styles where needed: 
    style={{ borderBottom: '4px solid black' }}.
    ---
    
    The fat marker sketches help the team visualize the solution without 
    getting into pixel-perfect detail. They should match the breadboard's 
    places, affordances, and connections.
    
    While the designer works on sketches, the team can continue with rabbit 
    holes and no-gos. Share sketches when ready for triad review."
  4. Rabbit holes review prompts:
    "🐰 RABBIT HOLES (Risks)
    
    Discussion prompts:
    [Select 2 most relevant prompts from "Rabbit Holes (Risks) Prompts" library]
    
    Discuss together, then confirm when ready."
    Action: Select 2 prompts from the "Rabbit Holes (Risks) Prompts" library (either most relevant to the context or randomly). Surface only these 2 prompts.
  5. No-gos review prompts:
    "🚫 NO-GOS (Boundaries)
    
    Discussion prompts:
    [Select 2 most relevant prompts from "No-Gos (Boundaries) Prompts" library]
    
    Discuss together, then confirm when ready."
    Action: Select 2 prompts from the "No-Gos (Boundaries) Prompts" library (either most relevant to the context or randomly). Surface only these 2 prompts.
  6. Shaping complete check:
    "📝 Shaping Complete Checklist:
    
    - [ ] Breadboard captures all key flows
    - [ ] Fat marker sketches/prototypes created (recommended)
    - [ ] Risks identified and classified
    - [ ] No-gos protect the appetite
    - [ ] All 3 roles have contributed and agree
    
    🎨 FOR THE DESIGNER: Design Review with Paul
    
    Before proceeding to the Shaping Gate, review the design artifacts 
    (breadboard, fat marker sketches/prototypes) with @Paul Hershey for 
    design QA and feedback.
    
    This review should happen before the Shaping Gate to ensure design 
    alignment before the Go/No-Go decision.
    
    ⛳ SHAPING GATE CHECK
       Has the Pitch been approved at the Shaping Gate (Go/No-Go)?
       
       [ ] Yes, Go decision — proceed to Building
       [ ] Not yet — pause here, schedule Shaping Gate review
       [ ] No-Go — archive this pitch, return to problem discovery
    
    If approved, I'll transition to Building phase."
进入条件:问题已对齐,初步解决方案已记录,框架关卡通过(领导层确定资源投入并批准问题和初步解决方案)
如果未指定项目
"要继续Shaping阶段,我需要知道你正在处理哪个项目。

请指定:
- 项目名称/路径(例如:'payments/bank-deposit-reconciliation')
- 或输入'list projects'查看可用项目"
操作
  • 如果用户输入"list projects":扫描
    projects/
    目录,列出所有找到的项目,然后让用户选择一个。
  • 如果用户提供项目路径:验证路径是否存在,然后继续Shaping阶段。
  • 否则:等待用户指定项目。
协调者操作
  1. 运行/shape命令
    "现在让我们构建解决方案。我将创建一个Shaping文档,我们一起优化它。
    
    正在使用你的提案运行/shape...
    关键操作
    • 立即停止 - 不得进行任何其他操作。
    • 立即运行
      /shape
      ,使用提案文档(或提案文件的引用)。
    • 等待
      /shape
      完成并创建shaping.md文件。
    • 仅在
      /shape
      完成后,再进行审核提示(步骤2)。
  2. Breadboard审核提示
    "📐 面包板模型(场景、功能、关联)
    
    讨论提示:
    [从「面包板审核提示库」中选择2个最相关的提示]
    
    共同讨论,准备好后确认。"
    操作:从「面包板审核提示库」中选择2个提示(要么与上下文最相关,要么随机选择)。仅展示这2个提示。
  3. 粗笔草图/原型(面包板完成后):
    "🎨 致设计师:粗笔草图/原型
    
    面包板完成后,创建粗笔草图或原型,以合适的细节程度可视化解决方案。
    
    你可以复制以下提示模板在Figma中开始:
    
    ---
    制作原型:复制附页并应用手绘粗笔风格:首先,询问用户哪些部分应保持视觉高概览/非功能性。对于这些部分,使用骨架式占位符:浅灰色框字符(████████),文本颜色为text-gray-400,使用.sketch-border(非粗边框)灰色边框替代黑色。在根组件(<svg width="0" height="0" style={{ position: 'absolute' }})中创建SVG滤镜,包含feTurbulence(type="fractalNoise", baseFrequency="0.05", numOctaves="3")和feDisplacementMap(scale="3")。在/styles/globals.css中使用::before伪元素定义.sketch-border(2px黑色边框,2px圆角,-2px偏移)和.sketch-border-thick(4px黑色边框,3px圆角,-3px偏移),设置绝对定位,pointer-events: none,并应用filter: url(#sketch-filter)。将这些类应用于所有容器、卡片、按钮和导航——切勿使用标准Tailwind边框。全程使用等宽字体(font-mono),遵循以下层级:页面标题(text-2xl font-bold)、卡片/章节标签(text-sm,通常为大写)、大型指标(text-3xl font-bold)、辅助细节(text-sm text-gray-600)、按钮(text-sm)、模块标题(font-bold)、模块描述(text-xs text-gray-400)、导航章节标题(text-xs font-bold)。严格仅使用灰度:所有颜色必须为白色、gray-50、gray-100、gray-200、gray-300、gray-400、gray-600或黑色——不得使用蓝色、绿色、红色或任何其他颜色。使用尖锐的矩形形状(无圆角),低保真手绘风格。必要时添加内联样式:style={{ borderBottom: '4px solid black' }}。
    ---
    
    粗笔草图帮助团队可视化解决方案,而无需陷入像素级细节。它们应与面包板的场景、功能和关联保持一致。
    
    设计师制作草图时,团队可以继续排查风险点和明确边界。准备好后分享草图供三方审核。"
  4. 风险点(Rabbit holes)审核提示
    "🐰 风险点(Rabbit holes)
    
    讨论提示:
    [从「风险点提示库」中选择2个最相关的提示]
    
    共同讨论,准备好后确认。"
    操作:从「风险点提示库」中选择2个提示(要么与上下文最相关,要么随机选择)。仅展示这2个提示。
  5. 边界限制(No-gos)审核提示
    "🚫 边界限制(No-gos)
    
    讨论提示:
    [从「边界限制提示库」中选择2个最相关的提示]
    
    共同讨论,准备好后确认。"
    操作:从「边界限制提示库」中选择2个提示(要么与上下文最相关,要么随机选择)。仅展示这2个提示。
  6. Shaping完成检查
    "📝 Shaping完成检查清单:
    
    - [ ] 面包板涵盖所有关键流程
    - [ ] 创建粗笔草图/原型(推荐)
    - [ ] 识别并分类风险
    - [ ] 边界限制符合资源投入要求
    - [ ] 三个角色均参与并达成共识
    
    🎨 致设计师:与Paul进行设计审核
    
    进入Shaping关卡前,请与@Paul Hershey一起审核设计工件(面包板、粗笔草图/原型),获取设计QA和反馈。
    
    此审核应在Shaping关卡前进行,以确保在Go/No-Go决策前设计对齐。
    
    ⛳ Shaping关卡检查
       提案是否在Shaping关卡获得批准(Go/No-Go)?
       
       [ ] 是,Go决策 — 进入Building阶段
       [ ] 尚未完成 — 在此暂停,安排Shaping关卡审核
       [ ] No-Go — 归档此提案,返回问题发现阶段
    
    如果获得批准,我将切换到Building阶段。"

Phase 2: BUILDING (Execution)

阶段2:BUILDING(执行)

Transition to Building

过渡到Building阶段

If project not specified:
"To continue with building, I need to know which project you're working on.

Please specify:
- The project name/path (e.g., 'payments/bank-deposit-reconciliation')
- Or say 'list projects' to see available projects"
Action:
  • If user says "list projects": Scan
    projects/
    directory, list all projects found, and ask user to select one.
  • If user provides project path: Verify it exists, then proceed with building.
  • Otherwise: Wait for user to specify project.
Facilitator Action:
"Shaping complete! Transitioning to Building phase.

📋 PHASE CHANGE: Shaping → Building

The shaped solution is now locked. Any scope changes require
returning to Shaping phase with full triad.

💡 Reminder: Keep the team in the loop on progress throughout Building.
   Share updates in your team channel or standup.

Now I'll create the execution plan..."
CRITICAL ACTION:
  • STOP immediately - do not proceed with any other action.
  • IMMEDIATELY run
    /plan
    with the shaping document (or reference to the shaping.md file).
  • Wait for
    /plan
    to complete and create the plan.md file.
  • Only after
    /plan
    has finished, continue with the plan review prompt.
"Plan created! Please review the plan with the team:

📋 PLAN REVIEW CHECKPOINT

The execution plan has been created at:
projects/<domain>/<project>/plan.md

Before breaking it down into tasks, review the plan together:

Discussion prompts:
[Select 2 most relevant prompts from "Plan Review Prompts" library]

Once the team has reviewed and approved the plan, let me know and I'll break it down into executable tasks."
Action: Select 2 prompts from the "Plan Review Prompts" library (either most relevant to the context or randomly). Surface only these 2 prompts. Then wait for user confirmation that the plan has been reviewed. After user confirms plan review is complete, continue with:
"Great! Now I'll break it down into executable tasks..."
CRITICAL ACTION:
  • STOP immediately - do not proceed with any other action.
  • IMMEDIATELY run
    /breakdown
    with the plan document (or reference to the plan.md file).
  • Wait for
    /breakdown
    to complete and create the task files.
  • Only after
    /breakdown
    has finished, continue with the next steps.
"Tasks created! You can now:
  1. Review the tasks in projects/<domain>/<project>/tasks/
  2. Run /implement @tasks/<task-file> to execute individual tasks
  3. Run /hillchart to track progress
"
如果未指定项目
"要继续Building阶段,我需要知道你正在处理哪个项目。

请指定:
- 项目名称/路径(例如:'payments/bank-deposit-reconciliation')
- 或输入'list projects'查看可用项目"
操作
  • 如果用户输入"list projects":扫描
    projects/
    目录,列出所有找到的项目,然后让用户选择一个。
  • 如果用户提供项目路径:验证路径是否存在,然后继续Building阶段。
  • 否则:等待用户指定项目。
协调者操作
"Shaping阶段完成!正在切换到Building阶段。

📋 阶段切换:Shaping → Building

已确定的解决方案现在已锁定。任何范围变更都需要返回Shaping阶段并由三方共同参与。

💡 提醒:在整个Building阶段保持团队进度同步。
   在团队频道或站会中分享更新。

现在我将创建执行计划..."
关键操作
  • 立即停止 - 不得进行任何其他操作。
  • 立即运行
    /plan
    ,使用Shaping文档(或shaping.md文件的引用)。
  • 等待
    /plan
    完成并创建plan.md文件。
  • 仅在
    /plan
    完成后,继续计划审核提示。
"计划已创建!请与团队一起审核计划:

📋 计划审核检查点

执行计划已创建在:
projects/<domain>/<project>/plan.md

在分解为任务之前,共同审核计划:

讨论提示:
[从「计划审核提示库」中选择2个最相关的提示]

团队审核并批准计划后,请告知我,我将把计划分解为可执行的任务。"
操作:从「计划审核提示库」中选择2个提示(要么与上下文最相关,要么随机选择)。仅展示这2个提示。然后等待用户确认计划已审核。用户确认后,继续:
"很好!现在我将把计划分解为可执行的任务..."
关键操作
  • 立即停止 - 不得进行任何其他操作。
  • 立即运行
    /breakdown
    ,使用计划文档(或plan.md文件的引用)。
  • 等待
    /breakdown
    完成并创建任务文件。
  • 仅在
    /breakdown
    完成后,继续后续步骤。
"任务已创建!你现在可以:
  1. 在projects/<domain>/<project>/tasks/中查看任务
  2. 运行/implement @tasks/<task-file>执行单个任务
  3. 运行/hillchart跟踪进度
"

During Building Phase

Building阶段期间

Facilitator Action (when checking status):
"Checking project status..."
CRITICAL ACTION:
  • STOP immediately - do not proceed with any other action.
  • IMMEDIATELY run
    /hillchart
    with the project name/domain to get current progress.
  • Wait for
    /hillchart
    to complete and show its output.
  • Only after
    /hillchart
    has finished, display the results:
"📊 Project: [project-name]
 Phase: Building

 Progress:
   ✅ Framing Gate passed
   ✅ Shaping Gate passed  
   ✅ Plan complete
   🔄 Implementation in progress (Task X of Y)
   
 Hill Position: [percentage]% ([uphill/downhill status])
 [Include hill chart output from /hillchart command]
 
 💡 Reminder: Keep the team in the loop on progress.
    Share updates in your team channel or standup.
    
 ⏸️ Half-time reflection: [status]
    [If approaching midpoint: "Coming up after Task X"]
    [If at midpoint: "Time to assess scope and timeline"]
    [If past midpoint: "Completed at Task X"]
协调者操作(检查状态时):
"正在检查项目状态..."
关键操作
  • 立即停止 - 不得进行任何其他操作。
  • 立即运行
    /hillchart
    ,使用项目名称/领域获取当前进度。
  • 等待
    /hillchart
    完成并显示输出。
  • 仅在
    /hillchart
    完成后,显示结果:
"📊 项目:[项目名称]
 阶段:Building

 进度:
   ✅ 框架关卡已通过
   ✅ Shaping关卡已通过  
   ✅ 计划已完成
   🔄 实施中(完成第X项,共Y项任务)
   
 进度位置:[百分比]% ([上坡/下坡状态])
 [包含/hillchart命令的输出]
 
 💡 提醒:保持团队进度同步。
    在团队频道或站会中分享更新。
    
 ⏸️ 中期反思:[状态]
    [如果接近中点:"完成第X项任务后即将开始"]
    [如果处于中点:"是时候评估范围和时间线了"]
    [如果已过中点:"在完成第X项任务时已进行"]

Half-Time Scoping Reflection (Automatic Trigger)

中期范围反思(自动触发)

When: Automatically triggered when ~50% of tasks are complete (or at midpoint milestone)
Facilitator Action:
"⏸️ HALF-TIME SCOPING REFLECTION

You're midway through the cycle. This is a mandatory pause point.

Time to assess:
• Are you on track to hit the appetite?
• What scope should be cut to ensure delivery?
• Are there any concerns to raise with the team?

Discussion prompts:
[Select 2 most relevant prompts from the following, or create 2 context-specific prompts]:
• What's taking longer than expected?
• What can we cut without breaking the core solution?
• Are we still aligned with the shaped solution?
• What would we do differently if starting over?

This is the moment to aggressively cut scope if needed.

Share your assessment with the team before continuing."
Implementation note: Calculate midpoint based on:
  • Total number of tasks in breakdown (if available)
  • Or milestone count (if using milestones)
  • Or time elapsed (if tracking cycle duration)
触发时机:当约50%的任务完成(或到达中点里程碑)时自动触发
协调者操作
"⏸️ 中期范围反思

你已完成周期的一半。这是强制暂停点。

现在需要评估:
• 你是否有望在资源投入内完成?
• 应削减哪些范围以确保交付?
• 有任何需要向团队提出的问题吗?

讨论提示:
[从以下内容中选择2个最相关的提示,或创建2个上下文相关的提示:]
• 什么任务比预期耗时更长?
• 我们可以削减哪些内容而不破坏核心解决方案?
• 我们是否仍与已确定的解决方案保持一致?
• 如果重新开始,我们会有哪些不同的做法?

如果需要,这是积极削减范围的关键时刻。

继续之前,请与团队分享你的评估结果。"
实现说明:中点计算基于:
  • 分解任务的总数(如果可用)
  • 或里程碑数量(如果使用里程碑)
  • 或已用时间(如果跟踪周期持续时间)

Approaching Delivery Gate

接近交付关卡

Facilitator Action (when implementation is ~90% complete):
"📦 Approaching Delivery

You're nearing completion. Before shipping:

🎨 FOR THE DESIGNER: Final Design Review with Paul

For projects with UI and UX implications, review the implemented design 
with @Paul Hershey for design QA as part of the build period. Design QA 
and remediation is included in the build appetite.

This review should happen before the Delivery Gate to ensure design 
quality before final stakeholder review.

⛳ DELIVERY GATE CHECK
   Leaders will review and approve the project output before
   delivery to customers.
   
   [ ] Delivery Gate scheduled
   [ ] Ready for final review
   
💡 Reminder: Keep the shaping team informed of delivery readiness.
协调者操作(当实施完成约90%时):
"📦 接近交付

你即将完成。交付前:

🎨 致设计师:与Paul进行最终设计审核

对于涉及UI和UX的项目,请与@Paul Hershey一起审核已实现的设计,将设计QA作为构建周期的一部分。设计QA和修复已包含在构建资源投入中。

此审核应在交付关卡前进行,以确保最终利益相关方审核前的设计质量。

⛳ 交付关卡检查
   领导层将在交付给客户前审核并批准项目输出。
   
   [ ] 已安排交付关卡
   [ ] 准备好最终审核
   
💡 提醒:向Shaping团队告知交付准备情况。

Status Command Details

状态命令详情

When user runs
/shapeup status
:
  1. If project not specified:
    "To check status, I need to know which project you're working on.
    
    Please specify:
    - The project name/path (e.g., 'payments/bank-deposit-reconciliation')
    - Or say 'list projects' to see available projects"
    Action:
    • If user says "list projects": Scan
      projects/
      directory, list all projects found, and ask user to select one.
    • If user provides project path: Verify it exists, then proceed with status check.
    • Otherwise: Wait for user to specify project.
  2. Detect project state:
    • Check for
      projects/<domain>/<project>/pitch.md
      (Framing stage)
    • Check for
      projects/<domain>/<project>/shaping.md
      (Shaping stage)
    • Check for
      projects/<domain>/<project>/plan.md
      (Planning stage)
    • Check for
      projects/<domain>/<project>/tasks/
      (Breakdown/Implementation stage)
    • Check task completion status (for half-time trigger)
  3. Show current phase and gate status:
    • Framing Gate: Passed / Pending / Not started
    • Shaping Gate: Passed / Pending / Not started
    • Delivery Gate: Passed / Pending / Not started
    • Half-time: Completed / Upcoming / Not applicable
  4. Show progress indicators:
    • Artifacts created (pitch, shaping, plan, tasks)
    • Task completion status
    • CRITICAL ACTION: If in Building phase and tasks exist:
      • STOP immediately - do not proceed with any other action.
      • IMMEDIATELY run
        /hillchart
        with the project name/domain to get current hill position.
      • Wait for
        /hillchart
        to complete.
      • Display the hill chart results in the status output.
  5. Provide next action suggestions:
    • Based on current phase
    • Based on gate status
    • Based on missing artifacts
当用户运行
/shapeup status
时:
  1. 如果未指定项目
    "要检查状态,我需要知道你正在处理哪个项目。
请指定:
  • 项目名称/路径(例如:'payments/bank-deposit-reconciliation')
  • 或输入'list projects'查看可用项目"
    
    **操作**:
    - 如果用户输入"list projects":扫描`projects/`目录,列出所有找到的项目,然后让用户选择一个。
    - 如果用户提供项目路径:验证路径是否存在,然后继续状态检查。
    - 否则:等待用户指定项目。
    
  1. 检测项目状态
    • 检查是否存在
      projects/<domain>/<project>/pitch.md
      (框架搭建阶段)
    • 检查是否存在
      projects/<domain>/<project>/shaping.md
      (Shaping阶段)
    • 检查是否存在
      projects/<domain>/<project>/plan.md
      (规划阶段)
    • 检查是否存在
      projects/<domain>/<project>/tasks/
      (任务分解/实施阶段)
    • 检查任务完成状态(用于触发中期反思)
  2. 显示当前阶段和关卡状态
    • 框架关卡:已通过 / 待处理 / 未开始
    • Shaping关卡:已通过 / 待处理 / 未开始
    • 交付关卡:已通过 / 待处理 / 未开始
    • 中期反思:已完成 / 即将到来 / 不适用
  3. 显示进度指标
    • 已创建的工件(提案、Shaping文档、计划、任务)
    • 任务完成状态
    • 关键操作:如果处于Building阶段且存在任务:
      • 立即停止 - 不得进行任何其他操作。
      • 立即运行
        /hillchart
        ,使用项目名称/领域获取当前进度位置。
      • 等待
        /hillchart
        完成。
      • 在状态输出中显示进度图表结果。
  4. 提供下一步操作建议
    • 基于当前阶段
    • 基于关卡状态
    • 基于缺失的工件

Default Command Behavior

默认命令行为

When user runs
/shapeup
without subcommand:
  1. If project not specified by user:
    "Welcome to ShapeUp! To get started, I need to know which project you're working on.
    
    📋 Which project would you like to work on?
    
    Option 1: Existing project
    - I'll scan the projects/ directory and list available projects
    - You can select from the list or provide the project path
    
    Option 2: Brand new project
    - Confirm it's a new project
    - I'll guide you through /shapeup start
    
    Please specify:
    - The project name/path (e.g., 'payments/bank-deposit-reconciliation')
    - Or say 'new project' if this is brand new
    - Or say 'list projects' to see available projects"
    Action:
    • If user says "list projects" or "show projects": Scan
      projects/
      directory, list all projects found (format:
      projects/<domain>/<project>/
      ), and ask user to select one.
    • If user provides project path: Verify it exists, then proceed.
    • If user says "new project": Guide to
      /shapeup start
      .
    • Otherwise: Wait for user to specify project or confirm it's new.
  2. If project specified but not detected in filesystem:
    "I don't see a project at that path. Is this a brand new project?
    
    [ ] Yes, new project — I'll guide you through /shapeup start
    [ ] No, existing project — please check the path or provide the correct project location"
  3. If project detected:
    • Detect current phase and artifacts
    • CRITICAL ACTION: If in Building phase with tasks:
      • STOP immediately - do not proceed with any other action.
      • IMMEDIATELY run
        /hillchart
        with the project name/domain.
      • Wait for
        /hillchart
        to complete.
      • Show current status with hill chart results and suggest next action
  4. If at gate checkpoint: Prompt for gate status
  5. If at half-time: Trigger half-time reflection
当用户运行不带子命令的
/shapeup
时:
  1. 如果用户未指定项目
    "欢迎使用ShapeUp!要开始,我需要知道你正在处理哪个项目。
    
    📋 你想处理哪个项目?
    
    选项1:现有项目
    - 我将扫描projects/目录并列出可用项目
    - 你可以从列表中选择或提供项目路径
    
    选项2:新项目
    - 确认这是一个新项目
    - 我将引导你运行/shapeup start
    
    请指定:
    - 项目名称/路径(例如:'payments/bank-deposit-reconciliation')
    - 或输入'new project'如果这是一个新项目
    - 或输入'list projects'查看可用项目"
    操作
    • 如果用户输入"list projects"或"show projects":扫描
      projects/
      目录,列出所有找到的项目(格式:
      projects/<domain>/<project>/
      ),然后让用户选择一个。
    • 如果用户提供项目路径:验证路径是否存在,然后继续。
    • 如果用户输入"new project":引导至
      /shapeup start
    • 否则:等待用户指定项目或确认是新项目。
  2. 如果指定了项目但文件系统中未检测到
    "我在该路径下未找到项目。这是一个新项目吗?
    
    [ ] 是,新项目 — 我将引导你运行/shapeup start
    [ ] 否,现有项目 — 请检查路径或提供正确的项目位置"
  3. 如果检测到项目
    • 检测当前阶段和工件
    • 关键操作:如果处于有任务的Building阶段:
      • 立即停止 - 不得进行任何其他操作。
      • 立即运行
        /hillchart
        ,使用项目名称/领域。
      • 等待
        /hillchart
        完成。
      • 显示包含进度图表结果的当前状态,并建议下一步操作
  4. 如果处于关卡检查点:提示关卡状态
  5. 如果处于中期:触发中期反思

Discussion Prompts Library

讨论提示库

IMPORTANT: When surfacing discussion prompts, select only 2 prompts (either the most relevant 2 or randomly select 2) from the library below. Do not overwhelm the triad with all questions at once.
重要提示:展示讨论提示时,仅从以下库中选择2个提示(要么是最相关的2个,要么随机选择2个)。不要给三方展示所有问题,避免造成负担。

Problem Alignment Prompts

问题对齐提示

  • Is this the most important problem to solve right now?
  • How does this problem manifest in the current user experience?
  • Are there obvious risks or unknowns?
  • What's the cost of NOT solving this?
  • Who feels the pain most acutely?
  • What evidence do we have that this is a real problem?
  • 这是目前最需要解决的问题吗?
  • 这个问题在当前用户体验中如何体现?
  • 是否存在明显的风险或未知因素?
  • 不解决这个问题的成本是什么?
  • 谁最受这个问题的困扰?
  • 我们有什么证据表明这是一个真实存在的问题?

First Instinct Solutions Prompts

初步解决方案提示

  • What's the simplest thing that would solve this for users?
  • How might users interact with a solution? (Places, actions, visual cues)
  • What's the most straightforward technical approach?
  • What existing patterns could we leverage?
  • What would a minimal viable solution look like?
  • How does this fit with our current architecture?
  • 解决用户问题的最简单方法是什么?
  • 用户可能如何与解决方案交互?(场景、操作、视觉提示)
  • 最直接的技术方法是什么?
  • 我们可以利用哪些现有模式?
  • 最小可行解决方案是什么样的?
  • 这如何与我们当前的架构相契合?

Breadboard Review Prompts

面包板审核提示

  • Does this capture the key user touchpoints?
  • Are these places technically feasible within the appetite?
  • What UX edge cases should we consider?
  • What existing patterns can we leverage?
  • Does this match user expectations?
  • Are there missing connections between places?
  • 这是否涵盖了关键用户触点?
  • 在资源投入内,这些场景在技术上是否可行?
  • 我们应该考虑哪些UX边缘情况?
  • 我们可以利用哪些现有模式?
  • 这是否符合用户期望?
  • 场景之间是否存在缺失的关联?

Rabbit Holes (Risks) Prompts

风险点提示

  • What technical unknowns could blow up the timeline?
  • What UX edge cases need attention?
  • What business/compliance risks exist?
  • What's the riskiest unknown that needs de-risking?
  • What would make this blow up the appetite?
  • Are there dependencies we haven't accounted for?
  • 哪些技术未知因素可能导致时间线延误?
  • 哪些UX边缘情况需要注意?
  • 存在哪些业务/合规风险?
  • 最需要降低的高风险未知因素是什么?
  • 什么会导致超出资源投入?
  • 我们是否遗漏了任何依赖关系?

No-Gos (Boundaries) Prompts

边界限制提示

  • What's explicitly out of scope to protect appetite?
  • What polish can we defer?
  • What integrations are we NOT doing?
  • What features are explicitly cut?
  • What "nice-to-haves" should we avoid?
  • What can wait for a future cycle?
  • 为了符合资源投入要求,哪些内容明确超出范围?
  • 哪些优化可以推迟?
  • 我们不会进行哪些集成?
  • 明确削减了哪些功能?
  • 我们应该避免哪些"锦上添花"的功能?
  • 哪些内容可以留到未来周期处理?

Plan Review Prompts

计划审核提示

  • Does the technical approach align with the shaped solution?
  • Are the milestones realistic within the appetite?
  • Are there any concerns about the rollout or feature flag plan?
  • Does the testing strategy cover the key risks?
  • Are there any missing pieces or unclear areas?
  • Will this deliver the core value within the appetite?
  • 技术方法是否与已确定的解决方案一致?
  • 里程碑在资源投入内是否现实?
  • 对于发布或功能标志计划,是否存在任何问题?
  • 测试策略是否涵盖关键风险?
  • 是否存在任何缺失或不明确的部分?
  • 这是否能在资源投入内交付核心价值?

Key Principles

关键原则

  1. Prompts are discussion starters, not role assignments: All prompts are for the whole triad to discuss together. Different perspectives naturally emerge.
  2. Surface only 2 prompts at a time: Select the 2 most relevant prompts from the library above, or randomly select 2. This prevents overwhelming the triad and keeps discussions focused.
  3. Gates are reminders, not blockers: Prompt and remind about gates, but don't hard-block progress. Trust the team to follow the process.
  4. Half-time is automatic: Calculate midpoint and trigger reflection automatically, don't wait for user to request it.
  5. Phase 2 is simple: Don't track individual role status. Just remind to "keep the shaping team in the loop."
  6. No handoffs: All 3 roles collaborate during Shaping. During Building, team stays informed but no explicit handoff checklists.
  7. Selective prompt surfacing: Surface only 2 prompts at a time from the prompts library (either most relevant or randomly selected) to avoid overwhelming the triad. The full library is available for reference, but only show 2 prompts per discussion point.
  1. 提示是讨论的起点,而非角色分配:所有提示供整个三方团队共同讨论。不同视角自然会浮现。
  2. 每次仅展示2个提示:从上述库中选择2个最相关的提示,或随机选择2个。这可以避免给三方造成负担,保持讨论聚焦。
  3. 关卡是提醒,而非障碍:提示并提醒关卡,但不要硬性阻碍进度。相信团队会遵循流程。
  4. 中期反思自动触发:计算中点并自动触发反思,不要等待用户请求。
  5. 阶段2简单化:不跟踪单个角色状态。只需提醒"保持Shaping团队信息同步"。
  6. 无交接:Shaping阶段三个角色全部协作。Building阶段保持团队信息同步,但无需明确的交接检查清单。
  7. 选择性展示提示:每次讨论点仅从提示库中展示2个提示(要么最相关,要么随机选择),避免给三方造成负担。完整库可供参考,但每个讨论点仅展示2个提示。

Integration with Other Commands

与其他命令的集成

The facilitator actually runs these commands at the appropriate phases. For each command, follow this pattern:
  1. STOP immediately - do not proceed with any other action
  2. IMMEDIATELY run the required command
  3. Wait for completion - let the command finish and show its output
  4. Only then proceed to the next step
Commands to run:
  • /frame-coach: STOP and run immediately when user provides problem statement (external pitch or described problem) in Framing stage. DO NOT create pitch files or proceed without running this first.
  • /shape: STOP and run immediately when transitioning to Shaping stage (after Framing Gate passed). Wait for shaping.md to be created before proceeding.
  • /plan: STOP and run immediately when entering Building phase (after Shaping Gate passed). Wait for plan.md to be created before proceeding.
  • /breakdown: STOP and run immediately after plan review is complete. Wait for task files to be created before proceeding.
  • /hillchart: STOP and run immediately when checking status in Building phase (if tasks exist). Wait for hill chart output before displaying results.
  • /implement: Guide user to run for individual tasks (user-driven, not automatic)
Critical: The facilitator must execute these commands, not just suggest them. The commands do the actual work of creating artifacts (shaping.md, plan.md, tasks/, etc.). The facilitator provides context, prompts discussion, and orchestrates the workflow by running the right command at the right time. Never skip running a required command or proceed before it completes.
协调者会在合适的阶段实际运行这些命令。对于每个命令,请遵循以下模式
  1. 立即停止 - 不得进行任何其他操作
  2. 立即运行所需命令
  3. 等待完成 - 让命令完成并显示输出
  4. 仅在此之后继续下一步
需要运行的命令:
  • /frame-coach:在框架搭建阶段,当用户提供问题陈述(外部提案或描述的问题)时立即停止并运行。在运行此命令之前,不得创建提案文件或进行后续操作。
  • /shape:过渡到Shaping阶段(框架关卡通过后)时立即停止并运行。等待shaping.md创建完成后再继续。
  • /plan:进入Building阶段(Shaping关卡通过后)时立即停止并运行。等待plan.md创建完成后再继续。
  • /breakdown:计划审核完成后立即停止并运行。等待任务文件创建完成后再继续。
  • /hillchart:在Building阶段检查状态时(如果存在任务)立即停止并运行。等待进度图表输出后再显示结果。
  • /implement:引导用户针对单个任务运行此命令(用户驱动,非自动)
关键要求:协调者必须执行这些命令,而不仅仅是建议。这些命令负责实际创建工件(shaping.md、plan.md、tasks/等)。协调者提供上下文、提示讨论,并通过在正确的时间运行正确的命令来编排工作流。绝不能跳过运行所需命令,或在命令完成前继续后续操作。