@event4u/agent-config 1.9.1

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

@@ -0,0 +1,180 @@
+---
+name: feature-explore
+skills: [laravel]
+description: Brainstorm and explore a feature idea before committing to a full plan
+disable-model-invocation: true
+---
+
+# feature-explore
+
+## Instructions
+
+This is a **lightweight, conversational** exploration — no structured output yet.
+The goal is to help the user think through an idea and decide if it's worth planning.
+
+### 1. Start the conversation
+
+If the user provided an idea in their message, acknowledge it and start exploring.
+If not, ask:
+
+```
+💡 What's your idea? Describe it briefly — one sentence is enough to start.
+```
+
+### 1b. Refinement hint — detect ticket-shaped input
+
+Before entering brainstorm mode, check whether the input looks like an
+**existing ticket** rather than a fresh idea. If any of the following
+match, surface the hint below and let the user pick:
+
+- A Jira/Linear URL is present (`https://.../browse/[A-Z]+-[0-9]+`)
+- The current branch name contains a ticket key (`[A-Z]+-[0-9]+`)
+- The pasted text contains structured AC bullets (`- [ ]`, "Acceptance Criteria", "AC:")
+
+Prompt:
+```
+🎫 Looks like you're working with an existing ticket, not a fresh idea.
+
+1. Use `/refine-ticket` — rewrites the ticket + surfaces Top-5 risks + persona voices
+2. Continue brainstorming here — I'll treat it as a new idea to explore
+```
+
+If the user picks 1, hand off to `/refine-ticket` with the same input. If 2,
+continue with Step 2.
+
+### 2. Gather external context
+
+**Auto-detect ticket from branch:**
+Run `git branch --show-current` and extract ticket IDs (pattern: `[A-Z]+-[0-9]+`).
+
+If a ticket ID is found:
+```
+🔀 Branch: {branch-name}
+🎫 Ticket detected: {TICKET-ID} — Load the ticket? (y/n)
+```
+
+**Then ask for additional sources:**
+```
+Gibt es weitere Quellen?
+
+1. 🎫 Jira-Ticket(s) oder Epic(s) — Key(s) angeben
+2. 🔴 Sentry-Issue(s) — URL(s) angeben
+3. 🔗 Andere Links — Confluence, Slack, Docs
+4. ❌ Nein — ohne weitere Quellen starten
+```
+
+If the user provides ticket keys:
+- Fetch each ticket via Jira API (`/issue/{key}`).
+- For Epics: also fetch child issues (`/search/jql` with `"Epic Link" = {key}` or `parent = {key}`).
+- Extract and summarize:
+  - **Title & description** — the original requirement
+  - **Acceptance criteria** — if defined
+  - **Comments** — relevant discussion or decisions
+  - **Status & priority** — current state
+  - **Linked issues** — related tickets
+
+Show a summary:
+
+```
+📋 Jira context loaded:
+
+  {KEY}: {title}
+  Status: {status} | Priority: {priority}
+  Description: {first 2-3 sentences}
+  Acceptance criteria: {list or "none defined"}
+  Comments: {count} ({summary of key points})
+  Linked issues: {list or "none"}
+```
+
+Use this as **input for the exploration** — challenge it, validate it against the codebase, identify gaps.
+
+### 3. Understand the idea
+
+Listen for and gently probe:
+
+- **Problem:** What pain point does this solve? Who is affected?
+- **Vision:** What would the ideal outcome look like?
+- **Scope:** Is this a small tweak or a major feature?
+- **Context:** Is this for a specific customer, internal tooling, or the platform?
+
+If Jira context was loaded, use it to pre-fill understanding and ask targeted follow-ups:
+```
+Based on the ticket, this is about {summary}. Is that still accurate, or has the requirement changed?
+```
+
+**Be conversational, not interrogative.** Ask 1–2 follow-up questions at a time, not a checklist.
+
+### 4. Research the codebase
+
+While exploring, proactively research:
+
+- Use `codebase-retrieval` to find related code, existing patterns, and affected areas.
+- Check `agents/features/` for existing feature plans that might overlap.
+- Check the module structure (`app/Modules/`) for where this would live.
+- Look for existing services, models, or endpoints that could be extended.
+
+**Share findings naturally:**
+
+```
+I looked at the code — there's already an `ImportService` with
+similar logic. We could extend it instead of building something new.
+What do you think?
+```
+
+### 5. Challenge and refine
+
+Your role is **thought partner**, not yes-machine:
+
+- **Challenge scope:** "This sounds like a big feature. What would be the absolute minimum that already delivers value?"
+- **Suggest alternatives:** "Instead of building this from scratch — could we extend the existing X?"
+- **Identify risks:** "This would affect the Y table, which depends on Z. We need to keep that in mind."
+- **Defer complexity:** "We can do the automation in Phase 2. Manual first?"
+
+### 6. Summarize and decide
+
+After 3–8 exchanges, summarize what you've learned:
+
+```
+───────────────────────────────────────────────
+💡 SUMMARY
+───────────────────────────────────────────────
+
+Problem:   {one sentence}
+Idea:      {one sentence}
+Scope:     {small / medium / large}
+Affected modules: {list}
+Risks:     {key risks}
+
+───────────────────────────────────────────────
+```
+
+Then ask:
+
+```
+What's next?
+
+1. 📋 Plan the feature → /feature-plan (create structured feature document)
+2. 🔍 Keep brainstorming (not ready to plan yet)
+3. ⏸️ Park the idea (revisit later)
+4. ❌ Discard (not worth pursuing)
+```
+
+### 7. Handle decision
+
+- **Option 1:** Transition to `/feature-plan` — pass the exploration context along.
+- **Option 2:** Continue the conversation, dig deeper.
+- **Option 3:** Optionally create a minimal note in `agents/features/{name}.md` with status `💡 Idea`.
+- **Option 4:** Acknowledge and move on. No file created.
+
+### Rules
+
+- **Do NOT create a full feature plan** — that's `/feature-plan`'s job.
+- **Do NOT commit or push.**
+- **Do NOT skip codebase research** — always check what exists.
+- **Be honest about feasibility** — if something is hard, say so.
+- **Keep it conversational** — this is brainstorming, not a formal process.
+- **Max 1 file created** (optional idea note). No roadmaps, no implementation.
+
+## See also
+
+- [`role-contracts`](../guidelines/agent-infra/role-contracts.md#po) — PO mode output contract (Goal / Assumptions / Acceptance criteria / Impacted modules / Risks / Open questions for stakeholder)

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

@@ -0,0 +1,288 @@
+---
+name: feature-plan
+skills: [feature-planning]
+description: Interactively plan a feature — research, discuss, and create a structured feature document
+disable-model-invocation: true
+---
+
+# feature-plan
+
+## Instructions
+
+### 1. Gather the idea
+
+If the user provided a description, use it. Otherwise ask:
+
+```
+📋 Which feature do you want to plan?
+
+Describe briefly:
+- What should the feature do?
+- What problem does it solve?
+```
+
+### 2. Gather external context
+
+**Auto-detect ticket from branch:**
+Run `git branch --show-current` and extract ticket IDs (pattern: `[A-Z]+-[0-9]+`).
+
+If a ticket ID is found:
+```
+🔀 Branch: {branch-name}
+🎫 Ticket detected: {TICKET-ID}
+
+Load the ticket? (y/n)
+```
+
+If yes → fetch via Jira API and show summary.
+
+**Then ask for additional sources:**
+```
+Any additional sources?
+
+1. 🎫 Jira-Ticket(s) oder Epic(s) — Key(s) angeben (z.B. DEV-1234)
+2. 🔴 Sentry-Issue(s) — URL(s) angeben (falls relevant)
+3. 🔗 Andere Links — Confluence, Slack, Docs, etc.
+4. ❌ No — start without additional sources
+```
+
+If the user provides ticket keys:
+- Fetch each ticket via Jira API (`/issue/{key}`).
+- For Epics: also fetch child issues (`/search/jql` with `"Epic Link" = {key}` or `parent = {key}`).
+- Extract and summarize:
+  - **Title & description** — the original requirement
+  - **Acceptance criteria** — if defined in the description or subtasks
+  - **Comments** — relevant discussion, decisions, or clarifications
+  - **Status & priority** — current state
+  - **Linked issues** — related tickets, blockers, dependencies
+  - **Subtasks / child issues** — for Epics, list all child tickets with status
+
+Show a structured summary:
+
+```
+📋 Jira context loaded:
+
+  {KEY}: {title}
+  Status: {status} | Priority: {priority}
+  Description: {first 2-3 sentences}
+  Acceptance criteria: {list or "none defined"}
+  Comments: {count} ({summary of key points})
+
+  {If Epic — show child issues:}
+  Untertickets:
+    ✅  {KEY}: {title} (Done)
+    🔄 {KEY}: {title} (In Progress)
+    ⏸️  {KEY}: {title} (To Do)
+```
+
+Use this as **foundation for the feature plan** — pre-fill Problem, Proposal, and Scope from the ticket data.
+Challenge gaps: "The ticket says X, but there's no statement about Y. How should that work?"
+
+### 3. Check for existing work
+
+Run in parallel:
+- Check `agents/features/` for existing plans that might overlap or relate.
+- Check `agents/roadmaps/` for related roadmaps.
+
+If a related feature plan exists:
+```
+ℹ️  Es gibt bereits ein verwandtes Feature:
+📄 agents/features/{name}.md — {title}
+
+Should I build on this or create a new feature?
+```
+
+### 4. Research the codebase
+
+Before asking detailed questions, **proactively research**:
+
+- Use `codebase-retrieval` to find:
+  - Existing code related to the feature
+  - Affected modules, models, services, controllers
+  - Similar patterns already implemented
+  - Database tables that would be affected
+- Read module-level `agents/` docs if a specific module is involved.
+- **Read `agents/memory/architecture-decisions.yml`** (if it exists) for active
+  ADRs whose `scope:` covers the affected modules. An ADR with
+  `status: active` is a binding constraint — propose structure that
+  respects it. If the feature needs to contradict an ADR, surface that
+  as a decision for the user before drafting the plan. See
+  [`engineering-memory-data-format`](../guidelines/agent-infra/engineering-memory-data-format.md).
+
+**Share key findings with the user** — this informs the discussion:
+
+```
+I analyzed the code. Here's what I found:
+
+🔍 Affected areas:
+  - Module: Import (app/Modules/Import/)
+  - Service: ImportService — already has similar logic
+  - Model: ImportUpload — needs new fields
+  - API: /api/v1/imports — new endpoint needed
+
+💡 Existing patterns:
+  - The ExportService uses a similar queue pattern
+  - There's already an ImportUploadType enum
+```
+
+### 5a. Check for existing context
+
+Check if a context document exists for the affected area:
+- `agents/contexts/` for project-wide contexts
+- `app/Modules/{Module}/agents/contexts/` if a module is involved
+
+If a context exists:
+```
+📄 There's a context for this area:
+   {path/to/context.md} — {title}
+
+I'll use it as the basis for the technical analysis.
+```
+Read it and use it to pre-fill Affected Areas and Technical Approach.
+
+If no context exists, note this for step 8 (offer to create one after planning).
+
+### 5b. Determine scope (module vs. project-wide)
+
+Check if `app/Modules/` exists in the project. If yes, ask:
+
+```
+Does this feature belong to a specific module?
+
+1. 📦 Yes — in a module (feature + roadmaps in module directory)
+2. 🌐 No — project-wide (feature + roadmaps in root)
+```
+
+If the user chooses a module:
+- List available modules from `app/Modules/`.
+- Ask which module, or accept the module name directly.
+- Target directories become:
+  - Feature: `app/Modules/{Module}/agents/features/`
+  - Roadmaps (later): `app/Modules/{Module}/agents/roadmaps/`
+  - Create directories if they don't exist (with `.gitkeep`).
+
+If project-wide:
+- Target: `agents/features/` and `agents/roadmaps/`.
+
+### 5c. Interactive planning
+
+Walk through the feature plan sections **conversationally** — not as a form.
+Ask 1–2 questions at a time, building on previous answers.
+
+**Round 1 — Problem & Proposal:**
+```
+Do I understand correctly: {restate the problem}?
+
+And the solution would be: {restate the proposal}?
+
+What's missing or incorrect?
+```
+
+**Round 2 — Scope:**
+```
+What definitely belongs in scope?
+And what can we consciously leave out or defer?
+```
+
+**Round 3 — Technical Approach:**
+Based on codebase research, present options:
+```
+For the implementation I see two approaches:
+
+Option A: {approach} — {pros/cons}
+Option B: {approach} — {pros/cons}
+
+Was passt besser?
+```
+
+**Round 4 — Open Questions:**
+```
+Mir sind noch ein paar offene Fragen aufgefallen:
+- {question 1}
+- {question 2}
+
+Hast du dazu schon eine Meinung?
+```
+
+### 6. Create the feature document
+
+- Read `.augment/templates/features.md` for the structure.
+- Create the feature file in the target directory determined in step 5a:
+  - Module: `app/Modules/{Module}/agents/features/{feature-name}.md`
+  - Project-wide: `agents/features/{feature-name}.md`
+- Fill in all sections based on the conversation.
+- Set the `Module` field in the feature doc accordingly.
+- Set status to `📋 Planned`.
+- If Jira tickets were provided, add them to the `Jira` field and reference them in the feature doc.
+
+**Ask for the filename:**
+```
+What should the feature be named?
+
+Suggestion: {suggested-kebab-case-name}
+{If module: "Target: app/Modules/{Module}/agents/features/{name}.md"}
+{If root: "Target: agents/features/{name}.md"}
+```
+
+### 7. Show the result
+
+Display a summary:
+
+```
+═══════════════════════════════════════════════
+  📋 FEATURE GEPLANT
+═══════════════════════════════════════════════
+
+📄 agents/features/{name}.md
+📊 Status: 📋 Planned
+
+───────────────────────────────────────────────
+OVERVIEW:
+───────────────────────────────────────────────
+
+Problem:    {one sentence}
+Solution:   {one sentence}
+Scope:      {in-scope summary}
+Module:     {affected modules}
+Open questions: {count}
+
+═══════════════════════════════════════════════
+```
+
+### 8. Next steps
+
+If no context document exists for this area, offer to create one:
+
+```
+📄 No context document exists for this area yet.
+   A context documents the current state (structure, key classes, DB, API)
+   and helps with implementation.
+
+   Should I create one? → /context-create
+```
+
+Then show next steps:
+
+```
+What's next?
+
+1. 🗺️ Create roadmap → /feature-roadmap
+2. 📄 Create context → /context-create
+3. ✏️ Refine feature further → /feature-refactor
+4. ✅ Done for now — continue later
+```
+
+### Rules
+
+- **Do NOT commit or push.**
+- **Do NOT skip codebase research** — always check what exists before planning.
+- **Do NOT create roadmaps** — that's `/feature-roadmap`'s job.
+- **Be collaborative** — ask questions, don't assume.
+- **Challenge scope** — suggest what can be deferred.
+- **Reference existing code** — link to files and patterns found in research.
+
+## See also
+
+- [`role-contracts`](../guidelines/agent-infra/role-contracts.md#po) — PO mode output contract (Goal / Assumptions / Acceptance criteria / Impacted modules / Risks / Open questions for stakeholder)
+- [`refine-ticket`](refine-ticket.md) — optional upstream step: run first when the input is a Jira/Linear ticket rather than a fresh idea
+- [`estimate-ticket`](estimate-ticket.md) — sibling of `refine-ticket`; size + risk + split recommendation for an already-refined ticket

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

@@ -0,0 +1,181 @@
+---
+name: feature-refactor
+skills: [laravel, php-coder]
+description: Refine and update an existing feature plan through interactive discussion
+disable-model-invocation: true
+---
+
+# feature-refactor
+
+## Instructions
+
+### 1. Find the feature
+
+- List all feature plans in `agents/features/`.
+- Also check module-level `app/Modules/*/agents/features/` directories.
+
+If only one feature exists, load it directly.
+If multiple exist, show a list:
+
+```
+📂 Existing feature plans:
+
+  #  Name                              Ort                  Status
+  ─  ──────────────────────────────    ───────────────────  ──────
+  1  import-csv-validation.md          Module: Import        📋 Planned
+  2  webhook-retry-logic.md            Project root         🗺️ Roadmapped
+  3  user-notification-preferences.md  Module: UserProfile   💡 Idea
+
+Which feature do you want to edit? (number or name)
+```
+
+If no features exist:
+```
+ℹ️  No feature plans found. Create one first with /feature-plan.
+```
+Stop.
+
+### 2. Load and display the feature
+
+- Read the selected feature file completely.
+- Display a summary:
+
+```
+═══════════════════════════════════════════════
+  ✏️  FEATURE: {title}
+═══════════════════════════════════════════════
+
+📊 Status:   {status}
+📅 Created:   {date}
+🎯 Problem:   {problem summary}
+💡 Solution:  {proposal summary}
+
+───────────────────────────────────────────────
+SCOPE:
+───────────────────────────────────────────────
+
+In Scope:
+  • {item 1}
+  • {item 2}
+
+Out of Scope:
+  • {deferred item 1}
+
+───────────────────────────────────────────────
+OPEN QUESTIONS: {count}
+───────────────────────────────────────────────
+
+  • {question 1}
+  • {question 2}
+
+───────────────────────────────────────────────
+ROADMAPS: {linked roadmaps or "keine"}
+═══════════════════════════════════════════════
+```
+
+### 3. Ask what to change
+
+```
+What do you want to adjust?
+
+1. 🎯 Revise problem / proposal
+2. 📐 Change scope (add/remove/move features)
+3. 🔧 Rethink technical approach
+4. ❓ Resolve open questions
+5. 🎫 Jira-Tickets verlinken oder aktualisieren
+6. 📊 Change status
+7. 🗑️ Feature verwerfen
+8. 💬 Etwas anderes — sag mir was
+```
+
+### 4. Interactive refinement
+
+Based on the user's choice, start a focused conversation:
+
+**Problem/Proposal (Option 1):**
+- Show current text.
+- Ask what changed or what's wrong.
+- Research codebase if new context is needed.
+- Rewrite the section together.
+
+**Scope (Option 2):**
+- Show current In Scope / Out of Scope.
+- Ask what to add, remove, or move between lists.
+- Challenge additions: "Do we really need this for the first version?"
+- Validate removals: "Wenn wir X weglassen, funktioniert Y dann noch?"
+
+**Technical Approach (Option 3):**
+- Show current approach and options considered.
+- Research codebase for new patterns or constraints.
+- Present new options if the landscape changed.
+- Update the Options Considered table.
+
+**Open Questions (Option 4):**
+- Go through each open question.
+- Research codebase to help answer them.
+- Mark resolved questions as `[x]`.
+- Add new questions if they come up.
+
+**Jira-Tickets (Option 5):**
+- Show currently linked Jira tickets (from the feature's `Jira` field).
+- Ask: "Ticket-Key(s) zum Verlinken? (z.B. DEV-1234, DEV-5678)"
+- Fetch each ticket via Jira API and show a summary.
+- For Epics: also fetch child issues and show their status.
+- Add the ticket links to the feature's `Jira` field.
+- If the ticket contains new requirements or acceptance criteria, ask:
+  ```
+  > The ticket contains new requirements. What to do?
+  > 1. Incorporate — add requirements to the feature
+  > 2. Ignore — just link the ticket
+  ```
+- If yes, update Problem, Scope, or Acceptance Criteria accordingly.
+
+**Status (Option 6):**
+- Show current status and available statuses (from template).
+- Ask for new status.
+- If changing to `❌ Rejected`, ask for reason and add to Notes.
+
+**Reject (Option 7):**
+- Confirm with numbered options:
+  ```
+  > 1. Yes — mark feature as ❌ Rejected
+  > 2. Cancel
+  ```
+- If confirmed: Set status to `❌ Rejected`, add reason to Notes.
+
+### 5. Update the feature file
+
+- Apply all changes to the feature file.
+- Show a diff summary of what changed:
+
+```
+───────────────────────────────────────────────
+CHANGES:
+───────────────────────────────────────────────
+
+  ✏️  Problem: updated
+  ✏️  Scope: 1 item added to In Scope, 2 moved to Out of Scope
+  ✅  Open Questions: 2 resolved, 1 new added
+  📊 Status: 📋 Planned → 🗺️ Roadmapped
+```
+
+### 6. Ask about next steps
+
+```
+Feature updated ✅
+
+What's next?
+
+1. ✏️ More changes to the feature
+2. 🗺️ Roadmap erstellen/aktualisieren → /feature-roadmap
+3. ✅ Done for now
+```
+
+### Rules
+
+- **Do NOT commit or push.**
+- **Do NOT modify roadmaps** — that's `/feature-roadmap`'s job.
+- **Do NOT delete feature files** — mark as `❌ Rejected` instead.
+- **Research the codebase** when technical questions come up.
+- **Show changes clearly** — the user should know exactly what was modified.
+- **Preserve history** — don't silently remove decisions or notes.