Techcle Wiki

Discovery Questions

8 min read

OpenCode Slack Integration - Discovery Questions

Date: 2026-01-30
Project: .ai/projects/ai-dev/opencode-slack-integration
Context: Integrating Slack with OpenCode CLI for mobile-first, async AI development

Current State Understanding

What We Know

  • ✅ You use OpenCode CLI (Claude Code v1.1.40)
  • ✅ Runs in K8s pod with tmux/ttyd for web access
  • ✅ PVC-backed file system for persistence
  • ✅ Code Server shares same PVC for code review
  • ✅ You have repos/ai-dev project (ai-dev-poc implementation) with OpenWebUI/Gateway partially built
  • ✅ OpenWebUI doesn’t feel like the right tool
  • ✅ OpenCode Web can replace OpenWebUI’s role
  • ✅ Slack integration is the primary goal
  • ✅ You’re concerned OpenCode is single-threaded (vs codev’s parallel worker model)
  • ✅ You’ve opened issue on codev to support OpenCode

Current Pain Points (to validate)

  • VPN + web access required for ttyd
  • Mobile interaction is awkward via browser terminal
  • Network instability disrupts WebSocket connections
  • No async notifications when agents make progress or get blocked

Section 1: Project Scope & Strategy

1.1 Relationship to Existing Work

Q1: Should we use repos/ai-dev as the foundation for this Slack integration?

  • Yes - Refactor repos/ai-dev to focus on Slack instead of OpenWebUI
  • No - Start fresh in .ai/projects/ai-dev/opencode-slack-integration
  • Hybrid - Reuse components from repos/ai-dev but new project structure
  • Other: _____________

Your notes:

There’s a lot of good work there already which is relevant

Q2: What should we do with the OpenWebUI components already in repos/ai-dev?

  • Remove entirely - not needed for Slack approach
  • Keep as optional secondary interface (dual interface model)
  • Archive for reference but don’t maintain
  • Other: _____________

Your notes:

Leave them for now, don’t change them, we can consider whether they can be useful lateer

1.2 Implementation Scope

Q3: What’s your target timeline for MVP?

  • 1-2 weeks - Basic Slack integration, essential features only
  • 3-4 weeks - Full-featured with polish
  • 2-3 months - Strategic multi-channel architecture
  • Explore first, commit to timeline later

Your notes:

Q4: Is this primarily for your solo use, or team collaboration?

  • Solo only - Just me interacting with AI agents
  • Small team (2-5 people) - Shared projects and agents
  • Larger team - Multiple teams, multiple projects
  • Building for others to use

Your notes:

Definitely solo to start with, could envisage building further if it works for me

Section 2: OpenCode Architecture & Constraints

2.1 Single-Threaded Limitation

Q5: How critical is parallel execution for your workflow?

  • Critical - I regularly need multiple agents working simultaneously
  • Important - Would be nice but can work serially for now
  • Not urgent - Can wait for codev OpenCode support
  • Not needed - Single-threaded is fine

Your notes:

Its not about multi agents working on the same thing, more about completely seperate pieces of work with seperate agents.

Q6: What’s your typical concurrent work pattern?

  • One project, one task at a time
  • One project, multiple parallel tasks
  • Multiple projects, sequential work
  • Multiple projects, parallel work across projects

Your notes:

One task per project in progress usually…

2.2 Session Management

Q7: How long do your OpenCode sessions typically run?

  • Minutes - Quick tasks, complete and move on
  • Hours - Complex features, multi-step implementations
  • Days - Long-running projects with breaks in between
  • Variable - Depends on task complexity

Your notes:

Q8: Do you want persistent OpenCode sessions that survive inactivity?

  • Yes - Session should stay alive for hours/days
  • No - Spawn new session per Slack interaction
  • Hybrid - Session per “work unit” with explicit lifecycle
  • Unsure - Need to explore options

Your notes:

The context needs to span days/weeks potentially, but it’s not a problem if an opencode session is persisted then exits as long as it can be picked up again

Q9: How do you handle context switching between projects currently?

  • Separate tmux windows per project
  • Single OpenCode session, manually switch context
  • Restart OpenCode when switching projects
  • Other: _____________

Your notes:

Section 3: Slack Integration Design

3.1 Slack Workspace & Channels

Q10: How many Slack workspaces will this integrate with?

  • One - My personal/company workspace
  • Multiple - Different clients/contexts
  • Design for multi-workspace from start
  • Start with one, support multiple later

Your notes:

Q11: What’s your preferred channel organization?

  • One channel per project (e.g., #proj-api-service)
  • One channel for all AI dev work (e.g., #ai-dev)
  • Dynamic - Create channels as needed
  • Multiple channels per project (e.g., #proj-dev, #proj-review)
  • Other: _____________

Your notes: Open to suggestions

Q12: How should threading work in Slack?

  • One thread per OpenCode session/task
  • One thread per agent question/blocker
  • All messages in channel (no threading)
  • Hybrid - Status in channel, details in threads
  • Other: _____________

Your notes: One thread per significant unit of work within a project IMHO, happy for this to be appropriately defined.

3.2 Interaction Model

Q13: How do you want to start an AI development task via Slack?

  • Post message in channel: “Implement X feature”
  • Slash command: /opencode implement X feature
  • React to message with emoji to trigger
  • Slack workflow builder button/form
  • Other: _____________

Your notes: I don’t mind too much, a slash command or workflow form would seem sensible

Q14: How should the bot handle agent questions/blockers?

  • Post in thread and wait for my reply
  • Post in thread with interactive buttons (Slack Workflow Builder)
  • Post with emoji reactions for simple choices
  • Direct message me for urgent blockers
  • Other: _____________

Your notes: 1 or 2, would also make sense to include a default option & timeout (ie within 2 business hours) whereby work continues with the best option if no response received.

Q15: What level of progress updates do you want?

  • Every action - Very verbose (e.g., “Created file X”, “Running tests”)
  • Major milestones only (e.g., “Phase complete”, “Tests passing”)
  • Summary every N minutes
  • Only when blocked or task complete
  • Configurable per project

Your notes:

3.3 Code Review Integration

Q16: How should code changes be presented in Slack?

  • Short summary + link to Code Server
  • Inline code snippets for small changes
  • Screenshot/rendered image of diff
  • Link to GitHub/GitLab PR
  • Multiple options depending on change size

Your notes: Ideally it would include a link to a running service - docker compose makes sense for early prototyping, but as its on k8s perhaps a lab namespace per project or similar makes sense?

Q17: How do you want to approve/reject changes?

  • Reply in thread: “approve” or “reject”
  • React with ✅ or ❌ emoji
  • Slack workflow buttons
  • External link to approval UI
  • Other: _____________

Your notes:

Section 4: Technical Architecture

4.1 Deployment Model

Q18: Where should the Slack integration service run?

  • Same K8s pod as OpenCode (sidecar pattern)
  • Separate K8s deployment, same namespace
  • Separate service entirely (different cluster/cloud)
  • Other: _____________

Your notes: As needed based on design

Q19: What’s your preferred Slack integration mode?

  • Webhook Mode - Slack POSTs events to public URL (requires ingress)
  • Socket Mode - Bot connects to Slack WebSocket (works behind firewall)
  • Don’t care - Whatever is easiest
  • Other: _____________

Your notes:

4.2 State Management

Q20: How should we track Slack thread ↔ OpenCode session mapping?

  • In Git (e.g., state.yaml in project)
  • Separate database (Redis, PostgreSQL, etc.)
  • In-memory only (ephemeral)
  • File system on PVC
  • Other: _____________

Your notes:

Q21: Should session state survive service restarts?

  • Yes - Critical for reliability
  • Nice to have - Can tolerate occasional session loss
  • No - Fresh start on restart is fine

Your notes:

4.3 OpenCode Integration

Q22: How should Slack bot communicate with OpenCode CLI?

  • PTY/pseudo-terminal - Pipe Slack messages to OpenCode stdin
  • tmux scripting - Send commands to existing tmux session
  • Spawn new OpenCode process per Slack message
  • Wait for OpenCode automation API
  • Other: _____________

Your notes:

If its based on tmux might that help solve the multi project concurrency issue?

Q23: Should we modify OpenCode or wrap it?

  • Wrapper only - Don’t modify OpenCode itself
  • Contribute to OpenCode - Add Slack integration upstream
  • Fork and customize - Maintain our own version
  • Wait for official support

Your notes:

Section 5: Workarounds & Future Considerations

5.1 Handling Single-Threaded Constraint

Q24: Until codev adds OpenCode support, how should we handle parallelism?

  • Accept limitation - Work on one task at a time
  • Multiple OpenCode instances - One per project/task
  • Queue system - Serialize Slack requests
  • Hybrid - Use codev for parallel work, OpenCode for interactive
  • Other: _____________

Your notes:

5.2 Evolution Path

Q25: What’s the long-term vision for this tool?

  • Personal tool - Solve my immediate pain points
  • Team tool - Expand to my organization
  • Open source - Share with broader community
  • Product - Build for external customers
  • Unsure - Solve current problems first

Your notes:

Q26: What other integrations would you want in the future?

  • Discord (for open source projects)
  • Microsoft Teams (for enterprise)
  • Email notifications
  • Native mobile app
  • Other: _____________

Your notes: None for the moment

Section 6: Open Questions & Concerns

6.1 Your Questions for Us

Q27: What are you most uncertain about regarding this integration?

Your notes: Multi project, whether async/slack is valuable

Q28: What’s the biggest risk or concern you see?

Your notes:

Q29: What success looks like for MVP (minimum viable product)?

Your notes: Working as i do in codev, in slack

6.2 Constraints & Preferences

Q30: Any technical constraints we should know about?

  • Programming language preferences? Python where appropriate but others as needed for native suppport
  • Infrastructure limitations?
  • Security/compliance requirements?
  • Budget constraints?

Your notes:

Q31: Are there examples of similar tools/workflows you’ve seen that we should reference?

Your notes: Codev

Next Steps

Once you’ve annotated this document:

  1. Party Mode Team will synthesize your answers
  2. Winston will propose architecture based on your priorities
  3. John will draft a focused PRD
  4. Sally will sketch key UX flows
  5. Barry/Amelia will outline implementation plan

Please save your annotated version and let us know when ready to continue!

Notes Section (Free-form)

Use this space for any additional context, thoughts, or requirements that don’t fit the questions above:

Graph View