/powerup for Teams: Turn a Solo Grind into Onboarding Infrastructure

The individual /powerup guide covered how a single developer earns XP and unlocks badges. That works for solo hackers. At a team, the same feature solves a different problem: how do you get six new hires to the same "I understand Claude Code" baseline without babysitting?

The answer is not "force everyone to type /powerup." It's treating the lesson list as the spine of your onboarding checklist, wiring progress events to Slack and dashboards, and using CI to gate privileges on lesson completion. /powerup becomes the mechanism; your team workflow becomes the beneficiary.

This guide covers the gap between solo and team use, an onboarding pipeline template, five concrete integration patterns, and the pitfalls that make gamification backfire at scale.

Solo /powerup is a self-guided grind: you open a session, run /powerup, complete lessons at your own pace, and the XP accumulates in your local state. Three things break the moment a team tries to scale this:

• Visibility: you cannot tell whether the new hire is actually learning or just clicking through. Progress lives on their laptop only.
• Consistency: without a shared "must-complete" list, each dev skips the lessons most relevant to their gaps, which is exactly the ones they need.
• Integration: lesson completion does not trigger anything — no Slack ping, no CI gate, no Notion checkbox. The value ends at "XP increased."

Solving these three turns /powerup from a feature into infrastructure. The ingredients are the hook system (from the hooks cookbook), the file-based settings in .claude/, and a small amount of glue to your existing team tools.

A concrete 7-day pipeline that uses /powerup as the backbone:

Day 1: Environment Setup

New hire clones the repo. Your .claude/settings.json already has a permissions allowlist, a type-check PreToolUse hook, and a Slack notification hook. First session runs /powerup, unlocking lessons 1-3 (basic session, slash commands, reading a file).

Day 2-3: Core Workflow Fluency

Milestone lessons: CLAUDE.md editing, using @ file attachment, running a multi-step plan. These three complete prove the hire can drive a Claude session without pair-programming.

Day 4-5: Team Conventions

Milestone lessons: following the team permission config, using a custom slash command from .claude/commands/, invoking the /review command before pushing. These tie /powerup to your team's actual workflow, not a generic tutorial.

Day 6-7: Output Check

The hire completes a scoped task with Claude Code, uses /review before their PR, and their progress (via Stop hook) lands in a shared Slack channel. Their manager can tell if they are stuck without asking.

The list of required lessons lives in one place: .claude/onboarding.yml, checked against /powerup status output. When all required lessons are complete, the hire graduates.

The primitive: every /powerup lesson completion goes through Claude Code's state. Surface it to the team via a Stop hook that posts to a webhook.

// .claude/settings.json
{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "sh .claude/hooks/powerup-sync.sh" }
        ]
      }
    ]
  }
}COPY

#!/bin/sh
# .claude/hooks/powerup-sync.sh
status=$(claude /powerup status --json 2>/dev/null || exit 0)
completed=$(echo "$status" | jq -r '.completedLessons | length')
total=$(echo "$status" | jq -r '.totalLessons')
user=$(git config user.name 2>/dev/null || echo "unknown")

# Post to internal dashboard webhook
curl -sS -X POST "$TEAM_DASHBOARD_URL" \
  -H "Content-Type: application/json" \
  -d "{\"user\":\"$user\",\"completed\":$completed,\"total\":$total}" \
  > /dev/null 2>&1 &COPY

The & at the end forks it to the background — Claude's session never waits on the network call. Dashboard side: a 10-line Cloudflare Worker or Vercel function that writes to a KV store, keyed by user.

For a lightweight alternative, point the webhook at a Slack incoming webhook and skip the dashboard entirely. Post a message to #onboarding like "alice: 12/15 lessons (+3 today)."

1. Slack completion ping

PostToolUse hook that watches for /powerup runs and announces completion:

#!/bin/sh
# .claude/hooks/powerup-slack.sh
if [ "$(jq -r '.tool_input.name // empty')" = "powerup" ]; then
  user=$(git config user.name)
  curl -s -X POST "$SLACK_WEBHOOK" \
    -H "Content-Type: application/json" \
    -d "{\"text\":\"🎮 $user just ran /powerup\"}"
fiCOPY

Quick team ambient awareness without surveillance.

2. GitHub Action: gate PR on onboarding

Don't let a new hire merge before core lessons are done:

# .github/workflows/onboarding-gate.yml
on: pull_request
jobs:
  check-onboarding:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check author completed core /powerup lessons
        run: node scripts/check-onboarding.js --author "$" --required claude-md,plan-mode,review-commandCOPY

Require the hire to link their dashboard status (from Recipe above) or store per-user JSON in a dedicated repo the script reads.

3. CI announcement of new team member

When git log finds a first-time committer, check their /powerup progress and post to Slack. Combines naturally with the dashboard.

4. Notion dashboard sync

Nightly cron job reads dashboard KV → updates Notion database. Managers see progress without opening a new tool. Use Notion's API with a service account. 40-line Python script.

5. Pair-up queue

When someone completes lesson 5 (plan mode), auto-add them to the "ready to pair-review" roster. When another dev is stuck, a slash command /find-pair pulls from the roster. Turns /powerup into a team mentoring triage, not just XP.

1. Minimal onboarding.yml

# .claude/onboarding.yml (not read by Claude directly —
# consumed by your check-onboarding.js script)
required_lessons:
  week_1:
    - first-session
    - slash-commands
    - read-file
  week_2:
    - claude-md
    - file-attachment
    - plan-mode
graduation:
  required: 6
  grace_period_days: 14COPY

2. Shared permission template

In .claude/settings.json, provide a team baseline permission set so new hires don't reinvent what's safe:

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git status)", "Bash(git diff)",
              "Edit", "Write", "Read", "Grep", "Glob"],
    "deny":  ["Bash(git push --force*)", "Bash(rm -rf *)", "Bash(sudo *)"]
  }
}COPY

3. Onboarding slash command

.claude/commands/onboarding.md:

---
description: Show what's left on the new-hire checklist
allowed-tools: Bash(claude:*), Read
---

!`claude /powerup status --json | jq -r '.completedLessons[].id'`

Compare the above to .claude/onboarding.yml. List what's missing.COPY

4. Weekly /powerup leaderboard Slack bot

Cron that reads dashboard KV every Monday 9am, posts the completion delta for the week. Keep it celebratory, never shaming.

5. Graduation automation

GitHub Action that, on completing the required lesson set, automatically opens a PR to add the hire to .github/CODEOWNERS. Makes graduation material, not just symbolic.

Gamification can backfire. Three patterns that shred trust if you adopt them:

• Public shaming leaderboards. Showing who is behind publicly punishes the hire your onboarding failed. Keep the leaderboard to self-celebration (deltas, personal bests), not rankings.
• Blocking everything on lesson completion. Using /powerup as a strict CI gate on every PR, not just onboarding PRs, creates learned helplessness. Gate onboarding, not daily work.
• Over-fitting lesson XP to compensation. Tying /powerup completion to reviews or pay turns learning into a checkbox. Keep XP in the intrinsic-motivation zone.

The rule: /powerup is a scaffold for onboarding, not a ranking for ongoing work. Drop the scaffold when the hire doesn't need it.

You have the team scaffolding. Go deeper on the individual pieces:

• The /powerup guide for individuals — the lesson-by-lesson walkthrough your hires will follow.
• /powerup vs /buddy comparison — context on why /powerup replaced /buddy and what that means for gamification philosophy.
• Hooks cookbook — the Stop and PostToolUse patterns that power the integration hooks above.
• .claude/ folder guide — where the team settings and permission templates live.
• /powerup Tracker tool — a quick public progress tracker for individuals; use as a UI reference.

Built a team /powerup pipeline worth sharing? Start from the checker and drop notes in the comments.

Does /powerup have an API for reading progress programmatically?

Yes, via claude /powerup status --json as of Claude Code 2.1.97+. Output includes completedLessons array, totalLessons, xp, and timestamps. Parse with jq in any hook or script.

Can we disable /powerup for existing senior devs who don't need it?

Yes — put "powerup": { "enabled": false } in a senior dev's .claude/settings.local.json. The gamification UI disappears, but they still see /powerup status on demand if they want it.

How do we handle hires who hit a lesson that fails for environment reasons?

The /powerup reset <lesson-id> command clears a specific lesson's completion so they can retry. For flaky lessons, your onboarding pipeline should have an "acknowledged" alternative — a manual sign-off in lieu of automated lesson completion.

Is there a multi-tenant /powerup for agencies or consultancies with many clients?

Not natively. Each ~/.claude/ directory is single-user. For agencies, use per-project .claude/settings.json to define a client-specific lesson pathway via your own scripts, not the built-in XP system. Report with the dashboard approach above.

What about privacy — is our lesson completion data being sent to Anthropic?

/powerup state is local-only by default. Your Stop hook pushing progress to your own webhook is opt-in and under your control. Anthropic does not collect /powerup telemetry per their published privacy policy. Verify with claude --verbose during a /powerup run to confirm no external calls you didn't configure.