# Sdlc Agents Select > Use when the user needs to pick which SDLC agents to install based on the tools they already use. Filters the full fleet roster against the user's integrations, presents a short opinionated recommendation, and records the selection to .sdlc-agents/selection.yaml. Invoked by sdlc-agents after tool discovery. - Skill: `aws-samples/sdlc-agents-select` (Agent Skill) - Install (CLI): `npx skillmds@latest add aws-samples/sdlc-agents-select` - Raw SKILL.md: https://api.skillmd.com/api/skills/aws-samples/sdlc-agents-select/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: aws-samples (https://skillmd.com/u/aws-samples) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/aws-samples/sdlc-agents-select --- # Select the right agents for this customer ## Prerequisites You should already know (from earlier conversation): - PM tool in use (Asana / Jira / Linear / etc. / none) - Source control (GitHub / GitLab / Bitbucket / etc.) - Chat platform (Slack / Teams / etc. / none) - Optional signals: Salesforce, Datadog/observability, Figma If you don't know these, stop and ask the user. Do not guess. ## The roster Match this table against what the user has. **Hide rows that require a tool the user doesn't use.** Don't present unreachable agents; it's noise. Only agents with `Status: shipping` have working code and can be installed today. The others have design docs under `docs/agents/.md` but no runtime — don't present them to the user even if their tool requirements match. If the user explicitly asks about one, tell them it's planned and point them at `docs/agents/.md`. | Agent | Status | What it does | Hard requirements | Nice-to-have | |---|---|---|---|---| | `workitems` | shipping | PO/PM. Decomposes feature asks into tracker issues; status reports; risk detection. | PM tool **and** source control | Slack for weekly status | | `researcher` | shipping | Business analyst. Research synthesis, competitive intel, backlog analysis. | PM tool | Web search (Tavily, SerpAPI, Perplexity) | | `docwriter` | shipping | Technical writer. API docs, release notes, doc PRs. | Source control | PM tool for feature context | | `adr` | shipping | Tags issues + reviews PRs against the ADRs that govern the work. | Source control **and** an ADR directory that already exists | - | ## ADR agent has a repo-specific check The `adr` agent is useful only when the **target repo** already has an ADR library — it can't tag work against decisions that don't exist. Before including `adr` in any recommendation, confirm the target repo actually has ADRs. **Check the target repo, not the installer cwd.** The top-level flow resolves `TARGET_REPO` as an absolute path before invoking this skill; all filesystem checks here run against that path. If `TARGET_REPO` isn't set, stop and ask the top-level flow to resolve it — don't fall back to `ls` in the current directory, since that will misdetect when the installer and target are different repos. Check the common ADR locations under `TARGET_REPO` (for example `"$TARGET_REPO/adrs"`, `"$TARGET_REPO/ADRs"`, `"$TARGET_REPO/docs/adrs"`, `"$TARGET_REPO/docs/decisions"`, `"$TARGET_REPO/architecture/decisions"`). If one is present and non-empty, report which path you found and ask the user to confirm it's the right one. If none are present, ask the user whether they keep ADRs at a non-standard path before concluding there are none. - **Yes, at one of those paths:** include `adr` in Optional. Record the path in `selection.yaml` under `adr.dir` (relative to the target repo root). - **Yes, at a non-standard path** (e.g. `architecture/decisions/`, `docs/decisions/`): include `adr` in Optional; record the custom path. - **No ADRs yet:** omit `adr` from the presentation entirely. Don't recommend it, don't list it as skipped — the user doesn't need to see it as an option. If they explicitly ask about it, tell them: *"The `adr` agent needs an ADR library in the target repo to link against. Start writing ADRs in `docs/adrs/` there first, then re-run selection."* The agent has no fallback behavior for "no ADRs" — it's not useful without them, so don't ship it half-configured. ## Present to the user 1. Filter the table to agents that are `shipping` **and** whose hard requirements are met. (For `adr`, this includes the ADR-directory check above — don't show it if the repo doesn't have ADRs.) 2. Group into two categories — **Recommended** and **Optional** — and print each with a one-line purpose. The Recommended bucket should be anchored to what tools the user has, e.g.: > Based on your setup (Asana + GitHub + Slack), I recommend starting with: > - **workitems** — drives Asana ↔ GitHub decomposition and weekly status to Slack > - **docwriter** — opens GitHub doc PRs on merged code PRs > - **researcher** — synthesizes customer research into Asana stories > > Optional add-ons that fit your stack: `adr` (if you have an ADR library). 3. Ask the user which to install. Accept three answers: - "just the recommended" → select the Recommended list - an explicit list (space- or comma-separated agent names) - "all" → select Recommended + Optional 4. Before recording, warn on redundant combinations: - `adr` without an ADR directory → won't find anything to link against (the ADR-directory check above should already have removed it) ## Record the selection Write `.sdlc-agents/selection.yaml` at the **target project root** (`$TARGET_REPO/.sdlc-agents/selection.yaml`), not in the installer repo: ```yaml # Generated by sdlc-agents-select. Edit by re-running the skill. selected_at: 2026-04-29T00:00:00Z toolchain: pm: asana # or: jira, linear, trello, aha, none scm: github # or: gitlab, bitbucket chat: slack # or: teams, none support: null # or: salesforce observability: null # or: datadog, cloudwatch, grafana agents: - workitems - docwriter - researcher adr: # only present if `adr` was selected dir: docs/adrs # where the repo's ADRs live aws: account_id: "123456789012" # replace with the target AWS account region: # replace with the target region, e.g. us-west-2 stage: dev ``` If the file exists, read it first, merge, and ask before overwriting any existing keys the user didn't re-confirm. ## What not to do - Don't try to make every customer install the whole fleet. The interesting demo is a focused one. - Don't reorder the Recommended list arbitrarily — keep the ordering by "dependency": `workitems` first (the orchestrator), then `researcher` (feeds workitems), then `docwriter` (fed by workitems). Dependent agents after their producers. - Don't invent agents that aren't in the roster above. If a customer asks for an agent name we don't have (common: "@reviewer", "@qa"), tell them the closest match or flag it as a gap.