Workflow Commands

Slash commands for planning, deliberation, auditing, goal management, and parallel team orchestration. These commands drive the structured workflow lifecycle in CLI-JAW -- from initial idea through execution and completion.

Overview

Workflow commands are invoked with a leading / in the chat interface. They trigger specialized planning and orchestration routines that go beyond what a single conversational turn can accomplish. Each command activates a dedicated workflow with its own context, prompts, and output structure.

/plan [request]

Generates a structured implementation plan from a natural language request. The plan includes phases, file-level tasks, acceptance criteria, risks, and estimated effort. Output is formatted as markdown and can be piped directly into a /goal.

Arguments

What it produces

• Problem statement -- What problem are we solving and why
• Scope and non-goals -- Explicit boundaries to prevent scope creep
• Implementation phases -- Ordered steps with dependencies
• File plan -- Per-file create/modify/delete annotations
• Acceptance criteria -- Testable conditions that define "done"
• Risks and mitigations -- Known unknowns and fallback strategies
• Effort estimate -- Rough time/complexity rating

Example usage

# Plan a new feature
/plan add WebSocket-based 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>

Before jumping into implementation, /interview asks 1--3 targeted clarifying questions to nail down ambiguous requirements. This prevents wasted effort from misunderstood specifications and produces a refined requirement document that downstream commands (/plan, /goal) can consume.

Arguments

How it works

1. Analyze -- Parses the request to identify ambiguous areas, unstated assumptions, and missing constraints
2. Ask -- Generates 1--3 focused questions ranked by impact on implementation decisions
3. Refine -- Incorporates your answers into a refined requirement summary
4. Hand off -- The refined requirement is ready for /plan or /goal set

Example usage

# 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

Typical questions the interview might produce:

1. Should notifications be real-time (WebSocket/SSE) or polling-based?
   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>

Runs a structured multi-persona deliberation on a topic. Three internal personas -- Planner, Architect, and Critic -- debate the topic from different angles, producing a balanced analysis with trade-offs, recommendations, and dissenting opinions.

Arguments

The three personas

Output structure

• Summary -- One-paragraph consensus (or lack thereof)
• Planner's view -- Execution feasibility and phasing recommendation
• Architect's view -- Technical analysis with diagrams if applicable
• Critic's view -- Counter-arguments, risks, and alternative approaches
• Recommendation -- Final recommendation with confidence level and caveats

Example usage

# 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]

Performs a read-only audit of an existing plan. Unlike /plan which generates plans, /planaudit reviews them -- checking for gaps, unrealistic estimates, missing edge cases, dependency issues, and scope risks. It does not modify the plan; it produces an audit report.

Arguments

Audit dimensions

Example usage

# 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

Sample audit output:

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

Manages persistent goals that survive across conversation sessions. Goals track progress, accumulate context, and provide a structured lifecycle from creation through completion. Goal state is persisted to disk and synced across instances via the dashboard.

Subcommands

Goal lifecycle

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

Example usage

# Create a goal
/goal set Implement WebSocket 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 -- WebSocket server handler 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

Integration with other commands

Goals compose naturally with other workflow commands:

# 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

Orchestrates a parallel multi-agent team for large-scale tasks. The /team command spawns multiple sub-agents, assigns them independent work streams, monitors their progress, and collects their results into a unified output.

Subcommands

How it works

1. Decomposition -- /team plan analyzes the request and identifies independent work streams that can run in parallel
2. Assignment -- Each work stream is assigned to a sub-agent with its own context and instructions
3. Execution -- Agents run in parallel. Each agent has filesystem access but not shared conversation context
4. Monitoring -- /team status polls all agents for progress updates
5. Auditing -- /team audit checks for cross-agent conflicts before merging
6. Collection -- /team collect merges all agent outputs into a single coherent result

Example usage

# 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

Practical workflow

# 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

Command Chaining

Workflow commands are designed to compose. A typical feature development lifecycle chains several commands in sequence:

# 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 WebSocket vs SSE for our notification delivery

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

# 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

Quick Reference