/scaffold-doctor

name: scaffold-doctor
description: >
  Scaffolds a complete scheduled "doctor" agent directly into the user's repo.
  The doctor audits app health on a recurring schedule, routes code-fixable
  findings to an automated repair pipeline that opens pull requests, and files
  deduped tracker tickets for everything else. A Slack (or equivalent) digest
  posts after every run, even if remediation fails. Use when a team wants to
  deploy an autonomous health-auditing agent alongside their application without
  copying a pre-built engine — the skill generates the engine in the user's
  chosen stack by following the bundled reference docs.

scaffold-doctor

Generates a production-ready "doctor" agent inside the target repo by following the pattern described in [`references/architecture.md`](references/architecture.md). **Read that file first** — it defines the module table, data flow diagram, three run modes, and the error-isolation invariant that all generated code must preserve.

---

Interactive Flow

Ask questions **one at a time**, in the order listed below. Use multiple choice wherever possible. Stack questions come first because they determine which modules get generated and which swap-table rows apply.

---

Q1 — Stack

Ask each sub-question on its own turn.

**1a. Language / runtime**

1) TypeScript (default)
2) Python
3) Other — describe

**1b. LLM provider**

1) Amazon Bedrock (default)
2) Anthropic API direct

**1c. Scheduler**

1) AWS EventBridge + Lambda (default)
2) GitHub Actions
3) POSIX cron / systemd timer
4) Kubernetes CronJob

**1d. VCS**

1) GitHub (default)
2) GitLab

**1e. Tracker**

1) Linear (default)
2) Jira
3) GitHub Issues

**1f. Chat**

1) Slack (default)
2) Microsoft Teams
3) Discord

For any non-default choice, note which swap-table row applies (see [`references/swap-table.md`](references/swap-table.md)) — generation will follow that row exactly.

---

Q2 — Product name

> What is your application's name? (Used as the doctor's identity in the system > prompt, e.g. "Acme Doctor".)

Free text. Store as `PRODUCT_NAME`.

---

Q3 — Target repo

> What is the owner/name of the GitHub (or GitLab) repo the doctor will read > from and open PRs against? (e.g. `acme-corp/backend`)

Free text. Store as `REPO_SLUG`.

---

Q4 — Log source

> Which log groups should the doctor scan? List ARNs or names, one per line. > Press enter twice when done. (Default: CloudWatch Logs; describe a different > source if applicable.)

Collect as `LOG_GROUPS[]`. Default lookback: 60 minutes.

---

Q5 — Data source for audits

> Which query tool should runbooks use?

1) AWS Athena (default)
2) Generic SQL (Postgres, MySQL, BigQuery…) — specify driver
3) Prometheus
4) None — runbooks use only log/metric/VCS tools

Store as `DATA_SOURCE`. For non-default choices, generation follows the matching swap-table row in [`references/swap-table.md`](references/swap-table.md).

---

Q6 — Model and region

> Primary model ID and AWS region (Bedrock) or plain model string (Anthropic > API)? > > Defaults: `us.anthropic.claude-sonnet-4-6`, `us-east-1`. Press enter to > accept.

Store as `MODEL_ID` and `AWS_REGION`. Fallback model defaults to `us.anthropic.claude-haiku-3-5` (Bedrock) or `claude-haiku-3-5` (Anthropic API).

---

Q7 — Budgets

Present defaults; user may override any or all.

| Parameter | Default | |---|---| | `maxPrsPerRun` | 3 | | `maxTicketsPerRun` | 5 | | `maxIterations` (per runbook) | 15 | | `maxTokensPerCall` | 4096 | | `patchCandidates` | 3 | | `maxRepairAttempts` (per CI PR) | 3 |

---

Q8 — Runbook schedule assignment

> The example runbook `scan-logs` will be registered as a **daily** runbook. > Do you have additional runbooks to schedule now? (You can add more later with > `add-doctor-runbook`.)

1) No, start with scan-logs only (default)
2) Yes — list names and daily/weekly for each

Collect `DAILY_RUNBOOKS[]` (starts with `["scan-logs"]`) and `WEEKLY_RUNBOOKS[]` (starts empty).

---

Generation Directive

Once all answers are collected, generate the doctor engine by following the reference docs below. **Do not restate their content** — implement exactly what they specify.

Module list and file tree

Follow [`references/architecture.md`](references/architecture.md) — Module Responsibilities table and Default-Stack File Tree. Generate every listed module. For non-default stack choices, apply the relevant rows from [`references/swap-table.md`](references/swap-table.md) before generating.

`run-skill` and `prompts/system`

Follow [`references/agentic-loop.md`](references/agentic-loop.md) completely.

**Port these two reference snippets verbatim** (translated to the target language/stack):

• **Model fallback** (§5): the `createMessage` wrapper that retries once on

the fallback model before propagating.

• **Anti-loop guard** (§4): the `lastCalls` tail-check that injects a nudge

text block when the same tool fires three times in a row.

The system prompt must follow the four-section structure in §8 exactly:

1. Identity block — `You are {PRODUCT_NAME} Doctor, an automated auditor for the {PRODUCT_NAME} platform.` 2. Core behavioral contract (static prose as specified). 3. Known gotchas (empty placeholder — keep the heading). 4. Runtime context block + runbook content appended at run time.

The runbook section must always be separated by `---` and the heading `## Skill to execute` — **do not rename this heading**; the control tools depend on it.

`repair-pipeline` and `repair-ci`

Follow [`references/repair-pipeline.md`](references/repair-pipeline.md) for the full five-phase flow and CI auto-repair loop.

**Port these reference snippets verbatim** (translated to the target language):

• `applySearchReplaceBlocks` and `parseSearchReplaceBlocks` — exact regex and

match-count semantics.

• `selectWinner` (single-file, `repair-pipeline`) — filter → group → sort →

count≥2 t