Back to Details

groom

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/groom

/groom

Orchestrate interactive backlog grooming. Explore the product landscape with the user, brainstorm directions, then synthesize into prioritized issues.
编排交互式待办事项梳理流程：与用户一同探索产品现状，头脑风暴发展方向，随后整合为优先级明确的工单。

Philosophy

设计理念

Exploration before synthesis. Understand deeply, discuss with user, THEN create issues.
Orchestrator pattern. /groom invokes skills and agents, doesn't reimplement logic.
AI-augmented analysis. External tools provide specialized capabilities:
  • Gemini — Web-grounded research, current best practices, huge context
  • Codex — Implementation recommendations, concrete code suggestions
  • Thinktank — Multi-model consensus, diverse expert perspectives
Opinionated recommendations. Don't just present options. Recommend and justify.
先探索后整合：深入理解需求，与用户充分讨论，再创建工单。
编排器模式：/groom调用各类技能与Agent，不重复实现底层逻辑。
AI增强分析：借助外部工具提供专业能力：
  • Gemini — 基于网络的调研、当前最佳实践、大上下文分析
  • Codex — 实现方案建议、具体代码示例
  • Thinktank — 多模型共识、多元专家视角
带有明确立场的建议：不只是罗列选项，还要给出推荐方案并说明理由。

Org-Wide Standards

全组织标准

All issues MUST comply with 
groom/references/org-standards.md
. Load that file before creating any issues.
所有工单必须符合
groom/references/org-standards.md
中的规范。创建任何工单前请先加载该文件。

Process

流程

Phase 1: Context

第一阶段：上下文收集

Step 1: Load or Gather Vision

步骤1：加载或收集产品愿景

Check for 
vision.md
in project root:
If vision.md exists:
  1. Read and display current vision
  2. Ask: "Is this still accurate? Any updates?"
  3. If updates, rewrite vision.md
If vision.md doesn't exist:
  1. Interview: "What's your vision for this product? Where should it go?"
  2. Write response to 
    vision.md
vision.md format:
markdown
undefined
检查项目根目录下是否存在
vision.md
文件：
若存在vision.md：
  1. 读取并展示当前产品愿景
  2. 询问用户：“该愿景是否仍准确？是否需要更新？”
  3. 若需更新，重写vision.md文件
若不存在vision.md：
  1. 访谈用户：“你对这款产品的愿景是什么？它应该往哪个方向发展？”
  2. 将用户反馈写入vision.md文件
vision.md格式：
markdown
undefined

Vision

愿景

One-Liner

一句话概述

[Single sentence: what this product is and who it's for]
[用一句话说明产品定位与目标用户]

North Star

北极星指标

[The dream state — what does success look like in 2 years?]
[理想状态——两年后的成功是什么样的？]

Key Differentiators

核心差异化优势

[What makes this different from alternatives?]
[与竞品相比，这款产品的独特之处是什么？]

Target User

目标用户

[Who specifically is this for?]
[产品的具体目标用户群体是哪些？]

Current Focus

当前重点

[Immediate priority this quarter?]
Last updated: YYYY-MM-DD Updated during: /groom session

Store as `{vision}` for agent context throughout session.
[本季度的首要任务是什么？]
最后更新时间：YYYY-MM-DD 更新场景：/groom 会话

将该文件内容存储为`{vision}`，供整个会话中的Agent使用。

Step 2: Capture What's On Your Mind

步骤2：收集用户的即时想法

Before structured analysis:
Anything on your mind? Bugs, UX friction, missing features, nitpicks?
These become issues alongside the automated findings.

(Skip if nothing comes to mind)
For each item: clarify if needed (one follow-up max), assign tentative priority. Don't create issues yet — collect for Phase 4.
在结构化分析之前：
你有任何想法吗？比如Bug、UX痛点、缺失功能、细节优化建议？
这些内容会和自动化分析结果一同转化为工单。

（若无想法可跳过）
对于每个收集到的想法：必要时进行澄清（最多跟进一次），并分配临时优先级。暂不创建工单，统一留到第四阶段处理。

Step 3: Quick Backlog Audit

步骤3：快速待办事项审计

bash
gh issue list --state open --limit 100 --json number,title,labels,body,createdAt,updatedAt
Evaluate each existing issue:
  1. Still relevant? Given current vision and codebase state
  2. Priority correct? Focus may have shifted
  3. Duplicate? Will new findings cover this?
  4. Actionable? Can someone pick this up?
Present findings. Don't auto-close anything yet. "Here's where we stand: X open issues, Y look stale, Z may need reprioritization."
bash
gh issue list --state open --limit 100 --json number,title,labels,body,createdAt,updatedAt
评估每个现有工单：
  1. **是否仍具相关性？**结合当前产品愿景与代码库状态判断
  2. **优先级是否合理？**团队重点可能已发生变化
  3. **是否重复？**新的分析结果是否已覆盖该工单内容
  4. **是否可执行？**是否有人能立即接手处理
向用户展示审计结果，暂不自动关闭任何工单。示例话术：“当前状态：共X个未关闭工单，其中Y个已失效，Z个可能需要重新调整优先级。”

Phase 2: Discovery

第二阶段：探索分析

Launch agents in parallel:
AgentFocus
Product strategistGaps vs vision, user value opportunities
Technical archaeologistCode health, architectural debt, improvement patterns
Domain auditorsRun 
check-*
skills (audit-only, no issue creation)
Growth analystAcquisition, activation, retention opportunities
Domain auditors invoke in parallel:
  • /check-production
    , 
    /check-quality
    , 
    /check-docs
    , 
    /check-observability
  • /check-product-standards
    , 
    /check-stripe
    , 
    /check-bitcoin
    , 
    /check-lightning
  • /check-virality
    , 
    /check-landing
    , 
    /check-onboarding
Synthesize findings into 3-5 strategic themes with evidence. Examples: "reliability foundation," "onboarding redesign," "API expansion."
Present: "Here are the themes I see across the analysis. Which interest you?"
并行启动多个Agent：
Agent聚焦方向
产品策略Agent愿景差距分析、用户价值挖掘
技术考古Agent代码健康度、技术债务、优化模式
领域审计Agent运行
check-*
技能（仅审计，不创建工单）
增长分析Agent用户获取、激活、留存机会挖掘
领域审计Agent会并行调用以下技能：
  • /check-production
    、
    /check-quality
    、
    /check-docs
    、
    /check-observability
  • /check-product-standards
    、
    /check-stripe
    、
    /check-bitcoin
    、
    /check-lightning
  • /check-virality
    、
    /check-landing
    、
    /check-onboarding
将分析结果整合为3-5个战略主题并附上依据。示例主题：“可靠性基础建设”、“新手引导重设计”、“API能力扩展”。
向用户展示：“以下是本次分析得出的核心主题，你对哪些主题感兴趣？”

Phase 3: Exploration Loop

第三阶段：循环探索

For each theme the user wants to explore:
  1. Pitch — Agents brainstorm approaches. What it looks like, what it costs, what it enables.
  2. Present — 3-5 competing approaches with tradeoffs. Recommend one.
  3. Discuss — User steers. "What about X?" "I prefer Y because Z."
  4. Refine — Agents dig deeper on selected direction. Architecture, toolchain, risk.
  5. Decide or iterate — Lock direction or explore more.
Repeats per theme. Revisits allowed. Continues until user says "lock it in."
Use AskUserQuestion for structured decisions. Plain conversation for exploration.
Team-Accelerated Exploration (for large sessions):
TeammateFocus
Infra & qualityProduction, quality gates, observability
Product & growthLanding, onboarding, virality, strategy
Payments & integrationsStripe, Bitcoin, Lightning
AI enrichmentGemini research, Codex implementation recs
Teammates share findings via messages. Cross-pollination encouraged: when Infra finds a P0, Growth checks if it affects onboarding.
针对用户选择探索的每个主题：
  1. 提案 — Agent头脑风暴可行方案，说明方案形态、成本与价值
  2. 展示 — 呈现3-5种竞争方案及其利弊，推荐其中一种
  3. 讨论 — 用户引导方向，例如：“X方案怎么样？”“我更喜欢Y方案，因为Z”
  4. 细化 — Agent针对选定方向深入分析，包括架构、工具链、风险等
  5. 决策或迭代 — 锁定方向或继续探索
每个主题重复上述流程，允许用户回头重新探索其他主题，直到用户表示“锁定方向”为止。
结构化决策使用AskUserQuestion工具，探索阶段采用自由对话形式。
团队协作加速探索（适用于大型会话）：
团队角色聚焦方向
基础设施与质量团队生产环境、质量门禁、可观测性
产品与增长团队着陆页、新手引导、病毒式传播、产品策略
支付与集成团队Stripe、Bitcoin、Lightning
AI增强团队Gemini调研、Codex实现建议
团队成员通过消息共享分析结果，鼓励跨团队协作：例如基础设施团队发现P0级问题时，增长团队需检查该问题是否影响用户新手引导。

Phase 4: Synthesis

第四阶段：整合落地

Once directions are locked for explored themes:
一旦锁定探索主题的方向：

Step 1: Create Issues

步骤1：创建工单

Create atomic, implementable GitHub issues from agreed directions. Include user observations from Phase 1 Step 2.
Invoke 
log-*
skills for domains where automated issue creation helps:
  • /log-production-issues
    , 
    /log-quality-issues
    , 
    /log-doc-issues
  • /log-observability-issues
    , 
    /log-product-standards-issues
  • /log-stripe-issues
    , 
    /log-bitcoin-issues
    , 
    /log-lightning-issues
  • /log-virality-issues
    , 
    /log-landing-issues
    , 
    /log-onboarding-issues
For strategic issues from exploration: create directly with full context.
根据已达成一致的方向，创建原子化、可执行的GitHub工单，同时纳入第一阶段步骤2中收集的用户想法。
在适合自动化创建工单的领域，调用
log-*
技能：
  • /log-production-issues
    、
    /log-doc-issues
    、
    /log-quality-issues
  • /log-observability-issues
    、
    /log-product-standards-issues
  • /log-stripe-issues
    、
    /log-bitcoin-issues
    、
    /log-lightning-issues
  • /log-virality-issues
    、
    /log-landing-issues
    、
    /log-onboarding-issues
对于探索阶段产生的战略性工单：直接创建并附上完整上下文。

Step 2: Enrich

步骤2：工单增强

Each issue gets:
  • Problem statement (from exploration discussion)
  • Context and evidence
  • Recommended approach (from locked direction)
  • Acceptance criteria
  • Effort estimate
Use Codex for implementation recommendations on P0/P1 issues. Use Gemini for current best practices research. Use Thinktank for architecture validation on complex issues.
每个工单需包含以下内容：
  • 问题描述（来自探索阶段的讨论）
  • 上下文与依据
  • 推荐实现方案（来自锁定的方向）
  • 验收标准
  • 工作量预估
对于P0/P1级工单，使用Codex获取实现建议；使用Gemini调研当前最佳实践；对于复杂工单，使用Thinktank进行架构验证。

Step 3: Organize

步骤3：工单整理

Apply org-wide standards (load 
groom/references/org-standards.md
):
  • Canonical labels (priority, type, horizon, effort, source, domain)
  • Issue types via GraphQL
  • Milestone assignment
  • Project linking (Active Sprint, Product Roadmap)
Close stale issues identified in Phase 1 Step 3 (with user confirmation). Migrate legacy labels.
应用全组织标准（加载
groom/references/org-standards.md
）：
  • 规范标签（优先级、类型、周期、工作量、来源、领域）
  • 通过GraphQL设置工单类型
  • 分配里程碑
  • 关联项目（如当前迭代、产品路线图）
在获得用户确认后，关闭第一阶段步骤3中识别出的失效工单，并迁移旧标签。

Step 4: Deduplicate

步骤4：去重

Three sources of duplicates:
  1. User observations that overlap with automated findings
  2. New issues from log-* skills that overlap with each other
  3. New issues that overlap with existing kept issues
Keep the most comprehensive. Close others with link to canonical.
重复工单的三个来源：
  1. 用户想法与自动化分析结果重叠
  2. 不同
    log-*
    技能创建的新工单之间重叠
  3. 新工单与保留的现有工单重叠
保留内容最全面的工单，关闭其他重复工单并链接至标准工单。

Step 5: Summarize

步骤5：总结

GROOM SUMMARY
=============

Themes Explored: [list]
Directions Locked: [list]

Issues by Priority:
- P0 (Critical): N
- P1 (Essential): N
- P2 (Important): N
- P3 (Nice to Have): N

Recommended Execution Order:
1. [P0] ...
2. [P1] ...

Ready for /autopilot: [issue numbers]
View all: gh issue list --state open
梳理会话总结
=============

探索的主题：[列表]
锁定的方向：[列表]

按优先级分类的工单数量：
- P0（紧急）：N个
- P1（重要）：N个
- P2（一般）：N个
- P3（可选）：N个

推荐执行顺序：
1. [P0] ...
2. [P1] ...

可交由/autopilot处理的工单：[工单号]
查看全部工单：gh issue list --state open

Related Skills

相关技能

Audit Primitives (Phase 2)

审计基础技能（第二阶段）

  • /check-production
    , 
    /check-docs
    , 
    /check-quality
    , 
    /check-observability
  • /check-product-standards
    , 
    /check-stripe
    , 
    /check-bitcoin
    , 
    /check-lightning
  • /check-virality
    , 
    /check-landing
    , 
    /check-onboarding
  • /check-production
    、
    /check-docs
    、
    /check-quality
    、
    /check-observability
  • /check-product-standards
    、
    /check-stripe
    、
    /check-bitcoin
    、
    /check-lightning
  • /check-virality
    、
    /check-landing
    、
    /check-onboarding

Issue Creators (Phase 4)

工单创建技能（第四阶段）

  • /log-production-issues
    , 
    /log-doc-issues
    , 
    /log-quality-issues
  • /log-observability-issues
    , 
    /log-product-standards-issues
  • /log-stripe-issues
    , 
    /log-bitcoin-issues
    , 
    /log-lightning-issues
  • /log-virality-issues
    , 
    /log-landing-issues
    , 
    /log-onboarding-issues
  • /log-production-issues
    、
    /log-doc-issues
    、
    /log-quality-issues
  • /log-observability-issues
    、
    /log-product-standards-issues
  • /log-stripe-issues
    、
    /log-bitcoin-issues
    、
    /log-lightning-issues
  • /log-virality-issues
    、
    /log-landing-issues
    、
    /log-onboarding-issues

Standalone Domain Work

独立领域工作流

bash
/check-production     # Audit only
/log-production-issues # Create issues
/triage              # Fix highest priority
bash
/check-production     # 仅审计
/log-production-issues # 创建工单
/triage              # 处理最高优先级问题