@erclx/canon 4.83.0 → 4.84.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/claude/.claude-plugin/plugin.json +1 -1
- package/claude/skills/draft-and-pick/SKILL.md +1 -1
- package/claude/skills/ux-walkthrough/REQUIREMENT.md +53 -0
- package/claude/skills/ux-walkthrough/SKILL.md +50 -0
- package/claude/skills/ux-walkthrough/references/builds.md +15 -0
- package/claude/skills/ux-walkthrough/references/candidate-pages.md +26 -0
- package/claude/skills/ux-walkthrough/references/measuring.md +22 -0
- package/claude/skills/ux-walkthrough/references/record.md +36 -0
- package/claude/skills/ux-walkthrough/references/relay.md +25 -0
- package/claude/skills/youtube-transcripts/SKILL.md +1 -1
- package/docs/workflow/ai-workflow.md +1 -0
- package/docs/workflow/visual-design-workflow.md +1 -0
- package/package.json +1 -1
- package/src/claude/cases/workflow.ts +5 -0
- package/src/record-root.ts +4 -2
- package/src/records/backup.ts +4 -3
- package/standards/skill.md +1 -1
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: draft-and-pick
|
|
3
|
-
description: Drafts several candidates for a decision judged by looking, renders them side by side on one page, hands the operator the addresses, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, to write tests for a change already made, which is `ui-test`,
|
|
3
|
+
description: Drafts several candidates for a decision judged by looking, renders them side by side on one page, hands the operator the addresses, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, to write tests for a change already made, which is `ui-test`, to script a recording, which is `draft-screencast`, or to inspect a running app across many findings, which is `ux-walkthrough`.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Draft and pick
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ux-walkthrough
|
|
3
|
+
description: Why a multi-finding inspection walkthrough with the operator needs its own surface beside draft-and-pick, and where the boundary against building and auditing falls
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# UX walkthrough requirement
|
|
7
|
+
|
|
8
|
+
## Gap
|
|
9
|
+
|
|
10
|
+
Without this skill, a session running an inspection walkthrough with the operator:
|
|
11
|
+
|
|
12
|
+
- Files every round's evidence into one flat shared folder, so nothing shows which walkthrough a folder came from or in what order the rounds ran.
|
|
13
|
+
- Hands over screenshots or file paths the operator cannot open, where a served localhost page is the one form that reaches them.
|
|
14
|
+
- Asks the pick question before the operator has the page, so the answer is taken from a description.
|
|
15
|
+
- Sends the link inside the same message as the question, where the structured question surface draws over it and the operator never sees the link.
|
|
16
|
+
- Draws arms as hand-written mock-ups of the app, which drift a few pixels and a few words from what ships, rather than lifting the built page's own markup and stylesheet.
|
|
17
|
+
- Measures the mark and not the text inside it, or the gap and not what shows above it, so a pick ships with half its condition unchecked.
|
|
18
|
+
- Quotes figures in a pick question from memory, and records them without reading the computed values back.
|
|
19
|
+
- Relays each pick as it is taken when the operator wants picks batched on their own call.
|
|
20
|
+
- Serves a rebuilt export from a server whose working directory was deleted by the rebuild, and measures a page that is not there.
|
|
21
|
+
- Applies a pick to the tracked tree, or deletes the candidate pages, because the single-decision loop it borrowed does both.
|
|
22
|
+
- Leaves findings, numbers and build criteria in chat, so whoever files the work does it from a summary rather than from a record.
|
|
23
|
+
|
|
24
|
+
## Must
|
|
25
|
+
|
|
26
|
+
- Record conditions, findings with their measurements, picks with the arms they beat, evidence paths and build criteria in one walkthrough file under `.canon/walkthroughs/`.
|
|
27
|
+
- Measure each finding off the built page before drafting any arm.
|
|
28
|
+
- Build candidate pages from the app's rendered markup and built stylesheet, with a theme toggle, served on localhost.
|
|
29
|
+
- Capture every arm in every theme the app ships to its walkthrough's own evidence folder, and look at the captures before handing the link over.
|
|
30
|
+
- Number the walkthrough folder and each round's folders so they sort in the order they ran, and let a round's number match its finding's.
|
|
31
|
+
- Send the localhost link in its own message, ending the turn, before every pick question is asked.
|
|
32
|
+
- Hold picks and relay them only when the operator calls a batch, as one message, to the controller where one exists and to the operator otherwise.
|
|
33
|
+
- Route a finding with no visible choice into the batch as a proposed row rather than drafting arms for it.
|
|
34
|
+
|
|
35
|
+
## Must not
|
|
36
|
+
|
|
37
|
+
- Change a tracked file, create a branch or commit, or file a task row.
|
|
38
|
+
- Apply a winning arm or delete the evidence.
|
|
39
|
+
- Draft arms for a finding the operator has not raised.
|
|
40
|
+
- Restate `draft-and-pick`'s arm rules or the `canon capture` and `canon serve` mechanics.
|
|
41
|
+
- Fire on a request naming one decision alone, which `draft-and-pick` covers.
|
|
42
|
+
- Review criterion, not a gate: whether anything other than the operator or a controller's launch brief invokes this skill, and which lines a second project found in its way. Read both back after it has run outside the project it was written in.
|
|
43
|
+
|
|
44
|
+
## Guards
|
|
45
|
+
|
|
46
|
+
The refusal strings sit in the body. Two conditions stop a run: no build to measure against, and a request to change a tracked file.
|
|
47
|
+
|
|
48
|
+
## Out of scope
|
|
49
|
+
|
|
50
|
+
- `draft-and-pick` runs one decision end to end and applies it. This runs many decisions and applies none.
|
|
51
|
+
- `ux-audit` reads source for roughness. This takes its findings from what the operator saw.
|
|
52
|
+
- `plan-feature` and a worker build a pick. This stops at the record and the batch.
|
|
53
|
+
- The controller, or the operator where none exists, decides rows, order and pull request boundaries. This proposes and does not file.
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ux-walkthrough
|
|
3
|
+
description: Runs an inspection walkthrough over a running app with the operator. Measures each finding off the built page, drafts arms as served HTML pages lifted from the app's own markup and stylesheet, hands over the localhost link before every pick question, records findings and picks with the arms they beat in one walkthrough file, and relays picks only in batches the operator calls. Use when asked to "run a first-use walkthrough", "do an operator walkthrough", "go through my findings one by one", "inspection walkthrough over the app", or "walk through everything I listed with me". Do NOT use for one decision on its own, which is `draft-and-pick`, to read source for roughness, which is `ux-audit`, or to build a pick, which is `plan-feature` and a worker.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# UX walkthrough
|
|
7
|
+
|
|
8
|
+
A walkthrough turns what the operator sees in a running app into findings and picks a builder can act on without the conversation. The render is the decision and the record carries the measurements, so every pick here is taken by looking and written down with the numbers behind it.
|
|
9
|
+
|
|
10
|
+
## Guards
|
|
11
|
+
|
|
12
|
+
- If no running build or build command exists to measure against, stop: `❌ Nothing to inspect. A walkthrough measures a running build.`
|
|
13
|
+
- If the session is asked to change a tracked file, stop and route it: `❌ A walkthrough records and does not build. Hand the pick to whoever dispatches the build.`
|
|
14
|
+
- Draft no arm for a finding the operator has not raised or agreed to take up.
|
|
15
|
+
|
|
16
|
+
## Posture
|
|
17
|
+
|
|
18
|
+
- Write only under `.canon/`, never a tracked file, and create no branch, commit or task row.
|
|
19
|
+
- Stay in the checkout the session started in. Enter no worktree for a walkthrough, since nothing it writes is tracked.
|
|
20
|
+
- Read the `walkthrough.md` of every earlier walkthrough under `.canon/walkthroughs/` first, and raise nothing they already decided.
|
|
21
|
+
- Name every folder a walkthrough writes with a two-digit prefix, per `${CLAUDE_SKILL_DIR}/references/record.md`, so the walkthrough and its rounds sort in the order they ran.
|
|
22
|
+
- Put builds, generator scripts and logs in a scratch folder outside the tracked tree, and anything the operator opens under `.canon/tmp/`.
|
|
23
|
+
|
|
24
|
+
## Steps
|
|
25
|
+
|
|
26
|
+
1. **Bring up both builds and record the conditions.** Follow `${CLAUDE_SKILL_DIR}/references/builds.md`. Start the walkthrough file with the commit, the ports and the build commands before the first finding.
|
|
27
|
+
2. **Take the operator's list in their order.** Name each item as a finding with the walkthrough letter and a number, such as T1, and confirm the order once rather than per item.
|
|
28
|
+
3. **Measure before drafting.** Read the component behind the finding and pull the numbers off the built page, per `${CLAUDE_SKILL_DIR}/references/measuring.md`. Write the finding into the walkthrough file with those numbers before any arm exists.
|
|
29
|
+
4. **Route a finding with no visible choice.** A parse defect, a stale figure or a broken invariant gets recorded as a finding with no draft and goes into the batch as a proposed row, not as a pick.
|
|
30
|
+
5. **Draft three or four arms.** Follow `draft-and-pick` Steps 1 and 2 for the arms, with arm 0 the shipped state, one property varied and a cost on each. Build the page from the app's own rendered markup, per `${CLAUDE_SKILL_DIR}/references/candidate-pages.md`.
|
|
31
|
+
6. **Look before handing anything over.** Capture every arm in every theme the app ships into `.canon/walkthroughs/<nn>-<slug>/evidence/<nn>-<slug>/`, with the finding's number as the prefix, open the captures, and fix what rendered wrong before the operator sees the page.
|
|
32
|
+
7. **Hand the link, then ask.** Emit `http://localhost:<port>/<nn>-<slug>/candidates.html` in a message that ends the turn, confirmed with a `200`, carrying no question. Take any reply after that message as the operator having looked, an explicit "go" included, rather than holding for a stated confirmation, and only then put the choice through the structured question surface with the recommendation first.
|
|
33
|
+
8. **Record the pick.** Write what won, what it beat and by which numbers, where the evidence is, and the build criteria, per `${CLAUDE_SKILL_DIR}/references/record.md`. Read every figure you quote back from the page or the data file first, and correct the record where the question quoted one wrong.
|
|
34
|
+
9. **Hold picks for the batch.** Relay nothing per pick. When the operator calls the batch, send it once per `${CLAUDE_SKILL_DIR}/references/relay.md`.
|
|
35
|
+
10. **Close on the operator's word.** Add the walkthrough summary table and the handoff, leave the evidence in place, and report every file written by its path.
|
|
36
|
+
|
|
37
|
+
## Rules
|
|
38
|
+
|
|
39
|
+
- Answer a question the operator asks mid-walkthrough in prose first, with a recommendation, and offer a draft rather than drafting unasked.
|
|
40
|
+
- Say when a pick revises an earlier walkthrough's pick, and record it as a revision naming the pick it revises.
|
|
41
|
+
- Check a claim against the code or the data before an arm makes it, since an arm drawn on a wrong fact is a pick on nothing.
|
|
42
|
+
- Measure both halves of a pick whose condition has two, such as a gap and what shows above it.
|
|
43
|
+
- Keep a finding's measured numbers and the pick's build criteria in the record, never only in chat.
|
|
44
|
+
|
|
45
|
+
## What this delegates
|
|
46
|
+
|
|
47
|
+
- `draft-and-pick` owns the arm discipline and the structured question. This walkthrough departs from its Step 2 inlining and its Step 6 apply and delete, for the reasons `${CLAUDE_SKILL_DIR}/references/candidate-pages.md` states.
|
|
48
|
+
- `write-human` carries the voice of every recorded passage and any copy an arm puts in front of a reader.
|
|
49
|
+
- `plan-feature` and whoever dispatches builds turn a batch into plans and code.
|
|
50
|
+
- `canon capture`, `canon serve` and `canon sessions list` own the render, the address and the roster.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Builds and servers
|
|
2
|
+
|
|
3
|
+
Read when bringing the app up at the start of a walkthrough, and whenever a measurement returns nothing it should.
|
|
4
|
+
|
|
5
|
+
## Bring up
|
|
6
|
+
|
|
7
|
+
- Run the live build and whatever service it calls from the checkout the session started in, and record the commit, ports and any state that changes a reading as the walkthrough file's conditions.
|
|
8
|
+
- Build the artifact the deploy ships in a scratch folder outside the tracked tree, so a build never touches the project.
|
|
9
|
+
- Serve that artifact the way the host resolves it. A plain file server can answer a clean route the host rewrites with a 404, such as `/about` for `about.html`.
|
|
10
|
+
- Rebuild from the current main whenever main moves mid-walkthrough, and say so in the record. Measuring a stale build reports on code that no longer ships.
|
|
11
|
+
|
|
12
|
+
## Traps
|
|
13
|
+
|
|
14
|
+
- Restart a server after rebuilding what it serves. A server started inside an output folder the rebuild replaced keeps serving a deleted directory, and every selector comes back empty.
|
|
15
|
+
- Note what a build cannot show, such as live timing a recorded build does not carry or recompile pauses a dev server adds. Neither is a finding.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Candidate pages
|
|
2
|
+
|
|
3
|
+
Read when drafting arms for a finding. Skip it for a finding with no visible choice.
|
|
4
|
+
|
|
5
|
+
## Build from the app
|
|
6
|
+
|
|
7
|
+
- Dump the rendered markup of the surface under test from the built page, after it has loaded, into a JSON file in scratch. Strip scripts from the dump.
|
|
8
|
+
- Copy the built stylesheet and font files under `.canon/tmp/`, at the path the dumped markup links them from, so a candidate page renders with the stylesheet the app ships. Every arm then differs from the shipped page only by what the arm names.
|
|
9
|
+
- Trim a large dump to the part the finding needs, and keep the wrapper classes intact so layout rules keyed to them still resolve.
|
|
10
|
+
- Size each frame to the content width the finding names rather than the window width, since a container query reads the frame.
|
|
11
|
+
- Write copy an arm introduces with `write-human`, and take every other word from the dump.
|
|
12
|
+
|
|
13
|
+
## The page
|
|
14
|
+
|
|
15
|
+
- Generate the page with a short script, one per round, so a shared change is one edit and a rerun.
|
|
16
|
+
- Put a theme button on the page that flips the app's own theme switch on the root, rather than drawing each frame once per theme. Read `?arm=<id>&theme=<name>` to strip every other arm and the button for capture. Skip the button for an app that ships one theme.
|
|
17
|
+
- Print each frame's measurement under it from a script in the page, so the numbers the operator reads are the browser's.
|
|
18
|
+
- Write an index page linking one page per arm when an arm is a whole page or a route rather than a frame, with thumbnails copied beside it.
|
|
19
|
+
- Name anything the preview cannot reproduce, such as an asset whose colors follow the browser rather than the page's theme button, rather than fixing the page around it.
|
|
20
|
+
|
|
21
|
+
## Where this departs from draft-and-pick
|
|
22
|
+
|
|
23
|
+
- Capture into the walkthrough's own numbered evidence folder instead of the folder `draft-and-pick` Step 6 archives arms into, per `${CLAUDE_SKILL_DIR}/references/record.md`.
|
|
24
|
+
- Link the app's built stylesheet instead of inlining every asset. Lifted markup needs the real stylesheet, and an inlined copy is the drift this avoids.
|
|
25
|
+
- Keep `candidates.html` and never apply the winning arm. The walkthrough records and a build applies.
|
|
26
|
+
- Leave `.canon/tmp/<nn>-<slug>/` in place until the picks are built, and never delete the round's evidence folder.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Measuring
|
|
2
|
+
|
|
3
|
+
Read before writing a finding and before recording a pick.
|
|
4
|
+
|
|
5
|
+
## Off the page
|
|
6
|
+
|
|
7
|
+
- Measure on the built page in a real browser at the widths the finding names, in every theme the app ships, and record the viewport.
|
|
8
|
+
- Read computed styles rather than class lists. A class list names intent, and the computed value is what paints.
|
|
9
|
+
- Measure text contrast against the ground it sits on, and a mark's contrast against its own ground, as two numbers. A mark that sets a background and no text color inherits the browser default, and only the text reading catches it.
|
|
10
|
+
- Measure empty space by text extent, the union of each text node's client rects, rather than by leaf element boxes. A block element spans its row whatever its text covers.
|
|
11
|
+
- Measure a landing by the landed element's top against the bar's bottom edge and by whether the element before it is visible. A pick with a two-part condition needs both readings.
|
|
12
|
+
- Reproduce the shipped value inside the candidate page before trusting an arm's numbers. Arm 0 reading the same as the live page is what shows the page matches.
|
|
13
|
+
|
|
14
|
+
## Off the data
|
|
15
|
+
|
|
16
|
+
- Re-derive a figure from the data file that produced it rather than from any document quoting it. Two documents can disagree, and neither is the source.
|
|
17
|
+
- Count a defect across the whole corpus or tree before recording its size, and say whether it sits only at the end, only in one version, or throughout.
|
|
18
|
+
- Test a proposed fix without editing code where the question is its effect, by patching the function in a throwaway script and comparing before and after on counts the fix could move.
|
|
19
|
+
|
|
20
|
+
## Before quoting
|
|
21
|
+
|
|
22
|
+
- Read every figure a pick question or a record quotes back from the page or the script that computed it. Correct the record in place when the question quoted one wrong, and say so.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
# The walkthrough record
|
|
2
|
+
|
|
3
|
+
Read when starting the walkthrough file, recording a finding, and recording a pick.
|
|
4
|
+
|
|
5
|
+
## File
|
|
6
|
+
|
|
7
|
+
- Write to `.canon/walkthroughs/<nn>-<slug>/walkthrough.md`, with `<nn>-<slug>` the walkthrough's own folder.
|
|
8
|
+
- Open with one paragraph naming the walkthrough, the date, the commit and what landed since the last walkthrough, then `## Conditions`, `## Findings`, `## Picks`, `## Walkthrough summary` and `## Handoff`.
|
|
9
|
+
- Number findings with one letter per walkthrough and a counter, and never reuse a number.
|
|
10
|
+
|
|
11
|
+
## Folder names
|
|
12
|
+
|
|
13
|
+
- With no earlier walkthrough on this topic, a fresh folder takes the next ordinal in `.canon/walkthroughs/`'s own sequence: list the folders present, take the highest `<nn>`, and increment it, starting at `01` when none exist.
|
|
14
|
+
- Put a round's captures at `.canon/walkthroughs/<nn>-<slug>/evidence/<nn>-<slug>/` and its candidate pages at `.canon/tmp/<nn>-<slug>/`, where the inner `<nn>` is the finding's own number, so T1's folders start `01-`.
|
|
15
|
+
- Leave a gap where a finding has no draft. The missing number is what maps each folder to its entry in the record.
|
|
16
|
+
- Take `<slug>` from the decision sentence the way `draft-and-pick` Step 1 derives it, and add only the prefix.
|
|
17
|
+
- Rename no folder from a walkthrough that predates this rule. Tracked documents cite those paths, and a rename breaks every citation.
|
|
18
|
+
|
|
19
|
+
## A finding
|
|
20
|
+
|
|
21
|
+
- Head it `### T<n>: <what is wrong, as a claim>`.
|
|
22
|
+
- State what the operator saw, the code behind it by path and line, and the measurement in a table when it has more than two readings.
|
|
23
|
+
- Name an earlier pick the finding revises, and a collision with work in flight.
|
|
24
|
+
|
|
25
|
+
## A pick
|
|
26
|
+
|
|
27
|
+
- Head it `### Pick <n>, T<n>: arm <id>, <what won>`.
|
|
28
|
+
- One paragraph on what the arm does and its measured result, then `It beat:` with one bullet per losing arm and the number that lost it.
|
|
29
|
+
- One `Evidence:` line naming the evidence folder and its file set.
|
|
30
|
+
- `Build criteria:` as bullets a builder checks against the built page, each measurable, including what the render shows that the prose does not.
|
|
31
|
+
- An answer to a question the operator asked with the pick goes under the criteria, stated as a decision with its reason.
|
|
32
|
+
|
|
33
|
+
## Close
|
|
34
|
+
|
|
35
|
+
- `## Walkthrough summary` is one table row per finding: the finding, the pick, and the arms it beat.
|
|
36
|
+
- `## Handoff` proposes how the picks split into pull requests by the files each writes, and names shared files and the order they force.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Relaying picks
|
|
2
|
+
|
|
3
|
+
Read when the operator calls a batch, and at the start of the walkthrough when a launch brief asks for collisions.
|
|
4
|
+
|
|
5
|
+
## Where the batch goes
|
|
6
|
+
|
|
7
|
+
- Send it to the controller where the session was dispatched by one, resolved per the Channel rule, matched by name through `canon gov list --rules --json` rather than a path a target may not have installed.
|
|
8
|
+
- Give it to the operator as one list in the conversation where no controller exists. The walkthrough file is the handoff either way.
|
|
9
|
+
|
|
10
|
+
## When
|
|
11
|
+
|
|
12
|
+
- Relay nothing per pick. Relay once when the operator calls the batch, covering every pick held since the last one.
|
|
13
|
+
- Put a finding with no visible choice in the same batch, as a proposed row.
|
|
14
|
+
|
|
15
|
+
## The message
|
|
16
|
+
|
|
17
|
+
- Open with one line saying what the batch holds and where the record is.
|
|
18
|
+
- Give each pick its finding, the arm, the numbers that decided it, the arms beaten, and the files it writes.
|
|
19
|
+
- Close with overlaps and order: files two picks share, picks that must follow another, and collisions with open pull requests or unmerged branches.
|
|
20
|
+
- Name anything the operator holds that is not a row, such as a repository setting.
|
|
21
|
+
|
|
22
|
+
## Collisions
|
|
23
|
+
|
|
24
|
+
- List open pull requests with their files, and unmerged remote branches with `git diff --stat origin/main...origin/<branch>`, and compare file sets rather than descriptions.
|
|
25
|
+
- Stamp an overlap with the commit it was measured against.
|
|
@@ -25,7 +25,7 @@ canon transcripts <url>
|
|
|
25
25
|
```
|
|
26
26
|
|
|
27
27
|
- Pass `--keep-timestamps` when the user wants `[mm:ss]` markers per line instead of prose.
|
|
28
|
-
- Pass `--out <dir>` to override the output directory. The default is
|
|
28
|
+
- Pass `--out <dir>` to override the output directory, resolved against the current directory. The default is the backed `.canon/transcripts/` folder at the main worktree root, under a filename shaped `<fetch-date>--<title-slug>--<video-id>.md`.
|
|
29
29
|
- The written file path prints to stdout. Surface it back to the user as a full relative path, in the form the project's instruction file sets under `## Output`.
|
|
30
30
|
|
|
31
31
|
## After the fetch
|
|
@@ -242,6 +242,7 @@ This section is the corpus the coverage claim is measured against: every name `c
|
|
|
242
242
|
| `canon:markdown-propose` | When a markdown claim needs rewriting and the change should wait for an answer per file |
|
|
243
243
|
| `canon:ux-audit` | To read UI source for missing states, edge cases, and inconsistencies |
|
|
244
244
|
| `canon:ux-measure` | To start the interface and measure paint, processor, and layout cost |
|
|
245
|
+
| `canon:ux-walkthrough` | To run a multi-finding inspection pass over a running app with the operator |
|
|
245
246
|
|
|
246
247
|
### Ship it
|
|
247
248
|
|
|
@@ -41,6 +41,7 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
|
|
|
41
41
|
- `canon:ux-audit` for UX gap detection on existing surfaces
|
|
42
42
|
- `canon:ux-measure` for what a running surface costs to paint, read against published thresholds
|
|
43
43
|
- `canon:draft-and-pick` for a call settled by looking, drafting several candidates onto one page and taking your pick
|
|
44
|
+
- `canon:ux-walkthrough` for a multi-finding inspection pass over a running app with the operator, drafting arms from the app's own markup and recording each pick for a builder
|
|
44
45
|
- `canon:draft-identity` to draft a project's logo mark and compose it into an icon sequence and a social card, through `draft-and-pick`'s own render-and-pick loop
|
|
45
46
|
- Anthropic's `frontend-design` plugin optional for light visual steering
|
|
46
47
|
|
package/package.json
CHANGED
|
@@ -138,6 +138,11 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
|
|
|
138
138
|
prompt: 'Tell me the paint and layout cost of this page right now.',
|
|
139
139
|
expect: 'ux-measure',
|
|
140
140
|
},
|
|
141
|
+
{
|
|
142
|
+
prompt:
|
|
143
|
+
'Sit with me while I go through my whole list of app findings one at a time, and write down each pick with what it beat.',
|
|
144
|
+
expect: 'ux-walkthrough',
|
|
145
|
+
},
|
|
141
146
|
{
|
|
142
147
|
prompt:
|
|
143
148
|
'I am building this branch for another session. What am I on the hook for, and what is off limits?',
|
package/src/record-root.ts
CHANGED
|
@@ -46,8 +46,9 @@ const CANON_SCRATCH = 'tmp'
|
|
|
46
46
|
/**
|
|
47
47
|
* Every entry that lives under the record root, at the name `.claude/` gave it.
|
|
48
48
|
*
|
|
49
|
-
* These are the twelve ignore patterns the move to `.canon/` collapsed into
|
|
50
|
-
*
|
|
49
|
+
* These are the twelve ignore patterns the move to `.canon/` collapsed into
|
|
50
|
+
* one, plus every record folder added since, so the list counts entries
|
|
51
|
+
* rather than record folders: `.records.git` is the
|
|
51
52
|
* backup history rather than a record, and `README.md` is a file a records pull
|
|
52
53
|
* writes back. `worktrees` is absent because the harness creates a worktree
|
|
53
54
|
* under `.claude/` and requires its target to sit there.
|
|
@@ -72,6 +73,7 @@ export const RECORD_ENTRIES: readonly string[] = [
|
|
|
72
73
|
'review',
|
|
73
74
|
'tasks',
|
|
74
75
|
'teach',
|
|
76
|
+
'walkthroughs',
|
|
75
77
|
]
|
|
76
78
|
|
|
77
79
|
/** Whether a name under `.claude/` is one the record root owns. */
|
package/src/records/backup.ts
CHANGED
|
@@ -6,8 +6,8 @@ import { RECORD_ROOTS, recordRoot } from '@/record-root'
|
|
|
6
6
|
|
|
7
7
|
/**
|
|
8
8
|
* The folders a backup carries, relative to the record root `workTree` resolves
|
|
9
|
-
* rather than to either root specifically, since the same
|
|
10
|
-
* whichever one a tree holds.
|
|
9
|
+
* rather than to either root specifically, since the same eleven names sit
|
|
10
|
+
* under whichever one a tree holds.
|
|
11
11
|
*
|
|
12
12
|
* Nothing bounds this list any more, and the move is what took the bound away.
|
|
13
13
|
* The claude manifest used to ship a folder apiece, so the `# Claude` group
|
|
@@ -18,7 +18,7 @@ import { RECORD_ROOTS, recordRoot } from '@/record-root'
|
|
|
18
18
|
* a name is written here.
|
|
19
19
|
*
|
|
20
20
|
* Three counts describe this surface and each is right about a different
|
|
21
|
-
* question, so they are stated apart rather than reconciled.
|
|
21
|
+
* question, so they are stated apart rather than reconciled. Eleven is what a
|
|
22
22
|
* disk loss would take, which is this list. Twelve is what sat under `.claude/`
|
|
23
23
|
* as an ignored folder before the move, which adds the scratch folder that is
|
|
24
24
|
* deletable without loss and `worktrees/`, whose contents belong to the
|
|
@@ -47,6 +47,7 @@ export const BACKED_FOLDERS = [
|
|
|
47
47
|
'tasks',
|
|
48
48
|
'teach',
|
|
49
49
|
'transcripts',
|
|
50
|
+
'walkthroughs',
|
|
50
51
|
] as const
|
|
51
52
|
|
|
52
53
|
/**
|
package/standards/skill.md
CHANGED
|
@@ -210,7 +210,7 @@ Without this skill, a session <observed failure>, <observed failure>.
|
|
|
210
210
|
### Output and tuning
|
|
211
211
|
|
|
212
212
|
- Skill success lines emit the full relative path from the project root (`<dir>/<file>`) for any file written, updated, or deleted. A bare filename names a file the reader cannot open. The `## Output` section of the project's instruction file sets the form that path takes, so a skill body states which path is emitted and leaves the form to that section.
|
|
213
|
-
- Before a skill writes anything, decide whether the output is a deliverable the project keeps or a toolkit session record. A deliverable lands among the project's own tracked files. A session record lands under `.canon/`, in the named subfolder for its kind (`tasks/`, `plans/`, `review/`, `memory/`, `groundwork/`, `intake/`, `proposals/`, `diagrams/`, or `
|
|
213
|
+
- Before a skill writes anything, decide whether the output is a deliverable the project keeps or a toolkit session record. A deliverable lands among the project's own tracked files. A session record lands under `.canon/`, in the named subfolder for its kind (`tasks/`, `plans/`, `review/`, `memory/`, `groundwork/`, `intake/`, `proposals/`, `diagrams/`, `teach/`, or `walkthroughs/`, with `tmp/` for scratch nothing else claims), never in a folder the body invents. `canon/ARCHITECTURE.md`'s per-folder decisions are the precedent for which kind takes which folder.
|
|
214
214
|
- Codify a skill's posted or generated output as a fenced template, and keep the body consistent with every capability the frontmatter description names.
|
|
215
215
|
- When a skill gathers user input or pre-seeds a template, attach a concrete proposed default to every question, derived from project context. Accept "use defaults" as a bulk-confirm.
|
|
216
216
|
- Separate correctness axes (routing, sourcing, escalation, decline) from shape axes (line count, formatting, variant sprawl) when tuning a skill. Tighten only on correctness regressions. Do not convert soft caps to hard caps for aesthetic drift when correctness passes.
|