npm - @event4u/agent-config - Versions diffs - 5.10.1 → 6.1.0 - Mend

@event4u/agent-config 5.10.1 → 6.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (2351) hide show

package/.agent-src/skills/accessibility-auditor/SKILL.md DELETED Viewed

@@ -1,136 +0,0 @@
----
-model_tier: medium
-name: accessibility-auditor
-description: "Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'."
-personas:
-  - frontend-engineer
-domain: quality
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-# accessibility-auditor
-> Audit a UI surface against WCAG 2.2 AA, keyboard-only operation,
-> and screen-reader semantics. Output is a verdict with cited
-> failures, not a vibes check. Pair with
-> [`tailwind-engineer`](../tailwind-engineer/SKILL.md) for token-level
-> contrast fixes and [`ui-component-architect`](../ui-component-architect/SKILL.md)
-> for structural fixes (landmarks, heading order).
-## When to use
-- A new screen, component, or form lands and a11y has not been
-  reviewed yet.
-- A bug report mentions keyboard, screen reader, focus order,
-  contrast, or "user can't reach the X button".
-- A modal, dropdown, popover, tab strip, or tree view is being
-  introduced — these are the highest-yield bug zones.
-- German triggers: "barrierefrei prüfen", "Tastatur-Bedienung",
-  "Screenreader testen".
-Do NOT use when:
-- The visual design itself is the question (palette, type scale) —
-  route to [`fe-design`](../fe-design/SKILL.md).
-- The diff has no UI surface — accessibility audits without a UI are
-  speculation.
-- A specific component spec is missing entirely — get the component
-  built first via the stack-specific skill, then audit.
-## Procedure
-### 1. Identify the interaction surfaces
-List every interactive element on the screen: links, buttons,
-inputs, custom widgets (combobox, tab, dialog, tree). Each row
-gets a verdict in step 5; missing one is a coverage failure.
-### 2. Walk the four checklists
-**Perceivable** — text alternatives for non-text (`alt`, `aria-label`),
-contrast ≥ 4.5:1 for body / 3:1 for large or UI components, no
-colour-only state ("error in red" must also be iconic or text).
-**Operable** — every interactive element reachable by `Tab`, focus
-order matches visual order, focus indicator visible (≥ 3:1 against
-adjacent), `Esc` closes overlays, no keyboard traps.
-**Understandable** — labels associated (`label[for]` or wrapping),
-errors named in text (not just border colour), language attribute
-on `<html>`, predictable navigation across pages.
-**Robust** — landmarks present (`<header>`, `<nav>`, `<main>`,
-`<footer>`), heading order without skips, ARIA only when no native
-element exists, custom widgets follow ARIA-APG patterns.
-### 3. Run the keyboard pass
-`Tab` from page start: every interactive element receives focus,
-in visual order, with a visible indicator. `Shift-Tab` reverses
-cleanly. `Enter` / `Space` activate per role. Arrow keys work in
-composite widgets (tab strip, listbox, menu). `Esc` dismisses the
-top-most overlay only.
-### 4. Run the screen-reader pass
-Use VoiceOver (macOS), NVDA (Windows), or `aria-live` log
-inspection. Each surface announces: role, name, state, value,
-description (in that order). State changes (loading, expanded,
-selected, error) announce. Decorative images are silent.
-### 5. Score and report
-For each surface from step 1:
-| Surface | WCAG SC | Pass / Fail | Evidence |
-|---|---|---|---|
-| Submit button | 1.4.3 | Fail | contrast 3.1:1, expected 4.5:1 |
-| Modal | 2.1.2 | Fail | Tab leaves modal — focus trap missing |
-Verdict at the bottom: **AA-pass** (zero fails), **AA-pass-with-risk**
-(non-blocking gaps + plan), or **AA-fail** (blocking — fix before
-ship).
-## Output format
-```
-Scope:        <screen / component / route>
-Surfaces:     <count from step 1>
-Tools used:   <axe-core | manual | VoiceOver | NVDA — pick at least 2>
-Findings:
-  1. <SC>  <Pass/Fail>  <Evidence + file:line if known>
-  2. ...
-Verdict:      <AA-pass | AA-pass-with-risk | AA-fail>
-Top 3 fixes:  <ordered by user impact>
-```
-## Gotcha
-- `aria-label` on a `<button>` overrides its text content for
-  screen readers — only use when the visible text is not
-  descriptive (icon-only buttons).
-- `tabindex="-1"` removes from tab order *and* allows programmatic
-  focus; `tabindex="0"` adds to tab order. `tabindex >= 1` is
-  almost always wrong — fix the source order.
-- Native `<button>` and `<a>` come with role + keyboard for free;
-  reaching for `role="button"` on a `<div>` is a regression.
-- Contrast on disabled state has no WCAG threshold — but if the
-  user cannot tell it is disabled, that is a 1.4.1 failure on
-  state cue.
-## Do NOT
-- Do NOT declare AA-pass without a keyboard-only pass; an axe-core
-  green is necessary, not sufficient.
-- Do NOT add ARIA "to be safe" — wrong ARIA is worse than no ARIA.
-  Native semantics first.
-- Do NOT silence the audit on "internal-only tool" or "small user
-  base"; legal exposure does not scale with audience size in most
-  jurisdictions.
-- Do NOT close a finding by adjusting the test instead of the UI;
-  the user's experience is the ground truth, not the test report.

package/.agent-src/skills/adversarial-review/SKILL.md DELETED Viewed

@@ -1,156 +0,0 @@
----
-model_tier: high
-name: adversarial-review
-description: "ONLY when user requests adversarial review, devil's advocate, stress-test, OR honest critique of finished work ('poke holes', 'be brutal', 'was hältst du davon') — NOT for routine code/design review."
-personas:
-  - critical-challenger
-domain: quality
-council_depth: deep
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-# Adversarial Review
-## When to use
-Use this skill when:
-- You've completed a plan, design, or proposed fix and are about to present it.
-- The change is non-trivial (affects multiple files, changes behavior, touches critical paths).
-- You're about to recommend an architecture or design decision.
-- The user submits **finished work** (draft, post, naming decision, design proposal) and asks for an honest critical take — "what do you actually think?", "be brutal", "was hältst du wirklich davon". The flow is the same Attack-Defend-Revise loop, but on the user's artifact rather than the agent's plan.
-Do NOT use when:
-- The task is trivial (renaming, formatting, simple config change).
-- The user explicitly asked for a quick/rough draft.
-- You're exploring options, not committing to one yet.
-## Procedure: Adversarial review
-### Step 1: Attack (Grumpy Senior Engineer)
-Assume your plan/fix is flawed. Ask yourself:
-- What's the weakest assumption?
-- Where will this break under load, at scale, or with edge cases?
-- What did I ignore or hand-wave?
-- Is this over-engineered for the actual problem?
-- Would a simpler approach work just as well?
-- What will the next developer curse me for?
-### Step 2: Defend (Balanced Engineer)
-Counter the criticism fairly:
-- Which criticisms are valid and must be addressed now?
-- Which are theoretical and can be deferred?
-- What's the pragmatic middle ground?
-### Step 3: Revise
-- Fix the valid issues in your plan/fix.
-- Move deferred concerns to "Open Questions" or "Known Limitations".
-- Present the improved version to the user.
-**Do this internally** — the user sees the improved result, not the raw debate.
-Only surface trade-offs or concerns that need the user's input.
-## Context-specific attack questions
-### Feature plans / Architecture
-- Is this the simplest solution that works?
-- What happens when requirements change (and they will)?
-- Are there hidden dependencies or coupling?
-- Does this respect existing patterns or introduce a new one unnecessarily?
-- What's the migration/rollback story?
-### Bug fixes
-- Is this the root cause or just a symptom?
-- Will this fix break something else?
-- Does the fix handle the edge case that caused the bug?
-- Is there a regression test that proves the fix works?
-- Are there other places with the same bug pattern?
-### Code changes / Refactoring
-- Would I understand this code in 6 months without context?
-- Did I check all callers and downstream effects?
-- Are the tests actually testing the right behavior?
-- Did I introduce a new pattern where an existing one would work?
-### Database migrations
-- Can this destroy or corrupt data?
-- Is rollback possible?
-- What happens to running queries during migration?
-- Did I check the table size (large table ALTER can lock)?
-### API design
-- Is this a breaking change?
-- Is it consistent with existing endpoints?
-- Are error responses clear and actionable?
-- Did I consider pagination, filtering, versioning?
-### Security-sensitive changes
-- Where is the attack surface I'm not seeing?
-- Am I trusting user input anywhere?
-- Are there authorization gaps?
-- Would this pass a security review?
-## Integration with other skills
-- **feature-planning** — adversarial review after Understanding Lock, before presenting the plan.
-- **bug-analyzer** — review the proposed fix before implementing.
-- **code-review** — self-review before creating a PR.
-- **laravel-migration** (or framework-native equivalent) — review migration for data safety.
-- **api-design** — review API design for consistency and breaking changes.
-- **security** — review security-sensitive changes for attack surface.
-## Auto-trigger keywords
-- adversarial review
-- self-review
-- challenge plan
-- review my approach
-- sanity check
-### Validate
-- Confirm each identified risk has a concrete mitigation or explicit acceptance.
-- Verify the review produced at least one actionable finding (or explicit "no issues found").
-- Check that the review did not just restate the plan — it must challenge assumptions.
-## Output format
-1. Improved plan/code incorporating adversarial findings
-2. Risk summary — top concerns discovered and how they were addressed
-3. Remaining open risks (if any) with severity rating
-## Gotcha
-- Don't use this on trivial changes — it adds overhead without value on simple renames or config tweaks.
-- The model tends to invent risks that don't exist. Ground every concern in actual code, not hypotheticals.
-- Don't challenge the user's explicit requirements — challenge the implementation, not the goal.
-## Do NOT
-- Do NOT present the raw adversarial debate to the user — only the improved result.
-- Do NOT use this as an excuse to delay work — the review should take seconds, not minutes.
-- Do NOT apply this to trivial changes — it adds overhead without value.
-- Do NOT let the "grumpy engineer" kill good ideas — the balanced engineer must counter.
-- Do NOT skip Step 3 (Revise) — attacking without improving is just complaining.
-## References
-- **Tree-of-Thoughts (ToT)** — [arxiv.org/abs/2305.10601](https://arxiv.org/abs/2305.10601)
-  Deliberate problem-solving by exploring multiple reasoning branches.
-  This skill adapts ToT by pitting a grumpy engineer against a
-  balanced engineer — the branching happens between roles, not
-  between thought-tree nodes.

package/.agent-src/skills/agents-md-thin-root/SKILL.md DELETED Viewed

@@ -1,143 +0,0 @@
----
-model_tier: inherit
-name: agents-md-thin-root
-description: "Use when editing AGENTS.md (package root) or templates/AGENTS.md (consumer) — enforces Thin-Root contract: hard char ceilings, ≥40% pointer ratio, mandatory emergency-triage block."
-domain: process
-execution:
-  type: assisted
-  handler: internal
-  allowed_tools: []
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-<!-- cloud_safe: noop -->
-# agents-md-thin-root
-## When to use
-Use when:
-- Editing `AGENTS.md` at the package root.
-- Editing `packages/core/.agent-src.uncondensed/templates/AGENTS.md` (consumer-shipped template).
-- Reviewing a PR that changes either file.
-- Running `/optimize/agents`.
-- A budget meter (`scripts/measure_augment_budget.py`) flags the package-root AGENTS.md as the dominant cost.
-## Do NOT
-- Edit `.github/copilot-instructions.md` with this skill (use `copilot-agents-optimization` instead).
-- Edit other `.md` files under `.augment/`, `packages/*/.agent-src.uncondensed/`, or `agents/` with this skill.
-- Add a section to AGENTS.md without first checking whether an outboard target already exists in `agents/settings/contexts/` or `docs/contracts/`.
-- Replace prose with a bare link `[label](path)` — every pointer needs a *why*-clause ≥ 60 chars or it does not count toward the 40 % ratio.
-- Reuse the package-root anatomy in the consumer template — caps and target paths differ.
-## Why Thin-Root
-Augment Code injects `AGENTS.md` verbatim into every workspace prompt. Each kilobyte spent here permanently consumes the 49,512-char workspace-guidelines budget shared with always-rules and auto-rule registry stubs. The Thin-Root pattern keeps the entry point a navigation surface (pointers + intent) and pushes deep detail into files Augment loads on demand via `load_context` or that other tools fetch only when their search retrieves them. Strategic council R2 (2026-05-08, Sonnet 4.5 / Opus 4.1 / gpt-4o / o1) converged on the contract codified below as the minimum guard against AGENTS.md re-bloat.
-## Iron Law — Capabilities over Structure
-Every entry describes **what** the project does or **where** to learn more — never **where** individual files live. Path lists rot every refactor and poison context; capability pointers survive structural churn. Full anatomy with rewrite recipes, monorepo guidance, and multi-tool symlink strategy: [`agents-md-anatomy`](../../contexts/contracts/agents-md-anatomy.md).
-## The contract — hard caps
-| File | FAIL above | WARN above | Target |
-|---|---|---|---|
-| `AGENTS.md` (package root) | 3,000 chars | 2,800 chars | ≤ 2,800 |
-| `packages/core/.agent-src.uncondensed/templates/AGENTS.md` (consumer) | 2,500 chars | 2,300 chars | ≤ 2,300 |
-Char-count is raw file size (`wc -c`), frontmatter included. Enforcement: `scripts/lint_agents_md.py` (Phase 7), wired into the package's CI pipeline via the `lint-agents-md` task. WARN is a soft signal in CI; FAIL blocks merge.
-The R2 council originally proposed 2,500 / 2,000 caps. Phase 6.4 empirical refactor demonstrated that the mandatory emergency-triage block (≈ 700 chars) plus operational must-haves (source-of-truth disclaimer, `task` quickstart, six substantive pointers) raise the achievable floor by ≈ 500 chars. The caps above are the post-refactor baseline; the previous numbers stayed unattainable without dropping mandatory content.
-## The contract — pointer ratio
-≥ 40 % of non-blank lines must be **substantive pointers**. A substantive pointer is a Markdown link `[label](path[#anchor])` whose surrounding sentence carries a *why* clause ≥ 60 chars explaining what the reader will learn there. Decorative links (table-of-contents, badges, repeated cross-refs) do not count. Lint formula:
-```
-pointer_ratio = (substantive_pointer_lines / non_blank_lines) >= 0.40
-```
-## The contract — pointer anatomy
-Every substantive pointer specifies, on the same line or the immediately following line:
-1. **Target file path** — repo-relative, no leading `./`.
-2. **Optional anchor** — `#section-slug` when the linked file's content is large enough that landing in the middle saves the reader. Skip only when the linked file is itself short.
-3. ***Why* clause** — ≥ 60 chars, present-tense, names the concrete decision the pointer unblocks. Not "see also", not "more info", not the file's title repeated.
-### Wrong vs. right
-❌ **Wrong** — bare link, no *why*, no anchor:
-> See [`commit-policy`](.agent-src/rules/commit-policy.md).
-❌ **Wrong** — *why* present but < 60 chars:
-> Commit rules: [`commit-policy`](.agent-src/rules/commit-policy.md).
-✅ **Right** — full anatomy, anchor, *why* ≥ 60 chars:
-> Commit policy — never auto-commit, four named exceptions, Hard Floor list of bulk-deletion / infra triggers: [`commit-policy § Iron Law`](.agent-src/rules/commit-policy.md#the-iron-law).
-✅ **Right** — anchor optional when target is short:
-> Mirror the user's language every reply, single Iron Law that overrides any momentum: [`language-and-tone`](.agent-src/rules/language-and-tone.md).
-## The contract — emergency-triage block
-Every Thin-Root AGENTS.md MUST contain an **Emergency Triage** section verbatim from `packages/core/.agent-src.uncondensed/contexts/contracts/emergency-triage-block.md` (Phase 6.4 will create that file as the canonical source). The block lists the five questions a host agent answers from the root file alone when network / tool access is degraded:
-1. What is this repository?
-2. What language(s) does this repository accept?
-3. Where do I edit (source-of-truth path)?
-4. What is the lint / test / sync entry point?
-5. Where do the always-active behavior rules live?
-Each answer must fit on one line. The block exists so the root never silently degrades to "useful only when every linked file is reachable".
-## Procedure — apply Thin-Root to AGENTS.md
-1. **Measure baseline.** `wc -c AGENTS.md` and `python3 scripts/measure_augment_budget.py`. Record current char-count and the gap to 2,200 / 2,500.
-2. **Inventory sections.** List every `## ` heading and its char-count. Mark each as `keep-inline` (Iron-Law-adjacent, ≤ 200 chars, no good outboard target) or `outboard-candidate` (longer-form prose, table-only sections, narrative).
-3. **Identify outboard targets.** For each `outboard-candidate`, name the destination — `packages/core/.agent-src.uncondensed/contexts/`, `docs/contracts/`, an existing rule body, an existing skill body. Never invent a new top-level directory.
-4. **Move content; insert pointer.** Cut the section into the target file. Replace it in AGENTS.md with a single substantive pointer per anatomy above. Verify the *why*-clause length.
-5. **Re-measure.** `wc -c AGENTS.md` again. If above 2,200, repeat steps 2–4 on the next-largest section. Above 2,500 = must outboard further before commit.
-6. **Validate pointer ratio.** Count non-blank lines and substantive-pointer lines. Ratio < 0.40 = collapse decorative or boilerplate lines into a single pointer or remove.
-7. **Verify emergency-triage block.** Diff the in-file block against `packages/core/.agent-src.uncondensed/contexts/contracts/emergency-triage-block.md`. Drift = revert to canonical.
-8. **Run lints.** `task lint-agents-md && task check-refs && task lint-skills`. All green before commit.
-## Procedure — apply Thin-Root to consumer template
-Same procedure, applied to `packages/core/.agent-src.uncondensed/templates/AGENTS.md`. Hard cap shifts to 2,000 / 1,700. The consumer template intentionally lacks the package-self-references — its pointers target files that exist in the **consumer's** repo (`.augment/skills/`, `agents/settings/contexts/`, ...), not this package's authoring tree.
-## Gotchas
-- **Outboarding to a new top-level dir.** Inventing `agents/explainers/` or `docs/notes/` for the moved content silently widens the contract surface. Outboard only into `packages/core/.agent-src.uncondensed/contexts/`, `docs/contracts/`, an existing rule body, or an existing skill body.
-- **Pointer-ratio inflation by decoration.** Adding boilerplate "Browse all skills" / "See also" links to lift the ratio above 40 % defeats the purpose. The lint counts only substantive pointers (with a *why*-clause ≥ 60 chars); decorative links get filtered out and the ratio drops back below threshold.
-- **Emergency-triage drift.** Editing the in-file emergency-triage block instead of the canonical `packages/core/.agent-src.uncondensed/contexts/contracts/emergency-triage-block.md` causes the package-root and consumer-template versions to diverge silently. Always edit the canonical file and let the lint diff pull both back in sync.
-- **Cap inversion under WARN.** A 2,250-char AGENTS.md (above 2,200 WARN, below 2,500 FAIL) is a yellow signal not a green one — every additional sentence raises the probability of the next FAIL. Treat WARN as the spend boundary, not a buffer.
-- **Char-count includes frontmatter.** `wc -c` counts every byte including the YAML preamble, blank lines, and the trailing newline. Stripping a section to "look smaller" without re-running `wc -c` understates the true budget impact.
-- **Path enumeration.** A run of three or more bare `` `path/to/dir/` `` bullets without *why*-clauses is the classic re-bloat pattern. The lint emits a WARN at ≥ 3 such lines. Collapse them into one capability-style pointer — see the recipe in [`agents-md-anatomy § Iron Law`](../../contexts/contracts/agents-md-anatomy.md#iron-law--capabilities-over-structure).
-- **Tool-specific duplicates.** Copy-pasting AGENTS.md into `CLAUDE.md` / `GEMINI.md` / `.cursorrules` doubles the budget cost across tools. Use the symlink-or-stub pattern in [`agents-md-anatomy § Multi-tool symlink strategy`](../../contexts/contracts/agents-md-anatomy.md#multi-tool-symlink-strategy) instead.
-## Output format
-When invoked as a planning step, produce:
-1. Current size + gap to target (one line per file).
-2. Inventory table (section, chars, keep-inline / outboard-candidate, target).
-3. Pointer ratio before / after (predicted).
-4. Specific outboarding edits as a numbered diff plan.
-5. The four lint commands the agent must run before claiming completion.
-## Cloud Behavior
-Inert on cloud surfaces. The skill governs the package-root `AGENTS.md` and the consumer-shipped template — both authoring artifacts inside this repository. Cloud agents working on consumer projects never edit those files directly; their copy is delivered by the package install pipeline and refreshed by the package sync pipeline. The Thin-Root contract therefore has no cloud-side procedure to execute, which is why this skill is marked `cloud_safe: noop`.
-## See also
-- [`agents-md-anatomy`](../../contexts/contracts/agents-md-anatomy.md) — Capabilities-over-Structure Iron Law, multi-tool symlink strategy, monorepo per-package layout, refactor recipe, full gotcha catalog.
-- [`copilot-agents-optimization`](../copilot-agents-optimization/SKILL.md) — sibling skill for `.github/copilot-instructions.md`; runs alongside Thin-Root in `/agents optimize`.
-- [`agent-docs-writing`](../agent-docs-writing/SKILL.md) — broader documentation-structure context for navigating outboard targets.
-- [`size-enforcement`](../../rules/size-enforcement.md) — covers per-skill / per-rule / per-command size budgets; AGENTS.md caps live in this skill instead.
-- [`ADR-004-rule-governance-pruning`](../../../docs/decisions/ADR-004-rule-governance-pruning.md) — captures the rule-governance pruning that freed the workspace-guidelines budget; the Thin-Root caps build on that headroom.