interview-to-freeform-summary

SKILL.md

# interview-to-freeform-summary

Follow the procedure below and use the artifact/reference sections as the runtime contract.

## When To Use

- Normalize a free-form user interview into the shared freeform-summary workflow handoff.

## Inputs

- No upstream artifact inputs declared. See the procedure for user-supplied runtime inputs.

## Outputs

- Write artifact `freeform-summary` as `freeform-summary.md`. Format: `markdown`. Methods, tools, sample data, references, constraints, open questions, and workflow intent gathered from a user interview.

## Required Tools

- None declared. Procedure should not assume external CLIs are present.

## Load Upfront

- None declared.

## Load On Demand

- None declared.

## Validation

- None declared.

## Procedure

Turn a free-form user interview into the shared `freeform-summary` artifact consumed by downstream freeform-summary skills.

The harness owns the live interaction style. It may run this skill inside an interactive Claude/Codex session, feed it a saved transcript, or collect answers through a custom UI. The skill's job is the normalized handoff, not the conversation.

Emit Markdown, not a target workflow schema. Downstream skills treat this exactly like the output of summarize-paper: useful source evidence with explicit uncertainty, not a fully specified workflow. Keeping the two producers shape-compatible is what lets paper and interview starts share one design/template tier.

### What to capture

Record what the interview actually supports, and mark the rest as uncertain rather than inventing it:

- **Workflow intent** — what the user is trying to build, in their words.
- **Methods / algorithms** — the analytical steps, ordered as the user describes them.
- **Tools** — named tools or versions if given; otherwise the operation to be resolved downstream.
- **Inputs** — sample data, formats, per-sample structure, paired/grouped shape.
- **Outputs** — expected results and which ones matter for review or testing.
- **Parameters** — any non-default settings the user calls out.
- **Data availability** — whether real or test data exists, and where.
- **Constraints** — runtime, environment, licensing, or scale limits.
- **Confidence and open questions** — where the user was unsure, and what still needs answering.

### Don't over-specify

A free-form source carries genuine uncertainty; preserve it. Do not promote a vague answer ("some kind of alignment") into a precise tool or parameter — record it as intent plus an open question. Silent invention here propagates as false confidence through every downstream brief.

## Feedback Mode

- Feedback mode is off unless the caller explicitly enables `--feedback` or supplies a feedback-ledger path.
- When enabled, read `_feedback.md` before doing the work and use its registered `foundry-feedback.ledger.yml` protocol.
- Preserve harness-owned run and phase state. Append only concrete observations about a canonical Foundry source asset or a related project that this run showed to be at fault; do not put ordinary workflow requirements in this ledger.
- Before reporting completion, make one explicit pass over the work you just did. Do not ask yourself whether anything was unclear — recall what happened: where you guessed at something the instructions should have settled, needed information this bundle does not carry, hit an instruction that contradicted another or contradicted the artifacts in front of you, used a packaged reference that did not cover your case, or did something the procedure never describes.
- Append an entry for each such event that clears the protocol's bar. If none do, append nothing and report `no feedback` explicitly. Silence and a clean pass are not the same thing, and nothing downstream can tell them apart unless you say which one it was.
- Pass the same ledger path to any subagent used for this work, and merge updates serially so one writer cannot overwrite another.

## Runtime Notes

- Do not read Foundry source files at runtime; use only files packaged in this skill bundle and user-supplied artifacts.
- Preserve declared artifact filenames unless the user or harness supplies explicit paths.
- Carry unresolved assumptions into the output artifact instead of silently inventing missing source evidence.