@event4u/agent-config 5.10.0 → 6.0.0

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

@@ -1,190 +0,0 @@
----
-model_tier: medium
-name: commit
-tier: 0
-cluster: commit
-skills: [git-workflow]
-description: Stage and commit all uncommitted changes — splits into logical commits following Conventional Commits
-suggestion:
-  eligible: true
-  trigger_description: "commit my changes, save this to git, create commits for these changes"
-  trigger_context: "git status shows uncommitted changes"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /commit
-
-Top-level entry point for the `/commit` family. Bare `/commit` runs the
-interactive split-and-confirm flow described below. The `:in-chunks`
-sub-command runs the same split logic without the confirmation prompt.
-
-## Sub-commands
-
-| Sub-command | Routes to | Purpose |
-|---|---|---|
-| `/commit` (bare) | this file (`## Default flow`) | Interactive — split, present plan, wait for approval, commit |
-| `/commit:in-chunks` | `commands/commit/in-chunks.md` | Autonomous — split and commit without confirmation |
-
-## Dispatch
-
-1. Parse the user's argument: `/commit[:<sub>] [args]`.
-2. Bare `/commit` → run the `## Default flow` below verbatim.
-3. `/commit:in-chunks` → load `commands/commit/in-chunks.md` and follow
-   its `## Instructions` section verbatim.
-4. Unknown sub-command → print the table above and ask which one.
-
-## Default flow
-
-### 1. Detect uncommitted changes
-
-Run:
-```bash
-git status --short
-git diff --stat
-git diff --cached --stat
-```
-
-If there are no uncommitted changes (staged or unstaged), report "Nothing to commit." and stop.
-
-### 2. Determine the ticket number
-
-- Extract the ticket ID from the current branch name (e.g. `feat/DEV-1234/...` → `DEV-1234`).
-- If no ticket ID is found in the branch name, ask the user:
-  ```
-  > No Jira ticket found in branch name. Do you want to include one?
-  >
-  > 1. Yes — I'll provide the ticket number
-  > 2. No — skip ticket number
-  ```
-- If the user provides a ticket number, use it as the scope in all commit messages.
-- If skipped, omit the scope entirely — write `chore: ...` not `chore(): ...`.
-
-### 3. Analyze the changes
-
-- Run `git diff HEAD` (and `git diff --cached` for already staged changes) to understand the full diff.
-- Group changed files into **logical units** — files that belong together because they:
-  - Implement the same feature or fix
-  - Are a migration + its corresponding model/seeder
-  - Are a test file and the class it tests
-  - Are purely stylistic/formatting changes (separate from logic changes)
-  - Are unrelated to the main change (e.g. config fix, unrelated typo)
-
-### 4. Plan the commits
-
-For each logical group, determine the commit message following the commit conventions rule
-(see `.augment/rules/commit-conventions.md`).
-
-Rules for splitting:
-- **Do NOT split arbitrarily** — only split when the changes are logically independent.
-- **Prefer fewer, coherent commits** over many tiny ones.
-- **Tests always go with the code they test** unless there are many test-only changes.
-- **Style-only changes** (ECS/Rector formatting) may get their own `style:` or `chore:` commit
-  if they are large and mixed with logic changes.
-
-### 5. Present the commit plan (verbosity-gated)
-
-Read `verbosity.preview_artifacts` and `verbosity.routine_confirmations`
-from `.agent-settings.yml`. Both default to `false`.
-
-**Terse path** — `preview_artifacts: false` AND `routine_confirmations: false`:
-
-1. Validate every generated commit message against the
-   conventional-commits regex
-   `^(feat|fix|chore|docs|refactor|test|perf|style|build|ci|revert)(\([^)]+\))?!?: .+`.
-2. **All messages valid** → skip the preview block and the confirmation
-   prompt. Print one line summarising the plan and proceed to step 6:
-
-   ```
-   → 3 commits planned: feat, test, chore (scope: DEV-1234)
-   ```
-
-3. **Any message invalid** → `preview-on-error` safety net fires:
-   force the full preview block below + the numbered confirm prompt,
-   regardless of the two flags. The user must approve before step 6.
-4. **Hard-Floor diff** (bulk deletion ≥5 unrelated files, infra changes
-   touching Terraform / Pulumi / k8s / Ansible / cloud-config) →
-   ALWAYS preview + confirm regardless of flags, per
-   [`non-destructive-by-default`](../rules/non-destructive-by-default.md).
-
-**Preview path** — `preview_artifacts: true` OR `routine_confirmations: true`
-(or `preview-on-error` triggered):
-
-Show the proposed commits as a numbered list, including which files go into each:
-
-```
-Proposed commits:
-
-1. feat(DEV-1234): add absence type filter to working time report
-   → app/Services/WorkingTimeService.php
-   → app/Http/Controllers/WorkingTimeController.php
-   → app/Http/Resources/WorkingTimeResource.php
-
-2. test(DEV-1234): add component test for working time controller
-   → tests/Component/WorkingTime/WorkingTimeControllerTest.php
-
-3. chore: apply Rector formatting
-   → app/Models/Absence.php
-```
-
-Then ask:
-```
-> 1. Looks good — commit
-> 2. Adjust — I'll tell you what to change
-> 3. Cancel
-```
-
-Wait for the user's response before doing anything.
-
-**Override:** the user may force the preview at any time with
-*"show me the commit plan first"* / *"preview commits"* — treat as a
-one-shot `preview_artifacts: true` for this invocation.
-
-### 6. Commit
-
-On the **terse path** proceed directly. On the **preview path** only after
-the user confirms (option 1).
-
-For each planned commit in order:
-1. Stage only the files for that commit: `git add {files...}`
-2. Commit: `git commit -m "{message}"`
-
-### 7. Report (verbosity-gated)
-
-Read `verbosity.post_action_reports` from `.agent-settings.yml` (default
-`minimal`).
-
-- `off` → emit nothing.
-- `minimal` (default) → one line:
-
-  ```
-  → 3 commits created
-  ```
-
-- `full` → multi-line summary: number of commits + commit messages
-  (one per line).
-
-## Rules
-
-- **Never commit before the user confirms** the plan.
-- **Never push** — pushing is left to the user.
-- **Never modify files** — only stage and commit existing changes.
-- **Do NOT add untracked files** unless they are clearly part of the change (check with `git status`).
-- **Follow commit conventions** as defined in `.augment/rules/commit-conventions.md`.
-
-## Optional: wrap in `/do-and-judge`
-
-If the user invoked `/commit` under `/do-and-judge` (or explicitly asked
-for judged commits), treat the planned commit list from step 5 as the
-implementer artifact:
-
-- Hand the commit plan + diff to the judge before step 6.
-- Judge verdict `apply` → proceed with step 6 unchanged.
-- Judge verdict `revise` → adjust grouping or messages per the issue
-  list, re-present the updated plan to the user, then re-judge.
-- Judge verdict `reject` → stop, report, do not commit.
-
-Two-revision ceiling applies per [`/do-and-judge`](do-and-judge.md).
-Outside the wrapper this section is a no-op.

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

@@ -1,235 +0,0 @@
----
-model_tier: medium
-name: condense
-tier: 1
-skills: []
-description: Condense .md files from .agent-src.uncondensed/ into telegraph format and write to .agent-src/
-suggestion:
-  eligible: false
-  rationale: "Package-internal tooling; only the event4u/agent-config repo runs this."
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# condense
-
-Condense agent config `.md` files from `.agent-src.uncondensed/` into token-efficient telegraph format
-and write the condensed output to `.agent-src/`.
-
-Uses SHA-256 hashes to track which source files changed since last condensation.
-Only changed files need recondensation — saving tokens and time.
-
-## Step 1: Sync non-.md files
-
-```bash
-bash scripts/condense.sh --sync
-```
-
-This copies non-`.md` files (`.php`, etc.), deletes stale files, and shows the count of
-changed `.md` files that need condensation.
-
-## Step 2: Get changed files
-
-```bash
-bash scripts/condense.sh --changed
-```
-
-This lists only `.md` files whose source has changed since the last condensation (based on
-stored SHA-256 hashes). If no files changed → you're done.
-
-If you need to see ALL files regardless of change status:
-`bash scripts/condense.sh --list`.
-
-## Step 3: Condense each changed .md file
-
-**Core principle:** Condensation must improve execution quality, not just reduce length.
-A condensed file should be easier to scan, easier to trigger, and easier to execute than the original.
-
-For each changed `.md` file:
-
-1. Read the source from `.agent-src.uncondensed/{path}`
-2. Condense the prose using these rules:
-   - **Remove:** articles (a, an, the), filler (just, really, basically, actually, simply, essentially),
-     pleasantries, hedging, connective fluff (however, furthermore, additionally),
-     redundant wording, obvious framework knowledge, repeated explanations, decorative prose
-   - **Shorten:** "in order to" → "to", "make sure to" → "ensure", use short synonyms
-   - **Abbreviate** common terms when context is unambiguous: `DB`, `auth`,
-     `config`, `req`, `res`, `fn`, `impl`, `env`, `deps`, `ctx`. Skip if it
-     would be the first occurrence of the concept in the file, or if the
-     abbreviation collides with a domain term (e.g. `auth` stays
-     `authentication` inside an auth-module file). Never abbreviate inside
-     code blocks, frontmatter, file paths, command strings, or Iron Law
-     fenced blocks.
-   - **Arrows for causality:** `X causes Y` / `X leads to Y` / `X, then Y`
-     → `X → Y`. Keep arrows out of code blocks, frontmatter, and Iron Law
-     fenced blocks; only the surrounding prose uses them. (The example
-     phrases here are intentionally backticked so the inline-code
-     protection skips them — never strip those backticks.)
-   - **Fragments OK:** "Run tests before commit" not "You should always run tests before committing"
-   - **Drop:** "you should", "make sure to", "remember to" — state action directly
-   - **Merge** redundant bullets that say the same thing differently
-   - **Prefer** bullets over prose, direct instructions over explanatory paragraphs, one-line decisions over paragraphs
-3. **Copy-paste first, condense second:**
-   Before condensing ANY prose, extract and set aside these elements from the source.
-   They go into the condensed output **unchanged, byte-for-byte**:
-   - **All code blocks** (``` fenced or indented) — copy EVERY code block from source to output FIRST
-   - **YAML frontmatter** — copy verbatim
-   - **All inline code** (`backtick content`)
-   - **All URLs, links, file paths, commands**
-   - **All H1/H2 headings** — exact text preserved
-   - **Tables** (structure preserved, condense cell text only)
-   - **Technical terms, library names, API names**
-   - **Dates, version numbers, numeric values**
-   Then condense ONLY the prose around these preserved elements.
-4. **NEVER remove (even if verbose):**
-   - Trigger clarity (When to use / description)
-   - Decision hints that prevent mistakes
-   - Concrete validation checks
-   - Gotchas based on real failure patterns
-   - Anti-patterns that prevent recurring failures
-   - **Iron Law sections** — see "Iron Laws — do not touch" below
-5. **Enrich (SKILL.md files only):** During condensation, also improve agent-effectiveness:
-   - **Validation steps:** If a Procedure ends with a vague validation ("check if it works"),
-     replace with concrete checks (expected output, commands to verify, specific conditions)
-   - **Mini examples:** If no `Examples` section exists, add a short safe/unsafe or good/bad example
-     (2-4 lines max — not a tutorial)
-   - **Output format:** If the Output format section is vague ("explain everything"), sharpen it to
-     specific numbered expectations ("1. Code snippet 2. Where to register 3. Gotcha if relevant")
-   - **Anti-patterns:** If the same mistake keeps recurring, add a short anti-patterns section
-   - **Do NOT invent content.** Only concretize what the source implies. If the source says
-     "validate copy/paste safety", you can add "Check: no nested backticks, fully selectable".
-     But don't add unrelated sections.
-   - **Do NOT condense weak skills.** If the source has no procedure or no validation, fix structure first.
-   - **Reference skill:** See `.agent-src.uncondensed/skills/skill-writing/SKILL.md` for the gold standard
-6. Write the condensed output to `.agent-src/{path}`
-7. **MANDATORY: Run condensation quality check on this file:**
-
-```bash
-python3 scripts/check_condensation.py --format text 2>&1 | grep "{path}"
-```
-
-If the output contains 🔴 (error) for this file: **STOP. Fix the condensed file before continuing.**
-Common errors and how to fix them:
-- `lost_code_blocks` → You dropped a code block. Copy ALL code blocks from source.
-- `modified_code_block` → Code block content changed. Replace with exact source content.
-- `frontmatter_mismatch` → YAML frontmatter differs. Copy verbatim from source.
-
-**Do NOT call `mark-done` until this file has zero 🔴 errors.**
-
-8. Show word count: `{original} → {condensed} words ({saved}% saved)`
-9. **Mark as done:** `bash scripts/condense.sh --mark-done {path}`
-
-### Batch processing
-
-When condensing multiple files, process them in batches of ~10.
-Mark each file done after writing it. After each batch, show a progress summary:
-
-```
-Batch 1/5 complete: 10 files, avg 42% saved
-```
-
-## Step 4: Final verification gate
-
-Run BOTH checks. Both must pass before finishing.
-
-```bash
-bash scripts/condense.sh --check
-```
-
-Must show ✅ (hashes in sync).
-
-```bash
-python3 scripts/check_condensation.py
-```
-
-Must show **zero 🔴 errors**. Warnings (🟡) are acceptable.
-If any 🔴 errors remain: go back and fix those files before finishing.
-
-## Step 5: Summary (verbosity-gated)
-
-Read `verbosity.post_action_reports` from `.agent-settings.yml` (default
-`minimal`).
-
-- `off` → emit nothing on success; surface errors only.
-- `minimal` (default) → one line: `→ N files condensed (avg X% savings)`.
-- `full` → multi-line table with per-category stats (files condensed,
-  avg savings).
-
-## Hash management
-
-- Hashes are stored in `.augment/.condensation-hashes.json` (committed to Git).
-- `bash scripts/condense.sh --sync` automatically cleans up hashes for deleted source files.
-- `bash scripts/condense.sh --mark-all-done` marks ALL current `.md` files as condensed
-  (useful after an initial full condensation or when bootstrapping the hash file).
-- A file with no stored hash is always treated as "changed".
-
-## Iron Laws — do not touch
-
-Sections under headings matching `Iron Law`, `Iron Laws`, or `The Iron Law` (any
-heading level, numbered variants like `Iron Law 1` included) are **load-bearing
-behavioral rules**. Condensation rules above do **not** apply to them.
-
-For every Iron Law section in a source file:
-
-- **Copy the heading verbatim**, exact text, exact `#` level. NEVER downgrade
-  `## Iron Law` to `### Iron Law` or to inline `**Iron Law:**`.
-- **Copy the fenced code block byte-for-byte**, including capitalization, line
-  breaks, and trailing punctuation.
-- **Copy the negation clauses verbatim** — `NO X`, `NEVER Y`, `NOT Z`. These
-  are the law's exception denials; stripping them weakens the rule.
-- **Telegraph the prose, keep every passage** — every paragraph, every list
-  item, and every fenced code block from the source must appear in the
-  condensed output, in order. Drop articles, shorten phrasing, primitive
-  grammar, terse cave-speak — all encouraged. What's forbidden is dropping
-  whole sentences, merging two paragraphs into one, or skipping a bullet.
-  One paragraph → one paragraph; one bullet → one bullet.
-- **No word-count budget** — condense the prose as hard as telegraph style
-  allows. The check is structural (passage count), not quantitative.
-
-`scripts/check_condensation.py` enforces these mechanically — `iron_law_missing`,
-`iron_law_passage_dropped`, and `iron_law_heading_downgrade` are `error`-level
-and block CI.
-
-If an Iron Law section genuinely contains filler (rare): edit the SOURCE in
-`.agent-src.uncondensed/`, not the condensed copy. Source is the truth.
-
-## Condensation quality checklist
-
-**Also apply the `preservation-guard` rule** — strongest validation, example, anti-pattern, and decision hints must survive condensation. Iron Laws are non-negotiable.
-
-After condensing each file, verify:
-
-- [ ] All code blocks preserved exactly (no content changes)
-- [ ] All inline code, URLs, file paths unchanged
-- [ ] YAML frontmatter identical to source
-- [ ] Headings match source exactly
-- [ ] Tables structure preserved (cell text may be shortened)
-- [ ] "NEVER", "MUST", "Do NOT" and other strong language preserved
-- [ ] Technical terms, library names, API names unchanged
-- [ ] No meaning lost — condensed version says the same thing, shorter
-- [ ] No sections accidentally removed
-- [ ] Word count reduction is 20-50% (typical range for prose-heavy files)
-
-### Safe vs unsafe condensation
-
-Safe:
-- "You should always make sure to run the tests before committing" → "Run tests before commit"
-- "In order to ensure that the configuration is correct" → "To verify config"
-- "It is important to note that this feature requires" → "Requires"
-
-Unsafe (DO NOT do this):
-- Removing a bullet point that contains unique information
-- Changing `php artisan test --filter=MyTest` to `php artisan test`
-- Shortening "Do NOT use float for money" to "Avoid float"
-- Removing "NEVER" from "NEVER add to phpstan-baseline.neon"
-
-## Rules
-
-- **Do NOT commit or push.** Only write files.
-- **Do NOT modify `.agent-src.uncondensed/`** — it is the source of truth.
-- **Only write to `.augment/`** — the condensed output directory.
-- **Preserve ALL technical content** — only condense natural language prose.
-- **YAML frontmatter** in command/skill files must be preserved exactly.
-- **Always run `bash scripts/condense.sh --mark-done {path}`** after writing each condensed file.

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

@@ -1,180 +0,0 @@
----
-model_tier: inherit
-name: context:create
-tier: 2
-cluster: context
-sub: create
-skills: [agent-docs-writing]
-description: Analyze a codebase area and create a structured context document
-suggestion:
-  eligible: true
-  trigger_description: "document this part of the codebase, create a context doc for X"
-  trigger_context: "working in a module without an agents/settings/contexts/ doc"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /context create
-## Instructions
-
-### 1. Ask what to document
-
-If the user provided a topic, use it. Otherwise ask:
-
-```
-📄 What area do you want to document?
-
-Examples:
-- A module (e.g. "ClientSoftware Module")
-- A service (e.g. "CustomerService and Tenant-Switching")
-- An integration (e.g. "ProBauS API Integration")
-- A domain area (e.g. "Import pipeline from upload to processing")
-- Infrastructure (e.g. "Queue system with Horizon")
-```
-
-### 2. Determine scope (module vs. project-wide)
-
-Resolve module roots via `scripts/_lib/agent_settings.py::enumerate_modules()`
-(reads `modules.root_paths` + `modules.agent_folder` from
-`.agent-project-settings.yml`). If at least one module is discovered, ask:
-
-```
-Should the context be created in a module or in the project root?
-
-1. 📦 In a module → {module_root}/{Module}/{agent_folder}/settings/contexts/
-2. 🌐 Project root → agents/settings/contexts/
-```
-
-If module:
-- Render the list of modules from `enumerate_modules()` and ask which one.
-- Target: `{module_root}/{Module}/{agent_folder}/settings/contexts/`
-  (Laravel example: `app/Modules/{Module}/agents/settings/contexts/`)
-- Create directory if it doesn't exist.
-
-If project-wide:
-- Target: `agents/settings/contexts/`
-
-### 3. Determine context type
-
-```
-What type of context is this?
-
-1. 📦 Module — structure and purpose of a module
-2. 🏢 Domain — business logic across multiple modules
-3. ⚙️ Service — complex service with dependencies
-4. 🔗 Integration — external API/system integration
-5. 🏗️ Infrastructure — DevOps, infrastructure
-```
-
-### 4. Analyze the code
-
-Based on the type, analyze the relevant code area:
-
-**Module context:**
-- List all directories and file counts
-- Read key services, controllers, models
-- Analyze route files
-- Check for tests, agent docs
-
-**Domain context:**
-- Search across modules for related code
-- Trace data flow through services
-- Identify all models and tables involved
-
-**Service context:**
-- Read the service class and its deps
-- Trace call chain (who calls it, what it calls)
-- Identify configuration and env deps
-
-**Integration context:**
-- Find API client classes, HTTP calls
-- Read config for credentials/URLs
-- Identify error handling and retry logic
-
-**Infrastructure context:**
-- Read config files, Docker setup
-- Identify services and their connections
-- Check monitoring/logging setup
-
-**Share findings as you go:**
-```
-🔍 Ich analysiere den Code...
-
-Gefunden:
-  • 5 Services in App/Services/
-  • 3 Controllers mit 12 API Endpoints
-  • 8 Models mit Beziehungen zu customer_database
-  • 42 Tests (15 Unit, 20 Component, 7 Integration)
-
-Should I investigate any specific areas in more detail?
-```
-
-### 5. Interactive refinement
-
-After analysis, discuss findings:
-
-- "I noticed {Service} depends on {Dependency}. Is that correct?"
-- "There are {count} endpoints — should all be documented?"
-- "Are there known issues or technical debt in this area?"
-- "Anything I missed?"
-
-### 6. Create the context document
-
-- Read `.augment/templates/contexts.md` for the structure.
-- Create the context file in the target directory.
-- Fill in all applicable sections from the analysis.
-- Set `Last Updated` to today's date.
-
-**Ask for the filename:**
-```
-Context name?
-
-> 1. {suggested-kebab-case-name} (suggested)
-> 2. Enter a custom name
-
-Target: {target-directory}/{name}.md
-```
-
-### 7. Show result
-
-```
-═══════════════════════════════════════════════
-  ✅  CONTEXT CREATED
-═══════════════════════════════════════════════
-
-📄 {path/to/context.md}
-📊 Typ: {type}
-📦 Module: {module or "project-wide"}
-
-───────────────────────────────────────────────
-INHALT:
-───────────────────────────────────────────────
-
-  Key Files:       {count}
-  Key Classes:     {count}
-  DB Tables:       {count}
-  API Endpoints:   {count}
-  Known Issues:    {count}
-
-═══════════════════════════════════════════════
-```
-
-### 8. Offer next steps
-
-```
-What's next?
-
-1. ✏️ Adjust context → /context-refactor
-2. 📋 Plan a feature based on this context → /feature-plan
-3. ✅ Done
-```
-
-### Rules
-
-- **Do NOT commit or push.**
-- **Always analyze the code first** — never guess or assume.
-- **Be factual** — document what IS, not what SHOULD be.
-- **Ask the user** about unclear areas or business context.
-- **Link to specific files** — not vague descriptions.