Setting Up a Team

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

First time using AIWG? Begin with Install, Connect, and Verify. This guide assumes AIWG is installed and the agent-owned use operation has completed for your provider.

Different people on your team use different AI tools. One person uses Claude Code, another uses Cursor, another uses GitHub Copilot. Without AIWG, they all have different agents, different rules, different commands — and no shared context.

AIWG deploys the same framework to every platform so the whole team works from the same foundation.

How it works

You run the agent-owned use operation from the project root for each provider the team uses. AIWG writes the complete system into platform-specific directories:

.claude/agents/          ← Claude Code picks this up
.cursor/agents/          ← Cursor picks this up
.github/agents/          ← Copilot picks this up
.factory/droids/         ← Factory AI picks this up

Every teammate gets the same agents, the same rules, the same commands — regardless of which AI tool they use. You commit the directories and they propagate through git.

Setup (one person does this)

Use AIWG to complete this documented outcome: Setup (one person does this)
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Each the agent-owned use operation invocation builds the shared capability index, connects that provider to the project context, and verifies the deployment before returning.

Then commit the results:

git add .claude/ .cursor/ .github/ .factory/ .aiwg/
git commit -m "feat: deploy AIWG framework to project"
git push

Everyone who pulls gets the framework automatically.

What each teammate needs

Each person installs their own AI platform (Claude Code, Cursor, etc.). They don't need to install AIWG themselves — the framework files are already in the repo via git.

If they want to use the `aiwg` CLI for other tasks (deploying updates, adding agents, running the daemon), they install it individually:

Use AIWG to complete this documented outcome: If they want to use the aiwg CLI for other tasks (deploying updates, adding agents, running the daemon), they install it individually
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Keeping everyone in sync

When AIWG releases updates or you add new agents and commands:

Use AIWG to complete this documented outcome: When AIWG releases updates or you add new agents and commands
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

This pulls the latest framework and re-deploys to all providers. Commit and push, and everyone gets the update with the next `git pull`.

the agent-owned sync operation is the deprecated alias and still works, but emits a warning and is scheduled for removal after the 2026.5.x stable line.

Shared project context

The `.aiwg/` directory contains your project's artifacts — requirements, architecture decisions, test strategies. Commit it:

git add .aiwg/
git commit -m "docs: add project artifacts"

Now every teammate's AI session has the same project context. No one has to re-explain the architecture. A new engineer joining the team can open Claude Code and ask:

Explain this project to me as if I just joined the team

The AI already knows the answer.

Team-level conventions

AIWG rules are shared conventions. When you define a rule — "never use raw SQL", "always include error handling in API endpoints", "require tests for new functions" — it applies to everyone's AI session.

To add a project-level rule:

Use AIWG to complete this documented outcome: To add a project-level rule
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Or edit `.claude/rules/` directly and commit. The rule applies to everyone on `git pull`.

Onboarding new engineers

When someone new joins the team:

1. They clone the repo 2. They install their AI platform (Claude Code, Cursor, etc.) 3. They open the project

AIWG is already there. The project context is already there. They can start asking the AI questions about the codebase immediately.

To give them a structured onboarding walkthrough:

/flow-team-onboarding <name> the role option <role>

This runs an orchestrated workflow that introduces the codebase, key decisions, and current state.

If your team uses GitHub Actions or CI

You can run AIWG audits as part of CI — security gates, test coverage checks, quality gates before merge:

# .github/workflows/quality.yml
- name: Security gate
  run: the agent-owned security-gate operation

See the security gate reference for configuration.

Multiple frameworks for different teams

Large orgs often have subteams with different needs — frontend, backend, DevOps, marketing. You can deploy different frameworks to different directories or branches:

Use AIWG to complete this documented outcome: Large orgs often have subteams with different needs — frontend, backend, DevOps, marketing. You can deploy different frameworks to different directories or branches
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Each team gets the agents and commands that match their work.