@event4u/agent-config 1.9.1

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

@@ -0,0 +1,97 @@
+---
+name: override-create
+description: Creates a project-level override for a shared skill, rule, or command.
+skills: [override-management, agent-docs-writing]
+disable-model-invocation: true
+---
+
+# /override-create
+
+Creates an override file in `agents/overrides/` for a shared `.augment/` resource.
+
+## Steps
+
+### 1. Ask: What to override
+
+Ask the user:
+
+> What do you want to override?
+> 1. **Rule** (`.augment/rules/`)
+> 2. **Skill** (`.augment/skills/`)
+> 3. **Command** (`.augment/commands/`)
+> 4. **Guideline** (`.augment/guidelines/`)
+> 5. **Template** (`.augment/templates/`)
+
+### 2. List available originals
+
+Based on the type, list all available files:
+
+- **Rules:** `ls .augment/rules/*.md`
+- **Skills:** `ls .augment/skills/*/SKILL.md`
+- **Commands:** `ls .augment/commands/*.md`
+- **Guidelines:** `find .augment/guidelines/ -name '*.md'`
+- **Templates:** `find .augment/templates/ -name '*.md' -not -path '*/overrides/*'`
+
+Present as a numbered list. Ask the user to pick one (or type a name).
+
+### 3. Check for existing override
+
+Check if `agents/overrides/{type}/{name}.md` already exists.
+
+- If yes → inform the user and ask if they want to edit the existing one instead
+- If no → continue
+
+### 4. Read the original
+
+Read the full content of the original file. Present a brief summary:
+
+> **Original:** `.augment/skills/eloquent/SKILL.md`
+> **Summary:** Writes Eloquent models with getter/setter pattern, eager loading, type safety...
+> **Sections:** Core Rules, Relationships, Scopes, Query Patterns, ...
+
+### 5. Ask: Mode
+
+> How should the override work?
+> - **extend** — The original stays active, your override adds or changes parts of it
+> - **replace** — Das Original wird komplett ignoriert, dein Override ist die einzige Quelle
+
+### 6. Ask: What to change
+
+Based on mode:
+
+- **extend:** "Which sections do you want to change or add?"
+  - List the original's section headings
+  - User picks sections or describes changes
+- **replace:** "Describe what the override should do instead."
+
+### 7. Create the override file
+
+Use the appropriate template from `.augment/templates/overrides/{type}.md`.
+
+Fill in:
+- The correct `Mode` and `Original` path
+- The user's changes/additions
+- Remove template comments
+
+**File path:** `agents/overrides/{type}/{name}.md`
+
+- **Rules:** `agents/overrides/rules/{rule-name}.md`
+- **Skills:** `agents/overrides/skills/{skill-name}.md`
+- **Commands:** `agents/overrides/commands/{command-name}.md`
+- **Guidelines:** `agents/overrides/guidelines/{lang}-{filename}.md` (e.g., `php-controllers.md`)
+- **Templates:** `agents/overrides/templates/{template-name}.md`
+
+**Important:** `.augment/` is a shared package — never modify files there for project-specific needs.
+
+### 8. Verify
+
+- Read the created file back
+- Confirm with the user:
+
+> ✅ Override created: `agents/overrides/skills/eloquent.md` (Mode: extend)
+>
+> Der Agent wird ab jetzt:
+> 1. Load the original (`.augment/skills/eloquent/SKILL.md`)
+> 2. Layer your override on top
+>
+> Anything else to adjust?

package/.agent-src/commands/override-manage.md

@@ -0,0 +1,96 @@
+---
+name: override-manage
+description: Reviews, updates, and refactors existing project-level overrides.
+skills: [override-management, agent-docs-writing]
+disable-model-invocation: true
+---
+
+# /override-manage
+
+Manages existing overrides in `agents/overrides/`.
+
+## Steps
+
+### 1. Scan all overrides
+
+```bash
+find agents/overrides/ -name '*.md' -not -name '.gitkeep' | sort
+```
+
+If no overrides exist:
+
+> No overrides found. Use `/override-create` to create one.
+
+### 2. Present inventory
+
+Show a table of all overrides with their status:
+
+| # | Override | Mode | Original exists? | Status |
+|---|---|---|---|---|
+| 1 | `rules/php-coding.md` | extend | ✅ | Active |
+| 2 | `skills/eloquent.md` | replace | ✅ | Active |
+| 3 | `commands/old-cmd.md` | extend | ❌ | ⚠️ Orphaned |
+
+**Status checks:**
+- **Active** — Original exists, override is valid
+- **Orphaned** — Original was deleted/renamed, override has no target
+- **Invalid** — Missing `Mode` header or malformed
+
+### 3. Ask: What to do
+
+> What would you like to do?
+> 1. **Review** — View an override in detail
+> 2. **Edit** — Edit an override
+> 3. **Delete** — Remove an override (original becomes active again)
+> 4. **Sync** — Check all overrides against their originals
+> 5. **Upgrade** — Update override after original changed
+
+### 4a. Review
+
+- Read the override file
+- Read the original file
+- Show a side-by-side comparison:
+  - What the original says
+  - What the override changes/adds/removes
+  - Effective result (merged view for `extend` mode)
+
+### 4b. Edit
+
+- Read the current override
+- Ask what to change
+- Apply changes
+- Verify the result
+
+### 4c. Delete
+
+- Confirm with the user:
+  > ⚠️ Override `skills/eloquent.md` will be deleted.
+  > The original `.augment/skills/eloquent/SKILL.md` will become active again unchanged.
+  > Proceed?
+- Delete the file
+
+### 4d. Sync
+
+For each override:
+1. Read the original
+2. Read the override
+3. Check if the override still makes sense:
+   - Does it reference sections that still exist?
+   - Has the original changed significantly?
+   - Are there new sections in the original that the override should address?
+
+Report findings:
+
+> **Sync Report:**
+> - `skills/eloquent.md` — ✅ OK, override still valid
+> - `rules/php-coding.md` — ⚠️ Original has new section "Enums" not covered by override
+> - `commands/old-cmd.md` — ❌ Original deleted, override is orphaned
+
+### 4e. Upgrade
+
+When an original has changed and the override needs updating:
+
+1. Show what changed in the original (diff-style)
+2. Ask if the override needs adjustment
+3. Apply changes to the override
+4. Verify the result

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

@@ -0,0 +1,154 @@
+---
+name: package-reset
+skills: [composer, npm]
+description: /package-reset
+disable-model-invocation: true
+---
+
+# package-reset
+
+Remove local package links created by `/package-test` and restore normal dependency resolution.
+
+## Instructions
+
+### 1. Detect linked packages
+
+Scan the project for locally linked packages:
+
+#### Composer
+
+Read `composer.json` → `repositories` array. Find entries with `"type": "path"`:
+
+```json
+{
+    "type": "path",
+    "url": "/some/local/path",
+    "options": { "symlink": true }
+}
+```
+
+For each, extract the package name from the local path's `composer.json`.
+
+#### npm
+
+Check for:
+- Symlinks in `node_modules/` pointing outside the project (via `npm link`)
+- `overrides` in `package.json` with `file:` protocol
+
+### 2. Present findings
+
+**No linked packages found:**
+
+```
+✅  No locally linked packages found. Nothing to reset.
+```
+
+**One linked package:**
+
+```
+Found 1 locally linked package:
+
+📦 {package-name} → {local-path}
+
+1. Remove it
+2. Cancel
+```
+
+**Multiple linked packages:**
+
+```
+Found {N} locally linked packages:
+
+1. {package-name-1} → {local-path-1}
+2. {package-name-2} → {local-path-2}
+...
+{N+1}. Remove all
+{N+2}. Cancel
+
+Which packages to remove? (comma-separated numbers or "all")
+```
+
+### 3. Remove the link
+
+#### Composer
+
+1. Remove the `"type": "path"` entry from `repositories` array in `composer.json`
+2. If `repositories` array is now empty, remove the entire `repositories` key
+3. Run:
+
+```bash
+composer update {package-name}
+```
+
+This resolves the package from Packagist (or other configured repos) again.
+
+If the package was added only for local testing (not in the project before):
+
+```bash
+composer remove {package-name}
+```
+
+Ask which case applies:
+
+```
+Was {package-name} already a dependency before local testing?
+
+1. Yes — update to restore the Packagist version
+2. No — remove it entirely
+```
+
+#### npm
+
+1. Run:
+
+```bash
+npm unlink {package-name}
+```
+
+2. Remove any `overrides` entry from `package.json`
+3. Run `npm install` to restore the published version
+
+If the package was added only for local testing:
+
+```bash
+npm uninstall {package-name}
+```
+
+Same question as Composer — was it a dependency before?
+
+### 4. Verify
+
+- **Composer:** Check `vendor/{package-name}` is NOT a symlink anymore
+- **npm:** Check `node_modules/{package-name}` is NOT a symlink anymore
+
+```
+✅  {package-name} restored to published version.
+   vendor/{package-name} → normal directory (not symlink)
+```
+
+Or if removed:
+
+```
+✅  {package-name} removed completely.
+```
+
+### 5. Summary
+
+After all selected packages are processed:
+
+```
+═══════════════════════════════════════════════
+Package Reset Summary
+═══════════════════════════════════════════════
+
+| # | Package | Action |
+|---|---|---|
+| 1 | {name} | Restored to Packagist |
+| 2 | {name} | Removed |
+```
+
+## Notes
+
+- Always verify `composer.json` / `package.json` changes look correct before running install/update.
+- If `composer update` fails (e.g., version constraint mismatch), suggest adjusting the version constraint.
+- This command is the counterpart to `/package-test`.

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

@@ -0,0 +1,154 @@
+---
+name: package-test
+skills: [composer, npm]
+description: /package-test
+disable-model-invocation: true
+---
+
+# package-test
+
+Test a local package in the current project by linking it via Composer or npm.
+
+## Instructions
+
+### 1. Detect or ask for package manager
+
+Check the project root for `composer.json` and `package.json`.
+
+- **Both exist** → ask:
+
+```
+Which package manager?
+
+1. Composer (PHP)
+2. npm (JavaScript/TypeScript)
+```
+
+- **Only one exists** → use that one automatically, confirm:
+
+```
+Detected: {manager}. Proceeding.
+```
+
+- **Neither exists** → abort:
+
+```
+❌  No composer.json or package.json found in project root. Cannot link a local package.
+```
+
+### 2. Ask for the local package path
+
+```
+Where is the local package located?
+
+Provide the absolute or relative path to the package directory.
+Example: ../my-package or /Users/me/projects/my-package
+```
+
+Validate:
+- Path exists and is a directory
+- For Composer: directory contains `composer.json`
+- For npm: directory contains `package.json`
+
+If invalid, show error and ask again.
+
+### 3. Read the package name
+
+- **Composer:** Read `name` from the package's `composer.json`
+- **npm:** Read `name` from the package's `package.json`
+
+Confirm:
+
+```
+📦 Found package: {package-name}
+   Path: {resolved-absolute-path}
+
+1. Link it
+2. Different package — let me re-enter
+3. Cancel
+```
+
+### 4. Link the package
+
+#### Composer
+
+Add or update `repositories` array in the **project's** `composer.json`:
+
+```json
+{
+    "type": "path",
+    "url": "{absolute-path-to-package}",
+    "options": {
+        "symlink": true
+    }
+}
+```
+
+Then run:
+
+```bash
+composer require {package-name}:@dev
+```
+
+If the package is already required, run instead:
+
+```bash
+composer update {package-name}
+```
+
+#### npm
+
+Run:
+
+```bash
+npm link {absolute-path-to-package}
+```
+
+Or for workspaces, add to `package.json`:
+
+```json
+"overrides": {
+    "{package-name}": "file:{relative-or-absolute-path}"
+}
+```
+
+Then: `npm install`
+
+### 5. Verify
+
+- **Composer:** Check that `vendor/{package-name}` is a symlink → the local path
+- **npm:** Check that `node_modules/{package-name}` is a symlink → the local path
+
+Report result:
+
+```
+✅  {package-name} linked successfully.
+   vendor/{package-name} → {local-path}
+
+To remove: run /package-reset
+```
+
+### 6. Remind about .gitignore
+
+If the `repositories` entry (Composer) or `overrides` (npm) was added:
+
+```
+⚠️  Local package link added to {file}. Don't commit this change to the repository.
+```
+
+## Error Handling
+
+- If `composer require` or `npm link` fails, show the error output and suggest:
+
+```
+1. Retry
+2. Show me the full error
+3. Cancel — I'll fix manually
+```
+
+## Notes
+
+- Composer path repositories with `symlink: true` create a symlink in `vendor/` pointing to the local directory. Changes in the local package are immediately reflected.
+- npm link creates a symlink in `node_modules/`.
+- Multiple local packages can be linked simultaneously. Each `/package-test` invocation adds one.
+- The `/package-reset` command reverses these changes.

package/.agent-src/commands/prepare-for-review.md

@@ -0,0 +1,91 @@
+---
+name: prepare-for-review
+skills: [git-workflow, quality-tools]
+description: Prepare a PR branch for local review — updates main and merges the full branch chain so the branch is up to date
+disable-model-invocation: true
+---
+
+# prepare-for-review
+
+## Input
+
+The user provides a PR number or ticket number (e.g. `DEV-1234` or `#42`).
+
+### PR detection
+
+1. If the user provides a GitHub PR URL or PR number → use that PR directly.
+2. If the user provides a Jira ticket number (e.g. `DEV-1234`) → search for an open PR linked to that ticket:
+   - Search via GitHub API for an open PR whose branch name contains the ticket number.
+   - If exactly one PR is found → confirm with the user: "I found PR #{number} on branch `{branch}`. Is that the one?"
+   - If none or multiple found → ask the user for the PR number or URL.
+3. **Never** reuse a PR number from earlier in the conversation without confirmation.
+
+## Instructions
+
+### 1. Fetch the PR
+
+- Use the GitHub API to get the PR details: base branch, head branch, and title.
+
+### 2. Build the branch chain
+
+- If **base branch is `main`** → chain is: `main → {head branch}`
+- If **base branch is NOT `main`** → the base branch itself may have a non-main base.
+  - Recursively fetch the PR for the base branch (search for an open PR with that head branch).
+  - Keep going until you reach `main`.
+  - Build the full ordered chain, e.g.: `main → feature/base → feature/sub → feature/target`
+
+### 3. Update main
+
+```bash
+git checkout main
+git pull origin main
+```
+
+If this fails, abort and report the error to the user.
+
+### 4. Fetch all branches
+
+Before any local checkout or merge, fetch all branches in the chain from `origin`:
+
+```bash
+git fetch origin {branch-1} {branch-2} ...
+```
+
+This ensures the branches exist locally and are up to date, even in a fresh clone.
+
+### 5. Merge chain bottom-up
+
+For each consecutive pair in the chain (starting from `main` upward):
+
+```bash
+git checkout {child-branch}
+git merge {parent-branch} --no-edit
+```
+
+- If a **merge conflict** occurs at any point:
+  - Run `git merge --abort`
+  - Abort the entire process immediately
+  - Report to the user exactly which branches conflicted
+  - Do NOT proceed further
+
+### 6. Check out the target branch
+
+Once all merges succeed:
+
+```bash
+git checkout {head-branch-of-target-PR}
+```
+
+### 7. Report
+
+Inform the user:
+- Which branch chain was processed (in order)
+- That the target branch is now checked out and up to date
+- Any warnings (e.g. branch was already up to date)
+
+## Rules
+
+- **Do NOT push** any branch — only local merges.
+- **Do NOT create manual commits** — only `git merge` may create merge commits as part of this workflow.
+- **Abort immediately** on any conflict — do not try to resolve conflicts.
+- **Always fetch fresh PR data** — never reuse stale data from earlier in the conversation.