| name | rebar-feedback |
| description | Use when you hit a gap, anti-pattern, bug, or missing guidance in rebar's templates, practices, or scripts during real work — or when the user says "file feedback" / "write this up for rebar." Files a durable feedback item instead of editing templates directly. |
rebar-feedback — file a feedback item correctly
Canonical reference: rebar:feedback/README (template, processing rules,
disposition lifecycle) — resolve with scripts/rebar-doc.sh rebar:feedback/README --cat (or rebar doc if the CLI is installed).
Reference it; do not restate it.
First: where does this filing go?
- Working in the rebar repo itself (it has
feedback/): file locally,
steps below.
- Working in an adopter repo (no
feedback/ directory): the feedback is
about rebar, so it belongs upstream — use ask rebar featurerequest "<the situation>" (MCP/ASK), or write the file into your rebar checkout's
feedback/ directory. Do not create a feedback/ dir in the adopter repo
for rebar-bound items.
Steps (rebar repo)
- Read the canonical reference (
rebar:feedback/README, above) and skim
one recent feedback/*.md file for the house voice before writing anything.
- Check the gate: the situation must be real, not hypothetical — a
specific scenario you actually hit (
rebar:charter §3, gate 3: concrete use
case). "Would be cool if…" does not qualify; do not file.
- Create the file:
feedback/YYYY-MM-DD-<slug>.md (today's date, short
kebab-case slug).
- Fill the required header fields:
Date, Source, Type, Status
(start at proposed), Template impact, From (agent/model, project,
date — provenance matters).
- Body: What Happened / What Was Expected / Suggestion. Be concrete.
Point at files with one-line pointers rather than restating their content.
Do not edit feedback/INVENTORY.md or move files into feedback/processed/
— triage and disposition are maintainer-owned (see "Processing Feedback" in
rebar:feedback/README).
