Choosing packaged rules

The plugin ships a library of tested rules. Switching one on adds its name to the use: list of AGENTLTL.yaml; the rule itself stays in the plugin and gets fixes with plugin updates. Arguments: $ARGUMENTS (--user means rules for every project, in ~/.claude/AGENTLTL.yaml).

Steps

1. List the library: run agentltl library --json. Each entry has a name, a summary, tags, in_use (already on in a file that applies here) and its rule ids.
2. Ask where the rules go, unless --user was given: this project (AGENTLTL.yaml at the project root) or every project (~/.claude/AGENTLTL.yaml). Rules for one repository's workflow (tests, deploys) usually belong to the project; personal habits (no Claude co-author, subagents on Sonnet) to every project.
3. Let the user choose. Use the AskUserQuestion tool with multiSelect: true. It takes at most 4 questions per call, and at most 4 options per question.
   • Group the entries by theme using their tags, for example "Git safety", "Files and secrets", or "Workflow and cost".
   • Each option's label is the entry's name, and its description is the summary.
   • Offer a bundle (an entry tagged bundle, such as devops-secrets, or a theme: theme-release-safety, theme-data-safety, theme-budget, theme-research, theme-human-in-the-loop) as one option that switches on all the entries it lists.
   • Mark entries already on with "(on)" in the description. Tell the user that unticking one switches it off.
   • If there are more entries than fit, ask in several rounds.
   • Without AskUserQuestion, show a numbered list and ask for the numbers.
4. Ask about strictness only if the user wants it. Every entry has a sensible default mode. To change it, use agentltl use NAME --mode warn. The modes are block, warn, ask, retry, stop and log; see the /agentltl:rules skill's reference.md.

5. Apply the choices, adding --user for every project:

   • agentltl use NAME... for the newly ticked entries;
   • agentltl unuse NAME... for the ones the user unticked.

   These commands edit only the use: list and keep the rest of the file. They create the file if it is missing.

6. Check the result: run agentltl validate. Then show the user the rules now in force, with each rule's mode and one line on what it does.
   • If a chosen rule depends on the project, say so. For example, tests-before-push knows common test runners (pytest, npm test, cargo test, make test...). If the project tests differently, offer to write a project rule with the same id: it replaces the packaged one.
   • agentltl library NAME shows a rule's YAML in full.
7. Offer to scan memory: run agentltl memory scan --json. If its counts.candidates is above 0, offer "Scan CLAUDE.md and memory for rules (N statements in M files)". If the user accepts, follow the import skill from its step 2, reusing that scan. Instructions already in memory then become rules that are enforced.

8. Offer the status line, once per machine. Claude Code shows nothing a plugin prints at startup, so the status line is where the user sees that AgentLTL is on: AgentLTL ● 4 rules · 2 block · 1 ask · 1 warn. Check ~/.claude/settings.json:

   • It has no statusLine: ask "Show AgentLTL and the number of rules in force in the status line?" If yes, run agentltl statusline --install. It changes only that key.
   • It already shows AgentLTL: say so and skip this step.
   • It has another status line: don't replace it. Show the line the install prints, which adds AgentLTL's line to the user's own script, and replace it with --force only if the user asks.

   The line appears on the next prompt; no restart is needed.

9. Offer custom rules: for anything the library and memory don't cover, use the /agentltl:rules skill to write a rule from the user's own words.

Changes apply from the next tool call. No restart is needed.