# Feature Landscape

**Domain:** tmux-Claude CLI integration + OpenClaw skill bridging
**Researched:** 2026-03-10

## Table Stakes

Features users expect. Missing = product feels incomplete.

| Feature | Why Expected | Complexity | Notes |
|---------|--------------|------------|-------|
| Session persistence | Users expect context to survive across chat sessions; Claude CLI conversations span hours/days | Medium | tmux provides this; state_manager.py pattern from dev-workflow shows JSON persistence approach |
| Command bridging | GSD slash commands must work through chat apps; core value proposition | Medium | Parse /gsd:* commands from messages, forward to Claude CLI via tmux |
| Basic messaging | Send message, get response - the fundamental loop | Low | OpenClaw handles channel routing; skill just processes content |
| SKILL.md frontmatter | AgentSkills spec compliance; OpenClaw won't load skill without it | Low | name + description required; metadata JSON optional |
| Workspace isolation | Projects must not interfere; users run multiple projects concurrently | Medium | Per-project tmux sessions + directory structure |
| State recovery | Long-running operations survive interruptions (network drops, restarts) | Medium | JSON state files like dev-workflow's state.json |
| Error handling | Failures must be reported clearly, not silently swallowed | Low | Return error messages through chat channel |
| Multi-channel support | OpenClaw's core value - works across WhatsApp/Telegram/Discord/etc | Low | OpenClaw handles channel abstraction; skill is channel-agnostic |

## Differentiators

Features that set product apart. Not expected, but valued.

| Feature | Value Proposition | Complexity | Notes |
|---------|-------------------|------------|-------|
| Intelligent context management | Auto-summarize long sessions to keep context window usable; proactive context pruning | High | Claude CLI has limits; proactive summarization prevents degradation |
| Proactive notifications | Push updates when long-running tasks complete (builds, deployments, tests) | Medium | Requires async monitoring + callback mechanism |
| Multi-agent coordination | Spawn sub-agents for parallel tasks (research, implementation, review) | High | dev-workflow shows pattern: 3 agents for design, 3 for review |
| Interactive approval flow | Request user confirmation for risky operations before execution | Medium | GSD has approval gates; bridge must expose these through chat |
| Session branching | Fork session state for "what if" exploration without losing main context | High | Advanced tmux session cloning + state snapshot |
| Command history search | Search past commands/outputs across sessions | Medium | Log all tmux I/O to searchable store |
| Rich output formatting | Markdown rendering, code blocks, progress indicators in chat | Medium | Channel-dependent; some support markdown, others plain text |
| Session handoff | Transfer session between channels (start on WhatsApp, continue on Telegram) | High | Requires session serialization + cross-channel identity |
| Intelligent retry | Auto-retry failed operations with backoff, report after N failures | Medium | dev-workflow pattern: 3 retries before user escalation |
| Progress snapshots | Periodic progress reports during long operations | Low | Simple timer-based status polling |

## Anti-Features

Features to explicitly NOT build.

| Anti-Feature | Why Avoid | What to Do Instead |
|--------------|-----------|-------------------|
| GSD core modifications | Breaks compatibility with upstream GSD updates; maintenance burden | Pure bridging - all GSD logic stays in GSD |
| Mobile native app | Outside scope; chat apps already cover mobile | Rely on OpenClaw's channel support |
| Custom auth system | Reinventing wheel; OpenClaw has dmPolicy, allowlists | Use OpenClaw's security model (pairing, allowlists) |
| Real-time streaming output | Most chat APIs don't support streaming; adds complexity | Batch updates at intervals or on completion |
| Complex permissions | Over-engineering for MVP; user isolation sufficient | Per-user workspaces + OpenClaw's channel-level access control |
| Web dashboard | Scope creep; OpenClaw has control UI at :18789 | Link to existing dashboard if needed |
| Custom tmux UI | tmux is the implementation detail, not the product | Abstract away tmux; users interact through chat |

## Feature Dependencies

```
tmux session management
    |
    +---> Command bridging (needs session to send commands)
    |         |
    |         +---> Interactive approval flow (needs bidirectional I/O)
    |         +---> Progress snapshots (needs output capture)
    |
    +---> Session persistence (needs tmux sessions)
    |         |
    |         +---> State recovery (needs persistent state files)
    |         +---> Session branching (needs session cloning)
    |
    +---> Workspace isolation (needs per-project sessions)
              |
              +---> Multi-user support (needs isolation foundation)

SKILL.md + orchestrator.py
    |
    +---> Multi-agent coordination (orchestrator spawns sub-agents)
    |         |
    |         +---> Intelligent retry (orchestrator handles retries)
    |
    +---> Error handling (orchestrator catches and reports)
    +---> Proactive notifications (orchestrator monitors and pushes)

OpenClaw integration
    |
    +---> Multi-channel support (OpenClaw handles routing)
    +---> Basic messaging (OpenClaw handles send/receive)
    +---> Security model (OpenClaw's dmPolicy/allowlists)
```

## Critical Path for MVP

Based on dependencies and table stakes:

```
Phase 1: Foundation
├── tmux session management (create, list, attach, destroy)
├── SKILL.md with proper frontmatter
├── orchestrator.py skeleton
└── Basic command bridging (send command, capture output)

Phase 2: Persistence
├── Session persistence (tmux sessions survive restart)
├── State recovery (JSON state files)
├── Workspace isolation (per-project sessions)
└── Error handling and reporting

Phase 3: GSD Integration
├── All GSD slash commands bridged
├── Interactive approval flows
├── Progress reporting
└── State file integration with GSD's .planning/ structure

Phase 4: Polish
├── Proactive notifications
├── Rich output formatting
├── Intelligent retry
└── Progress snapshots
```

## MVP Recommendation

Prioritize:
1. **tmux session management** - Foundation for everything
2. **Command bridging** - Core value; enables GSD access
3. **SKILL.md + orchestrator.py** - OpenClaw integration

Defer:
- **Multi-agent coordination**: Complex; dev-workflow shows it's achievable but not MVP
- **Session branching**: Advanced feature; validate core use case first
- **Session handoff**: Cross-channel identity is complex; single-channel MVP

## Complexity Assessment

| Tier | Features | Est. Effort |
|------|----------|-------------|
| Tier 1 (MVP) | tmux sessions, command bridging, SKILL.md, basic persistence | 1-2 weeks |
| Tier 2 (Core) | Full GSD bridging, approval flows, workspace isolation, error handling | 2-3 weeks |
| Tier 3 (Enhanced) | Multi-agent, notifications, retry logic, progress snapshots | 2-3 weeks |
| Tier 4 (Advanced) | Session branching, handoff, context management, history search | 3-4 weeks |

## Sources

- OpenClaw docs: https://docs.openclaw.ai/skills - Skill structure, metadata, gating
- OpenClaw docs: https://docs.openclaw.ai/multi-agent - Multi-agent patterns, isolation, routing
- dev-workflow SKILL.md - Reference implementation for state persistence, phase management, retry logic
- dev-workflow orchestrator.py - Python orchestration pattern, phase execution
- PROJECT.md - GSD-OpenClaw requirements, constraints, out-of-scope items