@event4u/agent-config 5.10.1 → 6.0.0

package/.agent-src/commands/threat-model.md

@@ -1,125 +0,0 @@
----
-model_tier: high
-name: threat-model
-tier: 1
-skills: [threat-modeling, authz-review, security-sensitive-stop]
-description: Run a pre-implementation threat model on a proposed change — enumerates abuse cases, trust boundaries, and authorization gaps before the first line of code is written
-council_depth: deep
-suggestion:
-  eligible: true
-  trigger_description: "threat model this change, what could go wrong security-wise"
-  trigger_context: "changes touching auth, webhooks, uploads, secrets, or public endpoints"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# threat-model
-
-## Instructions
-
-Produce a structured threat model for the proposed change **before any code
-is written**. Dispatches to [`threat-modeling`](../skills/threat-modeling/SKILL.md)
-for abuse-case and trust-boundary analysis, and to
-[`authz-review`](../skills/authz-review/SKILL.md) whenever the change touches
-authorization, tenancy, or identity.
-
-### 1. Gather the context
-
-Collect, from the user or from the current branch:
-
-- **Change description** — what is being added or modified, in plain language
-- **Entry points** — routes, commands, queue handlers, webhooks that receive
-  the input
-- **Data touched** — tables, columns, storage, external APIs that are read
-  or written
-- **Actor** — who invokes this (authenticated user, tenant-scoped user, admin,
-  anonymous, service account, cron)
-
-If any of the four is missing, **ask the user** — do not guess. A threat model
-built on assumed context is worse than no threat model.
-
-### 2. Decide which skills to dispatch
-
-| Change touches | Skills to run |
-|---|---|
-| Any new or modified surface (default) | [`threat-modeling`](../skills/threat-modeling/SKILL.md) |
-| Permission checks, tenancy, ownership, role logic | + [`authz-review`](../skills/authz-review/SKILL.md) |
-| Secrets, tokens, credentials, signing keys | + [`security-audit`](../skills/security-audit/SKILL.md) |
-
-`threat-modeling` is always mandatory. `authz-review` is mandatory when the
-change crosses an authorization boundary — when in doubt, run it.
-
-### 3. Dispatch mode
-
-- **Sequential** (default) — `threat-modeling` first, then `authz-review` if
-  applicable. The authz findings often reference abuse cases from step 1.
-- **Parallel** — allowed only if `subagents.max_parallel` ≥ 2 in
-  `.agent-settings.yml` and both skills are available as subagents. Merge their
-  reports in step 4.
-
-Each skill produces its own structured output (abuse-case table, trust
-boundary list, authorization matrix). Do not rewrite those blocks — pass
-them through verbatim.
-
-### 4. Consolidate
-
-Produce one combined report with these sections, in order:
-
-1. **Change summary** — the four context items from step 1, restated as the
-   agent understood them
-2. **Abuse cases** — from `threat-modeling`, severity-sorted (🔴 → 🟡 → 🟢)
-3. **Trust boundaries** — entry points and what is trusted vs. untrusted at
-   each one
-4. **Authorization findings** — from `authz-review` if it ran, else a single
-   line: `authz-review skipped — change does not cross an authorization boundary`
-5. **Required controls** — the minimum set of validations, authorization
-   checks, logging, and negative tests that must exist before the change ships
-6. **Open questions** — anything the skills flagged as uncertain and the user
-   must answer before impl starts
-
-### 5. Decide next step
-
-After the report, ask:
-
-```
-> 1. Looks right — proceed to implementation against this threat model
-> 2. Something is wrong or missing — I'll revise the context and re-run
-> 3. Stop here — threat model is the deliverable, no implementation yet
-```
-
-- On **1**: hand off to the impl flow (e.g., `feature-plan`,
-  `bug-fix`, or direct edit) with the required-controls list pinned
-- On **2**: re-gather context and re-dispatch
-- On **3**: save the report as the deliverable, stop
-
-## Use this command when
-
-- Starting a feature that touches authentication, authorization, tenancy,
-  secrets, external input, or sensitive data
-- The [`security-sensitive-stop`](../rules/security-sensitive-stop.md) rule
-  fired and the user asks for the structured analysis
-- A PR reviewer asks for a threat model as a prerequisite
-- Before a change to a trust boundary (API endpoint, webhook, queue consumer,
-  middleware, policy)
-
-## Do NOT
-
-- NEVER skip `threat-modeling` — it is the entrypoint, not optional
-- NEVER produce a threat model on guessed context — ask for the four items
-  in step 1 if any is missing
-- NEVER merge `threat-modeling` and `authz-review` outputs into a single
-  block — each skill owns its format
-- NEVER write production code in the same turn as this command — the
-  deliverable is the report; impl is a separate step
-- NEVER mark the change "safe" if any 🔴 abuse case has no control
-
-## See also
-
-- [`threat-modeling`](../skills/threat-modeling/SKILL.md) — abuse cases, trust boundaries
-- [`authz-review`](../skills/authz-review/SKILL.md) — end-to-end authorization analysis
-- [`data-flow-mapper`](../skills/data-flow-mapper/SKILL.md) — trace specific data through the change
-- [`blast-radius-analyzer`](../skills/blast-radius-analyzer/SKILL.md) — enumerate affected call sites
-- [`security-sensitive-stop`](../rules/security-sensitive-stop.md) — the trigger rule
-- [`minimal-safe-diff`](../rules/minimal-safe-diff.md) — keep the impl scoped

package/.agent-src/commands/update-form-request-messages.md

@@ -1,199 +0,0 @@
----
-model_tier: medium
-name: update-form-request-messages
-tier: 2
-framework: laravel
-skills: [laravel-validation]
-description: "Sync the messages() method of a FormRequest class — add missing entries, link them to language keys, and clean up stale ones."
-suggestion:
-  eligible: true
-  trigger_description: "sync the form request messages, update the validation messages"
-  trigger_context: "edits to app/Http/Requests/*.php referencing rules without messages"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# update-form-request-messages
-
-## Trigger
-
-`/update-form-request-messages [ClassName or file path]`
-
----
-
-## Step 1: Resolve the FormRequest class
-
-**If the user attached a file or mentioned a class name explicitly** → use it.
-
-**Otherwise, ask:**
-
-> Which FormRequest class should I update?
-> Please provide the class name (e.g. `UpdateSuperUserRequest`), its namespace, or the file path.
-
-Once provided, locate the file:
-- Try `codebase-retrieval` or a `find` command to resolve the file path.
-- If multiple matches exist, list them and ask the user to pick one (numbered options).
-- If no match is found, tell the user and stop.
-
-Read the full file content.
-
----
-
-## Step 2: Check for rules()
-
-Scan the file for a `rules()` method.
-
-- **If no `rules()` method exists** → inform the user:
-
-  > ⚠️  No `rules()` method found in `{ClassName}`. Nothing was changed.
-
-  Stop here.
-
----
-
-## Step 3: Parse rules()
-
-Extract every `field → rules` pair from the `rules()` array.
-
-For each field, collect all rules and resolve their **rule names**:
-
-| Rule type | Example | Extracted name |
-|---|---|---|
-| String rule | `'required'` | `required` |
-| String rule with arg | `'max:250'` | `max` |
-| `Rule::` static call | `Rule::unique(...)` | `unique` |
-| `Rule::` static call | `Rule::exists(...)` | `exists` |
-| New object instance | `new Enum(...)` | `enum` (class basename, lowercased) |
-| Closure / `fn()` | `function(...) {}` | **skip** — closures call `$fail()` themselves |
-
-**Also skip these modifier rules** that never produce validation errors:
-`nullable`, `sometimes`, `bail`
-
-Build a flat list of `(field, rule_name)` pairs:
-e.g. `[('username', 'required'), ('username', 'string'), ('username', 'unique'), ...]`
-
----
-
-## Step 4: Determine the language key domain prefix
-
-Derive the domain prefix from the class name:
-1. Strip common verb prefixes: `Create`, `Update`, `Delete`, `List`, `Get`, `Send`, `Show`, `Store`, `Filter`, `Index`
-2. Strip the `Request` suffix
-3. Convert to `snake_case`
-
-Example: `UpdateSuperUserRequest` → `SuperUser` → `super_user`
-
-Present the result and ask to confirm:
-
-> The language key prefix will be `{derived_prefix}` (e.g. `validation.{derived_prefix}.field.rule`).
-> 1. Use `{derived_prefix}` ✓
-> 2. Enter a different prefix
-
-Wait for confirmation before continuing.
-
----
-
-## Step 5: Build the required message entries
-
-For each `(field, rule_name)` pair:
-
-- **messages() key:** `{field}.{rule_name}` (e.g. `'username.required'`)
-- **Lang key:** `validation.{domain}.{field}.{rule_name}`
-  - Wildcard fields keep their notation: `recipients.*.user_id.required`
-  - Example: `validation.super_user.username.required`
-
----
-
-## Step 6: Read existing messages() method (if any)
-
-- If a `messages()` method exists, parse all its `key => __('...')` entries.
-- Keep track of which `(field.rule_name)` keys are already covered.
-- Note the lang key referenced in each existing `__('...')` call.
-
----
-
-## Step 7: Add missing message entries
-
-For each required `(field, rule_name)` pair **not yet covered** by an existing messages() entry:
-
-1. **Check if the lang key already exists** in both `lang/de/validation.php` and `lang/en/validation.php`.
-2. If missing in either → generate a meaningful message:
-   - **English:** e.g. `'The email address is required.'` or `'The email address has already been taken.'`
-   - **German:** e.g. `'Die E-Mail-Adresse ist erforderlich.'` oder `'Diese E-Mail-Adresse ist bereits vergeben.'`
-   - Do **not** write `{field_label}` or `{rule_name}` literally into the lang file — replace them with the actual derived values.
-   - You may use Laravel's standard placeholders (`:attribute`, `:max`, `:min`, etc.) instead of embedding the label directly.
-   - Adapt the message text to fit the specific rule (e.g. `required` → "is required", `unique` → "has already been taken", `max` → "may not exceed :max characters")
-   - Use sensible human-readable field labels (derive from the field name: `snake_case` → "Title Case")
-3. Add the new lang key to `lang/de/validation.php` and `lang/en/validation.php` following the flat dot-notation format from `laravel-translations` rule.
-   - If a domain section comment exists for `{domain}`, insert near it. Otherwise append at the end.
-4. Add the entry to the `messages()` method: `'{field}.{rule_name}' => __('validation.{domain}.{field}.{rule_name}'),`
-
----
-
-## Step 8: Clean up stale messages() entries
-
-Find all keys in `messages()` where `{field}.{rule_name}` is **no longer valid**:
-- The field no longer exists in `rules()`, OR
-- The rule no longer applies to that field
-
-For each stale entry:
-1. Extract the lang key from the `__('...')` call.
-2. **Search the relevant source directories** for that exact lang key string, excluding `vendor/` and `node_modules/` (e.g. `grep -r "validation.super_user.username.old_rule" app lang resources routes config`).
-3. If the lang key is **used nowhere else** → remove it from both `lang/de/validation.php` and `lang/en/validation.php`.
-4. Remove the stale key from `messages()`.
-
----
-
-## Step 9: Write the messages() method
-
-If `messages()` did not exist → add it after `rules()`:
-
-```php
-/** @return array<string, string> */
-public function messages(): array
-{
-    return [
-        '{field}.{rule}' => __('validation.{domain}.{field}.{rule}'),
-        // ...
-    ];
-}
-```
-
-If it existed → update it in-place (keep existing entries that are still valid, add new ones, remove stale ones).
-
-Keep any spread array entries (e.g. `...parent::messages()`) at the top of the array in their original order. Below them, sort only the keyed entries by field name, then rule name within the same field.
-
----
-
-## Step 10: Summary
-
-Print a summary table of what changed:
-
-```
-FormRequest: UpdateSuperUserRequest
-
-ADDED TO messages():
-  username.required  →  validation.super_user.username.required
-
-REMOVED FROM messages():
-  email.old_rule  (lang key removed from both lang files)
-
-UNCHANGED:
-  username.string, username.unique, ...
-
-LANG FILES UPDATED:
-  lang/en/validation.php  — +1 added, -1 removed
-  lang/de/validation.php  — +1 added, -1 removed
-```
-
----
-
-## Rules
-
-- **Never hardcode message strings** in the FormRequest — always use `__('validation.key')`.
-- **Always update both** `lang/de/validation.php` AND `lang/en/validation.php`. One without the other is a bug.
-- **Lang keys use flat dot-notation** — never nested arrays in lang files.
-- **Do NOT commit or push.** Only apply local changes.
-- **Do NOT remove lang keys** that are still referenced anywhere else in the codebase.

package/.agent-src/commands/upstream-contribute.md

@@ -1,181 +0,0 @@
----
-model_tier: inherit
-name: upstream-contribute
-tier: 1
-skills: [upstream-contribute, skill-writing, learning-to-rule-or-skill]
-description: Contribute a learning, skill, rule, or fix from a consumer project back to the shared agent-config package
-suggestion:
-  eligible: true
-  trigger_description: "contribute this back to agent-config, upstream this learning"
-  trigger_context: "project-local skill/rule that fits the shared package"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /upstream-contribute
-
-## Input
-
-The user may provide:
-
-- A file path to a new or improved skill/rule/command
-- A description of what should be contributed
-- Nothing (auto-detect from recent work)
-
-## Steps
-
-### 1. Identify what to contribute
-
-If the user provided a file path → read it.
-If not → check for recent overrides or new skills:
-
-```bash
-ls agents/overrides/ 2>/dev/null
-find .augment/skills -name 'SKILL.md' -newer .augment/rules -maxdepth 3 2>/dev/null
-git diff --name-only HEAD~5 -- agents/overrides/ .augment/skills/ 2>/dev/null
-```
-
-Ask the user to confirm what should be contributed:
-
-```
-> Found these candidates for upstream contribution:
->
-> 1. {file1} — {brief description}
-> 2. {file2} — {brief description}
-> 3. Something else — I'll describe it
->
-> Which one?
-```
-
-### 2. Check universality
-
-Before proceeding, verify the content is package-worthy:
-
-- [ ] No project-specific references (domain names, local paths, FQDNs, project-specific classes)
-- [ ] Benefits ALL consumers, not just this project
-- [ ] Learning occurred 2+ times OR is clearly generalizable
-
-If project-specific content is found, ask:
-
-```
-> ⚠️ Found project-specific references: {examples}
->
-> 1. Remove them — make it universal
-> 2. Cancel — keep as project-only override
-```
-
-### 3. Determine contribution type and target path
-
-| Type | Uncondensed target | Condensed target |
-|---|---|---|
-| **Skill** | `.agent-src.uncondensed/skills/{name}/SKILL.md` | `.agent-src/skills/{name}/SKILL.md` |
-| **Rule** | `.agent-src.uncondensed/rules/{name}.md` | `.agent-src/rules/{name}.md` |
-| **Command** | `.agent-src.uncondensed/commands/{name}.md` | `.agent-src/commands/{name}.md` |
-| **Guideline** | `docs/guidelines/{cat}/{name}.md` | _(not condensed; reference-only)_ |
-
-### 4. Get access to the package repo
-
-```
-> I need to create files in the agent-config package repo.
->
-> 1. I have it cloned locally — I'll give you the path
-> 2. Clone it for me into /tmp/agent-config-upstream
-> 3. Just output the files — I'll handle it manually
-```
-
-**Option 1:** User provides path → verify it's the right repo:
-
-```bash
-cd {path} && git remote get-url origin
-# Must contain event4u-app/agent-config
-```
-
-**Option 2:**
-
-```bash
-git clone git@github.com:event4u-app/agent-config.git /tmp/agent-config-upstream
-cd /tmp/agent-config-upstream
-```
-
-**Option 3:** Skip to Step 7 (output files only).
-
-### 5. Create branch and write files
-
-```bash
-cd {package-repo}
-git checkout main && git pull
-git checkout -b {type}/{name}  # e.g. feat/skills/php-container-discovery
-```
-
-Write the **uncondensed version** (full, verbose, human-readable).
-Write the **condensed version** (token-efficient, 40-60% shorter for skills; 1:1 for rules/commands).
-
-Condensed version MUST preserve:
-
-- All code blocks (byte-for-byte)
-- YAML frontmatter (verbatim)
-- All headings
-- Validation rules, gotchas, "Do NOT" sections
-
-Frontmatter must have `source: package`.
-
-### 6. Run quality gates
-
-```bash
-python3 scripts/skill_linter.py --all           # 0 FAIL required
-python3 scripts/check_condensation.py            # No 🔴 errors for this file
-python3 scripts/condense.py --generate-tools    # Regenerate symlinks
-bash scripts/condense.sh --check                # .agent-src/ in sync with source
-bash scripts/condense.sh --check-hashes         # All hashes match
-```
-
-Fix any issues before continuing.
-
-### 7. Present result
-
-**If Option 1 or 2** (working in package repo):
-
-```
-> ✅ Files created in {package-repo}:
->
-> - `.agent-src.uncondensed/{type}/{name}` (uncondensed)
-> - `.agent-src/{type}/{name}` (condensed)
->
-> Quality gates: {pass/fail summary}
->
-> 1. Commit and push — I'll create the PR
-> 2. Commit only — I'll push later
-> 3. Review the files first
-```
-
-**If Option 3** (manual):
-
-Show both file contents in copyable fenced blocks with full paths as headers.
-
-### 8. Create PR (if user chose Option 1 in Step 7)
-
-```bash
-git add .
-git commit -m "{type}({scope}): add {name}
-
-{brief description of what it does and why it's universal}"
-git push -u origin {branch}
-```
-
-Create PR via GitHub API with the package's PR template.
-Fill in all gates (Promotion, Quality, Universality, Completeness).
-
-### 9. Remind about local override cleanup
-
-```
-> 📝 After the PR is merged and you update the package in this project:
->
-> ```bash
-> rm agents/overrides/{type}/{name}.md
-> composer update event4u/agent-config  # or: npm update
-> ```
->
-> The shared version will then replace your local override.
-```

package/.agent-src/commands/video/from-script.md

@@ -1,127 +0,0 @@
----
-model_tier: inherit
-name: video:from-script
-tier: 2
-cluster: video
-sub: from-script
-description: Drive a script end-to-end through the AI video pipeline — scenes → blueprint → image → operator pick → motion → video → stitch. Dry-run default; network calls require explicit per-turn confirmation.
-personas: [hollywood-director, ai-video-technical-director]
-skills: [scene-expander, video-director, pixar-storyteller, character-consistency, motion-choreographer]
-suggestion:
-  eligible: true
-  trigger_description: "render a video from a script, full AI video pipeline, multi-scene generation"
-  trigger_context: "user supplies a Markdown script with `## Scene N` headings and wants a final MP4"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /video:from-script
-
-`/video:from-script <path-to-script.md> [--image-provider <id>] [--video-provider <id>]`
-
-Drives a Markdown script through the full pipeline. Provider flags
-override the `<default-image-provider>` / `<default-video-provider>`
-from [`agents/.ai-video.xml`](../../../agents/templates/.ai-video.xml.example);
-absent flags fall back to the XML defaults.
-
-**Block-on-ambiguity:** a missing scene heading, an unparseable
-character-lock block, or a contradictory provider flag halts the run
-with a precise diff — no silent best-guess.
-
-## Steps
-
-### 1. Validate dependencies
-
-```bash
-scripts/ai-video/lib/validate-deps.sh .agent-src.uncondensed/commands/video/from-script.md
-```
-
-Fails fast with the missing-id list if any declared persona / skill is
-absent from `.agent-src/personas/` or `.agent-src/skills/`. No network
-call has happened yet.
-
-### 2. Load config + resolve providers
-
-Source `scripts/ai-video/lib/load-config.sh`. Resolve image / video
-provider in this order: command flag → `agents/.ai-video.xml` default
-→ fail with the available-providers list.
-
-### 3. Parse the script
-
-Run the `scene-expander` skill: split on `## Scene N` headings, extract
-dialogue / action / ambient blocks, and emit one `scene-blueprint.yaml`
-per scene under `<project>/scenes/<id>/`. Schema:
-[`scene-blueprint.schema.yaml`](../../skills/scene-expander/scene-blueprint.schema.yaml).
-
-### 4. Character lock
-
-Run `character-consistency` once for the whole project. Writes
-`<project>/character.json` (subject, palette, wardrobe, prop, seed)
-that every later prompt must reuse verbatim.
-
-### 5. Per-scene image render
-
-For each scene blueprint:
-
-1. Compose the eight-block image prompt via `video-director`
-   (style · subject · environment · action · camera · lens · lighting · mood).
-2. **Safety gate (Phase 5 Step 6).** If `AIV_DRYRUN=false`, print the
-   adapter, model, scene count, and estimated cost; refuse to continue
-   without an explicit operator confirmation **in this turn**. Mirrors
-   [`non-destructive-by-default`](../../rules/non-destructive-by-default.md).
-3. Call the image adapter (`run` subcommand) N times where N =
-   `<tuning/best-of-n>` (default 1).
-
-### 6. Operator pick (best-of-N checkpoint)
-
-```bash
-scripts/ai-video/lib/operator-pick.sh <project> <scene-id>
-```
-
-Renders the candidate contact-sheet PNG, pauses, and waits for the
-operator to write `<project>/scenes/<id>/selection.json`. In dry-run
-mode the helper auto-selects the first candidate so the smoke test
-stays unattended.
-
-### 7. Motion + video render
-
-Pass the locked image into `motion-choreographer` (per-provider profile)
-→ build the motion prompt → call the video adapter (`submit` / `poll` /
-`fetch`). Same safety gate as Step 5 fires before each live call.
-
-### 8. Stitch
-
-Build `<project>/manifest.json` (ordered `{scene_id, clip_path,
-audio_embedded, audio_path?, duration}`) and run:
-
-```bash
-scripts/ai-video/stitch.sh <project>/manifest.json <project>/final.mp4
-```
-
-Fail loud on missing clips; offer `--skip-scene <id>` or `--continue`
-per the stitcher contract.
-
-### 9. Report
-
-Print: project slug, final MP4 path, scenes rendered, scenes skipped,
-estimated cost (live mode) or `dry-run` marker. No commit. No push.
-
-## Rules
-
-- **No commit, no push, no PR.** Pipeline produces artefacts; the
-  operator chooses what to ship.
-- **Dry-run is the default.** Every live network call needs explicit
-  per-turn confirmation.
-- **Block on ambiguity** — never silently best-guess scene splits or
-  provider mismatches.
-- **One project per invocation.** Re-running on the same project
-  resumes from existing artefacts (skips completed scenes).
-
-## See also
-
-- [`/video:scene`](scene.md) — single-scene iteration
-- [`/video:storyboard`](storyboard.md) — image-only contact sheet
-- [`/video:stitch`](stitch.md) — re-stitch after operator edits
-- [`scripts/ai-video/lib/adapter-contract.md`](../../../scripts/ai-video/lib/adapter-contract.md)