@event4u/agent-config 5.10.1 → 6.0.0

package/dist/agent-src/commands/roadmap/process-phase.md

@@ -0,0 +1,75 @@
+---
+model_tier: medium
+name: roadmap-process-phase
+pack: product-basic
+tier: 2
+cluster: roadmap
+sub: process-phase
+skills: [agent-docs-writing, ai-council, roadmap-management]
+description: Autonomously process every open step in the next or current phase of a roadmap, then stop. Default execution scope of the /roadmap cluster.
+suggestion:
+  eligible: true
+  trigger_description: "process the next phase, finish this phase autonomously, eine phase abarbeiten"
+  trigger_context: "existing agents/roadmaps/*.md and user wants the next phase done end-to-end"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /roadmap:process-phase
+
+Default execution scope of the [`/roadmap`](../roadmap.md) cluster.
+Sibling of [`/roadmap:process-step`](process-step.md) and
+[`/roadmap:process-full`](process-full.md). Replaces the legacy
+`/roadmap execute` (which paused for confirmation before every step).
+
+## Instructions
+
+Run the canonical loop in
+[`contexts/execution/roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md)
+with the **scope delta below**. The loop file owns roadmap discovery,
+pre-run summary, cadence resolution, commit-step pre-scan, the step
+loop with AI-council branching, halt conditions, and the archival
+check.
+
+## Scope delta
+
+- **Working set:** all open steps in the **first phase with
+  `count_open > 0`**. If every phase is closed → report "Roadmap
+  already complete." and run the archival check from
+  [`roadmap-process-loop § 6`](../../contexts/execution/roadmap-process-loop.md#6-final-report-and-archival).
+- **Stop after:** the phase boundary. Do **not** advance into the next
+  phase. Use [`/roadmap:process-full`](process-full.md) for continuous
+  execution across phases.
+- **Quality cadence at the boundary:** run the per-phase pipeline when
+  `quality_cadence: per_phase` (or `per_step`). Skip when
+  `end_of_roadmap`.
+
+## Rules
+
+- **Autonomous within the phase, never beyond.** The user picks
+  `process-step` for one step or `process-full` for the whole roadmap.
+- **No commit, push, branch, PR, tag, or bulk-destructive op** without
+  explicit permission this turn — see
+  [`commit-policy`](../../rules/commit-policy.md) and
+  [`scope-control § git-ops`](../../rules/scope-control.md#git-operations--permission-gated).
+  Roadmap-listed commit steps follow the single-upfront-ask flow in
+  [`roadmap-process-loop § 3`](../../contexts/execution/roadmap-process-loop.md#3-commit-step-pre-scan--one-upfront-ask).
+- **Every checkbox edit syncs the dashboard in the same response** per
+  [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md).
+- **AI-council consultations run silently when council is on.** No
+  per-call confirmation. The opt-in covers the whole run.
+- **Decline = silence.** Once the user said "skip council", do not
+  re-offer for the rest of this run.
+- **Halt cleanly on Hard-Floor or true ambiguity.** Surface state,
+  wait. Resume on the user's next turn from the same checkbox.
+
+## See also
+
+- [`/roadmap`](../roadmap.md) — cluster orchestrator
+- [`/roadmap:process-step`](process-step.md) — single-step variant
+- [`/roadmap:process-full`](process-full.md) — across-phases variant
+- [`/roadmap:create`](create.md) — sibling, scaffolds roadmaps
+- [`roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md) — canonical mechanics
+- [`roadmap-management`](../../skills/roadmap-management/SKILL.md) — checkbox + archival mechanics

package/dist/agent-src/commands/roadmap/process-step.md

@@ -0,0 +1,63 @@
+---
+model_tier: medium
+name: roadmap-process-step
+pack: product-basic
+tier: 2
+cluster: roadmap
+sub: process-step
+skills: [agent-docs-writing, ai-council, roadmap-management]
+description: Autonomously process the single next open step of a roadmap and stop. Smallest execution scope of the /roadmap cluster — one step in, one step out.
+suggestion:
+  eligible: true
+  trigger_description: "process the next step, do the next roadmap step, einen schritt abarbeiten"
+  trigger_context: "existing agents/roadmaps/*.md and user wants exactly one step done autonomously"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /roadmap:process-step
+
+One-step execution scope of the [`/roadmap`](../roadmap.md) cluster.
+Same canonical loop as [`/roadmap:process-phase`](process-phase.md),
+bounded to a single iteration.
+
+## Instructions
+
+Run the canonical loop in
+[`contexts/execution/roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md)
+with the **scope delta below**.
+
+## Scope delta
+
+- **Working set:** the **first checkbox `[ ]` in document order**
+  inside the first phase with `count_open > 0`. If every step is
+  closed → report "Roadmap already complete." and run the archival
+  check from
+  [`roadmap-process-loop § 6`](../../contexts/execution/roadmap-process-loop.md#6-final-report-and-archival).
+- **Stop after:** one full iteration of
+  [`roadmap-process-loop § 5`](../../contexts/execution/roadmap-process-loop.md#5-step-loop)
+  (sub-steps 1–7). After the checkbox edit + dashboard regen, **stop**.
+- **Quality cadence:** run the per-step pipeline only when
+  `quality_cadence: per_step`. Skip otherwise.
+- **Phase boundary:** if this single step happens to close the phase,
+  do **not** advance. Report the phase as complete and stop.
+- **Roadmap boundary:** if this single step happens to close the
+  entire roadmap, run the archival check before reporting.
+
+## Rules
+
+- **Stop after one step**, even if the next step is trivial. The user
+  picks `process-phase` or `process-full` when they want more.
+- All other rules from
+  [`process-phase § Rules`](process-phase.md#rules) apply unchanged:
+  Hard-Floor, no auto-commit, dashboard sync, AI-council silent-when-on,
+  decline = silence.
+
+## See also
+
+- [`/roadmap`](../roadmap.md) — cluster orchestrator
+- [`/roadmap:process-phase`](process-phase.md) — default scope, single phase
+- [`/roadmap:process-full`](process-full.md) — across-phases variant
+- [`roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md) — canonical mechanics

package/dist/agent-src/commands/roadmap.md

@@ -0,0 +1,83 @@
+---
+model_tier: medium
+name: roadmap
+disable-model-invocation: true
+pack: product-basic
+intent: "Roadmap dispatcher — create, process-step, process-phase, process-full, ai-council"
+routes_to: [roadmap-create, roadmap-process-step, roadmap-process-phase, roadmap-process-full]
+replaces: []
+tier: 1
+description: Roadmap orchestrator — routes to create (authoring) and process-step / process-phase / process-full (autonomous execution).
+cluster: roadmap
+type: orchestrator
+suggestion:
+  eligible: true
+  trigger_description: "create a roadmap, process a roadmap, work through a roadmap autonomously, plan or abarbeiten"
+  trigger_context: "user wants to scaffold or autonomously execute a roadmap under agents/roadmaps/"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /roadmap
+
+Top-level orchestrator for the `/roadmap` family. Carries authoring
+(`create`) and the three autonomous-execution scopes (`process-step`,
+`process-phase`, `process-full`). The legacy `/roadmap execute` (which
+paused for confirmation before every step) was removed —
+`process-phase` is the default execution scope.
+
+## Sub-commands
+
+| Sub-command | Routes to | Purpose |
+|---|---|---|
+| `/roadmap:create` | `commands/roadmap/create.md` | Interactively scaffold a new roadmap in `agents/roadmaps/` |
+| `/roadmap:ai-council` | `commands/roadmap/ai-council.md` | Challenge an existing roadmap with the AI council (deep tier) and refactor from convergence findings |
+| `/roadmap:process-step` | `commands/roadmap/process-step.md` | Autonomously process the next open step, then stop |
+| `/roadmap:process-phase` (**default execution scope**) | `commands/roadmap/process-phase.md` | Autonomously process every open step in the current phase |
+| `/roadmap:process-full` | `commands/roadmap/process-full.md` | Autonomously process every open step across every phase |
+
+Sub-command names match the locked contract in
+[`docs/contracts/command-clusters.md`](../docs/contracts/command-clusters.md).
+`:` and space are equivalent at the cluster boundary — see
+[`slash-command-routing-policy-mechanics`](../contexts/communication/rules-auto/slash-command-routing-policy-mechanics.md#routing-semantics).
+The three `process-*` subs share the canonical loop in
+[`contexts/execution/roadmap-process-loop`](../contexts/execution/roadmap-process-loop.md);
+each only binds a scope delta.
+
+## Dispatch
+
+1. Parse the user's argument: `/roadmap[:<sub>] [args]` or
+   `/roadmap <sub> [args]`.
+2. Look up the sub-command in the table above.
+3. Load the body of the routed file and follow its `## Instructions`
+   section verbatim with the remaining args.
+4. **Legacy forwarding:**
+   - `/roadmap execute` or `/roadmap-execute` → forward to
+     [`/roadmap:process-phase`](roadmap/process-phase.md) (default
+     scope) with a one-time migration notice.
+   - `/roadmap-process[:<sub>]` (legacy top-level cluster) → forward
+     to `/roadmap:process-<sub>` with a one-time migration notice.
+5. If the sub-command is unknown or missing, print the table above
+   and ask:
+
+   > 1. create — scaffold a new roadmap interactively
+   > 2. ai-council — challenge + refactor an existing roadmap (deep tier)
+   > 3. process-step — process the next open step, then stop
+   > 4. process-phase — process the current phase (default)
+   > 5. process-full — process every open step across every phase
+
+## Rules
+
+- **Do NOT commit, push, or open a PR** unless the sub-command
+  explicitly authorizes it. Roadmap-listed commit steps follow the
+  single-upfront-ask flow in
+  [`roadmap-process-loop § 3`](../contexts/execution/roadmap-process-loop.md#3-commit-step-pre-scan--one-upfront-ask).
+- **Do NOT chain sub-commands.** One `/roadmap <sub>` per turn.
+- If the user invokes `/roadmap` with no argument, **show the menu** —
+  do not guess which sub-command they meant.
+- Execution intents (*"work through the roadmap"*, *"abarbeiten"*,
+  *"finish this phase"*) default to
+  [`/roadmap:process-phase`](roadmap/process-phase.md) unless the user
+  named a different scope.

package/dist/agent-src/commands/rule-compliance-audit.md

@@ -0,0 +1,156 @@
+---
+model_tier: inherit
+name: rule-compliance-audit
+pack: meta
+tier: 2
+skills: [rule-compliance-audit]
+description: Audit rule trigger quality, simulate activation, detect overlaps, and find never-activating rules
+suggestion:
+  eligible: true
+  trigger_description: "audit my rules, check rule trigger quality"
+  trigger_context: "maintainer working on .augment/rules/ files"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# rule-compliance-audit
+
+> **Intentionally a command, not a skill** (ADR-057, road-to-6.2.0 Step 7b).
+> Meta-tool that inspects rule-trigger quality — the auto-detection machinery
+> itself. A description-match-only skill cannot debug a broken
+> description-matcher; the explicit `/rule-compliance-audit` command is the
+> guaranteed debug-bypass. Skill-conversion gate **declined**.
+
+## Instructions
+
+### 1. Inventory all rules
+
+Read every `.md` file in `.agent-src.uncondensed/rules/`. For each rule, extract:
+
+- **Name** (filename without `.md`)
+- **Type** (`always` or `auto`)
+- **alwaysApply** (`true` or `false`)
+- **Description** (the trigger description)
+
+Display:
+
+```
+═══════════════════════════════════════════════
+  🔍 RULE COMPLIANCE AUDIT
+═══════════════════════════════════════════════
+
+  Rules: {total} ({always_count} always, {auto_count} auto)
+```
+
+### 2. Trigger quality check (auto-rules only)
+
+For each auto-rule, evaluate the `description` field:
+
+**Strong trigger** ✅ — contains:
+- Specific keywords a user would type (e.g., "PHPStan", "commit", "Docker")
+- Concrete action verbs (e.g., "creating", "editing", "running")
+- Specific file types or paths (e.g., ".augment/", "Blade views")
+
+**Weak trigger** ⚠️ — has ANY of:
+- Only abstract nouns ("quality", "best practices", "patterns")
+- No concrete keywords that match user prompts
+- Overlaps significantly with another rule's description
+- Too broad ("when working with code")
+
+Display per rule:
+
+```
+  ✅  {name}: "{description}" — keywords: {extracted keywords}
+  ⚠️  {name}: "{description}" — WEAK: {reason}
+```
+
+### 3. Trigger simulation
+
+For each auto-rule, generate **3 realistic user prompts** that SHOULD activate the rule.
+Then check: does the description contain enough keywords to match?
+
+Display:
+
+```
+───────────────────────────────────────────────
+TRIGGER SIMULATION
+───────────────────────────────────────────────
+
+  {rule-name}:
+    Description: "{description}"
+    Test prompts:
+      1. "{prompt}" → {✅ would match | ⚠️ might miss}
+      2. "{prompt}" → {✅ would match | ⚠️ might miss}
+      3. "{prompt}" → {✅ would match | ⚠️ might miss}
+```
+
+Only show rules where at least 1 prompt might miss.
+
+### 4. Overlap detection
+
+Compare all rule descriptions pairwise. Flag pairs where:
+- >50% keyword overlap
+- Same domain but different scope (one should be merged or narrowed)
+
+```
+───────────────────────────────────────────────
+OVERLAP ANALYSIS
+───────────────────────────────────────────────
+
+  ⚠️  {rule-a} ↔ {rule-b}: overlapping keywords: {list}
+     Recommendation: {merge | narrow scope | keep separate because...}
+```
+
+If no overlaps found: `✅  No significant overlaps detected.`
+
+### 5. Always-rule health check
+
+For each always-rule, check:
+- **Size** — >100 lines = ⚠️ (token cost on every request)
+- **Specificity** — does it apply to ALL tasks? If not, should it be auto instead?
+
+```
+───────────────────────────────────────────────
+ALWAYS-RULE HEALTH
+───────────────────────────────────────────────
+
+  {name}: {line_count} lines — {✅ healthy | ⚠️ large (>100 lines) | ⚠️ could be auto}
+```
+
+### 6. Summary and recommendations
+
+```
+═══════════════════════════════════════════════
+  📊 AUDIT SUMMARY
+═══════════════════════════════════════════════
+
+  Total rules:        {total}
+  Strong triggers:    {count} ✅
+  Weak triggers:      {count} ⚠️
+  Overlapping pairs:  {count}
+  Large always-rules: {count}
+
+  Recommendations:
+  {numbered list of concrete actions}
+```
+
+Present recommendations as numbered options:
+
+```
+> 1. Fix weak trigger: {rule} — suggested description: "{improved}"
+> 2. Narrow overlap: {rule-a} vs {rule-b} — {action}
+> 3. Convert to auto: {rule} — only applies to {specific context}
+> 4. No changes needed ✅
+```
+
+Wait for user to pick which recommendations to apply.
+
+## Rules
+
+- **Do NOT modify any files** until the user approves recommendations.
+- **Do NOT run any scripts** — this is a pure analysis command.
+- **Be honest about uncertainty** — if a trigger might or might not match, say "might miss".
+- **Always-rules are expensive** — flag any that could safely be auto.
+- **Auto-rules that never activate are dead weight** — flag them clearly.

package/dist/agent-src/commands/set-cost-profile.md

@@ -0,0 +1,118 @@
+---
+model_tier: medium
+name: set-cost-profile
+pack: meta
+tier: 2
+description: Change the rule_loading_tier in .agent-settings.yml — shows each profile's meaning and applies the selection
+skills: [file-editor]
+suggestion:
+  eligible: false
+  rationale: "Settings mutation — must be deliberate."
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+<!-- cloud_safe: noop -->
+
+# /set-cost-profile
+
+Changes `rule_loading_tier` in `.agent-settings.yml`. Four profiles are defined in
+the [`agent-settings` template](../templates/agent-settings.md#cost-profiles):
+
+- `minimal` · `balanced` · `full` · `custom`
+
+`/set-cost-profile` without an argument asks interactively.
+`/set-cost-profile <name>` validates and applies directly.
+
+## When NOT to use
+
+- For first-run setup use [`/onboard`](onboard.md).
+- For any other single-value change, edit `.agent-settings.yml`
+  directly or ask the agent — the merge rules live in
+  [`layered-settings`](../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules).
+- For role modes use [`/mode`](mode.md) — different concept (sets
+  `roles.active_role`, not `rule_loading_tier`).
+
+## Steps
+
+### 1. Parse argument
+
+- `/set-cost-profile` → interactive (continue with steps 2–5).
+- `/set-cost-profile <name>` → validate `<name>` against the four defined
+  profiles. If unknown, refuse and list the valid values.
+
+Profile names are case-insensitive on input; the file value stays lowercase.
+
+### 2. Read settings
+
+Read `.agent-settings.yml`. If missing, tell the user to run
+`scripts/install` first and stop — do not create the file here.
+
+Extract the current `rule_loading_tier` value.
+
+### 3. Load profile descriptions
+
+Read `.augment/templates/agent-settings.md` and extract the `## Cost profiles`
+section (table rows). This is the single source of truth for profile
+meanings — do not paraphrase or inline descriptions in this command.
+
+### 4. Show current state and options
+
+Render the current value and present numbered choices with the hint text
+extracted in step 3:
+
+```
+> Current: rule_loading_tier = {current}
+>
+> 1. minimal — {hint from template}
+> 2. balanced — {hint from template}
+> 3. full — {hint from template}
+> 4. custom — {hint from template}
+> 5. Keep current — no change
+```
+
+If `<name>` was passed as argument, skip the numbered prompt and use that
+value directly — still echo the old → new line in step 6.
+
+### 5. Write the value
+
+Update `rule_loading_tier` in `.agent-settings.yml` using the
+[section-aware merge rules](../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules)
+(preserve comments, preserve key order, touch only the changed field).
+
+If the user picked "Keep current", do nothing and stop.
+
+### 6. Confirm
+
+```
+> rule_loading_tier: {old} → {new}
+```
+
+If the new profile activates a surface the user hasn't used before
+(`balanced` adds the runtime dispatcher, `full` adds tool adapters), point
+the user at `docs/customization.md` for setup details — no inline setup
+steps here, that's the docs' job.
+
+## Gotchas
+
+- `.agent-settings.yml` is git-ignored. This command never commits the file.
+- Profile names are case-sensitive in the file; case-insensitive on input.
+- The template is the source of truth for descriptions — if it changes,
+  this command reflects the new text on next run.
+- `custom` ignores the profile matrix — every per-feature toggle must be
+  set explicitly afterwards. Warn the user when switching to `custom`.
+
+## Cloud Behavior
+
+On cloud surfaces (Claude.ai Web, Skills API) this command is **fully inert** —
+there is no `.agent-settings.yml` to write and no `rule_loading_tier` toggle to
+flip. Cost behaviour on those surfaces is governed by the platform itself.
+
+## See also
+
+- [`agent-settings`](../templates/agent-settings.md) — profile matrix and settings reference
+- [`layered-settings`](../docs/guidelines/agent-infra/layered-settings.md) — merge rules for settings edits
+- [`onboard`](onboard.md) — first-run setup (includes profile confirmation)
+- [`mode`](mode.md) — role-mode setter (different concept)

package/dist/agent-src/commands/skill/preview.md

@@ -0,0 +1,68 @@
+---
+model_tier: medium
+name: skill-preview
+pack: meta
+tier: 2
+cluster: skill
+sub: preview
+description: Non-destructive preview of a skill — its declared steps, execution type, allowed tools, and file/command targets — before you run it. Read-only, no execution.
+skills: [file-editor]
+suggestion:
+  eligible: true
+  trigger_description: "what does this skill do, preview <skill> before running, what will it change, is it safe, /skill:preview competitive-positioning"
+  trigger_context: "user wants to inspect a skill's declared intent before committing to run it"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /skill preview
+
+Renders a skill's **declared intent** — its `## Steps`, execution type, handler,
+`allowed_tools`, and any file/command targets named in its body — so you can
+decide whether to run it. Read-only, no network, no execution. Implements the
+[`skill-dry-run`](../../../docs/contracts/skill-dry-run.md) contract.
+
+## Prerequisites
+
+- Python 3.10 + PyYAML on the host.
+- A skill name that resolves to `dist/agent-src/skills/<name>/SKILL.md`.
+
+## Steps
+
+### 1. Parse the argument
+
+`/skill preview <name> [--technical]`. The name is the first positional
+argument. Missing name → print usage and stop.
+
+### 2. Run the previewer
+
+```bash
+python3 scripts/skill_preview.py <name>
+```
+
+Add `--technical` for the raw frontmatter + numbered step list; default is the
+plain-language summary. `--format json` is machine-readable.
+
+### 3. Present the summary
+
+Show the plain-language preview: the skill's execution type (a `manual` skill
+renders **"instructional only — no automatic execution"**; an `assisted` skill
+renders its proposed actions), declared steps, tools, and any file/command
+targets. End on the contract reminder that preview shows *declared intent*, not
+a guarantee of side-effect-freeness.
+
+### 4. Hand back the decision
+
+Preview never runs the skill. After showing it, let the user decide whether to
+invoke the skill — that is the safe adoption loop:
+`/skills:discover` → `/skill:preview` → run.
+
+## Rules
+
+- **Read-only, no execution.** Preview inspects the SKILL.md; it does not run it.
+- **Not a sandbox** — it cannot prove a skill is harmless; it shows what the
+  skill *declares* it will touch.
+- **Malformed / missing SKILL.md → a structured error**, never a crash.
+- **One skill per invocation.**

package/dist/agent-src/commands/skill.md

@@ -0,0 +1,49 @@
+---
+model_tier: medium
+name: skill
+pack: meta
+tier: 2
+description: Single-skill orchestrator — routes to preview. Non-destructive "what will this skill do?" before you run it.
+cluster: skill
+type: orchestrator
+suggestion:
+  eligible: true
+  trigger_description: "what does this skill do, preview this skill before running, is this skill safe to run, what will it change, /skill:preview <name>"
+  trigger_context: "user wants to see a skill's declared steps + targets before committing to running it"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /skill
+
+Top-level orchestrator for the `/skill` family — **single-skill** operations
+(singular `skill` for one target; plural `/skills` is the catalog-wide
+discovery cluster). Today it carries one verb: `preview`.
+
+Anchors: [`skill-dry-run`](../docs/contracts/skill-dry-run.md) contract —
+what "preview" means, the explicit non-goals, and the surface.
+
+## Sub-commands
+
+| Sub-command | Routes to | Purpose |
+|---|---|---|
+| `/skill preview` | `commands/skill/preview.md` | Render a skill's declared steps, execution type, tools, and file/command targets before running it |
+
+Sub-command names match the locked contract in
+[`docs/contracts/command-clusters.md`](../docs/contracts/command-clusters.md).
+
+## Dispatch
+
+1. Parse the user's argument: `/skill <sub-command> [args]`.
+2. Look up the sub-command in the table above.
+3. Load the body of the routed file and follow its `## Steps` section verbatim.
+4. Unknown / missing sub-command → route to `preview` (the only verb today).
+
+## Rules
+
+- **Read-only.** Preview reads a skill's SKILL.md; it never runs the skill.
+- **Not a sandbox.** Preview surfaces *declared intent*, not a guarantee of
+  side-effect-freeness — a contract non-goal.
+- **One skill per invocation.** Do not chain.