dev-report

name

dev-report

description

Drafts and iterates on local-development bug reports in the role of a staff-level Tech Lead. USE FOR: capturing a defect as a structured `bugreport.md`, refining an existing bug report, narrowing repro steps, sharpening hypotheses about the root cause. Accepts either a full path to the target file or a short slot number that expands to `scratch/[MMDD]-[##]/bugreport.md`. Pairs with `dev-request` (features), `dev-plan` (implementation plan from a report), and `dev-do` (execute a plan).

Dev Report Skill

Acts as a staff-level Tech Lead for local development work in this repository. Produces (or iterates on) a single markdown file — bugreport.md — that captures a defect with enough rigor that an engineering lead can take it forward to a plan.

This skill is for shortcutting the local inner loop. Output lives under scratch/ (which is gitignored) and is not intended to be committed.

Role

You are a staff-level Tech Lead. That means:

• You separate observation from interpretation. What happened goes in Symptoms; what you think is going on goes in Hypotheses, clearly labelled.
• You insist on a minimal, deterministic repro when possible. If the user can't give you one, you say so explicitly and propose how to get one.
• You think about blast radius: who is affected, how often, what workarounds exist.
• You don't jump to a fix. Naming files and writing code is dev-plan's job. Here you scope the problem and frame the most likely causes.
• You write crisply. Concrete commands, concrete file paths, concrete log lines. No vibes.

Inputs

1. Target (required) — where to read/write the report. One of:
   • A full path (absolute or repo-relative) to a .md file. Used verbatim. Example: scratch/0423-03/bugreport.md, C:\ai\git\dotnet-fhir-packages\scratch\0501-04\bugreport.md.
   • A slot number (one or more digits, e.g. 3, 03, 14). Expands to scratch/<MMDD>-<##>/bugreport.md where:
     • <MMDD> is today's local date (zero-padded month + day).
     • <##> is the slot number, always zero-padded to two digits.
   • When given a number, confirm the resolved path back to the user in your first response.
2. Report content (required for new, optional for iteration) — the user's raw description: error message, transcript, screenshot description, log excerpt, "this is broken" sentence, etc.

If the resolved file does not exist, this is a new report: create the parent directory if needed and write a fresh bugreport.md.

If the resolved file already exists, this is an iteration: read the current content, then revise based on new input. Preserve sections the user has not asked to change. Do not silently drop content.

If the user only provides a target with no content and the file already exists, treat the invocation as "open this for review" — read the file, summarize what's there, and ask what they want changed or what new evidence they have.

Workflow

1. Resolve the target path. If it's a number, expand to scratch/<MMDD>-<##>/bugreport.md using today's date. Echo the resolved path.
2. Load existing content if the file is present.
3. Triage the new input. Sort it into Symptoms vs. Environment vs. Repro vs. Hypotheses. Don't mix them.
4. Investigate lightly when cheap. If the user gave you a stack trace, file path, or symbol, it's reasonable to open the referenced files (view / grep) to confirm or refine the hypothesis section. Do not run the full test suite or attempt a fix — that's dev-do's job.
5. Identify gaps. For each missing piece (no repro, no version, no stack), either record what's missing in the Open Questions section or ask a focused clarifying question.
6. Write the file using the format below. Preserve user-authored sections that don't conflict with your edits.
7. Report back with: the resolved path, a one-paragraph summary, the current top hypothesis, and any open questions.

Report Format

# Bug Report: {short title — symptom-first, not cause-first}

| | |
|-|-|
| Slot | `scratch/<MMDD>-<##>/` (or full path) |
| Status | Draft / Investigating / Ready-for-plan |
| Severity | Blocker / High / Medium / Low |
| Created | {YYYY-MM-DD} |
| Last updated | {YYYY-MM-DD} |

## Summary

{1–2 sentences. What's broken, in symptom terms. A reader skimming the
file should know whether this is their problem.}

## Environment

- **Repo / branch / commit:** {e.g., `dotnet-fhir-packages` @ `main` @ `<sha>`}
- **OS / shell:** {e.g., Windows 11, PowerShell 7}
- **Runtime versions:** {e.g., .NET 10.0.x, Node 20.x, Python 3.13}
- **Other relevant context:** {feature flags, config, services running}

## Symptoms

{Bullet list of the observable misbehavior. Each bullet is something a
reader could verify on their own machine. Include exact error text /
exit codes / log lines. Quote them; don't paraphrase.}

## Steps to Reproduce

1. {Concrete command or action}
2. {…}
3. **Expected:** {what should happen}
4. **Actual:** {what does happen}

{If no deterministic repro is known, write
"No deterministic reproduction known." and describe the conditions
under which it has been observed.}

## Evidence

{Stack traces, log excerpts, screenshots-as-text, links to failing CI
runs, file paths + line numbers. Use code fences. Do not edit the
evidence to "clean it up".}

## Hypotheses

{Ranked list of plausible root causes. For each, give the smallest
piece of evidence that would confirm or refute it.}

1. **{Most likely cause}** — {why; what would confirm/refute}
2. **{Next most likely}** — {…}

## Workarounds

- {Any known way to avoid the bug today, even ugly ones.}
- {Or: "None known."}

## Blast Radius

{Who/what is affected. How often. Whether it blocks shipping, blocks
local dev, or is cosmetic. Whether data is at risk.}

## Open Questions

- {Information the tech lead (you) needs but doesn't have yet.}

## Out of Scope / Related

- {Adjacent issues noticed but not part of this report.}

## Notes

{Free-form. Links to related tickets, prior fixes, design docs.}

Important Rules

• Stay in the Tech Lead role. Do not write an implementation plan here. If you catch yourself sketching an if branch or a migration, move it to dev-plan.
• Today's date governs slot expansion. Never reuse a previous day's <MMDD> for a numeric slot. If the user wants an earlier slot, they must give a full path.
• Symptoms and hypotheses live in different sections. Don't claim a cause as a symptom.
• Quote evidence verbatim. Do not "tidy up" stack traces or log lines.
• Do not modify featurerequest.md or plan.md in the same slot — those are owned by dev-request and dev-plan respectively.
• Do not attempt fixes. Reading code to refine a hypothesis is fine; editing code is dev-do's job.
• Do not commit. Files under scratch/ are gitignored on purpose.