@erclx/canon 5.31.0 → 5.33.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/README.md +1 -1
- package/claude/.claude-plugin/plugin.json +1 -1
- package/claude/skills/api-design/references/adopted.md +1 -1
- package/claude/skills/auto-ship/REQUIREMENT.md +4 -16
- package/claude/skills/auto-ship/SKILL.md +13 -58
- package/claude/skills/auto-ship/references/draft-mark.md +2 -2
- package/claude/skills/auto-ship/references/failure-recovery.md +1 -5
- package/claude/skills/auto-ship/references/tier-failures.md +1 -1
- package/claude/skills/auto-ship/references/ui-checklist.md +2 -2
- package/claude/skills/auto-ship/references/verb-absent.md +3 -27
- package/claude/skills/auto-ship/references/worktree-name.md +1 -1
- package/claude/skills/backlog-triage/REQUIREMENT.md +2 -2
- package/claude/skills/backlog-triage/SKILL.md +2 -2
- package/claude/skills/canon-cli/REQUIREMENT.md +19 -18
- package/claude/skills/canon-cli/SKILL.md +75 -32
- package/claude/skills/canon-feedback/REQUIREMENT.md +1 -1
- package/claude/skills/canon-feedback/SKILL.md +11 -14
- package/claude/skills/canon-feedback-triage/REQUIREMENT.md +13 -14
- package/claude/skills/canon-feedback-triage/SKILL.md +49 -30
- package/claude/skills/{canvas → canvas-board}/REQUIREMENT.md +5 -6
- package/claude/skills/{canvas → canvas-board}/SKILL.md +7 -7
- package/{standards → claude/skills/canvas-board/references}/canvas.md +12 -1
- package/{standards → claude/skills/canvas-board/references}/design.md +13 -5
- package/claude/skills/ci-workflow/REQUIREMENT.md +0 -1
- package/claude/skills/context-fold/REQUIREMENT.md +28 -48
- package/claude/skills/context-fold/SKILL.md +26 -95
- package/claude/skills/context-fold/references/classify.md +7 -8
- package/claude/skills/context-fold/references/completion-report.md +4 -8
- package/claude/skills/context-fold/references/context-refresh.md +7 -17
- package/{standards → claude/skills/context-fold/references}/context.md +19 -10
- package/claude/skills/context-fold/references/unusable-baseline.md +4 -8
- package/claude/skills/create-rule/REQUIREMENT.md +0 -1
- package/claude/skills/create-rule/SKILL.md +2 -2
- package/{standards → claude/skills/create-rule/references}/rule.md +12 -5
- package/claude/skills/create-skill/REQUIREMENT.md +6 -4
- package/claude/skills/create-skill/SKILL.md +10 -9
- package/{standards → claude/skills/create-skill/references}/skill-paths.md +1 -0
- package/{standards → claude/skills/create-skill/references}/skill.md +18 -15
- package/claude/skills/decision-escalate/REQUIREMENT.md +1 -1
- package/claude/skills/decision-escalate/SKILL.md +1 -1
- package/claude/skills/design-taste/REQUIREMENT.md +3 -5
- package/claude/skills/design-taste/SKILL.md +2 -4
- package/claude/skills/design-taste/references/vocabulary.md +1 -1
- package/claude/skills/docs-sync/REQUIREMENT.md +3 -3
- package/claude/skills/docs-sync/SKILL.md +3 -3
- package/{standards → claude/skills/docs-sync/references}/docs.md +11 -0
- package/{standards → claude/skills/docs-sync/references}/readme.md +9 -2
- package/claude/skills/document-health/REQUIREMENT.md +2 -2
- package/claude/skills/document-health/SKILL.md +4 -5
- package/claude/skills/document-health/references/axes.md +4 -6
- package/claude/skills/draft-and-pick/REQUIREMENT.md +16 -14
- package/claude/skills/draft-and-pick/SKILL.md +40 -32
- package/claude/skills/draft-and-pick/references/live-arms.md +9 -9
- package/claude/skills/draft-doc/REQUIREMENT.md +5 -5
- package/claude/skills/draft-doc/SKILL.md +9 -10
- package/claude/skills/draft-doc/references/requirements.md +61 -0
- package/claude/skills/draft-doc/references/wiki-kind.md +53 -0
- package/claude/skills/draft-doc/references/wiki.md +50 -30
- package/claude/skills/draft-figure/REQUIREMENT.md +2 -2
- package/claude/skills/draft-figure/SKILL.md +5 -5
- package/claude/skills/draft-figure/references/architecture-set.md +4 -4
- package/claude/skills/draft-figure/references/hand-drawn.md +2 -2
- package/claude/skills/draft-figure/references/mermaid-path.md +55 -0
- package/claude/skills/draft-figure/references/mermaid.md +43 -34
- package/claude/skills/draft-identity/REQUIREMENT.md +3 -3
- package/claude/skills/draft-identity/SKILL.md +10 -8
- package/claude/skills/draft-ready/REQUIREMENT.md +1 -1
- package/claude/skills/draft-ready/SKILL.md +7 -7
- package/claude/skills/draft-ready/references/assembly.md +1 -1
- package/{standards → claude/skills/draft-ready/references}/ready.md +13 -5
- package/claude/skills/git-branch/SKILL.md +1 -1
- package/{standards → claude/skills/git-branch/references}/branch.md +1 -1
- package/claude/skills/git-commit/SKILL.md +2 -2
- package/claude/skills/git-followup/REQUIREMENT.md +1 -1
- package/claude/skills/git-followup/SKILL.md +1 -1
- package/claude/skills/git-issue/SKILL.md +1 -1
- package/claude/skills/git-issue/references/issue.md +3 -3
- package/claude/skills/git-pr/SKILL.md +13 -13
- package/claude/skills/git-pr/references/evidence.md +2 -2
- package/claude/skills/git-pr/references/final-command.md +38 -14
- package/claude/skills/git-pr/references/labels.md +5 -1
- package/{standards → claude/skills/git-pr/references}/pr.md +19 -9
- package/{standards → claude/skills/git-pr/references}/publish.md +5 -3
- package/claude/skills/git-pr/references/task-number.md +1 -1
- package/claude/skills/git-ship/REQUIREMENT.md +0 -2
- package/claude/skills/git-ship/SKILL.md +5 -12
- package/claude/skills/git-split/SKILL.md +3 -3
- package/claude/skills/git-stage/SKILL.md +1 -1
- package/claude/skills/plan-feature/REQUIREMENT.md +1 -1
- package/claude/skills/plan-feature/SKILL.md +2 -6
- package/{standards → claude/skills/plan-feature/references}/plan.md +9 -10
- package/claude/skills/plan-groundwork/SKILL.md +5 -6
- package/{standards → claude/skills/plan-groundwork/references}/groundwork.md +17 -4
- package/claude/skills/plan-intake/SKILL.md +2 -3
- package/{standards → claude/skills/plan-intake/references}/intake.md +17 -2
- package/claude/skills/plan-intake-answer/REQUIREMENT.md +1 -1
- package/claude/skills/plan-intake-answer/SKILL.md +1 -1
- package/claude/skills/review-address/SKILL.md +2 -2
- package/claude/skills/review-address/references/post-review-findings.md +1 -1
- package/claude/skills/review-craft/REQUIREMENT.md +3 -3
- package/claude/skills/review-craft/SKILL.md +2 -2
- package/claude/skills/review-craft/references/ui.md +4 -4
- package/claude/skills/review-pr/REQUIREMENT.md +2 -2
- package/claude/skills/review-pr/SKILL.md +8 -10
- package/claude/skills/review-pr/references/body-variants.md +2 -2
- package/claude/skills/review-pr/references/key-changes.md +3 -3
- package/claude/skills/review-pr/references/post.md +4 -2
- package/claude/skills/review-ui/REQUIREMENT.md +1 -2
- package/claude/skills/review-ui/SKILL.md +2 -2
- package/claude/skills/review-ui/references/post.md +1 -1
- package/claude/skills/role-orchestrator/REQUIREMENT.md +3 -3
- package/claude/skills/role-orchestrator/SKILL.md +10 -10
- package/claude/skills/role-orchestrator/references/orchestrator-dispatch.md +3 -3
- package/claude/skills/role-orchestrator/references/orchestrator-handoff.md +9 -9
- package/claude/skills/role-orchestrator/references/orchestrator-launch.md +23 -1
- package/claude/skills/role-orchestrator/references/orchestrator-parked.md +2 -2
- package/claude/skills/role-orchestrator/references/orchestrator-refill.md +2 -5
- package/claude/skills/role-orchestrator/references/orchestrator-resume.md +4 -1
- package/claude/skills/role-planner/REQUIREMENT.md +2 -1
- package/claude/skills/role-planner/SKILL.md +15 -4
- package/claude/skills/role-reviewer/SKILL.md +2 -2
- package/claude/skills/role-worker/REQUIREMENT.md +1 -0
- package/claude/skills/role-worker/SKILL.md +11 -3
- package/claude/skills/session-compact/REQUIREMENT.md +1 -4
- package/claude/skills/session-compact/SKILL.md +3 -13
- package/claude/skills/session-compact/references/handoff-note.md +2 -2
- package/claude/skills/session-map/REQUIREMENT.md +1 -9
- package/claude/skills/session-map/SKILL.md +9 -17
- package/{standards → claude/skills/session-map/references}/session.md +17 -11
- package/claude/skills/session-relay/REQUIREMENT.md +1 -1
- package/claude/skills/session-resume/REQUIREMENT.md +6 -8
- package/claude/skills/session-resume/SKILL.md +3 -9
- package/claude/skills/session-worktree/SKILL.md +6 -6
- package/claude/skills/session-worktree/references/main-root-writes.md +2 -2
- package/claude/skills/systematic-debugging/REQUIREMENT.md +0 -1
- package/claude/skills/target-check/REQUIREMENT.md +3 -3
- package/claude/skills/target-check/SKILL.md +1 -1
- package/claude/skills/target-check/references/domains.md +1 -1
- package/claude/skills/target-setup/REQUIREMENT.md +4 -4
- package/claude/skills/target-setup/SKILL.md +3 -3
- package/claude/skills/target-setup/references/detect.md +2 -2
- package/claude/skills/task-board/REQUIREMENT.md +7 -12
- package/claude/skills/task-board/SKILL.md +9 -21
- package/{standards → claude/skills/task-board/references}/board.md +9 -0
- package/claude/skills/task-board/references/decline.md +1 -1
- package/{standards → claude/skills/task-board/references}/tasks.md +15 -10
- package/claude/skills/task-complete/REQUIREMENT.md +47 -0
- package/claude/skills/task-complete/SKILL.md +86 -0
- package/claude/skills/{task-board → task-complete}/references/archive.md +5 -5
- package/claude/skills/task-complete/references/receipt-sweep.md +32 -0
- package/claude/skills/task-complete/references/unusable-baseline.md +19 -0
- package/claude/skills/teach-workspace/REQUIREMENT.md +6 -2
- package/claude/skills/teach-workspace/SKILL.md +9 -5
- package/claude/skills/teach-workspace/references/lesson-craft.md +1 -1
- package/claude/skills/teach-workspace/references/promotion-fold.md +29 -0
- package/claude/skills/teach-workspace/references/promotion.md +3 -3
- package/claude/skills/teach-workspace/references/revisit.md +1 -1
- package/{standards → claude/skills/teach-workspace/references}/teach.md +17 -5
- package/claude/skills/ui-checklist/SKILL.md +1 -1
- package/claude/skills/ux-audit/REQUIREMENT.md +2 -2
- package/claude/skills/ux-audit/SKILL.md +3 -4
- package/claude/skills/ux-measure/SKILL.md +1 -1
- package/claude/skills/write-human/REQUIREMENT.md +0 -1
- package/claude/skills/write-human/SKILL.md +1 -1
- package/docs/agents/audits.md +1 -1
- package/docs/agents/canvas.md +1 -1
- package/docs/agents/commands.md +4 -8
- package/docs/agents/context-audit-checks.md +11 -25
- package/docs/agents/context-audit.md +7 -15
- package/docs/agents/context-classify.md +5 -5
- package/docs/agents/counts.md +5 -5
- package/docs/agents/drift-surfaces.md +2 -2
- package/docs/agents/index.md +5 -7
- package/docs/agents/indexes.md +1 -1
- package/docs/agents/install-and-sync.md +6 -11
- package/docs/agents/intake.md +1 -1
- package/docs/agents/key-changes.md +5 -5
- package/docs/agents/label-coverage.md +11 -0
- package/docs/agents/migrate.md +1 -1
- package/docs/agents/records-push.md +2 -2
- package/docs/agents/records-stale.md +13 -48
- package/docs/agents/records-validate.md +4 -8
- package/docs/agents/records.md +6 -28
- package/docs/agents/restated.md +1 -1
- package/docs/agents/rule-citations.md +2 -2
- package/docs/agents/sandbox.md +4 -4
- package/docs/agents/skills-audit.md +2 -2
- package/docs/agents/state-scoped-risk.md +2 -2
- package/docs/agents/superseded.md +2 -2
- package/docs/agents/tasks-plans.md +1 -1
- package/docs/agents/tasks-validate.md +1 -1
- package/docs/agents/tasks.md +3 -3
- package/docs/agents/teach.md +1 -1
- package/docs/agents/upstream.md +26 -2
- package/docs/target/migrations.md +32 -0
- package/docs/target/projects.md +5 -7
- package/docs/target/scenarios.md +2 -2
- package/docs/target/sync.md +4 -4
- package/docs/workflow/ai-workflow.md +7 -38
- package/docs/workflow/index.md +1 -1
- package/docs/workflow/operating-model.md +10 -10
- package/docs/workflow/parallel-features.md +12 -12
- package/docs/workflow/skill-map-on-request.md +21 -24
- package/docs/workflow/skill-map.md +23 -34
- package/docs/workflow/visual-design-workflow.md +13 -16
- package/governance/renames.toml +0 -30
- package/governance/rules/canon/605-worktrees.md +1 -1
- package/governance/rules/canon/context.md +13 -0
- package/governance/rules/{standards → canon}/plan.md +4 -5
- package/governance/rules/canon/tasks.md +18 -0
- package/governance/rules/claude/skill.md +17 -0
- package/governance/stacks/base.toml +2 -4
- package/package.json +4 -4
- package/scripts/core/install-check.sh +4 -4
- package/scripts/core/regen-web-previews.ts +1 -1
- package/scripts/lib/ui.sh +0 -159
- package/src/audits/catalog.ts +5 -98
- package/src/claude/cases/authoring.ts +0 -18
- package/src/claude/cases/misc.ts +1 -14
- package/src/claude/cases/setup.ts +7 -20
- package/src/claude/cases/workflow.ts +6 -34
- package/src/claude/seeds.ts +1 -7
- package/src/claude/skills-audit.ts +3 -3
- package/src/cli/help.ts +4 -5
- package/src/cli/ui.ts +2 -3
- package/src/cli.ts +0 -4
- package/src/commands/claude.ts +9 -15
- package/src/commands/context.ts +18 -280
- package/src/commands/feedback.ts +22 -91
- package/src/commands/gov.ts +2 -15
- package/src/commands/labels.ts +326 -7
- package/src/commands/migrate.ts +6 -1
- package/src/commands/pr.ts +1 -1
- package/src/commands/records.ts +17 -403
- package/src/commands/sandbox.ts +3 -6
- package/src/commands/sync.ts +5 -3
- package/src/commands/tasks.ts +3 -3
- package/src/commands/upstream.ts +135 -0
- package/src/context/audit.ts +10 -19
- package/src/context/classify/extract.ts +6 -13
- package/src/context/classify/patterns.ts +2 -41
- package/src/context/classify/prompts.ts +2 -6
- package/src/context/classify/run.ts +3 -3
- package/src/context/folders.ts +8 -13
- package/src/context/gate.ts +11 -91
- package/src/context/requirements.ts +13 -4
- package/src/counts/scan.ts +3 -3
- package/src/design/budget.ts +1 -1
- package/src/design/components.ts +3 -3
- package/src/design/document.ts +1 -1
- package/src/design/regen.ts +1 -1
- package/src/design/render.ts +1 -1
- package/src/feedback/body.ts +0 -12
- package/src/gate/measures.ts +7 -58
- package/src/gate/sequencer.ts +56 -1
- package/src/gate/stages.ts +1 -7
- package/src/gov/citations.ts +9 -3
- package/src/gov/install.ts +2 -3
- package/src/gov/restated.ts +3 -3
- package/src/gov/stacks.ts +1 -1
- package/src/hooks/post-merge.ts +1 -1
- package/src/labels/apply.ts +39 -0
- package/src/labels/format.ts +3 -3
- package/src/labels/phase.ts +3 -3
- package/src/labels/sections.ts +43 -0
- package/src/markdown/structure.ts +2 -2
- package/src/migrate/record-layout.ts +3 -3
- package/src/migrate/skill-names.ts +20 -1
- package/src/pr/paths.ts +4 -4
- package/src/records/backup.ts +16 -6
- package/src/records/ordinal.ts +1 -1
- package/src/records/prune.ts +2 -1
- package/src/records/stale-canonical.ts +33 -3
- package/src/records/validate.ts +2 -188
- package/src/roots/record.ts +1 -1
- package/src/sandbox/census.ts +1 -1
- package/src/sandbox/coverage.ts +2 -6
- package/src/sandbox/equivalence.ts +5 -44
- package/src/sandbox/expect.ts +4 -4
- package/src/sandbox/provision.ts +13 -36
- package/src/sandbox/scenario.ts +137 -55
- package/src/sandbox/tree.ts +2 -6
- package/src/shipped/references.ts +3 -3
- package/src/standards/read.ts +44 -0
- package/src/sync/git.ts +1 -1
- package/src/sync/seeds-report.ts +1 -1
- package/src/tasks/archive.ts +5 -5
- package/src/tasks/branch.ts +3 -3
- package/src/tasks/label.ts +1 -1
- package/src/tasks/reach.ts +2 -2
- package/src/tasks/record.ts +2 -2
- package/src/tasks/validate.ts +2 -2
- package/src/teach/workspace.ts +1 -1
- package/src/upstream/cursor.ts +1 -1
- package/src/upstream/due.ts +128 -0
- package/src/upstream/releases.ts +2 -1
- package/standards/index.md +0 -35
- package/standards/standard.md +1 -7
- package/tooling/base/reference.md +2 -2
- package/tooling/base/seeds/.github/pull_request_template.md +2 -2
- package/tooling/claude/reference.md +7 -21
- package/tooling/claude/seeds/.claude/hooks/pr-create-log.sh +9 -1
- package/tooling/claude/seeds/.claude/hooks/records-index.sh +8 -20
- package/tooling/claude/seeds/.claude/hooks/review-post-scan.sh +171 -0
- package/tooling/claude/seeds/.claude/hooks/standards-audit.sh +3 -3
- package/tooling/claude/seeds/.claude/settings.json +9 -0
- package/tooling/claude/seeds/CLAUDE.md +1 -3
- package/tooling/claude/seeds/canon/REQUIREMENTS.md +2 -9
- package/tooling/web/configs/e2e/screenshot.ts +0 -1
- package/claude/skills/auto-ship/references/review-findings.md +0 -20
- package/claude/skills/bash-cli-script/REQUIREMENT.md +0 -43
- package/claude/skills/bash-cli-script/SKILL.md +0 -53
- package/claude/skills/bash-cli-script/references/template.md +0 -19
- package/claude/skills/canon-operator/REQUIREMENT.md +0 -62
- package/claude/skills/canon-operator/SKILL.md +0 -113
- package/claude/skills/canon-rollout/REQUIREMENT.md +0 -59
- package/claude/skills/canon-rollout/SKILL.md +0 -140
- package/claude/skills/canon-rollout/references/failure-recovery.md +0 -20
- package/claude/skills/context-fold/references/anchor-sweep.md +0 -58
- package/claude/skills/context-fold/references/promoted-pages.md +0 -29
- package/claude/skills/context-fold/references/receipt-sweep.md +0 -43
- package/claude/skills/context-fold/references/wireframe-sweep.md +0 -45
- package/claude/skills/create-standard/REQUIREMENT.md +0 -33
- package/claude/skills/create-standard/SKILL.md +0 -31
- package/claude/skills/design-extract/REQUIREMENT.md +0 -42
- package/claude/skills/design-extract/SKILL.md +0 -108
- package/claude/skills/draft-and-pick/references/frame.html +0 -118
- package/claude/skills/draft-doc/references/wireframes.md +0 -48
- package/claude/skills/markdown-propose/REQUIREMENT.md +0 -47
- package/claude/skills/markdown-propose/SKILL.md +0 -122
- package/claude/skills/markdown-propose/references/format.md +0 -118
- package/claude/skills/memory-capture/REQUIREMENT.md +0 -50
- package/claude/skills/memory-capture/SKILL.md +0 -117
- package/claude/skills/memory-review/REQUIREMENT.md +0 -52
- package/claude/skills/memory-review/SKILL.md +0 -129
- package/claude/skills/memory-review/references/later-phases.md +0 -118
- package/claude/skills/memory-review/references/receipt-format.md +0 -64
- package/claude/skills/project-commands/REQUIREMENT.md +0 -42
- package/claude/skills/project-commands/SKILL.md +0 -87
- package/claude/skills/repo-metadata/REQUIREMENT.md +0 -37
- package/claude/skills/repo-metadata/SKILL.md +0 -54
- package/claude/skills/restate-plainly/REQUIREMENT.md +0 -41
- package/claude/skills/restate-plainly/SKILL.md +0 -41
- package/claude/skills/review-branch/REQUIREMENT.md +0 -40
- package/claude/skills/review-branch/SKILL.md +0 -137
- package/claude/skills/seed-sync/REQUIREMENT.md +0 -45
- package/claude/skills/seed-sync/SKILL.md +0 -158
- package/claude/skills/sketch-design/REQUIREMENT.md +0 -38
- package/claude/skills/sketch-design/SKILL.md +0 -94
- package/claude/skills/ux-walkthrough/REQUIREMENT.md +0 -56
- package/claude/skills/ux-walkthrough/SKILL.md +0 -53
- package/claude/skills/ux-walkthrough/references/builds.md +0 -15
- package/claude/skills/ux-walkthrough/references/candidate-pages.md +0 -11
- package/claude/skills/ux-walkthrough/references/measuring.md +0 -22
- package/claude/skills/ux-walkthrough/references/record.md +0 -36
- package/claude/skills/ux-walkthrough/references/relay.md +0 -25
- package/docs/agents/architecture-record.md +0 -36
- package/docs/agents/review-classification.md +0 -76
- package/governance/rules/canon/603-memory.md +0 -11
- package/governance/rules/lang/120-bash.md +0 -18
- package/governance/rules/standards/architecture.md +0 -13
- package/governance/rules/standards/context.md +0 -14
- package/governance/rules/standards/design.md +0 -12
- package/governance/rules/standards/groundwork.md +0 -13
- package/governance/rules/standards/intake.md +0 -12
- package/governance/rules/standards/memory.md +0 -12
- package/governance/rules/standards/readme.md +0 -12
- package/governance/rules/standards/ready.md +0 -13
- package/governance/rules/standards/requirements.md +0 -12
- package/governance/rules/standards/rule.md +0 -13
- package/governance/rules/standards/session.md +0 -13
- package/governance/rules/standards/skill.md +0 -21
- package/governance/rules/standards/standard.md +0 -13
- package/governance/rules/standards/tasks.md +0 -15
- package/governance/rules/standards/teach.md +0 -14
- package/governance/rules/standards/wiki.md +0 -13
- package/governance/rules/standards/wireframes.md +0 -13
- package/scripts/config.sh +0 -11
- package/scripts/lib/gov.sh +0 -14
- package/scripts/lib/sandbox-fixtures.sh +0 -191
- package/scripts/lib/sandbox-git.sh +0 -125
- package/scripts/lib/sandbox-path.sh +0 -50
- package/scripts/sandbox-hook.sh +0 -99
- package/src/autoship/classify.ts +0 -75
- package/src/autoship/paths.ts +0 -50
- package/src/commands/autoship.ts +0 -129
- package/src/commands/repo.ts +0 -393
- package/src/context/architecture.ts +0 -654
- package/src/context/wireframe-states.ts +0 -238
- package/src/gov/standard-rules.ts +0 -179
- package/src/records/migrate.ts +0 -78
- package/src/records/stale.ts +0 -243
- package/src/repo/metadata.ts +0 -206
- package/src/sandbox/hooks.ts +0 -128
- package/standards/architecture.md +0 -127
- package/standards/memory.md +0 -158
- package/standards/mermaid.md +0 -64
- package/standards/requirements.md +0 -79
- package/standards/wiki.md +0 -77
- package/standards/wireframes.md +0 -143
- package/tooling/claude/seeds/.claude/memory/index.md +0 -8
- package/tooling/claude/seeds/canon/ARCHITECTURE.md +0 -23
- package/tooling/claude/seeds/canon/wireframes/index.md +0 -8
- /package/{standards → claude/skills/create-skill/references}/skill-practice.md +0 -0
- /package/{standards → claude/skills/create-skill/references}/skill-requirement.md +0 -0
- /package/{standards → claude/skills/draft-figure/references}/figures.md +0 -0
- /package/{standards → claude/skills/git-branch/references}/slug.md +0 -0
- /package/{standards → claude/skills/git-commit/references}/commit.md +0 -0
- /package/{standards → claude/skills/git-commit/references}/versioning.md +0 -0
- /package/{standards → claude/skills/plan-feature/references}/plan-lifecycle.md +0 -0
- /package/{standards → claude/skills/plan-groundwork/references}/groundwork-spikes.md +0 -0
- /package/{standards → claude/skills/task-board/references}/tasks-decline.md +0 -0
- /package/{standards → claude/skills/teach-workspace/references}/glossary.md +0 -0
|
@@ -1,118 +0,0 @@
|
|
|
1
|
-
<!doctype html>
|
|
2
|
-
<html lang="en" data-theme="light">
|
|
3
|
-
<head>
|
|
4
|
-
<meta charset="utf-8" />
|
|
5
|
-
<title>Draft and pick frame</title>
|
|
6
|
-
<style>
|
|
7
|
-
:root {
|
|
8
|
-
--bg: #f4f4f5;
|
|
9
|
-
--fg: #18181b;
|
|
10
|
-
--bar: #ffffff;
|
|
11
|
-
--line: #d4d4d8;
|
|
12
|
-
}
|
|
13
|
-
:root[data-theme='dark'] {
|
|
14
|
-
--bg: #18181b;
|
|
15
|
-
--fg: #f4f4f5;
|
|
16
|
-
--bar: #27272a;
|
|
17
|
-
--line: #3f3f46;
|
|
18
|
-
}
|
|
19
|
-
* {
|
|
20
|
-
box-sizing: border-box;
|
|
21
|
-
}
|
|
22
|
-
body {
|
|
23
|
-
margin: 0;
|
|
24
|
-
height: 100vh;
|
|
25
|
-
display: flex;
|
|
26
|
-
flex-direction: column;
|
|
27
|
-
background: var(--bg);
|
|
28
|
-
color: var(--fg);
|
|
29
|
-
font-family: system-ui, sans-serif;
|
|
30
|
-
font-size: 14px;
|
|
31
|
-
}
|
|
32
|
-
header {
|
|
33
|
-
display: flex;
|
|
34
|
-
gap: 12px;
|
|
35
|
-
align-items: center;
|
|
36
|
-
padding: 8px 12px;
|
|
37
|
-
background: var(--bar);
|
|
38
|
-
border-bottom: 1px solid var(--line);
|
|
39
|
-
}
|
|
40
|
-
select,
|
|
41
|
-
button {
|
|
42
|
-
font: inherit;
|
|
43
|
-
color: inherit;
|
|
44
|
-
background: var(--bg);
|
|
45
|
-
border: 1px solid var(--line);
|
|
46
|
-
border-radius: 4px;
|
|
47
|
-
padding: 4px 8px;
|
|
48
|
-
}
|
|
49
|
-
main {
|
|
50
|
-
flex: 1;
|
|
51
|
-
overflow: auto;
|
|
52
|
-
display: flex;
|
|
53
|
-
justify-content: center;
|
|
54
|
-
padding: 12px;
|
|
55
|
-
}
|
|
56
|
-
iframe {
|
|
57
|
-
width: 100%;
|
|
58
|
-
height: 100%;
|
|
59
|
-
border: 1px solid var(--line);
|
|
60
|
-
background: #fff;
|
|
61
|
-
}
|
|
62
|
-
</style>
|
|
63
|
-
</head>
|
|
64
|
-
<body>
|
|
65
|
-
<header>
|
|
66
|
-
<label
|
|
67
|
-
>Page
|
|
68
|
-
<select id="picker"></select
|
|
69
|
-
></label>
|
|
70
|
-
<button id="theme" type="button">Theme: light</button>
|
|
71
|
-
<span>F12 device toolbar to resize</span>
|
|
72
|
-
</header>
|
|
73
|
-
<main><iframe id="page" title="Candidate page"></iframe></main>
|
|
74
|
-
<!-- The skill replaces the token below with one JSON object: {"themeKey": "<key the arms read>", "rounds": [{"label": "...", "pages": [{"label": "...", "src": "<path relative to this file>"}]}]} -->
|
|
75
|
-
<script type="application/json" id="frame-data">
|
|
76
|
-
__FRAME_DATA__
|
|
77
|
-
</script>
|
|
78
|
-
<script>
|
|
79
|
-
const data = JSON.parse(document.getElementById('frame-data').textContent)
|
|
80
|
-
const picker = document.getElementById('picker')
|
|
81
|
-
const themeButton = document.getElementById('theme')
|
|
82
|
-
const frame = document.getElementById('page')
|
|
83
|
-
let theme = 'light'
|
|
84
|
-
|
|
85
|
-
for (const round of data.rounds) {
|
|
86
|
-
for (const page of round.pages) {
|
|
87
|
-
const option = document.createElement('option')
|
|
88
|
-
option.value = page.src
|
|
89
|
-
option.textContent = round.label + ' · ' + page.label
|
|
90
|
-
picker.append(option)
|
|
91
|
-
}
|
|
92
|
-
}
|
|
93
|
-
|
|
94
|
-
// A page that stores its own theme and reads it back on load overwrites the
|
|
95
|
-
// attribute alone, so write the stored key as well as the attribute.
|
|
96
|
-
function applyTheme() {
|
|
97
|
-
document.documentElement.dataset.theme = theme
|
|
98
|
-
themeButton.textContent = 'Theme: ' + theme
|
|
99
|
-
try {
|
|
100
|
-
const win = frame.contentWindow
|
|
101
|
-
win.document.documentElement.setAttribute('data-theme', theme)
|
|
102
|
-
win.localStorage.setItem(data.themeKey, theme)
|
|
103
|
-
} catch {}
|
|
104
|
-
}
|
|
105
|
-
|
|
106
|
-
picker.addEventListener('change', () => {
|
|
107
|
-
frame.src = picker.value
|
|
108
|
-
})
|
|
109
|
-
themeButton.addEventListener('click', () => {
|
|
110
|
-
theme = theme === 'light' ? 'dark' : 'light'
|
|
111
|
-
applyTheme()
|
|
112
|
-
})
|
|
113
|
-
frame.addEventListener('load', applyTheme)
|
|
114
|
-
|
|
115
|
-
if (picker.options.length > 0) frame.src = picker.value
|
|
116
|
-
</script>
|
|
117
|
-
</body>
|
|
118
|
-
</html>
|
|
@@ -1,48 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
title: Wireframes kind
|
|
3
|
-
description: The root check, tree-walk guard, tier detection, transcription and role-intent modes, and regen folder for a brand-new wireframe surface, read by draft-doc once the request resolves to the wireframes kind
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Wireframes kind
|
|
7
|
-
|
|
8
|
-
`draft-doc` reads this file when the request resolves to a surface under `canon/wireframes/`. An existing surface is edited directly, since no skill owns a full rewrite of one.
|
|
9
|
-
|
|
10
|
-
This kind stays independent of `context-fold`'s wireframe coverage sweep, which writes only a bare `TODO` stub for a surface a diff touched and reports drift against one a wireframe already covers. Neither the stub nor the drift check is a draft, and this kind never reads or writes through that mechanism.
|
|
11
|
-
|
|
12
|
-
## Root
|
|
13
|
-
|
|
14
|
-
A project the surface move has not reached keeps its wireframes folder under `.claude/` rather than `canon/`. Walk and write at whichever root already carries the folder, and create it under `canon/` only when neither does, since a new `canon/` folder would hide every surface the old one holds. `<wireframes-root>` below names the root this check settled.
|
|
15
|
-
|
|
16
|
-
## Guards
|
|
17
|
-
|
|
18
|
-
- Derive a kebab-case slug from the surface. Walk the whole `<wireframes-root>` tree, including a surface nested inside a grouped subfolder, rather than checking the top level alone. A match at any depth means the surface already has a file. Stop: `❌ <path> already covers this surface. Edit it directly; this skill only drafts a surface with no file yet.`
|
|
19
|
-
|
|
20
|
-
## Placement
|
|
21
|
-
|
|
22
|
-
- Check every title and description in `<wireframes-root>/index.md` against the surface, and stop the same way on a match.
|
|
23
|
-
- Place the file at `<wireframes-root>/<slug>.md`, or inside a grouped subfolder only when the surface belongs beside siblings that already share one.
|
|
24
|
-
|
|
25
|
-
## Tier detection
|
|
26
|
-
|
|
27
|
-
- Read `canon/DESIGN.md` and every existing wireframe file for a tier signal: an Excalidraw or Figma reference, or a marker naming one of them.
|
|
28
|
-
- Always draft the regions-and-states shape regardless of what is detected, since that is the only shape any shipped mechanism produces. Report a higher tier rather than attempting a companion render for it.
|
|
29
|
-
- Default silently to tier 0 when nothing is detected.
|
|
30
|
-
|
|
31
|
-
## Draft
|
|
32
|
-
|
|
33
|
-
- Decide the mode before drafting. When the surface names an already-built component or file, open that source and draft in transcription mode, citing the render function, the stylesheet rule, or the built file each region and label traces to, per the standard's Transcription-wireframes section.
|
|
34
|
-
- Draft in role-intent mode otherwise: label each region by its role, never by a class name or a token value.
|
|
35
|
-
- Draft `title` and `description` frontmatter, then a lead paragraph naming what the surface is for and what it covers, then `## Regions` as a bullet list naming every region and where it sits relative to the others.
|
|
36
|
-
- Draw an ASCII `plaintext` fence with `←` role annotations only when the layout is not built yet. Skip the fence in transcription mode, which already cites the built source instead.
|
|
37
|
-
- Draft `## States` as a table listing every state a visitor can reach, what reaches it, what it shows in words, and its evidence folder, reading `not captured` in the evidence cell until a capture lands.
|
|
38
|
-
- Follow with `## Copy`, `## Behavior`, and `## Not on this surface`, against the standard's template.
|
|
39
|
-
- Give a layout that changes across a breakpoint or state its own entry in the regions list, named by what triggers it, never for a spacing difference alone.
|
|
40
|
-
- Leave out algorithms, event-handler code, framework prop or class names outside transcription mode, and anything else the standard sends to a context entry instead.
|
|
41
|
-
|
|
42
|
-
## Preview
|
|
43
|
-
|
|
44
|
-
Add `**Detected tier:** <tier-0 | tier-1 | tier-2 | none detected>` and the mode, and confirm both with the path, since each is a judgment call.
|
|
45
|
-
|
|
46
|
-
## Write
|
|
47
|
-
|
|
48
|
-
Run `canon markdown audit` against the prose outside the fenced block. Regenerate `<wireframes-root>`, so the surface appears in its `index.md` at once.
|
|
@@ -1,47 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: markdown-propose
|
|
3
|
-
description: Why a markdown rewrite is proposed per file and answered before anything applies, rather than edited live or argued in chat
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Markdown propose requirement
|
|
7
|
-
|
|
8
|
-
## Gap
|
|
9
|
-
|
|
10
|
-
Rewriting a passage in a governing document today means editing it live or arguing in chat, and two surfaces sit near this moment without covering it. `canon markdown audit` measures bans and structural checkpoints from package data.
|
|
11
|
-
|
|
12
|
-
`review-branch` reports findings on a diff someone already wrote. Neither drafts a replacement, carries an answer slot, or waits.
|
|
13
|
-
|
|
14
|
-
A review delivered in chat gets applied from memory across files nobody reopened, and nothing records which changes the operator approved. A change nobody agreed to either lands unreviewed, because the session acting on a chat review cannot tell an approved line from an inferred one, or never gets written down at all, because a finding with no draft behind it hands the rewrite back to whoever reads it next.
|
|
15
|
-
|
|
16
|
-
A second failure compounds the first. A claim copied across several files is corrected in the one a session happened to open, and the copies elsewhere now read as freshly reviewed while still disagreeing, since nothing reconciles a restatement against the source it was drawn from.
|
|
17
|
-
|
|
18
|
-
## Must
|
|
19
|
-
|
|
20
|
-
- Take the concern and the surface as inputs and run one procedure against them, so a second concern reuses this skill rather than forking it
|
|
21
|
-
- Grep the named surface for the concern before proposing, so a defect's site count is measured rather than assumed
|
|
22
|
-
- Draft the replacement text, not only the finding
|
|
23
|
-
- Carry three labelled variants on a change whose replacement was invented, and one on a change that corrects text to a recorded fact
|
|
24
|
-
- Write one proposal file per source file under `.canon/proposals/<nn>-<slug>/` and stop, leaving `You:` empty on every change
|
|
25
|
-
- Apply only a change carrying an answer, one file at a time, and re-grep its anchor before applying it
|
|
26
|
-
- Report what each file leaves alone, so a proposal cannot be read as finding everything wanting
|
|
27
|
-
|
|
28
|
-
## Must not
|
|
29
|
-
|
|
30
|
-
- Edit a source file during the Propose phase
|
|
31
|
-
- Apply an unanswered change, or a subset of a file's answered changes while leaving the rest for later
|
|
32
|
-
- Fill a `You:` slot, or infer a disposition from an empty one
|
|
33
|
-
- Name a specific concern in this skill's own procedure. A concern belongs in the invocation, and hardcoding one narrows the skill to the day it was written.
|
|
34
|
-
- Assume the skill earns its place because the gap is real. Whether anything invokes it beyond the operator typing its name has no answer at creation time, and is a review criterion to read against a later usage census rather than a gate this file can pass on its own.
|
|
35
|
-
|
|
36
|
-
## Guards
|
|
37
|
-
|
|
38
|
-
- No concern named and none derivable: stop rather than inferring one
|
|
39
|
-
- No surface named and none derivable: stop rather than screening the whole tree
|
|
40
|
-
- The concern resolves to one file: stop and say a single-file change needs no proposal folder
|
|
41
|
-
|
|
42
|
-
## Out of scope
|
|
43
|
-
|
|
44
|
-
- Reporting a violation with no drafted replacement, which `canon markdown audit` already owns
|
|
45
|
-
- Reviewing a diff someone already wrote, which `review-branch` owns
|
|
46
|
-
- Filing a raw brain dump as findings, which `plan-intake` owns
|
|
47
|
-
- Reviewing `.canon/memory/` and proposing promote-or-retire actions per entry, which `memory-review` owns on a different subject with a different answer contract
|
|
@@ -1,122 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: markdown-propose
|
|
3
|
-
description: Reviews a named markdown surface against a named concern, drafts a per-file proposal under `.canon/proposals/<nn>-<slug>/` carrying a diff and a reason for each change, and stops without editing a source file. Takes the concern and the surface as inputs, such as a claim stated stronger than the record, a fact gone stale, two files disagreeing, or a passage duplicated without derivation. A later invocation applies what the operator answered. Use when asked to "propose a change to CLAUDE.md", "draft a rewrite of this standard", "propose fixes to this doc", "draft alternatives for this passage", or "apply the answered proposals". Do NOT use to report without drafting a replacement (`canon markdown audit`), to review a diff already made (`review-branch`), or to file a raw brain dump as findings (`plan-intake`).
|
|
4
|
-
metadata:
|
|
5
|
-
family: check
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Markdown propose
|
|
9
|
-
|
|
10
|
-
Reviews what a markdown surface says against a named concern and proposes what it should say instead. Writes proposals and stops. The operator answers per change, and a later invocation applies the answered set.
|
|
11
|
-
|
|
12
|
-
The value is the gate. A rewrite delivered in chat gets applied from memory across files nobody reopened, and nothing records what was approved.
|
|
13
|
-
|
|
14
|
-
## Guards
|
|
15
|
-
|
|
16
|
-
- No concern named and none derivable from the conversation. Stop: `❌ No concern to screen for. Name what looks wrong, or the surface to review.`
|
|
17
|
-
- No surface named and none derivable. Stop: `❌ No surface to review. Name the files, or the folder, to screen.`
|
|
18
|
-
- The concern resolves to one file only. Stop and say so: a single-file change needs no proposal folder.
|
|
19
|
-
- A named file cannot be read. Stop and name it. Do not screen what resolved and report a partial result.
|
|
20
|
-
|
|
21
|
-
## Phase detection
|
|
22
|
-
|
|
23
|
-
Two phases share this body, picked by whether a proposal folder already exists for the request's slug.
|
|
24
|
-
|
|
25
|
-
Derive `<slug>` from the concern and the surface, kebab-case, naming the subject rather than the activity. List `.canon/proposals/` at the main worktree root and match the topic against the slug half of each `<nn>-<slug>` folder already there before deriving a fresh one, the same way `plan-intake` matches its own folder. Never match against `.claude/` itself.
|
|
26
|
-
|
|
27
|
-
With no match, a fresh folder takes the next ordinal in `.canon/proposals/`'s own sequence: list the folders present, take the highest `<nn>`, and increment it, starting at `01` when none exist. That sequence is independent of the one `intake` and `groundwork` share, so a proposals folder never reads or claims from theirs.
|
|
28
|
-
|
|
29
|
-
- No matching folder, or the operator names a concern and a surface: **Propose**.
|
|
30
|
-
- A matching folder exists and the operator says apply, ship, or commit the answers: **Apply**.
|
|
31
|
-
|
|
32
|
-
All `.canon/proposals/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
|
|
33
|
-
|
|
34
|
-
## Write scope
|
|
35
|
-
|
|
36
|
-
Write only inside `.canon/proposals/<nn>-<slug>/`. A source file, a standard, a rule, and a plan all live outside that folder, so this one rule forbids every one of them during the Propose phase. The Apply phase is the one exception, and only for a change carrying a `You:` answer.
|
|
37
|
-
|
|
38
|
-
## Concerns
|
|
39
|
-
|
|
40
|
-
The concern is an input, not a flow toggle. The passes below are one procedure and the concern decides what pass 1 looks for.
|
|
41
|
-
|
|
42
|
-
| Concern | What it looks like |
|
|
43
|
-
| ------------- | -------------------------------------------------------------------- |
|
|
44
|
-
| Inflation | a claim stated stronger than the record supports |
|
|
45
|
-
| Staleness | a fact correct when written and wrong now, usually a date or a count |
|
|
46
|
-
| Contradiction | two files, or two sections, asserting incompatible things |
|
|
47
|
-
| Duplication | one passage copied across files with no derivation, drifting apart |
|
|
48
|
-
|
|
49
|
-
The operator may name a concern outside this table. Run the same procedure against it.
|
|
50
|
-
|
|
51
|
-
## Propose phase
|
|
52
|
-
|
|
53
|
-
Read `${CLAUDE_SKILL_DIR}/references/format.md` before writing anything. Do not work the proposal format from memory.
|
|
54
|
-
|
|
55
|
-
### 1. Find the sites
|
|
56
|
-
|
|
57
|
-
Grep the named surface for the concern and its near-variants. A defect rarely repeats verbatim, so search the habit rather than the string.
|
|
58
|
-
|
|
59
|
-
Count hits per file before reading them. A file with one hit and a file with eight are different problems.
|
|
60
|
-
|
|
61
|
-
### 2. Find what it should say
|
|
62
|
-
|
|
63
|
-
Read whatever the operator names as the authoritative source for the concern. Absent one, grep the rest of the tree for a passage already stating the corrected form, since a correct version often already exists somewhere the defect has not reached.
|
|
64
|
-
|
|
65
|
-
Report a file that contradicts itself. A file holding both the defect and its corrected form is the strongest finding available, because the replacement is already drafted somewhere in the tree and needs no invention.
|
|
66
|
-
|
|
67
|
-
### 3. Judge per line, not per match
|
|
68
|
-
|
|
69
|
-
A matched string means different things in different registers. A word describing a mechanism is a fact about how something works. The same word describing reach is a claim about who relies on it. Sweeping both because they share a string is what makes the next pass harder to trust.
|
|
70
|
-
|
|
71
|
-
### 4. Write the proposals
|
|
72
|
-
|
|
73
|
-
One file per source file under `.canon/proposals/<nn>-<slug>/`, per `${CLAUDE_SKILL_DIR}/references/format.md`.
|
|
74
|
-
|
|
75
|
-
Draft the replacement text. A proposal reporting a problem without a replacement hands the work back rather than doing it.
|
|
76
|
-
|
|
77
|
-
Carry an `Open:` on any change whose replacement was written rather than corrected, and give it three variants per the format reference. Correcting an overstatement to the recorded fact has one answer. Inventing a paragraph has no right answer, and one draft asks the operator to veto instead of to choose, which costs a round every time the intent lands wrong.
|
|
78
|
-
|
|
79
|
-
Separate the two kinds before drafting. A change that deletes a claim the record does not support is cheap and rarely argued. A change that writes new prose is where the effort belongs.
|
|
80
|
-
|
|
81
|
-
Close each file with what it leaves alone, and say why those lines survived.
|
|
82
|
-
|
|
83
|
-
### 5. Report
|
|
84
|
-
|
|
85
|
-
Name the count, the files, and the single highest-value change. Point at the folder and stop.
|
|
86
|
-
|
|
87
|
-
Do not edit a source file. Do not fill a `You:` slot.
|
|
88
|
-
|
|
89
|
-
Propose in dependency order and state it in `00-overview.md` when the surface spans more than two files. A file other files quote is settled first, otherwise the same wording gets decided twice.
|
|
90
|
-
|
|
91
|
-
## Apply phase
|
|
92
|
-
|
|
93
|
-
Read `${CLAUDE_SKILL_DIR}/references/format.md` before applying anything, if this session has not already read it this pass.
|
|
94
|
-
|
|
95
|
-
Follow the Applying section there: one file at a time in settle order, every answered change in that file and nothing unanswered, re-grepping each anchor before applying it, sweeping the other named surfaces for the same claim before committing, and moving an applied change into `applied.md`.
|
|
96
|
-
|
|
97
|
-
Report the counts once the pass stops: files committed, changes applied, changes still carrying an empty `You:`. Leave the folder in place. Neither phase deletes it.
|
|
98
|
-
|
|
99
|
-
## Output
|
|
100
|
-
|
|
101
|
-
Chat output is the report. This skill persists only the proposal folder itself.
|
|
102
|
-
|
|
103
|
-
```plaintext
|
|
104
|
-
📂 Opened .canon/proposals/<nn>-<slug>/
|
|
105
|
-
|
|
106
|
-
**Screened:** <N> files, <N> changes proposed, <N> carrying three variants
|
|
107
|
-
|
|
108
|
-
**Highest value:** <the single strongest change, one line>
|
|
109
|
-
|
|
110
|
-
Next: answer the `You:` slots in the files under .canon/proposals/<nn>-<slug>/,
|
|
111
|
-
then re-invoke this skill to apply what you answered.
|
|
112
|
-
```
|
|
113
|
-
|
|
114
|
-
Use `📂 Resumed` in place of `📂 Opened` on a resume pass. The Apply phase reports instead:
|
|
115
|
-
|
|
116
|
-
```plaintext
|
|
117
|
-
✅ Applied .canon/proposals/<nn>-<slug>/
|
|
118
|
-
|
|
119
|
-
**Committed:** <N> files, <N> changes
|
|
120
|
-
|
|
121
|
-
**Still open:** <N> changes with an empty `You:`
|
|
122
|
-
```
|
|
@@ -1,118 +0,0 @@
|
|
|
1
|
-
# Proposal format reference
|
|
2
|
-
|
|
3
|
-
Governs the proposal `markdown-propose` writes before it edits anything. The concern being screened is an input and does not change the format.
|
|
4
|
-
|
|
5
|
-
## Contents
|
|
6
|
-
|
|
7
|
-
- [Folder](#folder)
|
|
8
|
-
- [Change format](#change-format)
|
|
9
|
-
- [The answer contract](#the-answer-contract)
|
|
10
|
-
- [Applying](#applying)
|
|
11
|
-
- [After](#after)
|
|
12
|
-
- [Retrieval](#retrieval)
|
|
13
|
-
|
|
14
|
-
## Folder
|
|
15
|
-
|
|
16
|
-
- One folder per screening pass at `.canon/proposals/<nn>-<slug>/`, where the slug names the subject rather than the activity
|
|
17
|
-
- One proposal file per source file, named `<nn>-<source filename, its own extension dropped>.md`, so a source already named `CLAUDE.md` becomes `01-CLAUDE.md` rather than `01-CLAUDE.md.md`
|
|
18
|
-
- `00-overview.md` when the pass spans more than two source files, holding the cross-file pattern, the change counts, and the settle order
|
|
19
|
-
- `applied.md` once the first change lands, holding every applied change with its reason and the answer it carried
|
|
20
|
-
|
|
21
|
-
The folder's own `<nn>` and a proposal file's own `<nn>` are two independent counters. The folder's ordinal records when the pass was opened, counted within `.canon/proposals/` alone rather than shared with `plan-groundwork` or `plan-intake`'s sequence, and a proposal file's ordinal inside it records settle order, the dependency order changes apply in. Reading one as the other gets a pass dated wrong or an apply ordered wrong.
|
|
22
|
-
|
|
23
|
-
The name carries both structures the folder has. The basename pairs a proposal to its source so a reader opens the two side by side, and the number is the settle order, which is a dependency rather than a preference: a file other files quote is settled first. Do not group proposals by theme.
|
|
24
|
-
|
|
25
|
-
A proposal opened after the initial pass takes the next free number, and the folder is never renumbered. Its number records when the site was found rather than where it belongs in the dependency order. Renumbering to restore the order would rewrite the names of files already carrying answers, which costs more than the ordering is worth once applying has started.
|
|
26
|
-
|
|
27
|
-
Settle a late proposal ahead of any unapplied proposal quoting the surface it covers, whatever the two numbers say. A proposal already applied is past the question, since the file it governs is committed.
|
|
28
|
-
|
|
29
|
-
## Change format
|
|
30
|
-
|
|
31
|
-
Each proposal file opens with `# Proposal: <source path>`, one line naming the concern, the settle order, and the full surface the pass screened, then one `###` heading per change, ending with a `## Left alone` section. A change never sits at `##`, which the closing section reserves, and a variant never sits at `###`, which the change heading reserves. Skipping from `#` straight to `###` is deliberate: the file has exactly one layer of change between its title and its variants.
|
|
32
|
-
|
|
33
|
-
Naming the surface on every file, not only the first, is what lets Applying's cross-surface grep run cold. The Propose and Apply invocations are typically separate sessions days apart, so the surface the operator named has to survive on the file rather than in a conversation neither session shares.
|
|
34
|
-
|
|
35
|
-
A change carries an `###` heading, a fenced `diff` block holding the current text against the proposed, the reason beneath it, and its own answer slot.
|
|
36
|
-
|
|
37
|
-
- Heading: `### N. The sentence or section it sits in`
|
|
38
|
-
- Body: a `diff` fence, `-` for current and `+` for proposed
|
|
39
|
-
- `- **Why:** the reason, naming what the change fixes`
|
|
40
|
-
- `- **Open:** only where the replacement was drafted rather than corrected`
|
|
41
|
-
- `- **Recommended:** only where a pick is proposed ahead of the answer, directly above the slot`
|
|
42
|
-
- `- **You:**` last on every change, shipped empty
|
|
43
|
-
|
|
44
|
-
### Variants
|
|
45
|
-
|
|
46
|
-
A corrected change carries one replacement. A drafted one carries three, because the intent behind invented prose is not recoverable from the source text and a single draft turns the answer slot into a veto.
|
|
47
|
-
|
|
48
|
-
- Ship three variants on any change carrying `Open:`, labelled `#### A`, `#### B`, `#### C`
|
|
49
|
-
- Make them differ in approach rather than in wording. Three phrasings of one bet are one variant.
|
|
50
|
-
- State the bet each one makes in a line above its block, so the choice is between strategies and not between paragraphs
|
|
51
|
-
- Ship one replacement everywhere else. A word swapped for the recorded fact has no second option worth reading.
|
|
52
|
-
|
|
53
|
-
Three is the cap as well as the count. A fourth splits attention without widening the space.
|
|
54
|
-
|
|
55
|
-
### Placement
|
|
56
|
-
|
|
57
|
-
- Title a change by the section or sentence it sits in, never by its position in the file
|
|
58
|
-
- Quote text from another file in a `markdown` block rather than citing a line number, which goes stale on the first applied change
|
|
59
|
-
- Split a `Why:` into labelled halves when one change fixes two things (`**Why, the date:**`)
|
|
60
|
-
- Carry an `Open:` on any change whose replacement text was written rather than corrected, so a blanket answer cannot swallow it
|
|
61
|
-
|
|
62
|
-
Close each file with what it leaves alone. A pass reporting only what it would change reads as one that found everything wanting.
|
|
63
|
-
|
|
64
|
-
## The answer contract
|
|
65
|
-
|
|
66
|
-
`You:` belongs to the operator and ships empty on every change. Empty means unread and never agreement, matching the intake contract in `${CLAUDE_SKILL_DIR}/../../standards/intake.md` rather than the plan file's, which reads a blank slot as accepting the suggestion above it. State the inversion at the top of `00-overview.md` when the folder spans more than one file, since a contract read from the wrong surface gets applied to the wrong document.
|
|
67
|
-
|
|
68
|
-
- One `You:` per change, last in its bullet list, so an answer lands where the change is read
|
|
69
|
-
- Never fill a `You:` slot and never infer a disposition from an empty one
|
|
70
|
-
- The slot takes free text, not only `ok`. A rejection, a caveat, or a rewrite of the proposed line are all valid answers and a later pass reads them correctly.
|
|
71
|
-
- A pick made on the operator's behalf goes on a `- **Recommended:**` line directly above the slot, never inside it, and states which variant it takes and why. The slot below it still ships empty, so a count of unread changes still reads the change as unread.
|
|
72
|
-
|
|
73
|
-
An answer rejecting the draft reopens the change rather than closing it. Move that answer to a `- **Answered:**` line above the variants it produced, and ship a fresh empty `- **You:**` beneath them. The change reads as unread again, which is what it is.
|
|
74
|
-
|
|
75
|
-
Per-change slots do not license a partial sweep. Answering a change records one decision, and the applying rule below is what holds the set together.
|
|
76
|
-
|
|
77
|
-
The overview file carries no slot, since it proposes no changes.
|
|
78
|
-
|
|
79
|
-
## Applying
|
|
80
|
-
|
|
81
|
-
- Apply one file at a time, in the folder's settle order
|
|
82
|
-
- Apply every change in that file that carries an answer, and nothing that does not
|
|
83
|
-
- Re-grep each change's anchor against its source before applying it, and again after a rebase
|
|
84
|
-
- Grep the other named surfaces for the same claim before committing the file
|
|
85
|
-
- Write every hit that grep returns onto the proposal owning the file it sits in, as a change with its own answer slot, and open a proposal for a surface the pass has none for
|
|
86
|
-
- Commit the file once its own answered changes are applied. A hit in a sibling never holds it.
|
|
87
|
-
- Move an applied change into `applied.md` beside the proposals, carrying its reason and its answer
|
|
88
|
-
|
|
89
|
-
A partial pass is worse than none, and a file is the unit that can be finished. Settling one claim across every file at once touches all of them and closes none, so each file ends the pass looking reviewed while other changes in it sit answered and unapplied. The surface grep is what covers the cross-file half a per-file pass would otherwise miss.
|
|
90
|
-
|
|
91
|
-
Recording a hit rather than acting on it is what keeps the grep from rebuilding the whole-set gate. A sibling holding the same claim is a change nobody has answered yet, and holding this file until it is answered makes every file wait on the slowest one, which is the shape the per-file unit replaced.
|
|
92
|
-
|
|
93
|
-
A proposal outlives its own diff. The source moves under it, so an approved change stops matching while the defect it names survives in fresh wording. The anchor re-grep is the only thing that catches that.
|
|
94
|
-
|
|
95
|
-
## After
|
|
96
|
-
|
|
97
|
-
- Strip the `diff` blocks
|
|
98
|
-
- Keep the files, their headings, their reasons, and the answers
|
|
99
|
-
|
|
100
|
-
What remains is the record of what changed and why, which is the half no commit message holds. The folder stays where it is, beside every earlier pass, so a later one reads what an earlier one settled instead of asking it again.
|
|
101
|
-
|
|
102
|
-
The folder is gitignored, and backed wherever a records remote is configured. It carries decision state rather than generated data, which is why `src/records/backup.ts` names it in `BACKED_FOLDERS` so `canon records push` and `canon records pull` carry it there, refusing with `no-remote` otherwise, but nothing else about its contents is enforced.
|
|
103
|
-
|
|
104
|
-
## Retrieval
|
|
105
|
-
|
|
106
|
-
Count the unread changes per file:
|
|
107
|
-
|
|
108
|
-
```bash
|
|
109
|
-
grep -c '^- \*\*You:\*\*$' .canon/proposals/<nn>-<slug>/*.md
|
|
110
|
-
```
|
|
111
|
-
|
|
112
|
-
Report every answer given, against the change it sits under:
|
|
113
|
-
|
|
114
|
-
```bash
|
|
115
|
-
awk '/^### /{h=FILENAME": "$0} /^- \*\*You:\*\*./{print h; print " "$0}' .canon/proposals/<nn>-<slug>/*.md
|
|
116
|
-
```
|
|
117
|
-
|
|
118
|
-
Both walk `###` headings, which is the mechanical reason an answer typed anywhere else is lost.
|
|
@@ -1,50 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: memory-capture
|
|
3
|
-
description: Which surface a session fact is owed to, what earns a memory file once routing has run, and why capture never edits a context entry itself
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Memory capture requirement
|
|
7
|
-
|
|
8
|
-
## Gap
|
|
9
|
-
|
|
10
|
-
Without this skill, what a session learned dies with it, and the correction the user made in message four is re-earned next week. What does get written is a narrative of how the session went wrong rather than a rule that fires again, so a reader gets a story and no instruction. A new file lands beside one already holding the same topic, and the folder grows two entries per subject until nothing in it can be trusted as current.
|
|
11
|
-
|
|
12
|
-
Writing every fact to one folder is the deeper gap, because the folder has no reader. A fact about a domain has an owning surface already, the context entry the three-tier model loads on demand, and filing it in memory instead puts it where only a deliberate sweep will ever find it. The measured outcome is a store that grows on every ship and is drained by nothing.
|
|
13
|
-
|
|
14
|
-
The threshold is what the remaining folder lives or dies on. A first-occurrence slip saved as feedback is noise that costs every later session a read, and a fact the repository already records is worse, because it duplicates a source that will be updated without it. From a linked worktree, writes resolved against `pwd` land in a second memory folder nothing else reads.
|
|
15
|
-
|
|
16
|
-
## Must
|
|
17
|
-
|
|
18
|
-
- Resolve every read and write at the main worktree root, so parallel worktrees write one folder
|
|
19
|
-
- Classify each candidate as feedback, project, user, or reference before routing or writing
|
|
20
|
-
- Route a project candidate whose subject names an entry in `canon/context/index.md` to that entry, and hand it off as a file rather than an edit
|
|
21
|
-
- Keep a candidate that matches no entry, or two entries with no clear owner, as a memory file
|
|
22
|
-
- Apply the save threshold, firing feedback only on an explicit correction or a pattern that repeated twice
|
|
23
|
-
- Grep the folder for an existing file on the topic and update it in place rather than adding a second
|
|
24
|
-
- Keep a feedback or project body to the rule, one line of why, and one line of when it fires next
|
|
25
|
-
- Write frontmatter the index renderer can read, so the generated catalog stays current
|
|
26
|
-
- Report that nothing was worth capturing rather than manufacturing an entry to show work
|
|
27
|
-
|
|
28
|
-
## Must not
|
|
29
|
-
|
|
30
|
-
- Edit a context entry, which `context-fold` owns
|
|
31
|
-
- Route a feedback, user, or reference candidate, since no context entry owns how to work or who to ask
|
|
32
|
-
- Route anything when the caller does not commit, because a context entry is a tracked file
|
|
33
|
-
- Hand-append a row to the memory index, which is generated from sibling frontmatter
|
|
34
|
-
- Write a session narrative or a recovery account in place of the pattern
|
|
35
|
-
- Save a first-occurrence slip as feedback
|
|
36
|
-
- Create a second file on a topic the folder already holds
|
|
37
|
-
- Save what the repository already records in code, git history, or its instruction files
|
|
38
|
-
- Curate, promote, or delete an existing entry
|
|
39
|
-
|
|
40
|
-
## Guards
|
|
41
|
-
|
|
42
|
-
- No correction, confirmation, or context disclosure worth persisting: stop with a pass
|
|
43
|
-
- Memory folder absent at the main root: create it rather than stopping
|
|
44
|
-
- Session in the main worktree, or a caller that does not commit: skip routing and write every candidate as a memory file
|
|
45
|
-
|
|
46
|
-
## Out of scope
|
|
47
|
-
|
|
48
|
-
- Editing the context entries themselves, which `context-fold` owns on its own pass
|
|
49
|
-
- Curating what is already in the folder, which `memory-review` owns
|
|
50
|
-
- Promoting an entry into an instruction file or a skill body, which mutates how the agent operates and ships as its own change
|
|
@@ -1,117 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: memory-capture
|
|
3
|
-
description: Extracts durable patterns from the current session, routes a domain fact to the context entry that owns it, and writes the residue to `.canon/memory/` as feedback, project, user, or reference files. Use when asked to "capture memory", "capture lessons", "wrap up the session", "end of session memory", or as a step in autoship. Do NOT use to curate existing memory. Use `memory-review` for that.
|
|
4
|
-
metadata:
|
|
5
|
-
family: ship
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Memory capture
|
|
9
|
-
|
|
10
|
-
Scan the current session for patterns worth persisting, send each to the surface that owns it, and leave in `.canon/memory/` only what no surface owns. Pair with `memory-review` for later curation.
|
|
11
|
-
|
|
12
|
-
A fact about a domain belongs in that domain's context entry, which the three-tier model already loads on demand. Writing it to memory instead puts it in a folder nothing opens. Routing is therefore the point of this skill and the memory file is the fallback.
|
|
13
|
-
|
|
14
|
-
The filename and its type prefix, the frontmatter, the body shape each type carries, and the lifecycle are fixed by `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Read it before writing an entry and follow it rather than working the shape from memory.
|
|
15
|
-
|
|
16
|
-
## Guards
|
|
17
|
-
|
|
18
|
-
- All `.canon/memory/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
|
|
19
|
-
- Every path below sits at the main root, so each write in this skill goes out as a heredoc, routed the way `session-worktree` states. A memory entry holds one fact and this session has read it, so an update rewrites the whole file with a heredoc rather than editing a line inside it.
|
|
20
|
-
- If `.canon/memory/` does not exist at the main worktree root, create it, along with an `index.md` carrying `title` and `subtitle` frontmatter. `canon claude init` seeds both, and a project predating that seed has neither. Regeneration errors without the index, so the first write into a bare folder would report a frontmatter failure against a file that is fine.
|
|
21
|
-
- If the session produced no user corrections, confirmations, or context disclosures worth persisting, run Step 6 and stop: `✅ Nothing worth capturing.`, followed by the review line when Step 6 counted one batch due.
|
|
22
|
-
- Routing edits a tracked file, so it runs only where the caller commits. When the session is in the main worktree, or the caller states it does not commit, skip Step 3 and write every candidate as a memory file. `role-orchestrator` is the caller this covers.
|
|
23
|
-
|
|
24
|
-
## Step 1: read context
|
|
25
|
-
|
|
26
|
-
Read in parallel, skipping any that do not exist:
|
|
27
|
-
|
|
28
|
-
- `${CLAUDE_SKILL_DIR}/../../standards/memory.md`: the filename, frontmatter, body shape, and lifecycle every entry follows
|
|
29
|
-
- `CLAUDE.md`: the project's write location and any rule it states over the folder
|
|
30
|
-
- `.canon/memory/index.md`: existing index, to avoid duplicates
|
|
31
|
-
- `canon/context/index.md`: the domain catalog Step 3 routes against, read under `.claude/` instead in a project the surface move has not reached
|
|
32
|
-
- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting applied to memory file bodies
|
|
33
|
-
- The `write-human` skill: voice, rhythm, and sentence construction applied to memory file bodies
|
|
34
|
-
|
|
35
|
-
## Step 2: classify candidates
|
|
36
|
-
|
|
37
|
-
Scan the session and group candidate patterns as `feedback`, `project`, `user`, or `reference`. What each type holds and what makes one fire are the Types table in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Read the table and classify against it rather than against a recollection of the four names.
|
|
38
|
-
|
|
39
|
-
Scan the whole session rather than its last exchange. A rule the user stated early and you followed since reads as settled and is exactly the one no file records.
|
|
40
|
-
|
|
41
|
-
## Step 3: route what a context entry owns
|
|
42
|
-
|
|
43
|
-
Only a **project** candidate is routable. Feedback, user, and reference describe how to work or who to ask rather than how a domain behaves, and no context entry owns them.
|
|
44
|
-
|
|
45
|
-
For each project candidate, match its subject against `canon/context/index.md`. The test is a named entry, not a judgment about fit: the fact names a surface that already has an entry in the catalog. Route it to that entry.
|
|
46
|
-
|
|
47
|
-
Fail closed. A project candidate matching no entry stays a memory file, and so does one matching two entries where neither is clearly the owner. The residue is what the folder is for, and a fact filed under the wrong entry is worse than one in memory because a context entry is a surface sessions trust.
|
|
48
|
-
|
|
49
|
-
Do not edit a context entry here. `context-fold` owns those edits and folds the routed facts in on its own pass, or two skills write one file at the same step. Write each routed fact to `.canon/tmp/handoff/memory-routing/<slug>.md` at the main worktree root instead, appending when the file exists. Name the heading with the entry's own path from `canon/context/index.md`, flat or the nested `index.md`, since that heading is what tells `context-fold`'s routed-facts fold which file to open. An append is a whole-file operation, so send it as a heredoc:
|
|
50
|
-
|
|
51
|
-
A flat domain takes:
|
|
52
|
-
|
|
53
|
-
```markdown
|
|
54
|
-
## canon/context/<domain>.md
|
|
55
|
-
|
|
56
|
-
<the fact in one or two sentences, stated as a fact about the domain rather than as a session narrative>
|
|
57
|
-
```
|
|
58
|
-
|
|
59
|
-
A domain split into a folder takes its own generated index instead:
|
|
60
|
-
|
|
61
|
-
```markdown
|
|
62
|
-
## canon/context/<domain>/index.md
|
|
63
|
-
|
|
64
|
-
<the fact in one or two sentences, stated as a fact about the domain rather than as a session narrative>
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
|
|
68
|
-
|
|
69
|
-
The handoff is a file rather than a spoken result so the routed fact survives a compaction between this step and the `context-fold` pass, and so the standalone caller leaves something behind for a later `/context-fold` to consume.
|
|
70
|
-
|
|
71
|
-
## Step 4: dedupe
|
|
72
|
-
|
|
73
|
-
For each remaining candidate, grep the top-level `*.md` files in `.canon/memory/` for an existing file on the same topic, never its `review/` or `archive/` subfolders, since a hit there is a receipt or a retired entry rather than a live one to update. If one exists, update it in place rather than create a new file. Read it first and write the whole file back, since the guard above rules out editing a line inside it. Carry a `reviewed` field through the rewrite untouched, since dropping it sends a kept entry back to the front of the review queue.
|
|
74
|
-
|
|
75
|
-
## Step 5: write the residue
|
|
76
|
-
|
|
77
|
-
Write each remaining candidate to `.canon/memory/<type>-<slug>.md`, following the template and the shape rules in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Copy the shape from there rather than from this body, so one edit to the standard moves every entry.
|
|
78
|
-
|
|
79
|
-
Two of its rules are the ones a capture pass gets wrong under time pressure. State the rule rather than the incident that produced it, since the session ending is the only reader who has the narrative. Write the `title` as the rule itself, never as the filename stem.
|
|
80
|
-
|
|
81
|
-
Do not edit the index. `.canon/memory/index.md` is generated from sibling frontmatter by a `PostToolUse` hook, the same way the task board's index is, so a hand-appended row is drift the next regeneration discards.
|
|
82
|
-
|
|
83
|
-
A shell write skips that hook, as `session-worktree` states. Regenerate the index once after the last write when the entries went out through `Bash`:
|
|
84
|
-
|
|
85
|
-
```bash
|
|
86
|
-
canon indexes regen --no-stage --root <main-root> <main-root>/.canon/memory/index.md
|
|
87
|
-
```
|
|
88
|
-
|
|
89
|
-
Run `canon records validate memory` when the writes are done and fix what it names. It reads the whole pen rather than this session's writes, so treat a finding on a carried entry as one to fix in place rather than as a reason to stop.
|
|
90
|
-
|
|
91
|
-
## Step 6: count what review owes
|
|
92
|
-
|
|
93
|
-
Run `canon records stale memory --json` and count the entries whose `due` is true, and among them the ones carrying a non-empty `unresolved` list. Branch on the record rather than on the exit, which a shell function wrapping `canon` can flatten to zero. When the count reaches 25, one `memory-review` batch, the Output below adds the review line. Below that, add nothing.
|
|
94
|
-
|
|
95
|
-
Stay silent when the record refuses or the installed binary carries no `records stale` subcommand. This step reports and never stops the capture.
|
|
96
|
-
|
|
97
|
-
The line fires on a count rather than on every run. An unconditional prompt after each ship was tried and removed, since a review per ship costs more than it drains, and a hook would reach every session including workers that cannot act on it.
|
|
98
|
-
|
|
99
|
-
## Output
|
|
100
|
-
|
|
101
|
-
Respond with one line per fact routed, written, or updated:
|
|
102
|
-
|
|
103
|
-
- `➡️ Routed: <fact subject> → canon/context/<domain>.md` for a flat entry, or `→ canon/context/<domain>/index.md` for a nested one, matching the heading the routing file carries
|
|
104
|
-
- `✅ Wrote: .canon/memory/<file> (<type>)`
|
|
105
|
-
- `✏️ Updated: .canon/memory/<file> (<type>)`
|
|
106
|
-
|
|
107
|
-
When anything routed, add a line naming the handoff so the caller knows a `context-fold` pass is owed:
|
|
108
|
-
|
|
109
|
-
`→ Routed facts wait at .canon/tmp/handoff/memory-routing/<slug>.md. Run /context-fold to fold them in.`
|
|
110
|
-
|
|
111
|
-
Omit that line when the caller runs `context-fold` itself later in its own chain.
|
|
112
|
-
|
|
113
|
-
When Step 6 counted at least one batch due, add the review line last:
|
|
114
|
-
|
|
115
|
-
`→ <n> memory entries due for review, <m> citing a moved path. Run /canon:memory-review.`
|
|
116
|
-
|
|
117
|
-
If nothing was captured, output `✅ Nothing worth capturing.`, followed by the review line when Step 6 counted one batch due.
|