setup-team

Files (1)

• SKILL.md

SKILL.md (first lines)

# SDLC Team Setup

Configure the right agent team for this project by selecting an SDLC method, a project type, and installing the matching team plugins.

## Steps

0. **Pre-check: inventory what's already installed**

   Before making any recommendations, check what plugins, agents, and skills are already available — both globally and for this project.

   **0a. Check installed plugins:**
   - Read `~/.claude/settings.json` → `enabledPlugins` field (global installs)
   - Read `.claude/settings.json` (project-level) → `enabledPlugins` field (if it exists)
   - Merge both lists. For each `sdlc-*@ai-first-sdlc` entry: record as installed.
   - Also check for `sdlc-knowledge-base@ai-first-sdlc`, `sdlc-programme@ai-first-sdlc`, and `sdlc-assured@ai-first-sdlc` specifically — these may be relevant to the SDLC method question in step 3.

   **0b. Check available agents:**
   - Glob `.claude/agents/**/*.md` (project-level agents)
   - Note which come from installed plugins vs which are project-local

   **0c. Check available skills:**
   - List currently registered skills (the set Claude Code can see)

   **0d. Present the pre-check results** to the user before any recommendations:

   ```
   Current state:

   Installed SDLC plugins:
     ✓ sdlc-core@ai-first-sdlc (global)
     ✓ sdlc-team-common@ai-first-sdlc (global)
     ✗ sdlc-team-fullstack@ai-first-sdlc
     ✗ sdlc-lang-python@ai-first-sdlc
     ✗ sdlc-knowledge-base@ai-first-sdlc
     ✗ sdlc-programme@ai-first-sdlc
     ✗ sdlc-assured@ai-first-sdlc

   Available agents: N (from installed plugins)
   Available skills: M

   I'll only recommend what you don't already have.
   ```

   **0e. Record the pre-check state** for use in later steps — the recommendation output (step 8) will mark already-installed plugins with `✓ (already installed)` instead of install commands, and the install command list (step 9) will exclude them.

1. **Check current team configuration**

Look for `.sdlc/team-config.json` in the project root (or `.claude/team-config.json` as a fallback). If it exists, display the current formation **and the recorded `sdlc_method`** (if present) and ask if the user wants to reconfigure.

2. **Ask the user what kind of project this is** (present as multiple choice):

   - **A. Full-stack web application** — frontend + backend + API + DevOps
   - **B. AI/ML system** — AI architects + prompt engineers + RAG designers
   - **C. Cloud infrastructure** — cloud + containers + SRE + observability
   - **D. API/microservices** — API + backend + integration + performance
   - **E. Security-focused** — security + compliance + privacy
   - **G. iOS app** — Apple HIG design + cross-platform mobile architecture & interaction UX
   - **H. Android app** — Material Design 3 + cross-platform mobile architecture & interaction UX
   - **I. Cross-platform mobile** — both iOS and Android design + shared mobile base
   - **F. Custom** — pick individual team plugins

3. **Ask about SDLC method (delivery structure)**

   The framework supports **four SDLC delivery structures**. This question is **orthogonal** to step 2 — step 2 picks team plugins (what kind of system); step 3 picks the SDLC method bundle (what kind of delivery discipline). A regulated medical-device system could be cloud-infrastructure (project type C) AND assured (SDLC method D); an AI/ML prototype could be project type B AND solo (SDLC method B).

   Present as multiple choice:

   - **A. Single-team (default)** — 3–10 contributors, organic delivery, no formal phase gates. Use the base SDLC (`/sdlc-core:new-feature` workflow) with team plugins from step 2. Most projects pick this.
   - **B. Solo** — 1–2 contributors, fast iteration, lightweight constitution overlay. Use the base SDLC with `/sdlc-core:commission --option solo`.
   - **C. Programme (Method 1)** — 11–50 contributors across 2–5 teams, formal phase gates (requirements → design → test → code) with mandatory cross-phase review. Adds the `sdlc-programme` bundle.
   - **D. Assured (Method 2)** — regulated industries (DO-178C, IEC 62304, ISO 26262, FDA 21 CFR Part 820). Bidirectional traceability, positional namespace IDs, DDD decomposition, typed evidence statuses, standard-specific exports. Adds the `sdlc-assured` bundle (v0.2.0 audit-ready at the tooling layer).
   - **E. Decide later** — proceed with single-team default; user can run `/sdlc-core:commission` at any time to switch.

   Default to **A** if the user presses Enter without selecting.

   **Map the answer:**

   | Selection | `sdlc_method` value | Bundle plugin to recommend | Post-install commission command |
   |-----------|---------------------|---------------------------|--------------------------------|
   | A. Single-team | `single-team` | (none — sdlc-core is sufficient) | (none — default behaviour) |
   | B. Solo | `solo` | (none — sdlc-core is sufficient) | `/sdlc-core:commission --option solo` |
   | C. Programme | `programme` | `sdlc-programme@ai-first-sdlc` | `/sdlc-core:commission --option programme --level production` (or `/sdlc-programme:commission-programme`) |
   | D. Assured | `assured` | `sdlc-assured@ai-first-sdlc` | `/sdlc-core:commission --option assured --level production` (or `/sdlc-assured:commission-assured`) |
   | E. Decide later | `undecided` | (none — defer) | (none — user runs `/sdlc-core:commission` later) |

   **What to record:**

   - Add `sdlc_method` to the team-config.json fields written in step 11 (e.g., `"sdlc_method": "assured"`).
   - For C / D: add the bundle plugin to the install recommendation list shown in step 8. If the bundle appears in the pre-check (step 0) list as already installed, mark it `✓ (already installed)` and skip re-recommending — but **do** surface the post-install commission command in the recommendation output, since commissioning is a separate step from plugin install.
   - For B / C / D: add a **"Post-install action"** line in the step 8 recommendation output advising the user to run the appropriate `/sdlc-core:commission` command after the plugin is installed (or, for B, even if no extra plugin is installed). Without this surfacing, the bundle would ship installed but uncommissioned, and the user would get validation errors with no clear diagnosis path.
   - For E: record `"sdlc_method": "undecided"` so the post-check (step 13) can surface a one-line reminder that commissioning is still pending.

   **If unsure, point to `docs/METHODS-GUIDE.md`** for a fuller decision tree, comparison table, trade-offs, and migration notes between methods.

4. **Map step 2 selection to recommended team plugins:**

   | Selection | Plugins |
   |-----------|---------|
   | A. Full-stack | `sdlc-team-common`, `sdlc-team-fullstack` |
   | B. AI/ML | `sdlc-team-common`, `sdlc-team-ai`, `sdlc-lang-python` |
   | C. Cloud | `sdlc-team-common`, `sdlc-team-cloud` |
   | D. API | `sdlc-team-common`, `sdlc-team-fullstack`, `sdlc-team-cloud` |
   | E. Security | `sdlc-team-common`, `sdlc-team-security` |
   | G. iOS app | `sdlc-team-common`, `sdlc-team-ios`, `sdlc-team-mobile`, `sdlc-lang-swift` |
   | H. Android app | `sdlc-team-common`, `sdlc-team-android`, `sdlc-team-mobile`, `sdlc-lang-kotlin` |
   | I. Cross-platform mobile | `sdlc-team-common`, `sdlc-team-ios`, `sdlc-team-android`, `sdlc-team-mobile`, `sdlc-lang-swift`, `sdlc-lang-kotlin` |
   | F. Custom | `sdlc-team-common` (pre-selected) + user picks additional team plugins |

   **Mobile plugins pair with the shared base.** `sdlc-team-ios` (Apple HIG) and `sdlc-team-android` (Material Design 3) each carry only their platform's design specialist; the cross-platform agents (`mobile-architect`, `mobile-ux-architect`) live once in `sdlc-team-mobile`. Always recommend the platform plugin **and** `sdlc-team-mobile` together — the marketplace has no hard dependency resolution, so this recommendation is the pairing mechanism. A cross-platform team installs both platform plugins + the single shared base (agents are never duplicated).

   **`sdlc-team-common` is a near-universal default.** It contains the research-and-agent-creation pipeline (`pipeline-orchestrator`, `deep-research-agent`, `agent-builder`, `repo-knowledge-distiller`) plus cross-cutting specialists (`solution-architect`, `database-architect`, `performance-engineer`, `observability-specialist`). Every project type above includes it because:

   - Discovery during setup relies on `pipeline-orchestrator` for the research → synthesis → agent-builder workflow
   - Any Section C coverage gap identified during discovery requires these agents to act on
   - Cross-cutting architecture decisions benefit from `solution-architect` regardless of project type

   For option F (Custom), `sdlc-team-common` is pre-selected. If the user wants to deselect it, present this warning:

   > ⚠️ You are deselecting `sdlc-team-common`. This plugin provides the agents required for custom agent creation (`pipeline-orchestrator`, `deep-research-agent`, `agent-builder`). Without it:

From SteveGJones/ai-first-sdlc-practices, MIT.

More from SteveGJones/ai-first-sdlc-practices