discuss
Discuss and explore ideas before committing to an approach
Best use case
discuss is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Discuss and explore ideas before committing to an approach
Teams using discuss should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/discuss/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How discuss Compares
| Feature / Agent | discuss | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Discuss and explore ideas before committing to an approach
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Discuss Phase
Capture implementation decisions BEFORE planning. Produces a CONTEXT.md
with locked decisions that /plan must honor.
## When to Use
- Before `/plan` when the phase has ambiguities
- When starting a new phase in `.planning/ROADMAP.md`
- When the team needs to agree on approach before implementation
## Process
### Step 1: Load Phase Context
1. Read `.planning/ROADMAP.md` to identify the target phase
2. Read `.planning/STATE.md` for current position
3. If a phase number is provided as argument, use that
4. If no argument, use current phase from STATE.md
### Step 2: Identify Gray Areas
Based on what the phase is building, identify 3-4 ambiguities:
| Domain | Typical Gray Areas |
|--------|-------------------|
| UI/Frontend | Layout approach, interaction patterns, responsive behavior, state management |
| API/Backend | Response formats, error handling, auth strategy, data validation |
| Data/Storage | Schema design, migration approach, indexing strategy |
| Infrastructure | Deployment target, scaling approach, monitoring |
Present them:
```
Phase [N]: [Name]
I've identified these areas that need decisions before planning:
1. **[Area 1]**: [Why this is ambiguous]
2. **[Area 2]**: [Why this is ambiguous]
3. **[Area 3]**: [Why this is ambiguous]
Which areas would you like to discuss? (or "all")
```
### Step 3: Deep-Dive Questions
For each selected area, ask 3-4 probing questions using AskUserQuestion:
- Concrete choices (not abstract preferences)
- Trade-off acknowledgment
- Edge case handling
- Prior art / references
### Step 4: Generate CONTEXT.md
Write to `.planning/phases/{phase}/CONTEXT.md`:
```markdown
# Phase [N] Context: [Phase Name]
## Scope (from Roadmap)
[Copy from ROADMAP.md]
## Implementation Decisions
### [Area 1]
- **Decision**: [Concrete choice]
- **Rationale**: [Why this choice]
- **Trade-off**: [What we're giving up]
### [Area 2]
...
## Deferred Ideas
- [Idea mentioned but deferred to later phase]
---
*Locked on [date]. /plan must honor these decisions.*
```
### Step 5: Update State
Update `.planning/STATE.md` to record that discussion is complete for this phase.
## Without .planning/
If no `.planning/` directory exists, /discuss still works:
- Ask what area/feature the user wants to discuss
- Run the same gray-area analysis and questioning
- Output to `plans/discuss_[topic]_[date].md` insteadRelated Skills
workflow
Guide through structured delivery workflow with plan, implement, validate phases
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
validate
Verify implementation against specifications
ui-ux-pro-max
UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, Astro, Nuxt, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, Jetpack Compose). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.
tui-style-guide
TUI style guide for consistent terminal interface design
token-usage
Show Claude Code token usage across sessions — daily, weekly, per-project, and per-session breakdowns. Parses {{HOME_TOOL_DIR}}/projects/**/*.jsonl for consumption data. Use when the user asks about token usage, costs, how many tokens were used, session statistics, or wants a usage report.
tmux-status
Show status of all tmux sessions including dev environments, spawned agents, and running processes
tmux-monitor
Monitor and report status of all tmux sessions including dev environments, spawned agents, and running processes. Uses tmuxwatch for enhanced visibility.
tmux-message
Reliable peer-to-peer message delivery to other Claude Code instances via tmux send-keys. Use as a fallback when claude-peers MCP send_message fails to surface in the receiver's inbox (delivered server-side but receiver never picks it up — observed behaviour). Also use when sending a directive to a known Claude Code TUI session by tmux session name or fuzzy hint, or when injecting a multi-line directive into a peer's prompt and submitting it. Trigger phrases — "claude-peers fallback", "tmux send-keys", "send to peer via tmux", "inject directive", "deliver to nanoclaw/hermes peer", "peer message". Tmux-only — won't reach peers running outside tmux.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.
test-ainb
Run tests for the ainb (agents-in-a-box) Rust workspace via a 5-layer strategy — unit, insta snapshot, mock-plugin compositing, real-plugin spawn, vhs recording. Wraps cargo + insta + vhs into one CLI. Use when Stevie says "/test-ainb", "test ainb", "run ainb tests", "snapshot <component>", "regenerate vhs tapes", or any phrasing about validating ainb test layers. The skill autodetects which ainb-tui worktree the cwd sits in and dispatches to scripts/run.sh.
sync-learnings
Sync user-level agent config changes back to toolkit repository (works for Claude, Codex, Copilot)