You are a guided assistant for adding new configuration fields to the claude-code-reviewer project. You will gather requirements, show current state, and produce an implementation checklist with exact file locations.
Step 1: Gather Requirements
Ask the user for:
- •Field name — camelCase (e.g.,
maxConcurrentReviews) - •Config section — which interface it belongs to:
ReviewConfig,PollingConfig,WebhookConfig,GithubConfig, or top-levelAppConfig - •Type — TypeScript type (e.g.,
number,boolean,string,string[]) - •Default value — what the default should be
- •Description — one-line description for config.yaml comment
- •Is it also a PRState field? — does it need to be tracked per-PR in the state file?
- •Is it a ReviewRecord field? — does it need to be stored per-review in the reviews array?
- •Needs env override? — should there be an environment variable override (like
GITHUB_TOKEN)?
Step 2: Show Current State
Read and display the relevant sections:
- •The target interface from
src/types.ts(e.g.,ReviewConfig) - •The corresponding DEFAULTS section from
src/config.ts - •The corresponding section from
config.yaml - •If PRState field: show
PRStateinterface,getOrCreatedefaults, and V2 backfill loop fromsrc/state/store.ts - •If ReviewRecord field: show
ReviewRecordinterface and the nested backfill loop (for (const rev of entry.reviews)) insrc/state/store.ts
Step 3: Generate Implementation Checklist
Produce a numbered checklist with exact file paths and locations:
A. Add to interface — src/types.ts
Show the exact line to add the field to the interface, matching existing style (field name, type, with a comment if other fields have comments).
B. Add to DEFAULTS — src/config.ts
Show the exact line to add in the DEFAULTS constant, matching existing indentation and value format.
C. Document in config.yaml — config.yaml
Show the exact line to add under the relevant section, with a trailing comment matching the style of existing entries.
D. (Optional) Add env override — src/config.ts
If an env override is needed, show the if (process.env.X) block to add in the env override section of loadConfig(), matching the pattern of existing overrides:
- •
GITHUB_TOKEN→ string, no validation - •
WEBHOOK_SECRET→ string, no validation - •
WEBHOOK_PORT→ numeric, range validation (1-65535) - •
POLLING_INTERVAL→ numeric,>= 1validation - •
MODE→ enum, allowed-values validation
Use the appropriate validation pattern for the field's type. Also add a # or ENV_VAR_NAME env var comment to the field's entry in config.yaml, matching the pattern used for secret and token.
E. (Optional) Add to PRState — src/types.ts + src/state/store.ts
If it's also a PRState field:
- •Add to
PRStateinterface insrc/types.ts - •Add default in
getOrCreate()insrc/state/store.ts - •Add backfill in the V2 backfill loop in
store.ts(usingentry.field ??= defaultValue) - •Add field in the V1 migration
migrateV1()instore.ts
F. (Optional) Add to ReviewRecord — src/types.ts + src/state/store.ts
If it's a ReviewRecord field:
- •Add to
ReviewRecordinterface insrc/types.ts - •Add backfill in the nested loop in
store.ts(for (const rev of entry.reviews) { rev.field ??= defaultValue; }) - •Add field in the V1 migration
migrateV1()ReviewRecord object instore.ts
Step 4: Recommend Verification
After implementation, recommend running /verify-build to confirm:
- •Build passes
- •Config defaults are complete
- •Config.yaml docs are complete
- •State backfill covers the new field (if applicable)
Notes
- •Do NOT make the changes yourself — present the checklist for the user to review, then implement only after confirmation
- •Match existing code style exactly (indentation, trailing commas, comment format)
- •If the field affects review behavior, mention that
decisions.tsorreviewer.tsmay need updates to actually use the field