# Worked Examples

This folder holds real outputs from past runs of the `validate-repo` skill.

## Who reads this

- **Reviewers of skill changes** — concrete artifacts make it easier to judge whether a SKILL.md edit improves the output. Compare the example before/after.
- **Future orchestrators** — when running this skill, the LLM can consult the example to calibrate report shape: how dense the findings table should be, how to write a "Top three priorities" block, how cross-agent dedup notes look, how the "Open questions" section is phrased.
- **New contributors** — fastest way to see what the skill does end-to-end without setting up and running it yourself.

## Conventions

- One file per audit run.
- File names: `example-report-<client-or-project>-<YYYY-MM-DD>.md`.
- Each example begins with an HTML-comment preamble describing provenance (which repo was audited, when, by which skill version) and noting whether content is real or synthetic.
- Real client content is acceptable inside the Gemma-internal toolkit. If this plugin ever ships externally, swap real examples for synthetic ones (the preamble flags this).

## Adding a new example

1. Run the skill against a project.
2. Copy the consolidated Phase C report into a new file here.
3. Prepend the HTML-comment preamble (see existing examples for the template).
4. Commit with `docs(gemma-dbt): add example validate-repo report from <project>`.

## What to avoid

- Don't include sub-agent raw JSON output — keep that in the Phase C consolidated form only. Raw findings JSON belongs in a separate `<repo>/audit/raw-findings-<date>.json` artifact if the user opts into that during Phase C5.
- Don't anonymize selectively (changing some names but not others) — either keep everything real or swap to a fully synthetic example. Partial anonymization is misleading.