@event4u/agent-config 1.9.1

package/.agent-src/commands/project-analyze.md

@@ -0,0 +1,300 @@
+---
+name: project-analyze
+skills: [project-analyzer]
+description: Full project analysis — detect stack, inventory modules, audit docs, create missing contexts
+disable-model-invocation: true
+---
+
+# project-analyze
+
+## Instructions
+
+This is a **multi-phase, interactive analysis**. Walk through each phase, show findings,
+and ask before creating any documents.
+
+### Phase 1: Project detection
+
+Gather in parallel:
+- `composer.json` → PHP version, framework, key packages
+- `package.json` → Node.js, frontend framework (if exists)
+- Check for: `artisan`, `Makefile`, `Taskfile.yml`, `docker-compose.yml`
+- Check for: `phpstan.neon`, `ecs.php`, `rector.php`, `config-dev/`
+- Check for: `.github/workflows/`, `CODEOWNERS`, `.editorconfig`
+- Check for: `app/Modules/`, multi-tenant indicators (`customer_database`)
+- Read: `AGENTS.md`, `.github/copilot-instructions.md` (if exist)
+
+Display:
+
+```
+═══════════════════════════════════════════════
+  🔍 PROJECT ANALYSIS
+═══════════════════════════════════════════════
+
+📦 Projekt:    {name from composer.json or directory}
+🏗️  Framework:  {Laravel 11 / Standalone PHP / etc.}
+🐘 PHP:        {version constraint}
+📊 Type:       {Modular Laravel SaaS / Monolith / Package / Legacy}
+
+───────────────────────────────────────────────
+TECH STACK:
+───────────────────────────────────────────────
+
+  Backend:     {Laravel, PHP 8.x}
+  Database:    {MariaDB / MySQL / SQLite / etc.}
+  Queue:       {Redis + Horizon / sync / etc.}
+  Cache:       {Redis / file / array}
+  Search:      {Meilisearch / Algolia / none}
+  Frontend:    {Vue / React / Blade / none}
+  Testing:     {Pest / PHPUnit}
+
+───────────────────────────────────────────────
+TOOLING:
+───────────────────────────────────────────────
+
+  Task Runner:     {Makefile ✅ | Taskfile ✅ | none ⚠️}
+  Docker:          {✅ docker-compose.yml | ❌}
+  Quality:         {PHPStan ✅ Level {n} | ❌}
+                   {Rector ✅ | ❌}
+                   {ECS ✅ | ❌}
+  CI/CD:           {GitHub Actions ✅ | ❌}
+  Editor Config:   {✅ | ❌}
+
+───────────────────────────────────────────────
+LEGACY CHECK (indicators):
+───────────────────────────────────────────────
+
+  strict_types:     {✅ in most files | ⚠️ missing in many | ❌ absent}
+  Typed properties: {✅ | ⚠️ partial | ❌}
+  Debug functions:  {✅ none found | ⚠️ var_dump/dd found}
+  Tests:            {✅ good coverage | ⚠️ few tests | ❌ no tests}
+
+═══════════════════════════════════════════════
+```
+
+Ask the user with numbered options:
+
+```
+> 1. Continue with Phase 2 — architecture analysis
+> 2. Stop here — keep the overview only
+```
+
+### Phase 2: Architecture mapping
+
+Analyze the directory structure:
+
+- Map top-level directories with file counts
+- Identify pattern: MVC, modules, services, repositories, DTOs
+- Count: Models, Controllers, Services, Jobs, Commands, Events, Policies
+- Detect: multi-tenancy, API versioning, queue usage
+
+Display:
+
+```
+───────────────────────────────────────────────
+ARCHITECTURE:
+───────────────────────────────────────────────
+
+  Pattern:      {Modular MVC + Service Layer + Repository}
+  API:          {Versioned REST (/api/v1/, /api/v2/)}
+  Multi-Tenant: {✅ Dual-DB (api_database + customer_database) | ❌}
+
+───────────────────────────────────────────────
+CODE INVENTORY:
+───────────────────────────────────────────────
+
+  Models:        {count}  (api_database: {n}, customer_database: {n})
+  Controllers:   {count}
+  Services:      {count}
+  Repositories:  {count}
+  Jobs:          {count}
+  Commands:      {count}
+  Events:        {count}
+  Policies:      {count}
+  Migrations:    {count}
+  Tests:         {count}  (Unit: {n}, Component: {n}, Integration: {n})
+
+═══════════════════════════════════════════════
+```
+
+### Phase 3: Module inventory (if modules exist)
+
+If `app/Modules/` exists, analyze each module:
+
+```
+───────────────────────────────────────────────
+MODULES:
+───────────────────────────────────────────────
+
+  #  Module           Controllers  Services  Models  Tests  Agent Docs  Context
+  ─  ───────────────  ───────────  ────────  ──────  ─────  ──────────  ───────
+  1  ApiClient        0            1         0       2      1 roadmap   ❌
+  2  Backoff          0            1         0       5      1 doc       ❌
+  3  ClientSoftware   8            12        5       45     6 roadmaps  ❌
+  4  Grafana          2            3         1       8      6 roadmaps  ❌
+  5  Stubbing         0            2         0       3      1 doc       ❌
+
+═══════════════════════════════════════════════
+```
+
+### Phase 4: Agent docs audit
+
+Scan all existing agent docs:
+
+```
+───────────────────────────────────────────────
+AGENT DOCS AUDIT:
+───────────────────────────────────────────────
+
+📄 Project Root (agents/):
+  ✅  Current:     {list of docs that reference existing code}
+  ⚠️  Review:      {list of docs that might be outdated}
+  ❌  Stale:       {list of docs referencing deleted code}
+
+📄 Module Level:
+  ClientSoftware:  6 Roadmaps  (✅ 2 active, ⚠️ 3 possibly outdated, ❌ 1 completed)
+  Grafana:         6 Roadmaps  (⚠️ review all)
+  ...
+
+📄 Missing:
+  ❌  No context documents found
+  ❌  No feature plans found
+  ⚠️  No module descriptions for: ApiClient, ClientSoftware, Grafana
+
+═══════════════════════════════════════════════
+```
+
+### Phase 5: Business domains
+
+Identify domains from models, services, routes, and directory structure.
+For each domain: map models → services → controllers → jobs → events.
+
+```
+───────────────────────────────────────────────
+BUSINESS DOMAINS:
+───────────────────────────────────────────────
+
+  #   Domain          Models  Services  Endpoints  Jobs  Events
+  ──  ──────────────  ──────  ────────  ─────────  ────  ──────
+  1   Projects        5       3         8          2     4
+  2   Planning        4       2         6          1     3
+  3   Users           3       2         5          0     1
+  4   Equipment       4       2         6          1     3
+  5   Working Times   3       3         5          1     5
+  6   Reports         3       1         4          0     2
+  7   Customers       4       3         3          2     2
+  8   Imports         5       6         4          3     1
+  ...
+
+═══════════════════════════════════════════════
+```
+
+Ask the user with numbered options:
+
+```
+> 1. Yes — create domain analysis files
+> 2. Skip — continue with next phase
+```
+
+For each confirmed domain, create `agents/analysis/domains/{domain}.md` using the template
+from the `project-analyzer` skill.
+
+### Phase 6: API surface & service map
+
+List all endpoints per version. Map all services with dependencies.
+
+```
+───────────────────────────────────────────────
+API SURFACE:
+───────────────────────────────────────────────
+
+  v1 Endpoints:  {count}
+  v2 Endpoints:  {count}
+  Shared (v1=v2): {count} (via fallback)
+
+───────────────────────────────────────────────
+SERVICE MAP:
+───────────────────────────────────────────────
+
+  Total Services:     {count}
+  With Repository:    {count}
+  God Services (>10 methods): {list}
+
+═══════════════════════════════════════════════
+```
+
+Ask the user with numbered options:
+
+```
+> 1. Yes — create API and service analysis files
+> 2. Skip — continue with next phase
+```
+
+Create:
+- `agents/analysis/api/endpoints-v1.md`
+- `agents/analysis/api/endpoints-v2.md`
+- `agents/analysis/api/contracts.md`
+- `agents/analysis/services/service-map.md`
+
+### Phase 7: Write analysis files
+
+Write all remaining analysis files that haven't been created yet:
+
+- `agents/analysis/overview.md` — project profile, tech stack summary
+- `agents/analysis/architecture/database.md` — schema, connections, multi-tenancy
+- `agents/analysis/architecture/api.md` — versioning, routes, middleware, auth
+- `agents/analysis/architecture/infrastructure.md` — Docker, CI/CD, deployment
+- `agents/analysis/architecture/patterns.md` — design patterns used
+- `agents/analysis/models/api-database.md` — all api_database models
+- `agents/analysis/models/customer-database.md` — all customer_database models
+- `agents/analysis/modules/{module}.md` — one per module
+- `agents/analysis/testing/test-map.md` — test suites, coverage, strategy
+
+For each file, ask with numbered options:
+
+```
+> 1. Create — {filename}
+> 2. Skip
+```
+
+### Phase 8: Gap analysis & action plan
+
+```
+───────────────────────────────────────────────
+RECOMMENDED ACTIONS:
+───────────────────────────────────────────────
+
+Priority 1 — Missing analysis files:
+  📄 {domains/modules that weren't created yet}
+
+Priority 2 — Update docs:
+  ✏️  {outdated docs that reference deleted code}
+
+Priority 3 — Cleanup:
+  🗑️  {stale roadmaps, orphaned docs}
+
+───────────────────────────────────────────────
+```
+
+Ask the user (in their language) what they want to do next:
+
+```
+1. 📄 Create missing analysis files
+2. ✏️  Review and update existing docs
+3. 🗑️  Cleanup (stale docs, completed roadmaps)
+4. 📋 Save everything as a roadmap (for later)
+5. ✅ Done
+```
+
+### Rules
+
+- **Do NOT commit or push.**
+- **Do NOT create documents without asking** — always confirm before each creation.
+- **Do NOT modify code** — this is analysis only.
+- **Do NOT analyze `vendor/` or `node_modules/`.**
+- **Present findings incrementally** — don't dump everything at once.
+- **Be honest about gaps** — flag missing docs and outdated references.
+- **Respect existing docs** — don't overwrite, offer to update.
+- **Reference existing `agents/docs/` and `agents/contexts/`** — don't duplicate their content
+  in analysis files. Link to them instead.
+- **Analysis files should be self-contained enough to rebuild** — include actual table names,
+  column names, class names, method signatures. Not just "see the code".

package/.agent-src/commands/project-health.md

@@ -0,0 +1,95 @@
+---
+name: project-health
+skills: [quality-tools]
+description: Quick project health check — show status of docs, modules, contexts, and roadmaps without creating anything
+disable-model-invocation: true
+---
+
+# project-health
+
+## Instructions
+
+This is a **quick, read-only** health check. No documents are created or modified.
+
+### 1. Gather data
+
+Run in parallel:
+- `composer.json` → framework, PHP version
+- `git branch --show-current` → current branch
+- `git log --oneline -3` → recent activity
+- Count files in `agents/` (docs, features, roadmaps, contexts)
+- Count files in `app/Modules/*/agents/` (per module)
+- Check `app/Modules/` for module list
+- Count test files
+
+### 2. Display health report
+
+```
+═══════════════════════════════════════════════
+  🏥 PROJEKT-HEALTH CHECK
+═══════════════════════════════════════════════
+
+📦 {project-name} | {framework} {version} | PHP {version}
+🔀 Branch: {current-branch}
+
+───────────────────────────────────────────────
+SESSION:
+───────────────────────────────────────────────
+
+  🎯 Next step: {next action}
+
+───────────────────────────────────────────────
+AGENT DOCS:          {total count}
+───────────────────────────────────────────────
+
+  📄 Projekt-Docs:    {count} in agents/
+  📄 Guidelines:       {count} in .augment/guidelines/
+  📋 Features:         {count} in agents/features/
+  🗺️  Roadmaps:        {count} in agents/roadmaps/
+  📄 Contexts:         {count} in agents/contexts/
+
+───────────────────────────────────────────────
+MODULE:              {total count}
+───────────────────────────────────────────────
+
+  Module             Agent Docs  Roadmaps  Features  Contexts
+  ───────────────    ──────────  ────────  ────────  ────────
+  {ModuleName}       {count}     {count}   {count}   {count}
+  ...
+
+───────────────────────────────────────────────
+ROADMAP STATUS:
+───────────────────────────────────────────────
+
+  {For each active roadmap:}
+  📄 {roadmap-name}
+     Progress: [{completed}/{total}] {progress-bar}
+     Last modified: {file modification date}
+
+  {If stale roadmaps (old modification date):}
+  ⚠️  Potentially outdated:
+    • {roadmap} — last modified {n} days ago
+
+───────────────────────────────────────────────
+GAPS:
+───────────────────────────────────────────────
+
+  {List gaps found:}
+  ⚠️  {count} modules without context document
+  ⚠️  {count} modules without agent docs
+  ⚠️  No active feature plans
+  ✅  All areas documented (if no gaps)
+
+═══════════════════════════════════════════════
+
+{If gaps found:}
+💡 Run /project-analyze for a full analysis with action plan.
+```
+
+### Rules
+
+- **Do NOT create or modify any files** — this is read-only.
+- **Do NOT commit or push.**
+- **Keep it fast** — no deep code analysis, just file counts and metadata.
+- **Show gaps clearly** — the user should see what's missing at a glance.
+- **Suggest `/project-analyze`** if significant gaps are found.

package/.agent-src/commands/propose-memory.md

@@ -0,0 +1,108 @@
+---
+name: propose-memory
+description: Append a provisional memory signal to the intake stream — the universal fallback for any producer (human or agent) to record a finding without committing to a curated entry.
+skills: [file-editor]
+disable-model-invocation: true
+---
+
+# /propose-memory
+
+Drops a **signal** into `agents/memory/intake/signals-YYYY-MM.jsonl` via
+`scripts/memory_signal.py`. Signals are append-only JSONL and
+merge-safe (see
+[`road-to-memory-merge-safety`](../../../agents/roadmaps/road-to-memory-merge-safety.md)).
+
+Unlike [`/memory-add`](memory-add.md) — which writes a **curated**
+entry the reviewer has validated — `/propose-memory` is cheap and
+provisional. Use it whenever a finding is worth preserving but does
+not yet justify a human reviewer's attention.
+
+## When to use
+
+- A producer command (`/bug-fix`, `/do-and-judge`, incident role exit)
+  resolved a failure and the pattern could recur.
+- The user says "remember this" about a finding that is not yet a
+  decision.
+- A reviewer spotted a smell worth recording without blocking the PR.
+
+Do NOT use when:
+
+- The entry is a **decision** — go to [`/memory-add`](memory-add.md)
+  with `architecture-decisions` or `product-rules`.
+- The finding contradicts an existing curated entry — open a
+  supersede-chain discussion instead; route via
+  [`road-to-memory-self-consumption`](../../../agents/roadmaps/road-to-memory-self-consumption.md).
+
+## Steps
+
+### 1. Pick the memory type
+
+```
+> Which memory type fits this signal?
+>
+> 1. historical-patterns — a recurring bug/fix pattern
+> 2. incident-learnings  — a post-mortem guardrail
+> 3. ownership           — a path → team mapping
+> 4. domain-invariants   — a module boundary rule
+> 5. architecture-decisions — a decision to revisit
+> 6. product-rules       — an intentional constraint
+```
+
+### 2. Gather minimum fields
+
+- `path` — the affected file / module / symbol
+- `body` — one or two sentences describing the finding
+
+### 3. Offer optional extras
+
+Ask once, numbered. If the user picks `skip`, proceed without them:
+
+- `symptom` (historical-patterns, incident-learnings)
+- `owner` (ownership)
+- `rule` (domain-invariants, product-rules)
+- `severity` — `low` · `medium` · `high`
+
+### 4. Emit via the shared helper
+
+```bash
+python3 scripts/memory_signal.py \
+    --type <type> \
+    --path "<path>" \
+    --body "<body>" \
+    --origin "propose-memory" \
+    --extra '{"symptom":"...","severity":"medium"}'
+```
+
+The helper deduplicates identical `(type, path, body)` within 7 days
+automatically — re-running the command on the same finding will
+silently skip the write. Add `--force` only when deliberate duplication
+is intended (rarely).
+
+### 5. Confirm and close
+
+```
+> ✅ Signal queued as id=<sig-xxxxxx> in <file>.
+>
+> Next steps:
+> 1. Promote to curated now — run /memory-add
+> 2. Leave as intake — reviewer will evaluate later
+> 3. Done
+```
+
+## Safety
+
+- The command **never** rewrites existing intake lines. Corrections go
+  via a new entry with `type: supersede` and `supersedes: <id>`
+  (append-only).
+- The command **never** writes outside `agents/memory/intake/`.
+- Schema mismatches (e.g., unknown `type`) raise — callers should
+  treat that as a bug in the producer, not a retryable failure.
+
+## See also
+
+- [`/memory-add`](memory-add.md) — curated (reviewer-validated) entries.
+- [`engineering-memory-data-format`](../guidelines/agent-infra/engineering-memory-data-format.md)
+- [`memory-access`](../guidelines/agent-infra/memory-access.md) — the
+  read-side contract that consumes what this command writes.
+- [`road-to-agent-memory-integration`](../../../agents/roadmaps/road-to-agent-memory-integration.md)
+  — Phase 2 (write-side producers).

package/.agent-src/commands/quality-fix.md

@@ -0,0 +1,106 @@
+---
+name: quality-fix
+skills: [quality-tools]
+description: Run quality pipeline (PHP and/or JS/TS) and fix all errors — auto-detects language from changed files
+disable-model-invocation: true
+---
+
+# quality-fix
+
+## Step 0: Detect language
+
+Check which files were changed to determine which pipeline(s) to run:
+
+```bash
+git diff --name-only origin/{default}..HEAD
+```
+
+| Changed files | Pipeline |
+|---|---|
+| `.php` files | → Run **PHP pipeline** (Steps 1–3) |
+| `.js`, `.ts`, `.tsx`, `.jsx` files | → Run **JS/TS pipeline** (Steps 4–6) |
+| Both | → Run **both** pipelines |
+
+---
+
+## PHP Pipeline
+
+### Prerequisites
+
+- All commands run **inside the PHP container** (e.g. `docker compose exec -T <service> ...`).
+- Detect the project type:
+  - Project ships a `quality:*` wrapper (Artisan or Composer script) → prefer `php artisan quality:phpstan` / `php artisan quality:rector --fix`
+  - `phpstan/phpstan` installed → `vendor/bin/phpstan analyse`
+  - `rector/rector` installed → `vendor/bin/rector process`
+  - `symplify/easy-coding-standard` installed → `vendor/bin/ecs check --fix`
+
+### Step 1: PHPStan — fix all errors
+
+1. Run PHPStan and capture the full output.
+2. For each error, **fix it in code**. Resolve the root cause.
+3. **Do NOT add errors to the baseline or phpstan.neon ignore lists.**
+4. If truly impossible (confirmed false positive), use inline ignore with reason.
+5. After fixing, run PHPStan again.
+6. Repeat until **0 errors**.
+
+### Step 2: Rector — apply automated refactoring
+
+1. Run Rector with the fix flag.
+2. Review what Rector changed — it may introduce new PHPStan errors.
+3. Run Rector again to verify no further changes are applied.
+4. Repeat until Rector produces no more changes.
+
+### Step 3: Final PHPStan verification
+
+1. Run PHPStan one more time.
+2. If new errors appeared (e.g. from Rector changes), fix them as in Step 1.
+3. If fixes were needed, go back to Step 2.
+4. Done when PHPStan reports **0 errors** and Rector has **no changes**.
+
+---
+
+## JS/TS Pipeline
+
+### Prerequisites
+
+- Check `package.json` for available tools and scripts.
+- Determine execution environment: host, Node container, or Makefile targets.
+
+### Step 4: Biome — auto-fix formatting + linting
+
+1. Run Biome with auto-fix (prefer npm script if available):
+   ```bash
+   npm run biome:fix          # or: npx biome check --write .
+   ```
+2. Review what changed — especially import reordering and formatting.
+3. If no Biome is installed, check for ESLint + Prettier and use those instead.
+
+### Step 5: TypeScript — fix type errors
+
+1. Run the type checker:
+   ```bash
+   npm run tscheck            # or: npx tsc --noEmit
+   ```
+2. For each error, **fix it in code**. Do NOT use `@ts-ignore`.
+3. If truly impossible, use `@ts-expect-error` with a reason comment.
+4. After fixing, re-run Biome (Step 4) — fixes may need reformatting.
+5. Repeat until **0 type errors**.
+
+### Step 6: Tests — verify nothing is broken
+
+1. Run the test suite:
+   ```bash
+   npm test
+   ```
+2. If tests fail, fix the failing tests or the code that broke them.
+3. After fixing, re-run Steps 4–5 to ensure quality is maintained.
+
+---
+
+## Rules
+
+- **Do NOT commit or push.** Only apply local changes.
+- **Do NOT modify baseline files** (`phpstan-baseline.neon`) or config files (`biome.json`, `tsconfig.json`).
+- **Do NOT add entries to `ignoreErrors`** in `phpstan.neon`.
+- Inline ignores (`@phpstan-ignore`, `@ts-expect-error`, `biome-ignore`) are a last resort.
+- Run `php -l` on modified PHP files if you made significant structural changes.

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

@@ -0,0 +1,81 @@
+---
+name: refine-ticket
+skills: [refine-ticket]
+description: Refine a Jira/Linear ticket before planning — rewritten ticket + Top-5 risks + persona voices, orchestrates validate-feature-fit and threat-modeling, ends with a close-prompt
+disable-model-invocation: true
+---
+
+# refine-ticket
+
+## Instructions
+
+### 1. Resolve input (delegate to jira-ticket loader)
+
+Accept one of four input paths:
+
+1. **Explicit key** — `/refine-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** — `/refine-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 refine? Paste a Jira key, URL, or the ticket text.
+```
+
+### 2. Pick the output language
+
+Apply the skill's language-strategy block. First hit wins:
+
+1. **User-message language** — latest user message decides. Honours
+   the global `language-and-tone` iron law.
+2. **Ticket body language** — minimal invocation (`/refine-ticket PROJ-123`
+   with no prose) mirrors the ticket's own language.
+3. **`.agent-settings.yml` default** — fallback when both silent; English
+   when absent.
+
+Quoted identifiers stay native; only prose mirrors the picked language.
+
+### 3. Run the refine-ticket skill
+
+Invoke the [`refine-ticket`](../skills/refine-ticket/SKILL.md) skill with the
+loaded ticket as input. The skill handles detection, orchestration, persona
+application, synthesis, and close-prompt.
+
+### 4. Honor flags
+
+- `--personas=<list>` — comma-separated override of the Core-6 default
+  (e.g. `--personas=developer,senior-engineer,critical-challenger`)
+- `--personas=+qa` — add the QA specialist to the Core-6
+- `--fresh-eyes` — reweight toward first-time-reader confusion signals
+  (critical-challenger voice gets more lines; less assumed context)
+
+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 three-section output template (refined ticket / Top-5 risks /
+persona voices) plus the close-prompt. Stop there. Do **not** chain into
+`/estimate-ticket` or `/feature-plan` — separate invocations by design.
+
+## Examples
+
+```
+/refine-ticket PROJ-123
+/refine-ticket                              # uses current branch
+/refine-ticket --personas=+qa PROJ-123
+/refine-ticket --fresh-eyes https://acme.atlassian.net/browse/PROJ-123
+```
+
+## See also
+
+- [`jira-ticket`](jira-ticket.md) — ticket loader this command delegates to
+- [`estimate-ticket`](estimate-ticket.md) — sibling command — run after refining if you also need sizing
+- [`feature-plan`](feature-plan.md), [`feature-explore`](feature-explore.md) — downstream commands
+- [`road-to-ticket-refinement.md`](../../agents/roadmaps/road-to-ticket-refinement.md) — governing roadmap