Setting Up a Team

AIWG is connected to the target project and your provider session can read the deployed context.

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 connected to the target project and your provider session can read the deployed context.

Different people on your team use different AI tools. One person uses Claude Code, another uses Cursor, another uses GitHub Copilot. AIWG gives the project a shared context and provider-specific files so each tool starts from the same repo facts and conventions.

The useful team outcome is a committed `.aiwg/` context plus provider files that each teammate can verify from their own tool.

How it works

Run Install, Connect, and Verify from the project root for the first provider. Repeat the deployment step for each provider the team uses. AIWG writes provider-specific files such as:

.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

Commit the generated provider files and `.aiwg/` artifacts that your team has reviewed. Teammates can then verify the handoff from their own provider session.

Setup For Multiple Providers

Use AIWG to complete this documented outcome: Setup For Multiple Providers
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 reviewed project context and provider files.

What each teammate needs

Each person installs their own AI platform. They can start from the committed provider files, then ask the agent to verify that the current session has read the project context.

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 each teammate's AI session can read the same project context after its provider handoff succeeds. A new engineer joining the team can open their AI tool in the project and ask:

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

The answer should cite `.aiwg/` artifacts or repository files so the teammate can see which context was used.

Team-level conventions

AIWG rules are shared conventions. When you define a rule such as "avoid raw SQL", "include error handling in API endpoints", or "require tests for new functions", commit it with the provider files that should receive it.

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 the appropriate provider rules directory and commit it. Each teammate should verify the rule is loaded in their own provider session.

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 in that platform

Then have them run the verification ask from Provider Handoff before depending on the context.

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.

Success means each subteam can verify its provider files, project context, and first useful output from its own directory.