Repository navigation
docs(archdev): rules are added from a session, not proposed - #73
rob-archastro wants to merge 2 commits into
Conversation
The archdev skill now tells agents to run `archdev rules`, `rules add`, `rules edit`, `disable`, `enable` and `revert` instead of `rules propose --proposed-path`, `rules candidates` and `rules pr`. A rule is active as soon as it is added; there is no adopt_to path, rules PR or inert candidate. Plugin copies are regenerated with tools/plugin-gen. Merge with the ArchDev rules activation promote, after the CLI release that carries ArchAstro/firstlanding#19039. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
rob-archastro
left a comment
There was a problem hiding this comment.
Review at c0f5d28 (draft; merges with the activation promote, after the CLI release carrying firstlanding #19039). I read the canonical archdev/ files and the test; plugins/* are generated copies, and npm run check covers them.
The text matches the CLI and gateway on firstlanding main:
rules addtakes no path and printsadded:/edited:, and a matching name edits the existing rule.- Edit, disable, enable and revert take an
rl_id and need GitHub write access. - Revert fails with no lower source, and an edit cannot rename a rule.
- File rules have source
repositoryand a path id, and the CLI can't change them. - The listing shows active and disabled rules (retired rules are left out), and
--jsonadds layers. - monitor.md's warning not to run write verbs for a read-only question is right.
One should-fix, in references/rule-candidates.md under "Add and check": "Confirm the listing shows the rule as active." If the repository has a committed rule file with the same name, the file outranks the stored rule and the listing shows only the file (source repository). An agent following this text would conclude the add failed and retry or escalate. Add one sentence, e.g.: "If a rule file in the repository has the same name, the listing shows the file instead; the file wins until it is removed."
Nothing else.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review on ArchCode
Problem and author intent
Rules now apply as soon as they are added (firstlanding
docs/plans/2026-10-19-repo-rules-auto-apply-design.md), and #19039 replaced the candidate-era CLI verbs. The skill still tells agents to runrules propose --proposed-path, readrules candidates, open arules pr, and treat candidates as inert. Once that CLI ships, those commands no longer exist.What changed
archdev/SKILL.md: the description listsrules, rules add, rules edit, rules disable. "Rule candidates from a session" becomes "Rules from a session" (rules addmakes the rule active at once). The PR-risk section points atrules --repository.archdev/references/rule-candidates.md(file name kept so links still resolve), now titled "Adding a rule from a session":archdev --json rules;rules addwith no--proposed-path;edit/disable/enable/revert;adopt_topath, the rules PR and candidate statuses are removed.archdev/references/monitor.md: "Repository rules, not PR verdicts" usesrules --repository. It says the write verbs change later PR checks, so a read-only question never runs them.plugins/*: regenerated withtools/plugin-gen(npm run build;npm run checkreports 140 files matching the catalog).tools/plugin-gen/test/generate.test.ts: the review-queries test asserts the new listing and thatrules candidates,rules prand "inert" are gone.Risk
Low. Skill text only. The risk is timing: merged before the CLI release and the activation promote, agents would run commands that don't exist yet.
Testing
npm testintools/plugin-gen: 115/115 pass.npm run check: generated output matches the catalog.🤖 Generated with Claude Code