AmplifierSkills and tools for thoughtful work

Tool

Team Access

See who has access. Apply the roster you intended.

For GitHub repository maintainers. Team Access compares a YAML roster with collaborators and invitations, shows permission drift and applies the changes you authorize through the stable addteam command.

Use Team AccessWatch the 72-second filmWalk through an example
What you getFictional illustration
Roster review
Additions: people listed in the roster but absent from access
Permission drift: existing collaborators with a different role
Removals: considered only by explicit sync mode

First command: addteam --help
Read-only choices: audit or dry-run
Apply: only the reviewed and authorized target set

Fictional access review. No real usernames, invitations or permission changes are represented.

Keep one readable roster

Use named role groups in team.yaml rather than remembering individual invitations and permission settings.

Review drift before changing access

Audit or dry-run additions, permission changes and removals before an apply operation.

Use it across repositories

Reuse a central roster or inspect several repositories while keeping the target repository explicit.

The film

Look before you sync.

In 72 seconds, Tansy the squirrel hands a key to whoever knocks, and months later nobody knows who still holds one. Team Access keeps one roster file of who gets in and how far. An audit compares it with real access and changes nothing, a dry run lists every change first, removals wait for sync mode, a typo gets a warning, and a circuit breaker stops a sync from removing half the team at once. Captions are on the player; a transcript is below.

Download the film 15-second cut Captions
Read the transcript

Meet Tansy. Tansy hands out the keys to your team’s code.

Whoever knocks gets one: a contractor, a new hire, a reviewer who only reads.

Months later, nobody knows who still holds a key.

Team Access keeps one roster: a short file of who gets in, and how far.

An audit compares the roster with real access, and changes nothing.

A dry run lists every change first. Removals wait for sync mode, which asks.

A typo gets a warning, and sync won’t remove half the team at once.

Its tests used stand-ins. No real invites went out. Applying is your call.

On screen: Look before you sync.

Team Access. See who has access. Apply the roster you intended.

The team, its handles and the repository are a fictional example. The film shows how the tool behaves; it does not report results.

See the work take shape.

Fictional access review. No real usernames, invitations or permission changes are represented.

Install and select the target

Use an authenticated GitHub CLI and select the repository that the roster applies to.

Fictional example

Fictional roster review

The brief Use Team Access to explain a fictional team.yaml and prepare a dry-run access review for an explicitly selected repository. Separate additions, permission changes and removals. Keep welcome issues and AI summaries off. Do not invite, remove or change anyone’s access.

Before

A sync could treat omitted members as removal candidates.

After applying the method

Warnings and incomplete-resolution gates make the roster problem reviewable before mutation.

The declared roster and the proposed changes must both be inspectable.

A clear job.
A useful stopping point.

Audit, preview or apply GitHub collaborator changes from a roster.

Use it when

  • A repository’s collaborator list has drifted from the team roster.
  • You want a repeatable access audit in CI or across repositories.
  • Several repositories share a central team configuration.

Choose another route when

  • Inferring permission to invite or remove people from installing the tool.
  • Treating a mocked test as a live permission-change result.

Audit

The owner needs to inspect access drift.

Current-vs-declared access findings.

Preview

A roster change is being reviewed.

A dry-run of invitations, permission changes and removals.

Apply

The exact access change is authorized.

Actual GitHub operations with circuit-breaker and incomplete-roster checks.

Read the canonical method

Use the native tool and its documented command interface.

Limits and prerequisites
  • Native addteam remains the executable and import namespace; no coaching skill or hidden invitation automation is introduced.
  • Audit/dry-run may read GitHub; tests use mocks and do not invite users, accept invitations, change permissions or send welcome issues.
  • A removal circuit breaker is an operational limit; it does not itself authorize any access change.

Your first useful run.

Read the command help and preview a roster against one explicitly selected repository.

This is a native tool or library. Install its package in an isolated environment, then use the documented command or protocol.

Source on GitHub

Start from the public source

git clone https://github.com/michaeljabbour/amplifier-tool-team-access.git
cd amplifier-tool-team-access
python3 -m venv .venv
.venv/bin/python -m pip install .
.venv/bin/addteam --help

Use the native package and command interface described in the installation guide. This capability does not require a portable skill.

  • The native package and command remain addteam.
  • GitHub CLI must be installed and authenticated with access to the selected repository.
  • Start with --help, then audit or dry-run. Applying or syncing changes is a separate consequential action.
  • The shown virtual-environment commands use macOS/Linux paths; on Windows, use the corresponding .venv\Scripts executables.

Try this with your agent

Use Team Access to explain a fictional team.yaml and prepare a dry-run access review for an explicitly selected repository. Separate additions, permission changes and removals. Keep welcome issues and AI summaries off. Do not invite, remove or change anyone’s access.

Use after installing the documented native package. Read its help, supply an explicit task and inspect the result.

Keep the guide nearby

Read the guide · License · Changes · Release metadata · CONSOLIDATION

Know what you can rely on.

Native mocked tests, roster parsing and a clean-wheel entry-point check passed. No real invitations, permission mutations or welcome messages were performed for the release checks.

Read the checks and their scope
  • Native functional baseline — passed

    287 native mocked tests and 2 roster parsing checks passed; no GitHub invitation or permission mutation.

  • Source-specific acceptance — passed

    287 native mocked tests and 2 roster parsing checks passed; no GitHub invitation or permission mutation.

  • Live execution acceptance — not-run

    No paid model call, real invitation, permission mutation, browser recording or film render was performed.

  • Clean wheel installation — passed

    All three wheels installed in a fresh Python 3.12 environment. Team Access help and TeaserKit no-AI storyboard validation passed; Imagen installed stdio smoke is recorded separately.

Source and conformance checks are separate from demonstrated benefit. Comparative effectiveness and outside-user outcomes are not established by this site.

Fictional examples explain the capability. Tests check the stated behavior. Outside-user outcomes need their own evidence.