Skip to content

docs(archdev): rules are added from a session, not proposed - #73

Draft
rob-archastro wants to merge 2 commits into
mainfrom
docs/rules-add-skill
Draft

rob-archastro wants to merge 2 commits into
mainfrom
docs/rules-add-skill

Conversation

@rob-archastro

@rob-archastro rob-archastro commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Review on ArchCode

Draft. Merge with the ArchDev rules activation promote (firstlanding task tsk_034ipc0AM1NOxnVx973vz7), after the CLI release that carries firstlanding #19039. Before activation, added rules are stored but not checked, and the released CLI (0.54) has no rules add. Companion docs PR: firstlanding #19045.

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 run rules propose --proposed-path, read rules candidates, open a rules pr, and treat candidates as inert. Once that CLI ships, those commands no longer exist.

What changed

  • archdev/SKILL.md: the description lists rules, rules add, rules edit, rules disable. "Rule candidates from a session" becomes "Rules from a session" (rules add makes the rule active at once). The PR-risk section points at rules --repository.
  • archdev/references/rule-candidates.md (file name kept so links still resolve), now titled "Adding a rule from a session":
    • drafts start from archdev --json rules;
    • rules add with no --proposed-path;
    • a "Change a rule" section for edit/disable/enable/revert;
    • the adopt_to path, the rules PR and candidate statuses are removed.
  • archdev/references/monitor.md: "Repository rules, not PR verdicts" uses rules --repository. It says the write verbs change later PR checks, so a read-only question never runs them.
  • plugins/*: regenerated with tools/plugin-gen (npm run build; npm run check reports 140 files matching the catalog).
  • tools/plugin-gen/test/generate.test.ts: the review-queries test asserts the new listing and that rules candidates, rules pr and "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 test in tools/plugin-gen: 115/115 pass.
  • npm run check: generated output matches the catalog.

🤖 Generated with Claude Code

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 rob-archastro left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 add takes no path and prints added: / 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 repository and a path id, and the CLI can't change them.
  • The listing shows active and disabled rules (retired rules are left out), and --json adds 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant