@event4u/agent-config 1.22.0 → 1.23.0

package/.agent-src/skills/roadmap-writing/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: roadmap-writing
+description: "Use when authoring or rewriting a roadmap in agents/roadmaps/ — phase prose, goal sentence, acceptance criteria, council notes — even when the user just says 'write a plan for X' or 'draft a roadmap'."
+source: package
+---
+
+<!-- cloud_safe: degrade -->
+
+# roadmap-writing
+
+## When to use
+
+* Authoring a new roadmap file in `agents/roadmaps/{name}.md` (or
+  module-scoped under `app/Modules/{Module}/agents/roadmaps/`)
+* Rewriting an existing roadmap (phase restructure, goal pivot,
+  council-pass integration — not a checkbox flip)
+* Drafting a phase block, exit criteria, or rollback section that
+  will land inside an existing roadmap
+
+Do NOT use this skill when:
+
+* Flipping checkboxes, regenerating the dashboard, archiving on
+  completion → use [`roadmap-management`](../roadmap-management/SKILL.md)
+* Updating AGENTS.md / module docs / contexts → use
+  [`agent-docs-writing`](../agent-docs-writing/SKILL.md)
+* Capturing an architectural decision → use
+  [`adr-create`](../adr-create/SKILL.md)
+
+## Roadmap-writing vs roadmap-management — critical test
+
+| Intent | Artifact |
+|---|---|
+| "I need to write the plan body" | **roadmap-writing** (this skill) |
+| "I need to track progress / regenerate dashboard / archive" | **roadmap-management** |
+
+This skill owns the **prose authoring** axis: structure, goal
+sentence, phase blocks, acceptance criteria. The execution and
+dashboard-sync axis stays in `roadmap-management`.
+
+## Procedure
+
+### 0. Drafting protocol
+
+Authoring or materially rewriting a roadmap must go through
+Understand → Research → Draft per the
+[`artifact-drafting-protocol`](../../rules/artifact-drafting-protocol.md)
+rule. Inspect existing roadmaps under `agents/roadmaps/` for overlap
+or supersession before opening a new one.
+
+### 1. Read the canonical template first
+
+The structure, frontmatter, lifecycle, and complexity-tier rules live
+in [`.agent-src.uncompressed/templates/roadmaps.md`](../../templates/roadmaps.md).
+Read it before authoring. Do not restate its rules in the roadmap
+body — link the template if a phase needs to override one.
+
+### 2. Pick complexity tier honestly
+
+Default `lightweight` (≤ 6 phases, ≤ 600 lines). Only use
+`structural` when the change touches a contract, kernel rule, or
+budget invariant — the complexity linter enforces it. Standard:
+[`roadmap-complexity-standard`](../../../docs/contracts/roadmap-complexity-standard.md).
+
+### 3. Write the goal first
+
+One sentence, top of file, decidable: "Reduce X by Y on flow Z."
+Vague goals ("improve roadmaps") force every reader to re-derive
+intent. If the goal needs three sentences, the roadmap is two
+roadmaps.
+
+### 4. Phase blocks carry checkboxes
+
+Every non-intro phase contains at least one `- [ ]`. Decision tables
+and council-pass notes capture the *why*; checkboxes capture the
+*what to do next*. Without checkboxes the phase is invisible to
+`agents/roadmaps-progress.md` — enforced by
+[`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)
+Iron Law #2.
+
+### 5. Exit & rollback per phase
+
+Each phase declares **exit criteria** (decidable signals that the
+phase is done) and **rollback** (what to revert if the phase fails).
+A phase without exit criteria is open-ended; a phase without
+rollback assumes success.
+
+## Output format
+
+A single Markdown file at `agents/roadmaps/{name}.md`:
+
+1. Frontmatter (`status`, `complexity`)
+2. `# Road to {short title}`
+3. One-sentence outcome blockquote
+4. `## Goal` — decidable target
+5. `## Prerequisites` — checkboxes
+6. `## Context` — why now, links to tickets
+7. Numbered `## Phase N — {name}` sections with checkboxes,
+   exit criteria, rollback
+8. `## Acceptance criteria` — final gates
+
+## Frugality Standards
+
+Apply the [Frugality Charter](../../contexts/contracts/frugality-charter.md)
+to every roadmap you author.
+
+**Examples in this artifact:**
+- Per the charter's default-terse rule, the goal sentence states the
+  outcome — no "This roadmap exists because…" ramp-up.
+- Per the cite-don't-restate principle, link the canonical template
+  for structural rules; do not paste them into the roadmap.
+- Per the post-action summary suppression, council-pass integration
+  notes append to the existing phase block — no new "Summary of
+  council passes" section.
+- Per the cheap-question check, never propose a "lightweight vs.
+  structural" numbered choice when the diff makes the answer
+  decidable.
+
+**Pre-save self-check:**
+1. Does the goal sentence open with the outcome, or with backstory?
+2. Does any phase block restate template rules instead of linking
+   them?
+3. Are checkboxes present in every non-intro phase?
+4. Are exit criteria decidable, or vibe-based ("looks good")?
+5. Is content duplicated from another roadmap (supersession instead)?
+
+## Do NOT
+
+* Author a roadmap without a goal sentence.
+* Restate `templates/roadmaps.md` rules inside the roadmap body.
+* Include version numbers, target releases, or git tags — banned by
+  template rule 13 + [`scope-control`](../../rules/scope-control.md#git-operations--permission-gated).
+* Plan automatic branch switches mid-roadmap (template rule 14).
+* Ship a phase without checkboxes (`roadmap-progress-sync` Iron Law #2).
+* Use ALL-CAPS Iron-Law fenced blocks — those belong in
+  [`kernel-membership`](../../../docs/contracts/kernel-membership.md)-listed
+  rules, not roadmaps.
+
+## Gotchas
+
+- **No checkboxes in a phase** — `agents/roadmaps-progress.md` cannot
+  count the phase; the dashboard reports zero open work even though
+  the phase has prose. Enforced by `roadmap-progress-sync` Iron Law #2.
+- **Vague goal sentence** — "Improve roadmap quality" forces every
+  reader to re-derive intent and blocks decidable acceptance.
+- **Restating template rules** — pasting structural rules into the
+  roadmap body creates two sources of truth that drift over months.
+- **Version numbers in phase names** — `Phase 1 — v1.8.0` violates
+  template rule 13 and `scope-control § git-operations`.
+- **Author-during-execution branch switches** — the agent should not
+  propose a new branch mid-roadmap; that decision is fenced to
+  authoring time.
+
+## Examples
+
+See `agents/roadmaps/archive/road-to-token-frugality.md`
+(structural, multi-phase, council-integrated) and any
+`agents/roadmaps/road-to-*.md` for canonical structure.

package/.agent-src/skills/rule-writing/SKILL.md

@@ -165,6 +165,28 @@ and body links (relative `../../docs/...`, rewriter handles depth).
 * Forgetting to run `python3 scripts/compress.py --generate-tools` — downstream tools stay stale.
 * Editing `.agent-src/rules/` or `.augment/rules/` directly — those are generated.
 
+## Frugality Standards
+
+Apply the [Frugality Charter](../../contexts/contracts/frugality-charter.md)
+to every rule you author.
+
+**Examples in this artifact:**
+- Per the charter's default-terse rule, no intent prose in the rule
+  body — start with the obligation, not a setup paragraph.
+- Per the Iron-Law literal predicate, ALL-CAPS fenced obligations
+  belong only when the rule sits on the
+  [`kernel-membership`](../../../docs/contracts/kernel-membership.md)
+  list.
+- Per the cheap-question check, the rule's "When to ask" guidance
+  must list decidable triggers, not vibe-based judgment.
+
+**Pre-save self-check:**
+1. Does the rule body open with the obligation, or with a setup
+   paragraph?
+2. Are any examples mere narration (no decidable test)?
+3. Are ALL-CAPS Iron-Law blocks used outside a kernel-listed rule?
+4. Are interactions duplicated from another rule rather than linked?
+
 ## Do NOT
 
 * Do NOT inline long procedures

package/.agent-src/skills/script-writing/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: script-writing
+description: "Use when adding or editing any script under `scripts/` — `--quiet` flag, `_lib/script_output` helpers, silent Taskfile wiring, Iron-Law carve-outs — even when you just say 'add a check script for X'."
+source: package
+---
+
+<!-- cloud_safe: degrade -->
+
+# script-writing
+
+## When to use
+
+* Creating a new Python script in `scripts/{name}.py` (linters, checks, generators, measure tools)
+* Editing an existing script that prints progress or success lines
+* Wiring a script into `Taskfile.yml` or `taskfiles/*.yml`
+* Reviewing a PR that adds scripts and asking "why does this still print on minimal?"
+
+Do NOT use this skill when:
+
+* The content is a one-off / archival under `scripts/ai_council/one_off_archive/` — those carry an `_one_off_` prefix and are exempt from the verbosity convention
+* The content is a shell entrypoint with secret prompts (install-keys, release confirms) → see § 3 Iron-Law carve-outs
+* The content is a `.mjs` / Node script under `scripts/cost/` — different runtime; convention covered in `agents/contexts/cost-tracking.md`
+
+## Script vs other writers — critical test
+
+| Intent | Artifact |
+|---|---|
+| "Maintenance script the agent or CI runs" | **This skill** |
+| "User types `/foo` to invoke" | `command-writing` |
+| "Constraint the agent must always honor" | `rule-writing` |
+| "Reference knowledge agents cite" | `guideline-writing` |
+
+Scripts orchestrate file checks, generators, and validators. They are
+neither user-invoked nor agent-routed — `task` and CI call them.
+
+## Procedure
+
+### 0. Run the Drafting Protocol
+
+Creating or materially rewriting a script that joins the linter / check
+family **must** go through Understand → Research → Draft from the
+[`artifact-drafting-protocol`](../../rules/artifact-drafting-protocol.md) rule.
+
+* **Understand** — what failure does this script catch that no existing
+  check catches? Is it a one-off (then archive it) or evergreen?
+* **Research** — `ls scripts/check_*.py scripts/lint_*.py`, grep for
+  overlap, skim 1–2 peer scripts (e.g. `lint_handoffs.py`,
+  `check_md_language.py`).
+* **Draft** — propose name + one-line purpose first. Only fill the body
+  after the shape is confirmed.
+
+### 1. `--quiet` flag — argparse + sys.argv fallback
+
+Every `check_*.py` / `lint_*.py` script MUST accept `--quiet` so the
+silent Taskfile layer (§ 4) can suppress success-only output.
+
+**With argparse (preferred):**
+
+```python
+parser = argparse.ArgumentParser(...)
+parser.add_argument("--quiet", action="store_true",
+                    help="Only print on failure")
+args = parser.parse_args()
+...
+if not args.quiet:
+    print("✅ All clean")
+```
+
+**Plain script (no argparse) fallback:**
+
+```python
+import sys
+
+QUIET = "--quiet" in sys.argv
+...
+if not QUIET:
+    print("✅ All clean")
+```
+
+Failure output (`❌`, non-zero exit) is **never** gated — failures must
+always print regardless of `--quiet`.
+
+### 2. `_lib/script_output` helpers — preferred for new scripts
+
+For anything richer than a single `✅`/`❌`, import the verbosity-aware
+router instead of raw `print()`:
+
+```python
+from _lib.script_output import info, success, warn, error, flush_summary
+
+info("Loading manifest")          # drops on silent + minimal
+success("Wrote 3 files")          # collected at minimal, printed at verbose
+warn("Skipping stale entry")      # stderr unless silent
+error("Manifest missing")         # stderr always
+
+flush_summary("Done — 3 entries") # one-line summary at minimal
+```
+
+Resolution order (first wins, cached for the process):
+
+1. `AGENT_SCRIPT_VERBOSITY` env (`silent` / `minimal` / `verbose`)
+2. `SCRIPT_OUTPUT_VERBOSE=1` alias (== `verbose`)
+3. `.agent-settings.yml` → `verbosity.script_output`
+4. Default `minimal`
+
+The resolved level is exported back into `AGENT_SCRIPT_VERBOSITY` so
+child processes inherit it. Tests reset via `reset_level()` from the
+same module — see `tests/test_script_output.py`.
+
+### 3. Iron-Law carve-outs — never silenced
+
+The following surfaces **MUST** use plain `print()` and never the
+helpers, so verbosity settings cannot suppress them:
+
+* Release confirms — every task in `taskfiles/release.yml`
+* Secret prompts — `install-anthropic-key`, `install-openai-key`,
+  `setup-evals`, `install-hooks` interactive sections
+* `runtime-e2e` and `test-triggers-live`
+* CI orchestration sentinels — `_ci-start`, `_ci-end`, root `ci`
+* Any prompt that asks the user for confirmation per
+  [`non-destructive-by-default`](../../rules/non-destructive-by-default.md) — Hard Floor cannot be silenced
+
+If unsure, check `scripts/ai_council/one_off_archive/2026-05/_one_off_silent_taskfiles.py`
+`CARVE_OUTS` for the canonical list.
+
+### 4. Taskfile wiring — `silent: true` + `{{.QUIET_FLAG}}`
+
+Every Taskfile task that wraps a `--quiet`-aware script MUST set
+`silent: true` and pass `{{.QUIET_FLAG}}` to the script:
+
+```yaml
+# Per-task in taskfiles/*.yml:
+tasks:
+  lint-handoffs:
+    silent: true
+    cmd: python3 scripts/lint_handoffs.py {{.QUIET_FLAG}}
+```
+
+The `QUIET_FLAG` var is defined once at the root of `Taskfile.yml`
+and resolves to `""` only when `AGENT_SCRIPT_VERBOSITY=verbose`:
+
+```yaml
+# Root Taskfile.yml — already in place, do not duplicate:
+vars:
+  QUIET_FLAG:
+    sh: '[ "$AGENT_SCRIPT_VERBOSITY" = "verbose" ] && echo "" || echo "--quiet"'
+```
+
+Carve-out tasks (release, install secrets, CI orchestration — see § 3)
+do **not** add `silent: true` and do **not** use `{{.QUIET_FLAG}}`.
+
+### 5. Validate
+
+* Run `python3 scripts/skill_linter.py .agent-src.uncompressed/skills/script-writing/SKILL.md` → 0 FAIL
+* Run `python3 scripts/{your-script}.py --quiet` and the verbose path — exit code 0 on clean, non-zero on failure regardless of flag
+* If the script uses `_lib/script_output`, add a test under `tests/` patterned on `tests/test_script_output.py` — assert `silent` / `minimal` / `verbose` behave per § 2
+* Run the full CI pipeline locally (see `Taskfile.yml` in this repo for the script list) — must exit 0 except for tolerated warnings
+
+## Output format
+
+1. Script file at `scripts/{name}.py` with `--quiet` accepted
+2. Taskfile wiring with `silent: true` + `{{.QUIET_FLAG}}` (unless carve-out)
+3. Test under `tests/` if `_lib/script_output` is used
+4. Linter output showing 0 FAIL
+
+## Gotchas
+
+* Forgetting `--quiet` — the silent Taskfile layer wraps the script and the call fails with `unrecognized arguments: --quiet`
+* Gating `❌` failures behind `--quiet` — failures must always print
+* Using raw `print()` for progress lines — drops on `minimal`, no inheritance
+* Adding `silent: true` to a release / install-keys task — bypasses the Hard Floor confirmation
+* Editing `Taskfile.yml`'s `QUIET_FLAG` var — single source of truth, do not duplicate
+* Forgetting that `from _lib.script_output import …` requires the script's resolution to walk up to `scripts/` — copy the `Path(__file__).resolve().parent` pattern from a peer
+
+## Frugality Standards
+
+Apply the [Frugality Charter](../../contexts/contracts/frugality-charter.md)
+to every script you author. Phase 10 of the charter (settings hooks
+row — `verbosity.script_output` / `verbosity.taskfile_command_echo`)
+is what this skill exists to teach.
+
+**Examples in this artifact:**
+- Per the charter's default-terse rule, success lines are gated behind
+  `--quiet` so the only thing visible at `minimal` is the end-of-run
+  summary or a failure.
+- Per the post-action summary suppression, scripts with multi-step
+  output collect via `success()` and emit one `flush_summary()` line.
+- Per the cheap-question check, scripts never prompt unless they hit
+  a Hard Floor surface (§ 3 carve-outs).
+
+**Pre-save self-check:**
+1. Does every `print("✅ ...")` line sit behind `--quiet` / the helper?
+2. Does the script add `silent: true` + `{{.QUIET_FLAG}}` to its
+   Taskfile entry (unless a carve-out)?
+3. Are failure lines (`❌`, exit non-zero) **never** gated by quiet?
+4. Are Iron-Law surfaces using plain `print()` and not the helper?
+
+## Do NOT
+
+* Do NOT gate `❌` / failure output behind `--quiet`
+* Do NOT use `_lib/script_output` for release confirms or secret prompts
+* Do NOT add `silent: true` to carve-out tasks
+* Do NOT hardcode `print()` for progress in new scripts — use `info()`
+* Do NOT skip the Taskfile wiring — without it the verbosity gates leak
+* Do NOT edit `.agent-src/`, `.augment/`, or `.claude/` projections
+
+## Cloud Behavior
+
+On cloud surfaces (Claude.ai Web, Skills API) the package's `task`
+runner and `_lib/script_output` are not reachable. The skill still
+applies — with prose-only validation:
+
+* Emit the full script + Taskfile snippet as copyable Markdown blocks. Do not attempt to write to disk.
+* Self-check: `--quiet` accepted, failures never gated, success lines gated, helper imports look syntactically right.
+* Tell the user to save under `scripts/{name}.py`, wire the Taskfile entry, and run `task lint-skills && task ci` locally before committing.
+* Skip every reference to running the linter or `task` commands yourself — they only run on the user's machine.
+
+## Examples
+
+Good description (trigger-shaped, names domain + symptoms):
+
+> "Use when adding or editing any script under `scripts/` — `--quiet` flag, `_lib/script_output` helpers, silent Taskfile wiring, Iron-Law carve-outs — even when you just say 'add a check script for X'."
+
+Bad description (vague, no trigger):
+
+> "Script conventions"

package/.agent-src/skills/skill-writing/SKILL.md

@@ -295,6 +295,29 @@ utility libs, or simple state managers.
 * Renaming a heading to "Procedure:" without numbered steps or `###` sub-headings
 * **Always run `python3 scripts/skill_linter.py` before saving — 0 FAIL required**
 
+## Frugality Standards
+
+Apply the [Frugality Charter](../../contexts/contracts/frugality-charter.md)
+to every skill you author.
+
+**Examples in this artifact:**
+- Per the charter's default-terse rule, the SKILL.md `## Procedure`
+  opens with the action ("Run the linter"), not "Let me walk you
+  through…".
+- Per the cheap-question check, only emit numbered-options output
+  when consequences differ — never as a stylistic choice.
+- Per the post-action summary suppression, the example output ships
+  the artifact, not a wrapping `## Status` / `## Summary` block.
+
+**Pre-save self-check:**
+1. Does any procedure step open with "Let me", "Now I will", "Found
+   it", "OK", or "Alright"?
+2. Does the skill prescribe numbered-options output without a real
+   consequence trade-off?
+3. Does the example output include a post-action summary block?
+4. Does the description carry filler ("comprehensive", "advanced",
+   "powerful")?
+
 ## Do NOT
 
 * Write documentation-style, pointer-only, or too-broad skills ("Laravel skill")

package/.agent-src/skills/test-driven-development/SKILL.md

@@ -27,6 +27,30 @@ Do NOT use when:
 * Catch edge cases **before** they become production bugs.
 * Leave every change with a regression test that runs in CI.
 
+## Escalate to a SPARC-style 5-phase workflow when
+
+Plain TDD (red → green → refactor) is the right size for **most** work.
+A small subset benefits from a gated 5-phase wrapper —
+**S**pec → **P**seudocode → **A**rchitecture → **R**efine → **C**omplete —
+where each gate produces a written artifact before the next phase runs.
+
+Decision tree — escalate if **any** branch is true:
+
+* The ticket has **AC count > 5** (the spec itself is non-trivial — write
+  it down before testing it).
+* The change **modifies a contract** consumed by ≥1 other module
+  (public API signature, persisted schema, event payload, queue message).
+* The change cuts across **≥3 modules / bounded contexts** at once.
+
+When escalating: drop the `Spec` artifact in `agents/roadmaps/` (or the
+project's planning location), capture it as an ADR via [`adr-create`](../adr-create/SKILL.md)
+when the decision is load-bearing, then run plain TDD inside each
+`Refine` cycle. Do **not** skip RED→GREEN inside a SPARC phase — the
+wrapper adds gates, not exemptions.
+
+For everything else (single-AC ticket, leaf-module change, bug fix),
+stay on plain TDD — the section above.
+
 ## The core discipline
 
 ```

package/.agent-src/templates/agent-settings.md

@@ -311,6 +311,69 @@ commands:
 # repo (gitignored). Maintainer-targeted feature; consumers leave it
 # off. See `.augment/contexts/contracts/artifact-engagement-flow.md`
 # (once Phase 3 of road-to-artifact-engagement-telemetry lands).
+# --- Verbosity (token frugality) ---
+#
+# Five toggles controlling what the agent shows after acting.
+# Default = terse. Flip to true to restore legacy verbose output.
+# See agents/roadmaps/road-to-token-frugality.md for the full rationale
+# and the contexts/contracts/frugality-charter.md for the writer-side
+# standard.
+verbosity:
+  # Show generated commit messages, PR titles/bodies, branch names
+  # before acting. false = use generated content directly.
+  preview_artifacts: false
+
+  # Confirmation prompts for routine workflow steps when there is
+  # one obvious answer ("looks good — commit?"). Iron-Law gates
+  # (commit-policy, scope-control git-ops, non-destructive) ALWAYS
+  # ask regardless of this flag.
+  routine_confirmations: false
+
+  # Offer "run AI Council on this?" inside delivery commands
+  # (/feature-plan, /review-changes, /roadmap-create). Council
+  # commands themselves (/council, /create-pr → already excluded)
+  # are unaffected.
+  offer_council_in_delivery: false
+
+  # Multi-line status / summary blocks after a successful action.
+  # off | minimal | full — default minimal (one-line confirmation).
+  post_action_reports: minimal
+
+  # Intent announcements ("Let me check…", "Now I will…", "Found
+  # it") in skill bodies. false = act and emit the result.
+  intent_announcements: false
+
+  # Script stdout chatter from `scripts/*.py`, `scripts/*.sh`, and
+  # `.augment/scripts/`. Read by the helper module
+  # `scripts/_lib/script_output.py`.
+  #   silent  = stderr only; success = no output
+  #   minimal = one summary line per script (default)
+  #   verbose = pre-Phase-10 behaviour (per-step prints)
+  # Override per-process: AGENT_SCRIPT_VERBOSITY={silent,minimal,verbose}
+  # Iron-Law surfaces (release confirms, install secrets prompts,
+  # error markers) ignore this key and stay loud.
+  script_output: minimal
+
+  # Suppress the `task: [name] cmd...` echo line that Taskfile prints
+  # before each task body. false = keep echoes (default Taskfile
+  # behaviour). true = the Taskfile sets `silent: true` on every
+  # safe task per Phase 10.3.
+  taskfile_command_echo: false
+
+# --- Caveman speak (authoring-only) ---
+#
+# Caveman-style compression scope for newly authored prose. The
+# compile-time toggle (`caveman.speak`) is added in Phase 8.
+# `speak_scope` lands now so the charter and consumers can pin it.
+caveman:
+  # speak_scope = how widely caveman-speak grammar applies in chat
+  #   off          = no caveman grammar in output (compile-time still
+  #                  governed by caveman.speak)
+  #   prose_only   = caveman in body prose; numbered options +
+  #                  Iron-Law-literal blocks stay full prose
+  #   aggressive   = caveman everywhere except Iron-Law literals
+  speak_scope: prose_only
+
 telemetry:
   artifact_engagement:
     # Master switch. `false` (default) produces zero file IO and zero
@@ -342,6 +405,10 @@ Personal and project-level settings (initial file written by
 **Key paths use dot-notation** to denote nesting: `personal.user_name`
 lives under `personal:` in YAML.
 
+The `verbosity.*` and `caveman.speak_scope` rows are summarized below;
+the canonical narrative lives in
+[`docs/customization.md` § Verbosity](../../docs/customization.md#verbosity).
+
 | Key path | Values | Default | Description |
 |---|---|---|---|
 | `cost_profile` | `minimal`, `balanced`, `full`, `custom` | `minimal` | Selects which agent surfaces are active. See [Cost profiles](#cost-profiles). |
@@ -386,6 +453,12 @@ lives under `personal:` in YAML.
 | `commands.suggestion.max_options` | integer | `4` | Max number of command suggestions before the always-present "run as-is" option (total rendered = `max_options + 1`). |
 | `commands.suggestion.blocklist` | list of command names | `[]` | Commands that never appear as a suggestion. They still work when typed explicitly. |
 | `commands.create_pr.preview_description` | `true`, `false` | `false` | When `false`: `/create-pr` skips the title/body preview + adjust loop and uses the generated content directly. Saves agent tokens. When `true`: show title and body before creating and ask for adjustments. `/create-pr:description-only` always previews regardless of this setting. |
+| `verbosity.preview_artifacts` | `true`, `false` | `false` | Show generated commit messages, PR titles/bodies, branch names before acting. `false` = use generated content directly. See [`road-to-token-frugality`](../../../agents/roadmaps/road-to-token-frugality.md) Phase 2/3. |
+| `verbosity.routine_confirmations` | `true`, `false` | `false` | Confirmation prompts for routine workflow steps when there is one obvious answer ("looks good — commit?"). Iron-Law gates (`commit-policy`, `scope-control` git-ops, `non-destructive-by-default`) ALWAYS ask regardless. |
+| `verbosity.offer_council_in_delivery` | `true`, `false` | `false` | Offer "run AI Council on this?" inside delivery commands (`/feature-plan`, `/review-changes`, `/roadmap-create`). Council commands themselves are unaffected. |
+| `verbosity.post_action_reports` | `off`, `minimal`, `full` | `minimal` | Multi-line status / summary blocks after a successful action. `off` = no report; `minimal` = one-line confirmation; `full` = bullet list. |
+| `verbosity.intent_announcements` | `true`, `false` | `false` | Intent announcements ("Let me check…", "Now I will…", "Found it") in skill bodies. `false` = act and emit the result. |
+| `caveman.speak_scope` | `off`, `prose_only`, `aggressive` | `prose_only` | How widely caveman-speak grammar applies in chat. `off` = no caveman grammar; `prose_only` = caveman in body prose, numbered options + Iron-Law-literal blocks stay full prose; `aggressive` = caveman everywhere except Iron-Law literals. Compile-time toggle (`caveman.speak`) lands in Phase 8. |
 | `telemetry.artifact_engagement.enabled` | `true`, `false` | `false` | Master switch for the artefact engagement log. Default-off; zero file IO and zero token cost when `false`. Maintainer-targeted; consumers leave it off. |
 | `telemetry.artifact_engagement.granularity` | `task`, `phase-step`, `tool-call` | `task` | Boundary at which events are recorded. `tool-call` is expensive — opt-in only. |
 | `telemetry.artifact_engagement.record.consulted` | `true`, `false` | `true` | When `true`: record artefacts loaded into context. |

package/.agent-src/templates/command.md

@@ -67,16 +67,21 @@ suggestion:
 
 ### N. Present findings
 
-<!-- For audit/analysis commands: always present findings before applying changes.
-     For action commands: show summary of what was done. -->
-
-Ask the user:
-
-```
-> 1. {Option 1}
-> 2. {Option 2}
-> 3. Skip — report only
-```
+<!-- For audit/analysis commands: state findings, then act or hand back.
+     For action commands: state what was done.
+
+     Default-terse per the
+     [Frugality Charter](../contexts/contracts/frugality-charter.md):
+     no preview-then-confirm pair, no "Ready to proceed?" gate, no
+     numbered options unless options differ in *consequence* (per
+     `no-cheap-questions § Pre-Send Self-Check`). Routine confirmations
+     are governed by `verbosity.routine_confirmations: false` (default).
+
+     Only emit a numbered-options block when ALL of:
+       1. Two or more options carry distinct consequences (not sequencing/format),
+       2. The user has not fenced the next step (per `scope-control § fenced step`),
+       3. No option violates `commit-policy`, `scope-control § git-ops`,
+          or `non-destructive-by-default`. -->
 
 ## Rules
 

package/.agent-src/templates/rule.md

@@ -85,6 +85,12 @@ routes_to:
 
 # {Rule Title}
 
+<!-- Default-terse per the
+  [Frugality Charter](../contexts/contracts/frugality-charter.md):
+  start with the obligation. No "This rule explains…" / "The purpose of
+  this rule is…" / narrative intro before the Iron Law. Body sections
+  are pointers, not playbooks — defer detail to skills/guidelines. -->
+
 **Iron Law.** {The single non-negotiable behavior the rule enforces.}
 
 ## When this fires

package/.agent-src/templates/skill.md

@@ -136,6 +136,38 @@ Do NOT use when:
 - Do NOT {anti-pattern 2}.
 - Do NOT {anti-pattern 3}.
 
+<!-- FRUGALITY STANDARDS (writer skills only — REQUIRED for skills whose
+  name ends in `-writing`, `-authoring`, or `-create`, AND for any
+  skill on the `FRUGALITY_WRITER_SKILLS` allowlist in
+  `scripts/skill_linter.py`. Mid-/untiered non-writer skills MUST
+  remove this section entirely.
+
+  Layer-1 of the linter checks for:
+    1. The literal H2 `## Frugality Standards`,
+    2. A markdown link matching the regex
+       `\[[^\]]+\]\([^)]*frugality-charter\.md[^)]*\)`.
+
+  Body shape — single charter cite, then 3–5 decidable pre-save
+  questions framed as *applying the charter*, not parallel rules
+  (council Pass #4 finding 0.B):
+
+  ## Frugality Standards
+
+  Per the [Frugality Charter](../../contexts/contracts/frugality-charter.md),
+  this writer applies the default-terse standard: no narrative intros,
+  no preview-then-confirm gates, no numbered options without a real
+  trade-off.
+
+  Pre-save self-check:
+  1. Does every body section start with the obligation, not an intro?
+  2. Are numbered options absent unless options differ in *consequence*?
+  3. Is every cited rule linked, not restated?
+  4. {artifact-specific question — e.g., for `command-writing`:
+     "Does the command honor `verbosity.routine_confirmations: false`?"}
+  5. {artifact-specific question — e.g., for `rule-writing`:
+     "Does the rule body open with the Iron Law, no preamble?"}
+-->
+
 <!-- SENIOR-TIER STUB BLOCKS (delete entire section if not `tier: senior`):
   Senior-tier skills (frontmatter `tier: senior`) require four extra
   blocks per `.agent-src.uncompressed/rules/skill-quality.md` §