/create-team — create the shared team-brain (leader)

This is the leader's half of a two-command flow. /join-team is the member's half, and the flow is only done when both have run — a seeded team-brain nobody has joined is a private repo with some folders in it.

Before you start

node "${CLAUDE_PLUGIN_ROOT}/tools/cortex-preflight.mjs"

A team-brain is pushed, so the profile line matters more here than anywhere else: lab seals outward sync entirely and this ritual has nothing to do on it. On home or work, the profile also tells you which world's material may land in the shared repo — see /set-profile if the answer is not obvious for this machine. On work, the team-brain remote must be on the company's approved list or nothing is cloned or pushed; check it first with node "${CLAUDE_PLUGIN_ROOT}/tools/cortex-destinations.mjs" check git <git-url>.

What to do

1. Ensure a private team-brain git repo exists (create it via gh repo create <org>/<team>-brain --private if the user hasn't) and get its URL.

2. With CORTEX_ROOT set to your vault — the seeded clone lives under it — run node "${CLAUDE_PLUGIN_ROOT}/mcp/ai-os.js" team init --name <team> --repo <git-url> --projects <slug1,slug2>. From a clone of the Cortex repo rather than the plugin, use that clone's path. If the organisation runs Cortex from its own fork, add --source <owner/repo|git-url>. It is written to team.json in the brain, and every /join-team copies it into that repo's connector, so /setup-repo stamps the fork there with no flag from members. A URL carrying a token is refused. Ask which trackers the team plans in, as one checkbox list, before running the command:

   Connect this team-brain to:
     [ ] GitHub issues      (in the owning repo of each ask)
     [ ] ServiceNow Agile   (instance URL, table, group per role)
     [ ] Jira               (site, project, issue type)
     [ ] none: asks stay in the brain only

   Pass the answer as --integrations github,servicenow,jira (or none), with each tracker's flags: --servicenow-instance <url> [--servicenow-table rm_story] [--servicenow-groups role=group,…], --jira-site <url> --jira-project <KEY> [--jira-issue-type Task], and for GitHub nothing, or --github-repo <owner/name> for asks whose project names no GitHub repo. --primary <kind> picks whose status wins; the default is the agile tracker. Never put a credential in a flag: the command prints the environment variable each tracker reads. It also prints the scheduled sync workflow; add --write-sync-workflow only once the user has read it and said yes.

3. Confirm the team-brain was seeded and pushed. --projects seeds a notes folder per slug, projects/<slug>/, and nothing else: it writes no project file, and team.md points at projects/ and lists no project.
4. Hand off. Give members the repo URL and the exact /join-team invocation they run inside each product repo — the command, not a description of it. A leader who shares only the URL leaves every member to rediscover the joining step, which is how a team-brain ends up with one contributor. Say that /join-team is also what registers a project: it writes projects/<slug>.md with the repo's address and links. Until someone runs it in a repo, that project is a notes folder the workspace lists as unregistered. /join-team also asks each member for their roles and their job and writes them to team.json; an ask to a role reaches whoever holds it there, so add yourself the same way, with your job: node "${CLAUDE_PLUGIN_ROOT}/mcp/ai-os.js" team member --team <team> --roles <role,role> --job lead. A job is one of developer, architect, lead, pm and qa. It changes what the rituals offer each person first, never what they may run. A member who works outside the repos, such as a project manager in Claude Desktop, installs their job's role pack rather than the plugin: each Cortex release attaches one zip per job, and node "${CLAUDE_PLUGIN_ROOT}/tools/cortex-pack.mjs" <job> --out <dir> builds the same.

Don't

• Don't put personal/machine paths anywhere — the team-brain holds only shared knowledge.
• Don't touch any product repo here. Wiring a product repo is /join-team's job, run by the person who owns that checkout.

Once members have joined, /whats-changed is what reads the team-brain's history back out. The authoring standard for anything you seed into it is /write-agent-docs.