工作流命令

用于规划、讨论审议、审计、目标管理和并行团队编排的斜杠命令。这些命令驱动 CLI-JAW 中结构化的工作流生命周期——从最初的想法到执行和完成。

概述

工作流命令在聊天界面中以 / 开头调用。它们会触发专门的规划和编排流程，超越单次对话所能完成的范围。每个命令都会激活一个专用的工作流，拥有自己的上下文、提示词和输出结构。

/plan [request]

根据自然语言请求生成结构化的实施计划。计划包括阶段划分、文件级任务、验收标准、风险和预估工作量。输出格式为 markdown，可以直接输入到 /goal 中。

参数

生成内容

• 问题陈述——我们要解决什么问题以及为什么
• 范围和非目标——明确的边界以防止范围蔓延
• 实施阶段——带有依赖关系的有序步骤
• 文件计划——每个文件的创建/修改/删除标注
• 验收标准——定义"完成"的可测试条件
• 风险和缓解措施——已知的未知因素和备选策略
• 工作量预估——大致的时间/复杂度评级

使用示例

# Plan a new feature
/plan add SSE-first real-time notifications

# Plan a refactor
/plan refactor the authentication middleware to support multiple providers

# Plan from conversation context (no argument)
/plan

# Plan with constraints
/plan migrate from REST to GraphQL, keep backward compatibility for 2 releases

/interview <request>

在开始实施之前，/interview 会提出 1-3 个针对性的澄清问题，以明确模糊的需求。这可以避免因误解规格说明而浪费精力，并生成一份精炼的需求文档，供下游命令（/plan、/goal）使用。

参数

工作原理

1. 分析——解析请求以识别模糊之处、未声明的假设和缺失的约束条件
2. 提问——生成 1-3 个按对实施决策影响程度排序的聚焦问题
3. 精炼——将你的回答整合到精炼的需求摘要中
4. 交接——精炼后的需求可供 /plan 或 /goal set 使用

使用示例

# Clarify a vague request
/interview build a notification system

# Clarify with some context already provided
/interview add user roles -- we need admin and viewer at minimum

# Clarify a complex migration
/interview migrate the monolith to microservices

面试可能产生的典型问题：

1. Should notifications use the SSE-first event channel or polling?
   This affects architecture, infrastructure, and client complexity.

2. What notification channels are in scope -- in-app only, or also
   email/push/SMS?

3. Do notifications need to persist (read/unread state, history) or
   are they ephemeral?

/deliberate <topic>

对某个主题进行结构化的多角色讨论审议。三个内部角色——规划者、架构师 和 批评者——从不同角度就主题展开辩论，产生包含权衡分析、建议和不同意见的均衡分析结果。

参数

三个角色

输出结构

• 摘要——一段话的共识（或分歧）
• 规划者视角——执行可行性和阶段划分建议
• 架构师视角——技术分析，如适用则包含图表
• 批评者视角——反对意见、风险和替代方案
• 建议——最终建议，包含置信度和注意事项

使用示例

# Deliberate an architecture decision
/deliberate should we use event sourcing or CRUD for the order service?

# Deliberate a technology choice
/deliberate database migration strategy: PostgreSQL vs CockroachDB for multi-region

# Deliberate a process decision
/deliberate monorepo vs polyrepo for our 5-service backend

# Deliberate with constraints
/deliberate real-time sync approach -- must work offline, team of 2, 3-week deadline

/planaudit [plan]

对现有计划进行只读审计。与生成计划的 /plan 不同，/planaudit 是审查计划——检查遗漏、不切实际的预估、缺失的边界情况、依赖问题和范围风险。它不会修改计划；它会生成一份审计报告。

参数

审计维度

使用示例

# Audit the current plan in conversation
/planaudit

# Audit a specific plan
/planaudit The plan is: Phase 1 - Set up database schema ...

# Audit after generating a plan
/plan add user authentication
/planaudit

审计输出示例：

Plan Audit Report
=================
Overall score: 7/10

[PASS] Completeness -- All stated requirements have corresponding tasks
[WARN] Feasibility  -- Phase 2 estimates 2 days for OAuth integration;
                       typical implementations take 3-5 days
[FAIL] Edge cases   -- No error handling for token refresh failures
[PASS] Scope risk   -- Non-goals clearly stated
[WARN] Testability  -- "Works correctly" is not a measurable criterion;
                       suggest specific test scenarios

/goal set|status|done|cancel|update|history

管理跨对话会话持久化的目标。目标会追踪进度、积累上下文，并提供从创建到完成的结构化生命周期。目标状态会持久化到磁盘，并通过仪表板在实例间同步。

子命令

目标生命周期

  set ──> active ──> done
             │
             ├──> update (repeatable, appends progress)
             │
             └──> cancel (archived)

使用示例

# Create a goal
/goal set Implement SSE-first notification system with read/unread tracking

# Check progress
/goal status

# Record incremental progress
/goal update Phase 1 complete -- schema and migrations are in place
/goal update Phase 2 in progress -- SSE event publisher done, client pending

# Complete the goal
/goal done

# Cancel a goal that is no longer relevant
/goal cancel 3

# Review all past goals
/goal history

与其他命令的集成

目标可以与其他工作流命令自然组合：

# Interview, plan, then set a goal from the refined output
/interview build user authentication
# (answer the clarifying questions)
/plan
/goal set Implement user authentication per refined requirements

# The goal tracks progress as you work
/goal update Auth middleware scaffolded, starting JWT integration
/goal update JWT working, adding refresh token rotation
/goal done

/team plan|audit|status|collect|stop

为大规模任务编排并行多智能体团队。/team 命令会生成多个子智能体，为它们分配独立的工作流，监控它们的进度，并将结果收集到统一的输出中。

子命令

工作原理

1. 分解——/team plan 分析请求并识别可以并行运行的独立工作流
2. 分配——每个工作流被分配给一个拥有自己上下文和指令的子智能体
3. 执行——智能体并行运行。每个智能体拥有文件系统访问权限，但不共享对话上下文
4. 监控——/team status 轮询所有智能体以获取进度更新
5. 审计——/team audit 在合并前检查跨智能体冲突
6. 收集——/team collect 将所有智能体的输出合并为一个连贯的结果

使用示例

# Refactor 4 API modules in parallel
/team plan Refactor user, order, product, and payment modules to use new BaseService class

# Check how agents are doing
/team status

# Run an audit to catch conflicts
/team audit

# Collect all results when agents finish
/team collect

# Emergency stop
/team stop

实际工作流

# Full team workflow for a large migration
/interview migrate from Express to Hono
# (answer clarifying questions)
/plan
/planaudit
/goal set Migrate Express to Hono

# Execute in parallel
/team plan Migrate Express to Hono -- routes, middleware, tests, docs

# Monitor and audit
/team status
/team audit

# Collect and finalize
/team collect
/goal update Migration complete, all tests passing
/goal done

命令串联

工作流命令被设计为可组合的。典型的功能开发生命周期会按顺序串联多个命令：

# 1. Clarify requirements
/interview 실시간 알림 시스템 만들어야 돼

# 2. Generate a plan from the refined requirements
/plan

# 3. Audit the plan for gaps
/planaudit

# 4. Deliberate on key design decisions
/deliberate SSE event channel vs polling for our notification delivery

# 5. Set a persistent goal
/goal set Implement real-time notification system (SSE-first)

# 6. Execute with a parallel team (for large tasks)
/team plan Implement notification system -- server, client, tests, docs

# 7. Monitor and collect
/team status
/team collect

# 8. Finalize
/goal update All modules integrated and tested
/goal done

快速参考