Setting Up Team Workflows with Tactic Remote

Tactic Remote was designed for individual developers, but increasingly, teams are adopting it. This guide covers how to set up Tactic Remote for a development team, including shared infrastructure, access management, and workflow conventions that keep everyone productive without stepping on each other's toes.

Architecture for Teams

Individual developers run Tactic Remote on their personal Mac. Teams have more options:

Option A: Personal Mac, Individual Setup

Each developer runs the Tactic Remote companion app on their own Mac and connects from their own iPhone. This is the simplest setup and preserves complete isolation between team members.

Best for: Small teams (2-5 developers) where everyone has a capable Mac and primarily works on different parts of the codebase.

Pros: Zero shared infrastructure, complete privacy, no coordination overhead. Cons: No shared session visibility, each developer manages their own setup.

Option B: Shared Development Server

A dedicated Mac (Mac Mini, Mac Studio, or Mac Pro) runs the Tactic Remote companion app with multiple user accounts. Each developer connects to their own user account on the shared machine.

Best for: Teams of 5-15 developers who want centralized infrastructure without sharing sessions.

How to set up:

1. Create a macOS user account for each developer on the shared Mac.
2. Install Claude Code and tmux in each user account.
3. Run the Tactic Remote companion app per-user (each gets a unique port).
4. Configure Cloudflare Tunnel with subdomain-per-developer routing.

developer1.team.example.com → localhost:3001 (Developer 1's companion app)
developer2.team.example.com → localhost:3002 (Developer 2's companion app)
developer3.team.example.com → localhost:3003 (Developer 3's companion app)

Each developer connects from their iPhone using their personal subdomain. Sessions are isolated between developers, but the infrastructure is centralized.

Pros: Centralized management, consistent environment, developers don't need powerful personal Macs. Cons: Shared machine resource contention, single point of failure.

Option C: Hybrid Setup

Senior developers and leads use the shared server (for consistency and team visibility), while individual contributors use personal Macs. This balances flexibility with coordination.

Team Conventions

Technical setup is the easy part. Team conventions are what make collaborative use of AI coding tools actually work.

Convention 1: Session Naming Standard

Adopt a consistent session naming format. We recommend:

{developer-initials}-{project}-{focus}

Examples:

• jk-api-auth-module
• ms-frontend-dashboard-redesign
• tc-infra-ci-pipeline

This makes it immediately clear who owns each session and what it's working on. On shared servers, it prevents confusion when multiple developers' sessions are visible.

Convention 2: Branch-Per-Session

Each Claude Code session should work on a dedicated Git branch:

ai/{developer}/{description}

Examples:

• ai/jkim/add-user-auth
• ai/msmith/refactor-payment-flow

This convention:

• Prevents merge conflicts between concurrent AI sessions
• Makes code review straightforward (one PR per AI session)
• Clearly identifies AI-generated changes in Git history
• Allows easy rollback if an AI session produces poor results

Convention 3: Approval Escalation

Not all approval decisions should be made by a single developer. Define team-level approval categories:

Self-approve (individual developer):

• File reads and writes within the session's project scope
• Running tests
• Installing dev dependencies
• Formatting and linting fixes

Peer-approve (notify a teammate):

• Database schema changes
• API contract changes (endpoint signatures, response formats)
• Security-sensitive code modifications
• Changes to shared configuration files

Lead-approve (require team lead sign-off):

• Production deployment commands
• Infrastructure changes
• Dependency major version upgrades
• Changes to authentication or authorization logic

Implementing this requires discipline rather than tooling (Tactic Remote doesn't yet enforce team approval policies), but establishing the convention early prevents costly mistakes.

Convention 4: Daily AI Standup

Add a brief AI-focused segment to your daily standup:

• What AI tasks completed overnight or during the morning?
• What AI tasks are currently running?
• Are there any approval requests that need team discussion?
• Did any AI-generated code need significant manual correction?

This keeps the team aware of AI activity and catches quality issues early. It also helps the team learn which types of tasks AI handles well and which still need human implementation.

Shared Prompt Library

Create a team-level prompt library in your repository:

.claude-prompts/
├── code-review.md       # Standard code review prompt
├── test-coverage.md     # Test coverage analysis prompt
├── security-audit.md    # Security review prompt
├── pre-deploy.md        # Pre-deployment checklist
├── dependency-update.md # Dependency update procedure
└── new-feature.md       # Feature implementation template

Each file contains a proven prompt that the team has refined through usage. Example code-review.md:

Review the diff for this branch against main. Evaluate:
 
1. Correctness: Does the code do what it claims?
2. Edge cases: What inputs or conditions could cause failure?
3. Security: Are there injection, auth, or data exposure risks?
4. Performance: Any O(n²) patterns, missing indexes, or memory leaks?
5. Maintainability: Would a new team member understand this code?
 
For each issue found, provide:
 
- Severity (critical / warning / suggestion)
- File and line reference
- Explanation of the problem
- Suggested fix
 
If the code looks good, say so — don't invent issues.

Team members reference these prompts from Tactic Remote:

Follow the code-review prompt in .claude-prompts/code-review.md
for the current branch.

This ensures consistent quality standards regardless of which developer is directing the AI.

Monitoring Team Activity

On a shared server, the Mac companion app's status panel shows all active sessions across all developers. The team lead can monitor:

• How many AI sessions are running concurrently
• Resource utilization (CPU, memory) across sessions
• Session durations and activity patterns
• Approval response times

This visibility helps identify when the shared server needs upgrading, when a developer might need help (a session stuck awaiting approval for hours), or when team conventions aren't being followed.

Security for Teams

Team usage amplifies security considerations:

API key management: Each developer should have a unique API key. Shared keys make it impossible to audit who did what. Store team API keys in a password manager with access controls.

Session isolation: On shared servers, verify that developers cannot access each other's tmux sessions. macOS user account separation provides this, but verify with testing.

Code access scope: Ensure each developer's Claude Code session has access only to repositories they're authorized to work on. Use macOS file permissions and Git SSH key separation.

Offboarding: When a developer leaves the team, revoke their API key, terminate their sessions, and remove their user account from the shared server. Document this in your offboarding checklist.

Getting Started with Team Adoption

We recommend a phased approach:

1. Week 1: Two developers set up individual Tactic Remote instances and use them for one sprint.
2. Week 2: Share learnings, establish naming conventions and prompt library.
3. Week 3: Expand to the full team with documented conventions.
4. Week 4: Evaluate — what's working, what needs adjustment?

Start small, learn fast, and scale deliberately. Tactic Remote is a powerful team tool, but its effectiveness depends on the conventions around it as much as the technology itself.

For individual setup, see Getting Started. For connection options, see Local Network and Cloudflare Tunnel.