Research Add Fields — Append to the Field Schema

In-place updates fields.yaml with additional research dimensions.

Trigger

/research-add-fields

Pipeline position

/research-outline → ► /research-add-fields ◄ → /research-deep → /research-report

Reachable any time after /research-outline has produced fields.yaml, but most useful before /research-deep so deep agents fill the new fields in their first pass.

Workflow

Step 1 — Auto-locate fields file

Glob */fields.yaml from the current working directory. Read it to know what's already defined — so suggestions don't duplicate existing fields and you can show the user the current categories when asking.

Step 2 — Pick a supplement source

AskUserQuestion with two options:

• A. Direct input — user dictates field names, descriptions, and categories.
• B. Web search — launch a research subagent via the Task tool (subagent_type: general-purpose) to propose common fields in the topic's domain.

Step 3 — Display and confirm

• Show the candidate field list back to the user (whether from A or B).
• AskUserQuestion for each candidate: keep / drop / edit.
• For each kept field, capture: category (must match an existing fieldcategories[].category or be a new one), detaillevel (brief | moderate | detailed), required (default false).

Step 4 — Save update

Append the confirmed fields to fields.yaml, preserving existing structure and ordering. Save in place.

Field shape (matches /research-outline)

field_categories:
  - category: <name>
    fields:
      - name: <field_name>
        description: <what to capture>
        detail_level: brief | moderate | detailed
        required: false

Output

Updated {topic}/fields.yaml — in-place modification, user confirms before save.

Gotchas

• Adding required: true retroactively breaks already-completed items. If /research-deep already produced JSONs for some items and you add a new required field, those JSONs will fail validation. Either add the field as required: false, or plan to re-run /research-deep for the affected items.
• Category names are matched literally. A new field whose category doesn't match an existing field_categories[].category creates a new top-level category in the schema. That's fine, but make sure it's intentional — a typo here is a silent split.
• The web-search subagent in option B operates outside the conversation context. Hand it the topic and an explicit list of categories that already exist, so its proposals fit the schema rather than colliding with what's there.
• fields.yaml is also consumed by ~/.claude/skills/research-outline/validatejson.py. The schema this skill writes must stay compatible with that validator — same fieldcategories[].fields[].name / required shape, no exotic YAML constructs.