@event4u/agent-config 1.9.1

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

@@ -0,0 +1,76 @@
+---
+name: create-pr
+skills: [git-workflow]
+description: Create a GitHub PR with structured description from Jira ticket and code changes
+disable-model-invocation: true
+---
+
+# create-pr
+
+Uses `/create-pr-description` to generate the PR content, then creates the PR via GitHub API.
+
+## Instructions
+
+### 1. Check prerequisites
+
+- Verify the current branch is NOT the default branch (`main` / `master`).
+- Run `git status` — warn if there are uncommitted changes.
+- Run `git log origin/{default}..HEAD --oneline` to verify there are commits to push.
+- If the branch has not been pushed yet, ask the user (in their language) whether to push.
+
+### 2. Generate PR content
+
+Run `/create-pr-description` to generate the PR title and body.
+This handles: Jira ticket extraction, diff analysis, commit messages, **PR template filling**.
+
+**CRITICAL**: The PR body MUST use the project's PR template (`.github/pull_request_template.md`).
+Read the template file and fill in its sections. If the template does not exist, use the
+fallback structure defined in `/create-pr-description`. NEVER invent a custom body structure.
+
+The user reviews and adjusts the content in that step.
+
+### 3. Create the PR
+
+Once the user approves the content from step 2:
+
+- **Head branch**: Use the EXACT output of `git branch --show-current` from step 1.
+  **NEVER** reuse a branch name from earlier in the conversation — always use the fresh value.
+- **Base branch**: Default branch (`main` / `master`).
+- Ask the user:
+  ```
+  > 1. Create as draft
+  > 2. Create as ready for review
+  ```
+- Create the PR via GitHub API with the approved title and body.
+- **CRITICAL**: Set the `draft` parameter based on the user's choice:
+  - Option 1 → `"draft": true`
+  - Option 2 → `"draft": false`
+  - Do NOT default to draft. The user's choice is the ONLY factor.
+- **After creating with `draft: false`**: The GitHub REST API sometimes ignores
+  `draft: false` and creates a draft anyway. Always verify by running:
+  ```bash
+  gh pr view {number} --json isDraft --jq '.isDraft'
+  ```
+  If it returns `true`, fix it immediately:
+  ```bash
+  gh pr ready {number}
+  ```
+
+### 4. After creation
+
+- Show the PR URL.
+- If a Jira ticket was linked, ask:
+  ```
+  > Transition Jira ticket {TICKET-ID} to "In Review"?
+  >
+  > 1. Yes — update status
+  > 2. No — leave as-is
+  ```
+
+### Rules
+
+- **Always use the PR template** from `.github/pull_request_template.md` — read it, fill its sections.
+- **Always show the PR content before creating it** — never create blindly.
+- **Push the branch first** if it hasn't been pushed (with user permission).
+- Only create the PR — never merge it.
+- Only commit or push with explicit user permission.

package/.agent-src/commands/do-and-judge.md

@@ -0,0 +1,114 @@
+---
+name: do-and-judge
+skills: [subagent-orchestration, verify-before-complete]
+description: Run a single change through an implementer→judge loop with a two-revision ceiling, then hand back to the user
+disable-model-invocation: true
+---
+
+# do-and-judge
+
+## Instructions
+
+### 1. Confirm scope
+
+The user invoked `/do-and-judge` with a task description or a pointer
+to an existing draft. Echo back the scope in one sentence and wait for
+confirmation if the scope is ambiguous. Do not proceed until the
+target is clear.
+
+### 2. Resolve model pairing
+
+Read `.agent-settings.yml`:
+
+- `subagents.implementer_model` → empty = session model
+- `subagents.judge_model` → empty = one tier above implementer
+
+If the two resolve to the same model in the same context, **stop** and
+report per the `subagent-orchestration` Iron Law.
+
+### 3. Run the implementer
+
+Produce the diff in the current session — this is the implementer.
+Capture the diff as the artifact the judge will review. Do **not**
+apply the diff yet.
+
+### 4. Run the judge
+
+Invoke the judge model on the diff **with the original task** as
+context. The judge must return one of:
+
+| Verdict  | Meaning                                        |
+|----------|------------------------------------------------|
+| `apply`  | Diff is correct and complete, land it          |
+| `revise` | Specific issues listed, implementer must fix   |
+| `reject` | Fundamentally wrong approach, hand back        |
+
+### 5. Apply or revise
+
+- `apply` → write the diff, run targeted tests, run quality pipeline
+- `revise` → hand the issue list back to the implementer, loop to step 4
+- `reject` → stop, report to user, do not loop
+
+**Hard ceiling: two revision cycles.** After the second `revise` fails
+judgment, stop and hand back — further iteration is the user's call.
+
+### 6. Emit a memory signal on repeated rejection
+
+When the judge has issued **≥ 2 `revise`/`reject` verdicts** for the
+same failure class on nearby paths during this session, that is a
+pattern worth recording. Drop a signal:
+
+```bash
+python3 scripts/memory_signal.py \
+    --type historical-patterns \
+    --path "<primary path under review>" \
+    --body "<failure class → fix guidance, one sentence>" \
+    --origin "do-and-judge" \
+    --extra '{"severity":"<low|medium|high>"}'
+```
+
+One signal per session — the helper's 7-day dedupe prevents re-emits
+of the same pattern from later sessions. Skip on a single rejection.
+
+### 7. Report
+
+```
+Mode:       do-and-judge
+Implementer: <resolved model>
+Judge:      <resolved model>
+Verdict:    applied | handed-back
+Revisions:  <N>/2
+Evidence:   <test result + judge transcript>
+Next step:  <commit / open PR / abandon>
+```
+
+## Safety gates
+
+- No apply without the judge's `apply` verdict
+- No silent model fallback — unknown alias = stop and ask
+- No more than two revisions without user consent
+- No skipping of `verify-before-complete` on the final apply
+
+## When to stop and ask
+
+- Judge and implementer resolved to the same model in same context
+- Revision loop still failing after ceiling
+- Judge transcript contradicts the original task (off-task drift)
+- User interrupts mid-loop
+
+## Wrappable commands
+
+Commands that document an optional `/do-and-judge` integration block:
+
+- [`/commit`](commit.md) — judge reviews the commit plan + diff before
+  staging. Useful on large, mixed-intent diffs.
+
+Any command without an integration block is still wrappable in
+principle, but the judge lacks a structured artifact to grade — expect
+weaker verdicts.
+
+## See also
+
+- [`subagent-orchestration`](../skills/subagent-orchestration/SKILL.md)
+- [`verify-before-complete`](../skills/verify-before-complete/SKILL.md)
+- [`subagent-configuration`](../contexts/subagent-configuration.md)

package/.agent-src/commands/do-in-steps.md

@@ -0,0 +1,84 @@
+---
+name: do-in-steps
+skills: [subagent-orchestration, verify-before-complete]
+description: Execute an ordered plan step by step with a judge gate between steps — stops on first failed verdict
+disable-model-invocation: true
+---
+
+# do-in-steps
+
+## Instructions
+
+### 1. Confirm the plan
+
+The user invoked `/do-in-steps` pointing to a plan (agents/plans/ file,
+roadmap phase, or inline list). Confirm:
+
+- N steps, numbered
+- Each step has a clear acceptance criterion
+- Dependencies between steps are explicit
+
+If any step is vague, **stop** and ask before running anything.
+
+### 2. Resolve model pairing
+
+Same as `/do-and-judge`:
+
+- `subagents.implementer_model` → session model by default
+- `subagents.judge_model` → one tier up by default
+
+Stop if both resolve to the same model in the same context.
+
+### 3. Run the loop
+
+For each step `i` from 1 to N:
+
+1. **Implement step i** in the current session
+2. **Run the judge** on the diff for step i alone, with the plan's
+   step-i acceptance criterion as the check target
+3. **Apply or revise**:
+   - `apply` → commit step i, run targeted tests, move to step i+1
+   - `revise` → hand back the issue list, re-implement step i (max 2 retries)
+   - `reject` → **stop the whole loop**, report which step and why
+
+### 4. Stop conditions
+
+The loop exits cleanly only when **all N steps pass judgment**. Any
+other outcome is a stop:
+
+- A step rejected → stop at that step
+- Revision ceiling hit on any step → stop at that step
+- User interrupts → stop immediately
+
+On stop, report the last verified state so the user can resume.
+
+### 5. Final verification
+
+After step N passes judgment, run `verify-before-complete` across the
+whole changeset — targeted tests + full suite + quality pipeline.
+Never declare the plan "done" without this gate.
+
+### 6. Report
+
+```
+Mode:       do-in-steps
+Steps:      <passed>/<total>  (stopped at step <K>? yes/no)
+Implementer: <resolved model>
+Judge:      <resolved model>
+Revisions:  step-by-step count
+Evidence:   final test + quality output
+Next step:  <commit / open PR / resume from step K>
+```
+
+## Safety gates
+
+- Never skip a step because the next one looks easier
+- Never apply a revised step without the judge re-verdicting
+- Never declare complete without final `verify-before-complete`
+- A failing step never cascades silently — stop, report, hand back
+
+## See also
+
+- [`subagent-orchestration`](../skills/subagent-orchestration/SKILL.md)
+- [`verify-before-complete`](../skills/verify-before-complete/SKILL.md)
+- [`/do-and-judge`](do-and-judge.md) — single-change variant

package/.agent-src/commands/e2e-heal.md

@@ -0,0 +1,98 @@
+---
+name: e2e-heal
+skills: [playwright-testing]
+description: Find, debug, and fix failing Playwright E2E tests
+disable-model-invocation: true
+---
+
+# e2e-heal
+
+## Instructions
+
+### 1. Identify failing tests
+
+- Ask the user:
+
+> 1. Run all E2E tests and fix whatever fails
+> 2. Fix a specific test file — which one?
+> 3. Fix tests that failed in CI — provide the CI run URL or error output
+
+- Read the Playwright guideline: `.augment/guidelines/e2e/playwright.md`
+
+### 2. Run failing tests
+
+- Execute the test(s) to see current errors:
+  ```bash
+  npx playwright test [file] --reporter=list 2>&1 | tail -30
+  ```
+- If all tests pass → report success and stop.
+- List all failing tests with their error messages.
+
+### 3. Debug each failure (one at a time)
+
+For each failing test:
+
+1. **Read the error** — understand what's expected vs. actual.
+2. **Classify the failure**:
+
+| Type | Symptom | Action |
+|---|---|---|
+| Selector changed | Element not found | Update locator (prefer semantic) |
+| Timing issue | Timeout | Add proper waits or `waitForResponse` |
+| Assertion mismatch | Expected ≠ Actual | Update expected value or test logic |
+| App bug | Test is correct, app is broken | Mark `test.fixme()` |
+| Data dependency | Missing test data | Fix seed/setup |
+| Environment issue | Works locally, fails in CI | Check config, viewport, baseURL |
+
+3. **Fix the test** — make the smallest change that resolves the issue.
+4. **Verify** — re-run only the fixed test:
+   ```bash
+   npx playwright test [file] -g "test name"
+   ```
+5. **If it passes** → move to next failure.
+6. **If it still fails** → try one more approach. After 3 failed attempts on the same test, mark as `test.fixme()`.
+
+### 4. Handle unfixable tests
+
+If a test fails because the **application** is broken (not the test):
+
+```ts
+test.fixme('should display avatar', async ({ page }) => {
+  // BUG: Avatar endpoint returns 404 since API v2 migration.
+  // TODO: Remove fixme when GALA-XXXX is resolved.
+  await page.goto('/profile')
+  await expect(page.getByRole('img', { name: 'Avatar' })).toBeVisible()
+})
+```
+
+- Always add a comment explaining current vs. expected behavior.
+- Ask the user if a bug ticket should be created.
+
+### 5. Final verification
+
+- Run all tests once more to confirm everything passes (or is properly marked `fixme`):
+  ```bash
+  npx playwright test --reporter=list
+  ```
+- Report results to the user.
+
+### 6. Summary
+
+Present a table:
+
+```
+| # | Test | Status | Action |
+|---|---|---|---|
+| 1 | login.spec.ts > should login | ✅ Fixed | Updated email locator |
+| 2 | checkout.spec.ts > should pay | ✅ Fixed | Added waitForResponse |
+| 3 | profile.spec.ts > should show avatar | ⚠️ fixme | App bug — avatar 404 |
+```
+
+### Rules
+
+- **Fix one test at a time** — don't batch fixes.
+- **Max 3 attempts per test** — then mark `test.fixme()` and move on.
+- **Never use `waitForTimeout()`** as a fix — always find the proper wait condition.
+- **Prefer updating locators** over adding retries.
+- **Do NOT commit or push** unless the user asks.
+- **Do NOT delete failing tests** — fix them or mark as `fixme`.

package/.agent-src/commands/e2e-plan.md

@@ -0,0 +1,85 @@
+---
+name: e2e-plan
+skills: [playwright-testing]
+description: Explore the application and create a structured E2E test plan in Markdown
+disable-model-invocation: true
+---
+
+# e2e-plan
+
+## Instructions
+
+### 1. Gather context
+
+- Ask the user:
+
+> 1. Which URL/page should be explored? (e.g., `http://localhost:3000/dashboard`)
+> 2. Which feature area? (e.g., "checkout flow", "user settings", or "all visible flows")
+> 3. Is there an existing seed/setup file? (e.g., `tests/e2e/fixtures/auth.ts`)
+
+- Read the Playwright guideline: `.augment/guidelines/e2e/playwright.md`
+- Check for existing test plans in `specs/` or `tests/e2e/specs/`.
+
+### 2. Explore the application
+
+- Use Playwright MCP tools to navigate the target URL.
+- Take a browser snapshot to understand the page structure.
+- Identify all interactive elements: forms, buttons, links, modals, navigation.
+- Map primary user journeys and critical paths.
+- Consider different user roles and their typical behaviors.
+
+### 3. Design test scenarios
+
+For each discovered flow, create scenarios covering:
+
+- **Happy path** — normal user behavior, expected outcomes
+- **Edge cases** — boundary values, empty states, long inputs
+- **Error handling** — validation errors, server errors, network failures
+- **Negative tests** — unauthorized access, invalid data
+
+### 4. Write the test plan
+
+Save as a Markdown file (ask user for location, default: `specs/plan.md`).
+
+Format:
+
+```markdown
+# [Feature Area] — E2E Test Plan
+
+## Application Overview
+Brief description of the page/feature and its core functionality.
+
+## Test Scenarios
+
+### 1. [Flow Name]
+**Seed:** `tests/e2e/fixtures/[setup].ts`
+
+#### 1.1 [Scenario Name]
+**Steps:**
+1. Navigate to [URL]
+2. Click [element]
+3. Fill in [field] with [value]
+4. ...
+
+**Expected Results:**
+- [What should happen]
+- [What should be visible]
+
+#### 1.2 [Next Scenario]
+...
+```
+
+### 5. Review with user
+
+- Present a summary of discovered flows and scenario count.
+- Ask if any flows are missing or should be excluded.
+- Wait for the user's confirmation before finalizing.
+
+### Rules
+
+- **Do NOT generate test code** — this command only creates the plan.
+- **Do NOT modify existing test files.**
+- Each scenario must be independent — no shared state assumptions.
+- Steps must be specific enough for any tester (human or agent) to follow.
+- Always include both the action and the expected result.
+- Reference seed files if test data setup is needed.

package/.agent-src/commands/estimate-ticket.md

@@ -0,0 +1,80 @@
+---
+name: estimate-ticket
+skills: [estimate-ticket]
+description: Estimate a Jira/Linear ticket before sprint planning — size + risk + split recommendation + uncertainty, sibling to /refine-ticket, ends with a close-prompt
+disable-model-invocation: true
+---
+
+# estimate-ticket
+
+## Instructions
+
+### 1. Resolve input (delegate to jira-ticket loader)
+
+Accept the same four input paths as [`/refine-ticket`](refine-ticket.md):
+
+1. **Explicit key** — `/estimate-ticket PROJ-123`
+2. **Branch detection** — no arg → `git branch --show-current` + regex `[A-Z]+-[0-9]+`
+3. **Pasted text** — markdown block under the command
+4. **URL** — `/estimate-ticket https://…/browse/PROJ-123`
+
+For paths 1, 2, 4: run steps 1-3 of the [`jira-ticket`](jira-ticket.md) command
+(extract ID, fetch `GET /issue/{id}`, scan for Sentry links). For path 3: parse
+the pasted markdown.
+
+If no input resolves: ask **one** focused question:
+
+```
+📏 Which ticket should I estimate? Paste a Jira key, URL, or the ticket text.
+```
+
+### 2. Check estimability first
+
+If the ticket is too vague to size (no concrete AC, no out-of-scope,
+no named dependencies), emit a single-line redirect at the top of the
+output and stop before the sizing step:
+
+```
+> ⚠️  This ticket is underspecified — run `/refine-ticket` first, then re-estimate.
+```
+
+Still produce an `Uncertainty: Underspecified` estimate block so the
+caller has something to record.
+
+### 3. Run the estimate-ticket skill
+
+Invoke the [`estimate-ticket`](../skills/estimate-ticket/SKILL.md) skill with
+the loaded ticket. The skill applies the four-axis sizing heuristic, the
+persona cast, and produces the output template.
+
+### 4. Honor flags
+
+- `--personas=<list>` — comma-separated override of the Core-6 default
+- `--personas=+qa` — add the QA specialist (regression risk, test surface)
+- `--scale=<map>` — override the story-point mapping
+  (default `S=2,M=3,L=5,XL=8`; example: `--scale=S=1,M=2,L=3,XL=5`)
+
+No `--apply` flag in v1. Write-back is user-controlled via the close-prompt
+at the end of the skill output.
+
+### 5. Emit output + close-prompt
+
+Render the four-section output (estimate / rationale / split points /
+persona voices) plus the close-prompt. Stop there. Do **not** chain into
+`/feature-plan` — separate invocations by design.
+
+## Examples
+
+```
+/estimate-ticket PROJ-123
+/estimate-ticket                              # uses current branch
+/estimate-ticket --personas=+qa PROJ-123
+/estimate-ticket --scale=S=1,M=2,L=3,XL=5 PROJ-123
+```
+
+## See also
+
+- [`refine-ticket`](refine-ticket.md) — sibling; run first if the ticket is vague
+- [`jira-ticket`](jira-ticket.md) — ticket loader this command delegates to
+- [`feature-plan`](feature-plan.md) — downstream planning
+- [`road-to-ticket-refinement.md`](../../agents/roadmaps/road-to-ticket-refinement.md) — governing roadmap

package/.agent-src/commands/feature-dev.md

@@ -0,0 +1,111 @@
+---
+name: feature-dev
+description: Full 7-phase feature development workflow for complex features.
+skills: [laravel, php-coder]
+disable-model-invocation: true
+---
+# /feature-dev
+
+> Full 7-phase feature development workflow for complex features.
+
+## Trigger
+
+`/feature-dev {description}` or `/feature-dev` (interactive)
+
+## When to use
+
+- New features that touch multiple files or modules
+- Features requiring architecture decisions
+- Complex integrations with existing code
+- Features where requirements are unclear
+
+Do NOT use for single-line fixes, trivial changes, or urgent hotfixes.
+
+## Workflow
+
+### Phase 1: Discovery
+
+1. If no description provided, ask: "What feature do you want to build?"
+2. Clarify the feature request:
+   - What problem does it solve?
+   - Who benefits?
+   - What are the constraints?
+3. Summarize understanding and **confirm with the user** before proceeding.
+
+### Phase 2: Codebase Exploration
+
+1. Use `codebase-retrieval` to find:
+   - Similar features already implemented
+   - Architecture patterns in the affected area
+   - Key files, services, models, routes involved
+2. Read identified files to build deep understanding.
+3. Check module docs (`app/Modules/*/agents/`) if applicable.
+4. Check existing contexts (`agents/contexts/`) for the affected area.
+5. Present findings with file references.
+
+### Phase 3: Clarifying Questions
+
+1. Review codebase findings against the feature request.
+2. Identify underspecified aspects:
+   - Edge cases and error handling
+   - Integration points with existing code
+   - Backward compatibility concerns
+   - Performance requirements
+   - Authorization and security
+3. Present all questions in an organized list.
+4. **STOP — Wait for answers before proceeding.**
+
+### Phase 4: Architecture Design
+
+1. Design 2-3 implementation approaches:
+   - **Minimal changes** — smallest change, maximum reuse of existing code
+   - **Clean architecture** — best maintainability, elegant abstractions
+   - **Pragmatic balance** — speed + quality tradeoff
+2. For each approach, describe:
+   - Files to create/modify
+   - New classes, services, or patterns introduced
+   - Pros and cons
+3. Present comparison and recommend one approach.
+4. **STOP — Ask which approach the user prefers.**
+
+### Phase 5: Implementation
+
+1. **Wait for explicit approval** before writing code.
+2. Create a task list with all implementation steps.
+3. Follow chosen architecture from Phase 4.
+4. Follow codebase conventions strictly (read guidelines).
+5. Update task list as progress is made.
+6. Write tests alongside the implementation.
+
+### Phase 6: Quality Review
+
+1. Review the implementation for:
+   - **Simplicity & DRY** — is the code as simple as possible?
+   - **Correctness** — are there logic errors or missing edge cases?
+   - **Conventions** — does it follow project patterns?
+2. Run quality tools:
+   - PHPStan (or equivalent)
+   - Tests
+   - Code style
+3. Present findings with severity levels.
+4. **Ask what to fix now vs. defer.**
+
+### Phase 7: Summary
+
+1. Summarize:
+   - What was built
+   - Key decisions made (and why)
+   - Files created/modified
+2. Suggest next steps:
+   - Additional tests needed
+   - Documentation updates
+   - Follow-up features or improvements
+3. If a feature plan exists, update it.
+
+## Rules
+
+- **Never skip phases** — each phase builds on the previous one.
+- **Always wait for user input** at Phase 3 and Phase 4 gates.
+- **All output in English** for documentation; speak German with the user.
+- **Use task management** to track progress through phases.
+- **Reference the `feature-planning` skill** for feature plan format.