@event4u/agent-config 1.9.1

package/.agent-src/skills/project-analysis-react/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: project-analysis-react
+description: "Use for deep React analysis: component tree, state flow, props flow, hooks usage, rendering behavior, and React-specific failure patterns."
+source: package
+---
+
+# project-analysis-react
+
+## When to use
+
+Use this skill when:
+
+* The project uses React
+* UI behavior is unclear or incorrect
+* There are rendering issues, state bugs, or performance problems
+* The issue spans multiple components or hooks
+* `universal-project-analysis` routes here after detecting React
+
+Do NOT use when:
+
+* The task is a simple UI change
+* The issue is isolated to a single component and obvious
+* The project is not React-based
+
+## Core principles
+
+* Rendering is derived from state — not imperative logic
+* State updates are async and batched
+* Hooks define lifecycle, not classes
+* Re-renders are the default, not the exception
+* Props flow down, events flow up
+* Memoization is a tool, not a default
+
+## Procedure
+
+### 1. Identify React setup
+
+Check: React version, framework wrapper (Next.js, Vite, CRA, etc.), TypeScript or JavaScript, routing setup, state libraries (Redux, Zustand, Context).
+Validate: React version is explicit, rendering environment is known (client-only vs SSR-capable).
+
+### 2. Map component tree
+
+Identify: root components, layout structure, nesting hierarchy, shared components, repeated patterns.
+Check: deep nesting, prop drilling, duplicated logic across components.
+
+### 3. Trace state flow
+
+Identify: where state is defined, where it is updated, how it flows across components, what triggers updates.
+
+Check:
+
+* local vs global state boundaries
+* unnecessary global state
+* duplicated or conflicting state
+* stale closures
+
+### 4. Analyze hooks usage
+
+Inspect: `useState`, `useEffect`, `useMemo`, `useCallback`, custom hooks, dependency arrays, side effects.
+
+Check:
+
+* missing dependencies
+* infinite loops
+* stale values
+* unnecessary memoization
+* side effects in render
+
+### 5. Analyze rendering behavior
+
+Check: what triggers re-renders, how often components re-render, conditional rendering logic, list rendering and keys.
+Validate: unnecessary re-renders, missing keys, expensive renders, incorrect conditional branches.
+
+### 6. Analyze async behavior
+
+Inspect: data fetching, loading states, race conditions, effect cleanup.
+Check: outdated responses overwriting newer state, missing cancellation logic, inconsistent loading/error handling.
+
+### 7. Detect common React anti-patterns
+
+* derived state stored unnecessarily
+* business logic inside components
+* deeply nested state objects
+* large components with mixed responsibilities
+* uncontrolled side effects
+
+### 8. Validate React analysis quality
+
+Check:
+
+* component tree is clearly understood
+* state flow is explicit
+* hooks behavior is verified
+* render triggers are identified
+* async flow is explained
+
+## Output format
+
+1. React setup summary
+2. Component tree overview
+3. State flow analysis
+4. Hooks and lifecycle findings
+5. Rendering behavior findings
+6. Async/data flow issues
+7. Key risks and fixes
+
+## Gotcha
+
+* React bugs often come from stale state, not broken logic.
+* Missing dependencies in hooks are one of the most common root causes.
+* Overusing memoization can make code harder to reason about without solving real problems.
+
+## Do NOT
+
+* Do NOT treat React as imperative UI code
+* Do NOT ignore dependency arrays
+* Do NOT assume state updates are synchronous
+* Do NOT ignore re-render behavior
+* Do NOT optimize before understanding render flow

package/.agent-src/skills/project-analysis-symfony/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: project-analysis-symfony
+description: "Use for deep Symfony project analysis: kernel/bootstrap, container wiring, routing/request flow, Doctrine, security, Messenger, and Symfony-specific failure patterns."
+source: package
+---
+
+# project-analysis-symfony
+
+## When to use
+
+Use this skill when:
+
+* The project uses Symfony
+* A deep Symfony-specific analysis is needed
+* `universal-project-analysis` routes here after framework detection
+* The issue spans kernel boot, DI, Doctrine, security, or Messenger
+
+Do NOT use when:
+
+* The task is a small isolated Symfony code change
+* The issue is already narrowed to a different specialist skill
+* The project is not actually Symfony
+
+## Core principles
+
+* Symfony behavior is highly container-driven
+* Environment-specific config changes meaningfully affect runtime
+* Service wiring and priority/order issues are common
+* Doctrine and Messenger often hide critical operational behavior
+* Security configuration must be traced end-to-end
+
+## Procedure
+
+### 1. Confirm Symfony version and app shape
+
+Check: `composer.lock`, `composer.json`, Symfony packages/components, PHP version, environment config structure.
+Validate: Symfony version is explicit, major bundles/components are identified, environment-specific config layout is known.
+
+### 2. Analyze kernel and container boot
+
+Inspect: Kernel bootstrap, bundle registration, compiler passes, `services.yaml`, autowiring/autoconfigure patterns, manual aliases/bindings, cache warmup/compiled container assumptions.
+
+Check:
+
+* autowiring conflicts
+* decoration order
+* tagged service priority
+* circular dependency symptoms
+* private/public service misuse
+
+### 3. Trace request-to-response flow
+
+Trace: route → request listeners/subscribers → controller → service layer → repository/Doctrine → serializer/forms → response.
+Validate: request lifecycle is visible, security checks are visible, serializer/form behavior is explicit, response transformation path is clear.
+
+### 4. Analyze Doctrine and persistence
+
+Inspect: entity mapping, repositories, lifecycle callbacks, subscribers/listeners, migration posture, DQL/QueryBuilder/native SQL usage.
+
+Check:
+
+* schema drift
+* proxy/lazy-loading issues
+* N+1 behavior
+* wrong lifecycle hook usage
+* transaction boundaries
+
+### 5. Analyze security and Messenger
+
+Inspect: firewalls, authenticators, voters, access rules, Messenger transports, handler routing, retry/failed-message behavior.
+
+Check:
+
+* auth flow correctness
+* firewall separation/context sharing
+* voter assumptions
+* failed-message handling
+* serialization/transport issues
+
+### 6. Validate Symfony analysis quality
+
+Check:
+
+* kernel/container behavior is explicit
+* request/security/doctrine paths are mapped
+* version-specific Symfony behavior was considered
+* Messenger/security risks are evidence-based
+* next specialist skill is clear if needed
+
+## Output format
+
+1. Symfony version and app summary
+2. Kernel/container findings
+3. Request/security flow
+4. Doctrine findings
+5. Messenger/async findings
+6. Key risks and next steps
+
+## Gotcha
+
+* In Symfony, configuration and service wiring often explain more than the controller code.
+* Compiler passes, decorators, tags, and priorities can change behavior in non-obvious ways.
+* Doctrine and Messenger issues often appear as "application bugs" but originate in framework integration details.
+
+## Do NOT
+
+* Do NOT analyze Symfony without explicit version context
+* Do NOT ignore service wiring and container behavior
+* Do NOT treat Doctrine entities as simple data objects without lifecycle effects
+* Do NOT skip security/firewall flow when access issues exist
+* Do NOT ignore Messenger transport and retry behavior in async problems

package/.agent-src/skills/project-analysis-zend-laminas/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: project-analysis-zend-laminas
+description: "Use for deep Zend Framework or Laminas project analysis: bootstrap, config merge order, service manager, MVC flow, data layer, and migration-specific risks."
+source: package
+---
+
+# project-analysis-zend-laminas
+
+## When to use
+
+Use this skill when:
+
+* The project uses Zend Framework or Laminas
+* A deep framework-specific analysis is needed
+* `universal-project-analysis` routes here after framework detection
+* The issue spans bootstrap, config merge, ServiceManager, MVC flow, or migration concerns
+
+Do NOT use when:
+
+* The task is a small isolated change
+* The project is not Zend/Laminas
+* The issue is already isolated to another specialist domain
+
+## Core principles
+
+* Config merge order is runtime behavior
+* ServiceManager resolution rules matter
+* Shared services can hide state issues
+* Legacy Zend/Laminas migrations often preserve subtle compatibility traps
+* MVC flow and module boundaries must be traced explicitly
+
+## Procedure
+
+### 1. Confirm framework generation and version
+
+Check: `composer.lock`, `composer.json`, Zend vs Laminas packages, PHP version, migration-related packages.
+Validate: framework family is explicit, migration state is known, major modules/components are identified.
+
+### 2. Analyze bootstrap and config merge order
+
+Inspect: application bootstrap, module loading order, global/local/autoload config, environment-specific overrides, `Module.php` lifecycle hooks.
+
+Check:
+
+* merge order surprises
+* missing overrides
+* environment config mismatches
+* heavy bootstrap logic
+
+### 3. Analyze ServiceManager behavior
+
+Inspect: factories, abstract factories, delegators, initializers, shared vs non-shared services, service aliases.
+
+Check:
+
+* incorrect sharing/state leakage
+* slow abstract factory fallback
+* delegator order problems
+* initialization side effects
+
+### 4. Trace request-to-response flow
+
+Trace: route match → dispatch/listener flow → controller → service layer → data access → view model/response rendering.
+Validate: authorization/input filtering path is visible, service resolution path is visible, rendering flow is explicit.
+
+### 5. Analyze data layer and migration risks
+
+Inspect: TableGateway/hydrators, Doctrine if present, SQL abstraction vs raw queries, buffered/unbuffered result usage, Zend → Laminas migration artifacts.
+
+Check:
+
+* namespace drift
+* hidden legacy references
+* data mapping inconsistencies
+* memory/performance risks on large result sets
+
+### 6. Validate Zend/Laminas analysis quality
+
+Check:
+
+* bootstrap and merge order are explicit
+* ServiceManager behavior is mapped
+* MVC and data flow are traceable
+* migration/legacy risks are evidence-based
+* next specialist skill is clear if needed
+
+## Output format
+
+1. Framework/version summary
+2. Bootstrap/config findings
+3. ServiceManager findings
+4. MVC/data flow findings
+5. Migration/legacy risks
+6. Key risks and next steps
+
+## Gotcha
+
+* Many Zend/Laminas issues are caused by config order and service resolution, not controller code.
+* Shared services and legacy migration remnants can create cross-request or environment-specific bugs.
+* Old project behavior may depend on historical bootstrap side effects that are easy to miss.
+
+## Do NOT
+
+* Do NOT assume Laminas behavior if the project still carries Zend-era patterns
+* Do NOT ignore config merge order
+* Do NOT ignore shared-service behavior
+* Do NOT treat migration leftovers as harmless
+* Do NOT stop at controller code when bootstrap or ServiceManager behavior is involved

package/.agent-src/skills/project-analyzer/SKILL.md

@@ -0,0 +1,341 @@
+---
+name: project-analyzer
+description: "ONLY when user explicitly requests: full project analysis, tech stack detection, or structured analysis documents for agents/analysis/. NOT for regular feature work."
+source: package
+---
+
+# project-analyzer
+
+## When to use
+
+Use this skill when:
+
+- Starting work on an unfamiliar project
+- Onboarding to a new codebase
+- Auditing the current state of agent docs, contexts, and features
+- Creating a baseline understanding of the project for future work
+- Generating comprehensive project documentation for knowledge transfer
+
+
+Do NOT use when:
+- Small, focused code changes
+- Regular feature development
+
+## Procedure: Analyze a project
+
+A **project analysis** is a systematic walkthrough of the entire codebase that:
+
+1. **Detects** — framework, language, tech stack, patterns, legacy vs. modern
+2. **Inventories** — modules, services, models, endpoints, tests
+3. **Analyzes** — business domains, data flows, API contracts, dependencies
+4. **Documents** — writes structured analysis files to `agents/analysis/`
+5. **Assesses** — identifies gaps, technical debt, missing docs
+
+It orchestrates other skills and commands to produce a comprehensive picture.
+
+## Analysis output
+
+All analysis results are written to `agents/analysis/` in a structured directory layout.
+The goal: **someone could rebuild the project from these documents alone.**
+
+### Directory structure
+
+```
+agents/analysis/
+├── overview.md                  ← Project profile, tech stack, architecture summary
+├── architecture/
+│   ├── database.md              ← Schema, connections, multi-tenancy, migrations
+│   ├── api.md                   ← Versioning, routes, middleware, auth flow
+│   ├── infrastructure.md        ← Docker, CI/CD, deployment, AWS, monitoring
+│   └── patterns.md              ← Design patterns used (Repository, Service, Pipeline, etc.)
+├── domains/
+│   ├── {domain}.md              ← One file per business domain (see below)
+│   └── ...
+├── modules/
+│   ├── {module}.md              ← One file per module (see below)
+│   └── ...
+├── models/
+│   ├── api-database.md          ← All api_database models, relationships, key columns
+│   └── customer-database.md     ← All customer_database models, relationships, key columns
+├── services/
+│   └── service-map.md           ← All services with purpose, dependencies, key methods
+├── api/
+│   ├── endpoints-v1.md          ← All v1 endpoints: route, controller, request, resource
+│   ├── endpoints-v2.md          ← All v2 endpoints: route, controller, request, resource
+│   └── contracts.md             ← API contracts: request/response shapes, validation rules
+└── testing/
+    └── test-map.md              ← Test suites, coverage areas, test data strategy
+```
+
+### Domain analysis files
+
+Each business domain gets its own file in `agents/analysis/domains/`. A domain groups
+related models, services, controllers, jobs, and events around a business concept:
+
+| Domain             | What it covers                                           |
+|--------------------|----------------------------------------------------------|
+| `projects.md`      | Construction sites, positions, project status, geocoding |
+| `planning.md`      | Appointments, crew assignments, capacity planning        |
+| `users.md`         | Employees, roles, permissions, authentication            |
+| `equipment.md`     | Machines, vehicles, repairs, time registration           |
+| `working-times.md` | Time tracking, absences, wage types, logs                |
+| `reports.md`       | Daily reports, images, measured quantities               |
+| `files.md`         | File uploads, file links, storage                        |
+| `customers.md`     | Tenant management, customer config, modules              |
+| `webhooks.md`      | Webhook dispatching, retry logic                         |
+| `imports.md`       | Client software imports (cross-reference with module)    |
+| `gps.md`           | GPS tracking, geofencing                                 |
+| `notifications.md` | Email, push, private messages, Slack                     |
+| `dashboard.md`     | Dashboard widgets, statistics                            |
+
+Not every project has all domains. Only create files for domains that actually exist.
+
+### Domain file template
+
+Each domain file should contain:
+
+```markdown
+# Domain: {Name}
+
+## Purpose
+
+{What this domain does in 2-3 sentences}
+
+## Models
+
+| Model | Table | Connection | Key Relationships |
+|---|---|---|---|
+
+## Services
+
+| Service | Purpose | Key Methods |
+|---|---|---|
+
+## Controllers (API Endpoints)
+
+| Endpoint | Controller | Request | Resource |
+|---|---|---|---|
+
+## Jobs & Events
+
+| Class | Type | Trigger | What it does |
+|---|---|---|---|
+
+## Business Rules
+
+- {Rule 1: e.g. "A project can only be deleted if it has no working times"}
+- {Rule 2}
+
+## Data Flow
+
+{Describe how data moves through this domain — from input to storage to output}
+
+## Dependencies
+
+- Depends on: {other domains}
+- Depended on by: {other domains}
+```
+
+### Module analysis files
+
+Each module gets its own file in `agents/analysis/modules/`. Format:
+
+```markdown
+# Module: {Name}
+
+## Purpose
+
+{What this module does}
+
+## Structure
+
+{Directory tree with key files}
+
+## Public API
+
+{What other parts of the app use from this module: Services, Events, Models}
+
+## Internal Components
+
+{Controllers, Jobs, Commands, Listeners that are module-internal}
+
+## Configuration
+
+{Config files, .env variables, feature flags}
+
+## Testing
+
+{Test suites, test data, stubs}
+```
+
+## Detection checklist
+
+### Framework & language
+
+| Check                 | How to detect                                 |
+|-----------------------|-----------------------------------------------|
+| PHP version           | `composer.json` → `require.php`               |
+| Laravel version       | `composer.json` → `require.laravel/framework` |
+| Laravel or standalone | `artisan` file exists → Laravel               |
+| Node.js               | `package.json` exists                         |
+| Frontend framework    | `package.json` → Vue, React, etc.             |
+| TypeScript            | `tsconfig.json` exists                        |
+
+### Project type
+
+| Signal                             | Type                           |
+|------------------------------------|--------------------------------|
+| `artisan` + `laravel/framework`    | Laravel application            |
+| `composer.json` without `artisan`  | Composer package or legacy PHP |
+| Module system (`app/Modules/`)     | Modular Laravel                |
+| Multi-tenant (`customer_database`) | Multi-tenant SaaS              |
+
+### Legacy indicators
+
+| Signal                                     | Meaning                   |
+|--------------------------------------------|---------------------------|
+| No `declare(strict_types=1)` in most files | Legacy codebase           |
+| No typed properties / return types         | Legacy PHP (< 7.4)        |
+| `var_dump()` / `print_r()` in code         | Legacy debugging patterns |
+| No tests or very few tests                 | Low test coverage         |
+| No PHPStan / Rector config                 | No static analysis        |
+| Mixed naming conventions                   | Inconsistent standards    |
+
+### Build & tooling
+
+| Check         | How to detect                                             |
+|---------------|-----------------------------------------------------------|
+| Task runner   | `Makefile` or `Taskfile.yml`                              |
+| Docker        | `docker-compose.yml` or `compose.yaml`                    |
+| CI/CD         | `.github/workflows/`                                      |
+| Quality tools | `phpstan.neon`, `ecs.php`, `rector.php`, or `config-dev/` |
+| Editor config | `.editorconfig`                                           |
+| Code review   | `CODEOWNERS`, PR templates                                |
+
+## Analysis phases
+
+### Phase 1: Project overview
+
+- Read `AGENTS.md`, `.github/copilot-instructions.md`, `README.md`
+- Detect framework, version, tech stack
+- Identify build tools and quality tooling
+- Classify: legacy vs. modern, monolith vs. modular
+- **Output:** `agents/analysis/overview.md`
+
+### Phase 2: Architecture
+
+- Map directory structure (top 3 levels)
+- Identify architectural patterns (MVC, modules, services, repositories)
+- Detect multi-tenancy, queue system, caching
+- Count: models, controllers, services, jobs, commands
+- **Output:** `agents/analysis/architecture/*.md`
+
+### Phase 3: Data layer
+
+- List all models with their connections, tables, and key relationships
+- Map database schema: tables, foreign keys, indexes
+- Document multi-tenant split (which tables in which DB)
+- **Output:** `agents/analysis/models/api-database.md`, `customer-database.md`
+
+### Phase 4: Business domains
+
+- Identify domains from models, services, routes, and directory structure
+- For each domain: map models → services → controllers → jobs → events
+- Document business rules and data flows
+- Document inter-domain dependencies
+- **Output:** `agents/analysis/domains/{domain}.md` (one per domain)
+
+### Phase 5: API surface
+
+- List all endpoints with controller, request, resource, OpenAPI attributes
+- Document request/response contracts (field names, types, validation rules)
+- Map version differences (v1 vs v2)
+- **Output:** `agents/analysis/api/endpoints-v1.md`, `endpoints-v2.md`, `contracts.md`
+
+### Phase 6: Service map
+
+- List all services with purpose, key methods, and dependencies
+- Map service → repository → model relationships
+- Identify God services (too many responsibilities)
+- **Output:** `agents/analysis/services/service-map.md`
+
+### Phase 7: Module inventory (if modules exist)
+
+- List all modules with purpose
+- For each module: structure, public API, internal components, tests
+- Check for module-level agent docs
+- **Output:** `agents/analysis/modules/{module}.md` (one per module)
+
+### Phase 8: Infrastructure & testing
+
+- Docker setup, CI/CD pipelines, deployment
+- Test suites, coverage areas, test data strategy
+- **Output:** `agents/analysis/architecture/infrastructure.md`, `agents/analysis/testing/test-map.md`
+
+### Phase 9: Agent docs audit
+
+- List all existing docs in `agents/docs/`, `agents/contexts/`, module `agents/`
+- Check for outdated docs (reference deleted files/classes)
+- Identify undocumented areas
+- Check for stale roadmaps
+
+### Phase 10: Gap analysis & action plan
+
+- Modules without context docs → offer `/context-create`
+- Complex services without docs → offer `/context-create`
+- Existing docs that reference deleted code → offer `/context-refactor`
+- Stale roadmaps (all steps done) → suggest archiving
+
+## Integration with other skills
+
+| Skill              | How it's used                                               |
+|--------------------|-------------------------------------------------------------|
+| `project-docs`     | Read existing docs before analyzing each area               |
+| `module-management`           | Detect and inventory modules                                |
+| `context-create`          | Create/update context documents                             |
+| `feature-planning` | Identify planned but undocumented features                  |
+| `agent-docs-writing`       | Audit and maintain agent documentation                      |
+| `roadmap-management`  | Review roadmap status                                       |
+| `api-endpoint`     | Understand endpoint structure for API analysis              |
+| `database`         | Understand schema and multi-tenancy for data layer analysis |
+
+## Workflow
+
+1. **Ask scope**: Full analysis or specific area (e.g. only domains, only API)?
+2. **Run phases incrementally** — show findings after each phase, ask before continuing.
+3. **Write files after each phase** — don't batch all writing to the end.
+4. **Ask before creating each file** with numbered options:
+   ```
+   > 1. Create — {filename}
+   > 2. Skip
+   ```
+5. **Update existing files** if re-running analysis — don't create duplicates.
+
+
+## Output format
+
+1. Structured analysis document in agents/analysis/
+2. Tech stack inventory with versions and dependencies
+3. Architecture diagram or module map
+
+## Auto-trigger keywords
+
+- project analysis
+- codebase analysis
+- architecture analysis
+
+## Gotcha
+
+- Full project analysis can take several minutes — warn the user about the time investment.
+- Don't analyze parts of the codebase that the user hasn't asked about — respect scope.
+- Analysis documents go in `agents/analysis/`, not in `.augment/`.
+
+## Do NOT
+
+- Do NOT create analysis files without asking — always confirm each creation.
+- Do NOT modify existing code — this is analysis only.
+- Do NOT commit or push.
+- Do NOT overwhelm the user — present findings incrementally, one phase at a time.
+- Do NOT analyze third-party code in `vendor/` or `node_modules/`.
+- Do NOT duplicate content that already exists in `agents/docs/` or `agents/contexts/` —
+  reference it instead. Analysis files complement existing docs, they don't replace them.