@event4u/agent-config 5.10.0 → 6.0.0

package/.agent-src/commands/context/refactor.md

@@ -1,182 +0,0 @@
----
-model_tier: high
-name: context:refactor
-tier: 2
-cluster: context
-sub: refactor
-skills: [agent-docs-writing]
-description: Analyze, update, and extend an existing context document
-suggestion:
-  eligible: true
-  trigger_description: "update the context doc, refresh this context document"
-  trigger_context: "existing agents/settings/contexts/*.md referenced in the prompt"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /context refactor
-## Instructions
-
-### 1. Find the context
-
-- List all context documents in `agents/settings/contexts/`.
-- Also check module-level contexts via `enumerate_modules()` — for each
-  module, look in `{module_path}/{modules.agent_folder}/settings/contexts/`
-  (Laravel shape: `app/Modules/*/agents/settings/contexts/`).
-
-If only one context exists, ask if that's the one to refactor.
-If the user has a context file open in their editor, use that one.
-If multiple exist, show a list:
-
-```
-📂 Existing context documents:
-
-  #  Name                    Ort                  Typ            Letzte Aktualisierung
-  ─  ──────────────────────  ───────────────────  ─────────────  ─────────────────────
-  1  client-software.md      Modul: ClientSoftware Module        2026-03-15
-  2  import-pipeline.md      Projekt-Root          Domain        2026-03-10
-  3  probaus-api.md          Projekt-Root          Integration   2026-02-28
-
-Which context do you want to update? (number or name)
-```
-
-If no contexts exist:
-```
-ℹ️  No context documents found. Create one first with /context-create.
-```
-Stop.
-
-### 2. Load and display the context
-
-- Read the selected context file completely.
-- Display a summary:
-
-```
-═══════════════════════════════════════════════
-  ✏️  CONTEXT: {title}
-═══════════════════════════════════════════════
-
-📊 Typ:              {type}
-📅 Last updated:     {last updated}
-📦 Module:           {module or "project-wide"}
-
-───────────────────────────────────────────────
-CURRENT CONTENT:
-───────────────────────────────────────────────
-
-  Key Files:       {count}
-  Key Classes:     {count}
-  DB Tables:       {count}
-  API Endpoints:   {count}
-  Known Issues:    {count}
-
-═══════════════════════════════════════════════
-```
-
-### 3. Re-analyze the code
-
-Re-analyze the documented area to find changes:
-
-- Check if documented files still exist.
-- Look for new files/classes that aren't documented.
-- Verify database tables and endpoints are still accurate.
-- Check for new tests.
-
-**Show findings:**
-
-```
-🔍 Re-analysis complete:
-
-  ✅  Still current:
-    • ImportService — unchanged
-    • 8 Models — all present
-
-  ⚠️  Outdated / changed:
-    • ProcessImportCommand — new parameters added
-    • ImportUploadType — 2 new enum values
-
-  🆕 New (not documented):
-    • ImportValidationService (newly added)
-    • api/v1/imports/validate endpoint
-
-  ❌  Removed:
-    • OldImportHelper — no longer exists
-```
-
-### 4. Ask what to do
-
-```
-What do you want to adjust?
-
-1. 🔄 Auto-update everything (based on the analysis)
-2. ✏️ Manually edit specific sections
-3. ➕ Add new areas
-4. 🗑️ Remove outdated entries
-5. 💬 Something else
-```
-
-**Option 1 — Auto-update:**
-- Remove entries for deleted files/classes.
-- Add entries for new files/classes.
-- Update changed entries.
-- Show all changes for confirmation before applying.
-
-**Option 2 — Manual edit:**
-Show section list:
-```
-Which section?
-
-1. Overview
-2. Key Files
-3. Key Classes & Services
-4. Database
-5. API Endpoints
-6. Dependencies
-7. Patterns & Conventions
-8. Known Issues / Technical Debt
-9. Notes
-```
-
-**Option 3 — Add new areas:**
-- Ask what to add.
-- Analyze the relevant code.
-- Add new sections or entries.
-
-### 5. Apply changes
-
-- Update the context file.
-- Update `Last Updated` to today's date.
-- Show a diff summary:
-
-```
-───────────────────────────────────────────────
-CHANGES:
-───────────────────────────────────────────────
-
-  🆕 Added: 3 Key Files, 1 Service, 1 Endpoint
-  ✏️ Updated: 2 Classes, 1 Known Issue
-  🗑️ Removed: 1 obsolete service
-  📅 Last Updated: 2026-03-20
-```
-
-### 6. Ask for additions
-
-```
-Anything else to add?
-
-1. ➕ Yes — document another area
-2. 🔍 Investigate a specific class/service in detail
-3. ✅ No, done
-```
-
-If option 1 or 2 → loop back to analysis and update.
-
-### Rules
-
-- **Do NOT commit or push.**
-- **Always re-analyze the code** before updating — don't just edit text.
-- **Show changes before applying** — the user should confirm.
-- **Preserve user-written notes and context** — don't overwrite manual additions.
-- **Update `Last Updated`** after every change.

package/.agent-src/commands/context.md

@@ -1,50 +0,0 @@
----
-model_tier: medium
-name: context
-tier: 2
-description: Context orchestrator — routes to create, refactor
-cluster: context
-type: orchestrator
-suggestion:
-  eligible: true
-  trigger_description: "create a context document, update an existing context, refactor a context file"
-  trigger_context: "user wants to author or restructure a context document"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /context
-
-Top-level orchestrator for the `/context` family. Replaces 2 standalone
-commands with a single entry point + sub-command dispatch.
-
-## Sub-commands
-
-| Sub-command | Routes to | Purpose |
-|---|---|---|
-| `/context create` | `commands/context/create.md` | Analyze a codebase area and create a structured context document |
-| `/context refactor` | `commands/context/refactor.md` | Analyze, update, and extend an existing context document |
-
-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: `/context <sub-command> [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. If the sub-command is unknown or missing, print the table above and ask:
-
-   > 1. create — author a new context document
-   > 2. refactor — update an existing context document
-
-## Rules
-
-- **Do NOT commit, push, or open a PR** unless the sub-command explicitly
-  authorizes it.
-- **Do NOT chain sub-commands.** One `/context <sub>` per turn.
-- If the user invokes `/context` with no argument, **show the menu** — do
-  not guess which sub-command they meant.

package/.agent-src/commands/cost-report.md

@@ -1,130 +0,0 @@
----
-model_tier: medium
-name: cost-report
-tier: 2
-description: Capture token cost from the active Claude Code session, append to the local sessions store, and surface the 50/75/90/100% budget alert ladder with cost-profile suggestions.
-skills: [file-editor]
-suggestion:
-  eligible: true
-  trigger_description: "check this session's token cost, see budget utilization, surface 50/75/90/100% alert ladder"
-  trigger_context: "user wants to know how expensive the active Claude Code session is or whether it crosses a budget threshold"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-<!-- cloud_safe: noop -->
-
-# /cost:report
-
-Records the current Claude Code session's token usage and checks it against
-the configured budget. Local-only: writes to
-`agents/cost-tracking/sessions.jsonl` (no MCP / external services).
-
-## Steps
-
-### 1. Capture the active session
-
-```bash
-node scripts/cost/track.mjs
-```
-
-Emits a Markdown summary of the session (model breakdown, per-tier cost,
-total USD) and appends a JSON record to
-`agents/cost-tracking/sessions.jsonl`.
-
-If `track.mjs` exits 2 with `no Claude Code project dir`, the user is not in
-a Claude Code session — surface that and stop.
-
-### 2. Check the budget
-
-```bash
-node scripts/cost/budget.mjs check
-```
-
-Reads the runtime budget config under `agents/cost-tracking/` (set via step 4
-if missing) and the JSONL store, computes utilization, and prints the alert
-level.
-
-### 3. Surface the alert ladder
-
-The check output already includes the level. Translate it into a
-profile recommendation per the table:
-
-| Level | Utilization | Recommendation |
-|---|---|---|
-| 🟢 OK | < 50% | within budget — no action |
-| 🟡 INFO | ≥ 50% | log notification, no UX disruption |
-| 🟠 WARNING | ≥ 75% | suggest dropping the **model tier** — `model.auto_switch: auto`, or pick a lighter `model_tier` for routine work (the dominant spend lever) |
-| 🔴 CRITICAL | ≥ 90% | recommend a lighter model tier first; only as a last resort suggest [`/set-cost-profile minimal`](set-cost-profile.md) **with a capability-loss warning** |
-| 🛑 HARD_STOP | ≥ 100% | halt non-essential work; review before continuing (`budget.mjs check` exits 1) |
-
-**Lever order matters.** Per-turn spend is dominated by the **model** (a high→lite
-tier swap is roughly a 10× cost delta) and by query/response volume — not by how many
-rules load. `rule_loading_tier` loads its rule bodies roughly once per session (a small,
-fixed cost), so lowering it saves little and *reduces the agent's guardrail coverage*.
-Recommend the model lever first:
-
-> Budget ≥ {level}. The biggest lever is the **model tier** — set
-> `model.auto_switch: auto` (or pick a lighter `model_tier` for routine turns).
-> Lowering `rule_loading_tier` saves far less and drops behavioural guardrails —
-> use [`/set-cost-profile minimal`](set-cost-profile.md) only as a last resort.
-
-### 4. First-run: prompt to set a budget
-
-If `budget.mjs check` reports `no budget configured`, ask the user (one
-question per turn — see [`ask-when-uncertain`](../rules/ask-when-uncertain.md)):
-
-> No budget set yet. What monthly USD cap do you want to track against?
-> (e.g. 25, 50, 200)
-
-On reply, run:
-
-```bash
-node scripts/cost/budget.mjs set <usd>
-```
-
-Then re-run step 2.
-
-### 5. Period filter (optional)
-
-If the user asks for spend in a specific window — "this week", "today",
-"this month" — re-run with `BUDGET_PERIOD`:
-
-```bash
-BUDGET_PERIOD=week node scripts/cost/budget.mjs check
-```
-
-Allowed values: `today`, `week`, `month`, `all` (default).
-
-## Rules
-
-- **Local-only.** Never persist cost data to remote stores. The
-  JSONL store and the `budget.json` config both live inside `agents/`,
-  which is gitignored by default in consumer projects.
-- **Don't auto-switch profiles.** This command surfaces a recommendation;
-  the user runs [`/set-cost-profile`](set-cost-profile.md) themselves.
-  Auto-mutation of `.agent-settings.yml` would breach
-  [`commit-policy`](../rules/commit-policy.md) and
-  [`scope-control`](../rules/scope-control.md).
-- **Honor HARD_STOP.** When `budget.mjs check` exits 1, surface the alert
-  prominently and stop the current task — do not keep working through the
-  cap silently.
-
-## See also
-
-- [`/set-cost-profile`](set-cost-profile.md) — change `rule_loading_tier` in
-  `.agent-settings.yml`.
-- [`/agent-status`](agent-status.md) — per-conversation token estimate
-  (different scope: in-flight estimate, not historical actuals).
-- [`scripts/cost/track.mjs`](../../scripts/cost/track.mjs) — tracker source.
-- [`scripts/cost/budget.mjs`](../../scripts/cost/budget.mjs) — budget source.
-
-## Attribution
-
-Forked from
-[`ruvnet/ruflo`](https://github.com/ruvnet/ruflo)
-`plugins/ruflo-cost-tracker/scripts/{track,budget}.mjs`. The MCP
-`memory_store` dependency was replaced with a local JSONL append; the
-50/75/90/100% alert ladder and pricing tiers are preserved verbatim.

package/.agent-src/commands/council/analysis.md

@@ -1,146 +0,0 @@
----
-model_tier: high
-name: council:analysis
-tier: 2
-cluster: council
-sub: analysis
-skills: [ai-council]
-description: Run the council on a local analysis output (project-analyze, audit script, codebase scan) — critiques the analysis itself for dedup, evidence quality, and roadmap-readiness.
-suggestion:
-  eligible: true
-  trigger_description: "council on this analysis, critique the project-analyze output, second opinion on the audit findings, turn analysis into roadmap"
-  trigger_context: "user has a local analysis artefact (agents/evidence/analysis/*.md|json) and wants an external critique of the analysis quality + roadmap-ready follow-ups"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /council analysis
-
-## Instructions
-
-Specialised council mode for **local analysis artefacts** — `/project-analyze`
-output, audit reports, codebase scans under `agents/evidence/analysis/`. Wraps
-`/council default files:<path>` with the `analysis` neutrality preamble that
-focuses members on **critiquing the analysis itself** (dedup, evidence
-quality, roadmap-readiness) rather than re-reviewing the underlying code.
-
-The synthesis output is shaped for direct consumption by
-`/roadmap-create` — Top-N consensus findings + per-finding metadata
-(`evidence-grade`, `roadmap-ready`, `supporting-citation`).
-
-### 1. Resolve the analysis artefact
-
-The user invoked `/council analysis <path>` or `/council analysis`. If
-no path was supplied, ask (one question per turn, per
-`ask-when-uncertain`):
-
-> Which analysis artefact should the council review?
->
-> 1. A file path under `agents/evidence/analysis/` (`.md` or `.json`)
-> 2. Multiple files (one analysis split across sections)
-> 3. Free-form analysis text in the chat — paste it now
-
-Pick **1** or **2** → use `files:` mode of `/council default`.
-Pick **3** → use `prompt:` mode of `/council default`.
-
-### 2. Capture the upstream-analysis goal
-
-Look for the artefact's stated goal — the first paragraph after the
-title, a `## Goal` / `## Scope` section, or the analyzer command that
-produced it (often in the file header). That goal is the `original_ask`
-for the handoff preamble. If absent, ask the user (one question per
-turn):
-
-> What was the goal of this analysis? (one sentence — used as neutral
-> framing for the council, not their critique)
-
-A follow-up question MAY also be supplied as part of the invocation
-(e.g. `/council analysis <path> "which findings warrant a roadmap?"`).
-Append it to `original_ask` so members see both the analyzer goal and
-the consumer question.
-
-### 3. Run /council default with the analysis mode preamble
-
-Invoke the matching `/council default` form:
-
-- `files:` → `/council default files:<paths>` with `--prompt-mode analysis`.
-- `prompt:` → `/council default prompt:"<artefact text>"` with
-  `--prompt-mode analysis`.
-
-`--prompt-mode` is the CLI flag (`scripts/council_cli.py`) that
-swaps the lens addendum after the bundler has run. The bundle shape
-stays as the resolved `--input-mode` (prompt | roadmap | files).
-
-The `analysis` mode addendum from `scripts/ai_council/prompts.py`
-focuses council members on:
-
-- Deduplicating findings restated under different headings.
-- Scoring evidence quality (confirmed / inferred / speculative).
-- Separating roadmap-ready findings from ones that need a discovery
-  loop first.
-- Proposing 3–5 ranked follow-up actions with supporting citations.
-
-The cost gate from `/council default` Step 3 still applies. Render via
-Step 5/5a/5b of `/council default`.
-
-### 4. Render the report (analysis-shaped header + Top-N consensus)
-
-Use the standard stacked + Convergence/Divergence layout. Add a
-one-line analysis header at the top so reviewers know the lens:
-
-```
-## Council on <artefact path> — analysis lens
-```
-
-After the standard Convergence / Divergence blocks, append a
-**Top-N consensus** block in the shape consumed by `/roadmap-create`:
-
-```
-## Top-N consensus findings (roadmap-ready first)
-
-1. <finding title>
-   - evidence-grade: confirmed | inferred | speculative
-   - roadmap-ready: yes | needs-discovery
-   - cited by: <member names — anonymised post-render is fine>
-   - supporting citation: <file:line | section heading from the upstream analysis>
-
-2. ...
-```
-
-Order: roadmap-ready findings first, ranked by member-consensus count;
-then `needs-discovery` items. Cap at N=10 unless the upstream analysis
-has fewer findings.
-
-### 5. Hand back to the user
-
-The council is **advisory**. Do **not** rewrite the analysis or open
-roadmap files based on findings. Surface the Top-N block and offer:
-
-> 1. Feed the Top-N block into `/roadmap create` to draft a roadmap.
-> 2. Discard — keep findings in chat only.
-> 3. Re-run with a narrower scope.
-
-### Hard floor (restated)
-
-`/council analysis` produces **text only**. It does NOT edit the
-analysis file, write roadmap files, or modify the codebase. Roadmap
-authoring is the explicit downstream step, not a side-effect.
-
-## Failure modes
-
-- **No artefact resolvable** → ask once; if still empty, stop.
-- **Artefact too large** → bundler raises `BundleTooLarge`; suggest
-  splitting (`/council default files:<single-section>` per heading).
-- **Analysis has zero citations** → flag in the rendered report; every
-  finding will score as `speculative`. The council will say so loudly
-  and the Top-N block will be empty of `confirmed` rows — that is the
-  signal to re-run the upstream analyzer with stricter evidence rules.
-
-## See also
-
-- `/council default` — base orchestration entry point.
-- `/project-analyze` — primary upstream producer of analysis artefacts.
-- `/roadmap create` — primary downstream consumer of the Top-N block.
-- `ai-council` skill — neutrality guidelines.

package/.agent-src/commands/council/debate.md

@@ -1,133 +0,0 @@
----
-model_tier: inherit
-name: council:debate
-tier: 2
-cluster: council
-sub: debate
-skills: [ai-council]
-description: Multi-round council debate with progressive cost disclosure — each member produces a position, then rebuts the strongest opposing position in subsequent rounds. User confirms spend between rounds.
-suggestion:
-  eligible: true
-  trigger_description: "council debate on X, multi-round rebuttal, escalate council to debate mode, push the council to argue not synthesize"
-  trigger_context: "user wants real pushback — initial positions plus explicit rebuttals across rounds, with progressive cost confirmation between rounds"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /council debate
-
-## Instructions
-
-Specialised council mode for **multi-round debates**. Each enabled member
-produces an initial position in Round 1, then rebuts the strongest
-opposing position in subsequent rounds. The orchestrator pauses between
-rounds and asks the user to continue (progressive cost disclosure). Hard
-cap: `ai_council.cost_budget.max_total_usd` aborts the next round if
-the projection breaches the cap, persisting the partial debate.
-
-This is **not a flag** on `/council default` — debate mode changes the
-orchestration shape (N members × R rounds = N×R calls) and the cost UX,
-so it earns its own sub-command per the R4 verdict.
-
-### 1. Resolve the topic
-
-The user invoked `/council debate "<topic>"` or `/council debate <path-to-artefact>`.
-Treat the argument as the **topic** of the debate (a question, a
-proposal, an architectural call). If missing, ask (one question per
-turn, per `ask-when-uncertain`):
-
-> What is the topic of the debate?
->
-> 1. Inline topic (e.g. "Should we adopt event sourcing for the orders module?")
-> 2. Path to a file containing the topic / artefact
-> 3. Cancel
-
-Capture the resolved topic as `original_ask` verbatim. Do **not** add
-the agent's framing.
-
-### 2. Decide round count + auto-continue
-
-Default: 2 rounds (initial position + one rebuttal). Cap: the value of
-`defaults.debate_max_rounds` in [`agents/settings/.ai-council.yml`](../../../agents/settings/.ai-council.yml)
-(default 4). `--rounds N` overrides the default; values above the cap
-are rejected by the CLI.
-
-Auto-continue is **off by default** — the user explicitly opts in via
-`--auto-continue` when they want to skip the y/N gate between rounds.
-The hard cost cap still applies regardless.
-
-### 3. Estimate (always)
-
-Run `council:estimate` first using `--prompt-mode=debate` (the CLI sets
-this automatically when invoked via `debate`). The estimate covers
-**one round**. Multiply by the planned round count for the worst-case
-projection. Surface the projection to the user with a clear note that
-progressive disclosure may stop the debate early.
-
-### 4. Cost confirmation (ALWAYS ASK)
-
-Per [`ai-council` skill § cost gate](../../skills/ai-council/SKILL.md),
-always surface the projected total spend and ask for explicit consent
-before invoking. Numbered options:
-
-> The debate is projected to cost **$X.XXXX** ($Y.YYYY × N rounds, worst case).
->
-> 1. Run all N rounds (auto-continue, no between-round prompt)
-> 2. Run round-by-round (confirm before each next round) — recommended
-> 3. Cancel
-
-The default recommendation is option 2 (progressive disclosure). Map
-option 1 to `--auto-continue`, option 2 to interactive mode, option 3
-to abort.
-
-### 5. Invoke the CLI
-
-```bash
-python3 scripts/council_cli.py debate <topic-path> \
-  --output agents/runtime/council/sessions/<date>-<slug>/ \
-  --confirm \
-  --rounds <N> \
-  [--auto-continue] \
-  [--continue-as-debate <prior-session.json>] \
-  --original-ask "<verbatim topic>"
-```
-
-Session directory shape: `agents/runtime/council/sessions/<YYYY-MM-DD>-debate-<slug>/`
-with `debate-round-1.json`, `debate-round-2.json`, … written incrementally.
-An interrupted debate leaves every completed round on disk.
-
-### 6. Continuation pivot (optional)
-
-If the user has a prior `/council default` session and wants more
-pushback, they can pivot via `--continue-as-debate <session.json>`. The
-orchestrator seeds Round 1 from the existing responses (no calls billed
-for Round 1) and starts the rebuttal loop at Round 2. **Members + models
-must match** the source session — a mismatch is a hard error.
-
-### 7. Render the final synthesis
-
-After all rounds complete, render the last round's JSON via
-`/council` render flow:
-
-```bash
-python3 scripts/council_cli.py render agents/runtime/council/sessions/<dir>/debate-round-<N>.json
-```
-
-The debate mode uses the structured decision-lens template (Karpathy
-synthesis) by default. `--prose-synthesis` switches to open-ended prose.
-
-### 8. Hard floor — text only
-
-`/council debate` produces text artefacts (round JSONs + synthesis
-markdown). It does NOT edit files, commit, push, or open PRs. The
-session directory is the canonical audit trail.
-
-## Cap exceeded
-
-If `DebateCapExceeded` fires, the CLI exits with code 3 and the partial
-debate is persisted. Surface the partial-debate path to the user and
-ask whether to (a) raise the cap in `agents/settings/.ai-council.yml` and rerun,
-(b) stop here and render the partial result, or (c) start a new debate
-with a smaller scope.