@erclx/canon 4.0.0

package/standards/groundwork.md

@@ -0,0 +1,211 @@
+---
+title: Groundwork reference
+description: Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
+---
+
+# Groundwork reference
+
+Applies to a groundwork track at `.claude/groundwork/<nn>-<slug>/`. A track measures one question that has to be settled before anyone can plan against it. The numbering inside the folder is the table of contents, so a reader opens the folder and knows where to start and what follows without an index maintained inside each file.
+
+The folder is gitignored and unbacked. No check reaches its contents and no history recovers a deleted one, so every rule here holds only while a session reads it, and the handoff file has to be self-contained.
+
+## Scope
+
+Governs a groundwork track under `.claude/groundwork/<nn>-<slug>/`: folder layout, ordinal naming, reserved numbering, frontmatter and dating, what each required file holds, and the conventions a track keeps.
+
+Does not govern:
+
+- A dump of many findings filed by domain, each carrying its own verdict: `intake.md`
+- The feature plan a closed track feeds, and the contract its answer slots keep: `plan.md`
+- The task file a closing track writes, and the origin line pointing back at the folder: `tasks.md`
+- Voice, rhythm, and sentence construction: the `write-human` skill
+- Headings, punctuation, word choice, and file references: `markdown.md`
+- When a project opens a track at all, and the procedure that runs one, which belong to the surface driving it
+
+## Folder name
+
+- Name the folder `<nn>-<slug>`, a two-digit zero-padded ordinal followed by a kebab-case slug.
+- Take the ordinal from the highest one already present across both `.claude/groundwork/` and `.claude/intake/`, incremented. A listing then sorts by when each folder opened rather than alphabetically, and the count includes both kinds because the two share one creation-order line.
+- With neither folder holding an entry, the first one opened takes `01`. Do not read this off the numbering inside a track, which starts at `00` on a large one and disagrees with intake's own first file.
+- Never renumber an existing folder. The ordinal is the order it opened, and a later reader cites it by that name.
+
+## What a working track looks like
+
+A track works when a session that has never seen it re-enters from the folder alone and can answer each of these:
+
+- Which single question is being measured, and why is it running now?
+- What is the current state, measured during this pass rather than carried in from an earlier one?
+- Which questions are still open, where does the evidence point, and what would overturn that?
+- What was decided, and what was considered and dropped?
+
+A track failing these is non-conforming even when it satisfies every shape rule below.
+
+## Frontmatter and dating
+
+Every file carries `title` and `description`. `README.md` carries one field the others do not.
+
+- `title` (required): the track subject in sentence case
+- `description` (required): one line naming what the track measures
+- `date` (required, `README.md` only): the day the folder opened, as `YYYY-MM-DD`
+
+Carry the opening date as a frontmatter field rather than a sentence in the body. A date written into prose is readable by a person and by nothing that walks the folder, and the two spellings drift once both are permitted. State it once and remove the body sentence rather than leaving the pair in place.
+
+Date the folder once rather than every file. A per-file date leaves every other file stale the first time one is edited, while the opening date never rots. The checkable half is the commit each measurement was taken against, which the file holding that measurement names.
+
+## Reserved numbers
+
+Five slots carry a fixed meaning. The rest are free, which is what lets the middle of a folder follow its subject.
+
+| Number       | Holds                                           | Required                    |
+| ------------ | ----------------------------------------------- | --------------------------- |
+| `00`         | Scope: constraints, risks, question list        | Large tracks only           |
+| `01`         | Current state, measured                         | Always                      |
+| `02` to `05` | Topic files, whatever the subject demands       | As needed                   |
+| `06`         | Decision                                        | To close                    |
+| `07`         | Handoff, self-contained                         | To close                    |
+| `08`         | Spikes: method, result, and cost per experiment | Tracks that run experiments |
+
+A folder missing `06` and `07` is live. That is the only status marker, and no separate tracking is needed.
+
+`08` sits after the closing files because it is an appendix. It holds evidence rather than a topic, so folding it into the `02` to `05` range buries it, and a track closes with or without one.
+
+## README.md
+
+Orients. Holds no findings.
+
+- A one-line definition of the investigation
+- A `## Why` section stating why the track is running now
+- A file-map table of filename and what it holds, kept current as files are added or retired
+- A `## Method` section splitting internal sources from external ones, naming which were used and which were not yet done, and listing under a leads heading any external source found but not opened
+- A `## Prior art` section
+- A `## Source citation` section stating the rule below, so a returning session picks it up from the folder
+- The phase stated out loud in the first three lines, in the form `Groundwork phase. Nothing here is a feature plan.`
+
+The file map is how a returning reader re-enters. After the decision, it is the highest-value thing in the folder.
+
+Every claim about a source outside the project carries a link to it, wherever the claim appears in the folder. A sentence asserting that a vendor documents something reads the same whether it came from a fetched page or from recall, and a later reader can neither check it nor tell the two apart.
+
+A source found and not read is listed as a lead and is never cited. That half is what keeps the rule from producing citation theater, because a link attached to a page nobody opened is worse than no link. Listing it still pays, since it stops a later pass re-searching for what this one already surfaced.
+
+Where the track supersedes an earlier plan or an earlier folder, name it and say not to go looking for it. Without that, the old reasoning keeps circulating.
+
+## 01-current-state.md
+
+Facts before opinion. Verified measurement only, taken during this pass.
+
+- Never carry a figure from a previous session without re-measuring. Stale ratios survive a sunset that invalidates them, and every number built on one is quietly wrong.
+- Mark an inference as an inference where one is unavoidable.
+- Measure only what an open question needs. A number with no question attached is the mechanism by which the groundwork becomes the work.
+
+## 00-scope.md
+
+Written when the subject is large enough to run away. Holds constraints, risks, the open question list, and the downstream surfaces a decision would touch. A small track skips it and carries its questions inside the topic files.
+
+## 06-decision.md
+
+Closes the folder. Everything above it is input.
+
+- The problem stated once
+- The goal
+- The items to do
+- What was considered and dropped
+
+The dropped list pays off later. It is what stops a future session re-proposing something already rejected.
+
+## 07-next-session.md
+
+Written to survive a compaction that loses the conversation. It repeats facts held elsewhere in the folder rather than pointing at them. That duplication is correct here and wrong everywhere else.
+
+## 08-spikes.md
+
+Evidence by experiment, sitting beside the evidence by measurement that `01-current-state.md` holds. Optional, and most tracks never open it, because measuring what is already there settles most questions.
+
+Each spike carries four things:
+
+- The open question it answers, named by file and number. A spike attached to no question is the same runaway the current-state file is capped against.
+- The method, stated fully enough for a later reader to re-run it. Name the fixture and where it lived, the exact command, and how many repetitions were run. An arm pointed at a fixture inside the project measured the project, so the fixture location is part of whether the result stands.
+- The result, and which question it closes. A spike that settles nothing is still recorded, so a later pass does not pay to learn the same thing twice.
+- The measured cost, and the caveats bounding what the result proves.
+
+Cost is a report rather than a limit, and it is what makes the next spike estimable before anyone commits to it. Record it even when it comes to a single read.
+
+A spike also leaves files behind, and they split on whether the track cites them rather than on whether they are markdown. An input the run reads, being a fixture page, an arm script, or a copied asset, is re-runnable and cited by nothing, so it stays outside the track wherever the surface driving the spike puts it. Evidence the record cites, being a recording, a render, or a frame pulled from one, is what a later reader opens to check a claim, so it lives in `evidence/` inside the track beside the file citing it. Name the split rather than the file types, which is what keeps this from going stale on the next kind of artifact a spike produces.
+
+`evidence/` takes no number, since numbering is the read order over the files a reader opens in sequence and an artifact is reached from the claim that cites it instead.
+
+Reach for a test harness the project already carries before building one. A track needing an experiment no existing harness can express has found a finding, and it belongs in the folder rather than in a new abstraction.
+
+One method error is worth naming, because it is made rather than imagined. Counting matches in a transcript overstates whether a file was read, since an instruction naming a path puts that path in the transcript whether or not anything opened it. The check is the tool call.
+
+## Open questions
+
+Every open question carries a lean, wherever it appears. A bare numbered list hands the reader a quiz and defers the judgment the track exists to inform.
+
+```markdown
+1. <question>
+   - Leaning: <where the evidence currently points>
+   - Overturned by: <the finding that would change it>
+```
+
+- Pair every lean with what would overturn it. A lean with no falsifier is an opinion.
+- On a measurement rather than a judgment, write `- Leaning: none, needs measuring` and drop the overturn line. A guess at a number is worse than an admission.
+- Mark each question open or answered, and repeat the open ones at the end of the file they belong to. That gives the decision file its agenda for free.
+
+A lean is weaker than the suggestion a plan file carries. It records the current read on a question still open by definition, not a decision to accept by default at execution time.
+
+## Conventions
+
+- State a number with what it settles. The strongest sections are the ones where a measurement answers a named question and says so.
+- Route a finding that would change an existing standard or rule through `claude-intake`. Only a demonstrated failure changes one.
+- Let the file count follow the number of genuinely separable questions, not the importance of the topic. A large topic with one question is a small folder.
+
+## Anti-patterns
+
+- **The groundwork becomes the work.** Gathering expands until the measuring costs more than the change it justifies. Cap it, and drop any thread with no question attached.
+- **Deciding by omission.** Closing a track while an unresolved question quietly fails an outcome. Resolve it or record it as knowingly accepted.
+- **Recording a constraint discovered while defending a decision.** Check a constraint against the alternative design before writing it down, or a fact about the current shape gets written up as inherent to the problem.
+- **A plan written before the groundwork.** Every track that has done this had to supersede the plan it wrote.
+- **The date left in the body.** A frontmatter field and a sentence both claiming the opening date resolve to whichever a reader happens to hit, and only one of them is readable by a walker.
+
+## Template
+
+```markdown
+---
+title: <Track subject>
+description: <one line naming what the track measures>
+date: <YYYY-MM-DD>
+---
+
+# <Track subject>
+
+Groundwork phase. Nothing here is a feature plan.
+
+<One line defining the investigation.>
+
+## Why
+
+<Why the track is running now.>
+
+## Files
+
+| File                  | Holds           |
+| --------------------- | --------------- |
+| `01-current-state.md` | <what it holds> |
+
+## Method
+
+<Internal sources used, external sources used, and what is not yet done.>
+
+### Leads
+
+- <external source found but not opened>
+
+## Prior art
+
+<Earlier plans, folders, or decisions this track supersedes or builds on.>
+
+## Source citation
+
+Every claim about a source outside the project carries a link. A source found
+and not read is listed as a lead and is never cited.
+```

package/standards/index.md

@@ -0,0 +1,36 @@
+---
+title: Standards
+subtitle: Reference docs for consistent authoring across the toolkit and target projects.
+---
+
+# Standards
+
+Reference docs for consistent authoring across the toolkit and target projects.
+
+- [Architecture reference](architecture.md): Shape and content rules for .claude/ARCHITECTURE.md
+- [Branch reference](branch.md): Branch naming format and type conventions
+- [Commit reference](commit.md): Commit message format and type conventions
+- [Context entry reference](context.md): Shape and content rules for .claude/context/<domain>.md entries
+- [Design reference](design.md): Shape and content rules for .claude/DESIGN.md
+- [Diagram reference](diagrams.md): Shape and content rules for .claude/diagrams/<kind>.md files
+- [Glossary reference](glossary.md): Frontmatter, entry shape, ordering, and the rules deciding which terms a glossary carries
+- [Groundwork reference](groundwork.md): Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
+- [Intake reference](intake.md): Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
+- [Issue reference](issue.md): GitHub issue title, labels, and body conventions
+- [Markdown reference](markdown.md): Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, banned words, and frontmatter wording
+- [Memory reference](memory.md): Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
+- [Plan reference](plan.md): Filename and slug, required sections, the suggested-and-answer contract, and the lifecycle from the live folder to the archive
+- [Pull request reference](pr.md): Pull request title and body conventions
+- [Publish reference](publish.md): Scan an author runs against finished text, the cross-reference form each destination takes, and the response to an unreadable source
+- [Readme reference](readme.md): Readme voice, structure, and content conventions
+- [Requirements reference](requirements.md): Shape and content rules for .claude/REQUIREMENTS.md
+- [Governance rule reference](rule.md): Rule frontmatter, body shape, and voice for .claude/rules files
+- [Session map reference](session.md): Filename and location, the sections a handoff carries, the write and read procedures, and how a role extends it
+- [Claude skill reference](skill.md): Claude skill structure and authoring rules
+- [Slug reference](slug.md): Transform from a git branch name to a slug, and the three responses to an empty result
+- [Snippet reference](snippets.md): Snippet reference and authoring conventions
+- [Standard reference](standard.md): Shape and content rules for authoring a standard
+- [Tasks reference](tasks.md): Folder layout, filename convention, readiness groups, and content rules for .claude/tasks/
+- [Teach reference](teach.md): Workspace layout, ordinal naming, frontmatter, and the mission and learning-record formats for a learning workspace
+- [Versioning reference](versioning.md): Phase label vs semver discipline across tasks, PRs, reviews, issues, commits, and tags
+- [Wireframe reference](wireframes.md): Shape and content rules for .claude/wireframes/<surface>.md files

package/standards/intake.md

@@ -0,0 +1,192 @@
+---
+title: Intake reference
+description: Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
+---
+
+# Intake reference
+
+Applies to an intake folder at `.claude/intake/<nn>-<slug>/`. One folder holds one dump, filed by domain, and every finding in it is an item carrying a measured problem, one proposed fix, and a verdict.
+
+The folder is gitignored and unbacked. No check reaches its contents, so the shape below survives only by being read.
+
+## Scope
+
+Governs an intake folder under `.claude/intake/<nn>-<slug>/`: folder layout, ordinal naming, the reserved index number, frontmatter and dating, the item format, the answer contract, and retrieval.
+
+Does not govern:
+
+- One question measured in depth before anyone can plan against it: `groundwork.md`
+- The feature plan a promoted item feeds, and the inverted answer contract it keeps: `plan.md`
+- The task file promoting an item onto the board, and the origin line pointing back at the folder: `tasks.md`
+- Voice, rhythm, and sentence construction: the `write-human` skill
+- Headings, punctuation, word choice, and file references: `markdown.md`
+- Which findings belong in a dump at all, and the procedure that files one, which belong to the surface driving it
+
+## Folder name
+
+- Name the folder `<nn>-<slug>`, a two-digit zero-padded ordinal followed by a kebab-case slug. This is the folder's own ordinal, distinct from the `NN-<domain>.md` numbering a cluster file carries inside it.
+- Take the ordinal from the highest one already present across both `.claude/intake/` and `.claude/groundwork/`, incremented. A listing then sorts by when each folder opened rather than alphabetically, and the count includes both kinds because the two share one creation-order line.
+- With neither folder holding an entry, the first one opened takes `01`. Do not read this off the numbering inside a dump, which starts at `00` and disagrees with groundwork's own first required file.
+- Never renumber an existing folder. The ordinal is the order it opened, and a later reader cites it by that name.
+
+## What a working intake looks like
+
+An intake works when a reader returning weeks later can act on it from the folder alone:
+
+- Which items are ready to promote, and what does shipping each one cost?
+- What measurement stands behind each problem line, and against which commit was it taken?
+- Which items has the operator answered, and which has nobody reached?
+- Which live board task does an item already overlap?
+
+An intake failing these is non-conforming even when it satisfies every shape rule below.
+
+## Files
+
+| File                 | Holds                                                       | Required |
+| -------------------- | ----------------------------------------------------------- | -------- |
+| `00-overview.md`     | Index: cluster table, verdicts, open questions              | Always   |
+| `NN-<domain>.md`     | One cluster of items, filed by the domain their fixes touch | Always   |
+| `99-next-session.md` | What a compaction destroys that no cluster file carries     | Optional |
+
+`00` is the only reserved number. Everything else is read order, and the domain rides in the filename so a reader knows what `07-tooling.md` holds without opening it.
+
+Do not reserve mid-range numbers. Clusters differ per dump, so a contract over `06` would force every future intake into one dump's shape. A folder whose shape is fixed can reserve its numbers, and that half of the convention does not transfer.
+
+Let the file count follow the number of separable domains. A large dump with two domains is a small folder.
+
+## Frontmatter and dating
+
+Every file carries `title` and `description`. `00-overview.md` carries one field the others do not.
+
+- `title` (required): the dump subject in sentence case
+- `description` (required): one line naming what the dump covers
+- `date` (required, `00-overview.md` only): the day the folder opened, as `YYYY-MM-DD`
+
+Carry the opening date as a frontmatter field rather than a sentence in the body. A date written into prose is readable by a person and by nothing that walks the folder, and the two spellings drift once both are permitted.
+
+Date the folder once rather than every file. Twelve dated files leave eleven stale the first time one cluster is edited, and the opening date never rots. The checkable half is the commit, which the overview body names as what the claims were measured against.
+
+## 00-overview.md
+
+The index. It points at items and answers nothing itself.
+
+- The answer contract stated out loud, since it inverts the plan file's
+- A cluster table of file, what it holds, item count, and open count
+- The verdict counts across the folder
+- A ready list, grouped by what shipping one actually costs
+- The open questions, each a labeled markdown link to its owning item's heading anchor
+
+The index carries no answer slot. One question in two answerable places has no rule for which wins, and retrieval walks item headings, so an answer typed into the index is found by nothing and lost silently.
+
+Where an item touches a task already on the board, say so in the index rather than only inside the item. A reader deciding what to promote reads the index first.
+
+## Item format
+
+```markdown
+### N. Short title stating the defect
+
+- **Problem:** what is wrong today, stated against the tree and carrying a number or a file path
+- **Fix:** the one change proposed
+- **Worth it:** yes, later, or no, with the reason
+- **Open:** only where the call is the operator's
+- **Suggested:** the pick in one sentence, then the reason and the main tradeoff in one or two
+- **Overlaps:** the live board task that already owns this item
+- **You:**
+```
+
+- `Problem:`, `Fix:`, `Worth it:`, and the empty `You:` slot ship on every item. The other two are conditional.
+- Number items per cluster file, and give a finding split after the fact a letter suffix on the number it came from, as in `3a` beside `3`. Renumbering the items below it instead moves every label a reader or an answer already cited.
+- `Suggested:` is required whenever `Open:` is present. A bare question invites a bare answer, and `ok` against two defensible options carries no information. Where the answer is the operator's preference rather than a technical call, say so in that form rather than inventing a default.
+- `Overlaps:` never replaces `Worth it:`. The items where a live board task might be the thing that is wrong are exactly the ones whose verdict matters most.
+
+Two heading levels is the right depth inside a cluster file. A third means the cluster should have been its own file.
+
+An item may carry a bolded standalone line between the bullets where a finding needs a name of its own. Keep it rare. Everything fitting the four bullets belongs in them.
+
+## The answer contract
+
+`You:` belongs to the operator and ships empty on every item.
+
+Empty means unread. It never means agreement. Accepting a verdict is typed as one token, `- **You:** ok`.
+
+That inverts the plan file's contract, where a blank answer slot means accept the suggestion, and the inversion is deliberate. A plan is read in one sitting with every question already surfaced in conversation. An intake folder is read over weeks, so an empty slot is ambiguous between accepting the verdict and never having reached the item, and the second reading is far more likely. Acting on silence as consent ships a change nobody approved.
+
+Never fill a `You:` slot, and never infer a disposition from an empty one. On a resume pass, report unread items by count rather than deciding them.
+
+A slot is filled two ways. The operator types into the cluster file, or answers in chat and a verb lands the selection on the item. Both put the answer on the item, which is what keeps retrieval working, and neither lets a session decide one. An answer given in conversation and never written back leaves the item unread, since the file rather than the conversation is the record.
+
+An item already carrying an answer is refused rather than overwritten, whichever route the second answer arrives by. A filled slot is a decision already made, and revising one is the operator editing their own line.
+
+## Retrieval
+
+Answers live on items, so one pass over the folder reports every touched slot.
+
+A session with the toolkit CLI on PATH reads the folder through `canon intake list`, which reports per-folder counts bare and one folder's items with `--json`, and takes `--unread` to keep only the empty slots. It is the surface under test, and it skips the index and every fenced sample, which the greps below cannot do.
+
+The greps stay for a reader without the CLI, and they overcount by whatever the folder displays in a fence.
+
+```bash
+awk '/^### /{h=FILENAME": "$0} /^- \*\*You:\*\*./{print h; print "   "$0}' *.md
+```
+
+Counting what is still unread runs against the empty slot instead.
+
+```bash
+grep -c '^- \*\*You:\*\*$' *.md
+```
+
+Both walk `###` headings, which is the mechanical reason an answer typed anywhere else is lost.
+
+## Conventions
+
+- State a number with what it settles. The strongest items are the ones where a measurement decides the verdict and says so.
+- File an item under the domain its fix touches, not the domain the complaint arrived from.
+- Name a live board task an item overlaps, and keep the verdict beside it.
+- Revise a verdict the tree has moved under rather than appending a second one narrating the change.
+- Report unread items by count on a resume pass. Never decide one.
+
+## Anti-patterns
+
+- **Silence read as consent.** An empty slot on a folder read over weeks means nobody reached the item, and treating it as acceptance ships a change nobody approved.
+- **A verdict with nothing behind it.** An item whose problem line carries no number is an opinion, and it reads exactly like the ones that were measured.
+- **The overlap that ate the verdict.** Replacing `Worth it:` with `Overlaps:` drops the call on the items most likely to change what a live task should do.
+- **A question in two places.** An open question answerable in the index and on the item resolves to whichever a reader happens to open.
+- **The dump filed as one concern.** Forty findings under one heading is a folder nobody can promote from, and the split by domain is what makes each item liftable on its own.
+- **The date left in the body.** A frontmatter field and a sentence both claiming the opening date resolve to whichever a reader happens to hit, and only one of them is readable by a walker.
+
+## Template
+
+```markdown
+---
+title: <Dump subject>
+description: <one line naming what the dump covers>
+date: <YYYY-MM-DD>
+---
+
+# <Dump subject>
+
+<One line on what the dump covers and the commit it was measured against.>
+
+## The answer contract
+
+`You:` ships empty and empty means unread. Accepting a verdict is typed as
+`- **You:** ok`. Nothing here is decided by silence.
+
+## Clusters
+
+| File             | Holds           | Items | Open |
+| ---------------- | --------------- | ----- | ---- |
+| `NN-<domain>.md` | <what it holds> | <n>   | <n>  |
+
+## Verdicts
+
+<counts across the folder>
+
+## Ready
+
+- <item, grouped by what shipping it costs>
+
+## Open questions
+
+1. [<question>](NN-<domain>.md#n-short-title-stating-the-defect)
+```

package/standards/issue.md

@@ -0,0 +1,94 @@
+---
+title: Issue reference
+description: GitHub issue title, labels, and body conventions
+---
+
+# Issue reference
+
+## Scope
+
+Governs a tracker issue: its title, its labels, and the sections its body carries.
+
+Does not govern:
+
+- Pull request title and body: `pr.md`
+- Whether a phase label may appear in issue text: `versioning.md`
+- Voice, rhythm, and sentence construction in issue prose: the `write-human` skill
+- Punctuation, formatting, and banned words in issue prose: `markdown.md`
+
+## Title
+
+- Format: `<type>: <subject>`
+- Type is `bug` or `task`. Lowercase the type and the first word of the subject.
+- Length: 72 characters maximum, no trailing period.
+
+## Labels
+
+- Apply `bug` for a defect and `enhancement` for a task or improvement.
+- Both are GitHub default labels. A label that does not exist makes `gh` reject the issue. Create it once with `gh label create`.
+- One label per issue unless a second genuinely applies.
+
+## Content
+
+- Use imperative mood and describe the actual defect or work, not that something is wrong.
+- Do not open with "This issue," "I want," or "We should."
+- Do not use buzzwords or speculative future scope.
+- State observable behavior for a bug, not a guessed cause.
+
+## Sections
+
+- `## Summary`: one line naming what and why.
+- `## Details`: for a bug, what happens versus what is expected. For a task, what to build.
+- `## Context`: for a bug, repro steps or commands. For a task, the driving reason, or `none`.
+- `## Proposed` (optional): one line naming a fix or approach. Omit when open.
+
+## Formatting
+
+- End every bullet with a period.
+- Keep each section to one or two lines.
+
+## Examples
+
+### Correct (bug)
+
+```markdown
+## Summary
+
+Fix the feedback CLI so it applies the `feedback` label.
+
+## Details
+
+`canon feedback --github` opens an issue with no label, so `canon-feedback-triage` never lists it.
+
+## Context
+
+Run a piped `canon feedback --github`, then check the issue carries no `feedback` label.
+
+## Proposed
+
+Pass `--label feedback` through the shared issue helper.
+```
+
+### Correct (task)
+
+```markdown
+## Summary
+
+Add a git-issue skill so a session can file an issue on the current repo.
+
+## Details
+
+Format an issue from session context and file it with `gh issue create`, next to git-pr in the git family.
+
+## Context
+
+The toolkit-issue skill only files on the toolkit repo. A general path is needed for target projects.
+```
+
+### Incorrect
+
+```markdown
+## Summary
+
+This issue is about the feedback system being kind of broken, and we should probably make it more robust.
+```