@event4u/agent-config 2.25.0 → 3.0.0

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

@@ -1,8 +1,20 @@
 ---
 name: project-analyzer
-description: "ONLY when user asks for single-pass tech-stack detection or `agents/analysis/` write-up. Deep multi-pass audit → `universal-project-analysis`. Raw primitives → `project-analysis-core`."
+description: "ONLY when user asks for single-pass tech-stack detection or `agents/evidence/analysis/` write-up. Deep multi-pass audit → `universal-project-analysis`. Raw primitives → `project-analysis-core`."
 source: package
 domain: discovery
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # project-analyzer
@@ -29,20 +41,20 @@ 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/`
+4. **Documents** — writes structured analysis files to `agents/evidence/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.
+All analysis results are written to `agents/evidence/analysis/` in a structured directory layout.
 The goal: **someone could rebuild the project from these documents alone.**
 
 ### Directory structure
 
 ```
-agents/analysis/
+agents/evidence/analysis/
 ├── overview.md                  ← Project profile, tech stack, architecture summary
 ├── architecture/
 │   ├── database.md              ← Schema, connections, multi-tenancy, migrations
@@ -70,7 +82,7 @@ agents/analysis/
 
 ### Domain analysis files
 
-Each business domain gets its own file in `agents/analysis/domains/`. A domain groups
+Each business domain gets its own file in `agents/evidence/analysis/domains/`. A domain groups
 related models, services, controllers, jobs, and events around a business concept:
 
 | Domain             | What it covers                                           |
@@ -139,7 +151,7 @@ Each domain file should contain:
 
 ### Module analysis files
 
-Each module gets its own file in `agents/analysis/modules/`. Format:
+Each module gets its own file in `agents/evidence/analysis/modules/`. Format:
 
 ```markdown
 # Module: {Name}
@@ -171,47 +183,73 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 
 ## 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                        |
+### Framework & language (multi-stack)
+
+| Check                  | How to detect                                                                |
+|------------------------|------------------------------------------------------------------------------|
+| PHP runtime + version  | `composer.json` → `require.php`                                              |
+| Laravel application    | `artisan` file at repo root + `laravel/framework` in `composer.json`         |
+| Symfony application    | `bin/console` + `symfony/framework-bundle` in `composer.json`                |
+| Composer package       | `composer.json` without `artisan` / `bin/console`                            |
+| Node.js runtime        | `package.json` exists                                                        |
+| TypeScript             | `tsconfig.json` exists                                                       |
+| Frontend framework     | `package.json` → `react`, `vue`, `svelte`, `solid`, `astro`, `@angular/core` |
+| Meta-framework         | `package.json` → `next`, `nuxt`, `remix`, `sveltekit`, `astro`               |
+| Python runtime         | `pyproject.toml`, `requirements.txt`, `setup.py`, or `Pipfile`               |
+| Python framework       | `pyproject.toml` / `requirements.txt` → `django`, `fastapi`, `flask`         |
+| Go module              | `go.mod` exists                                                              |
+| Rust crate / workspace | `Cargo.toml` exists                                                          |
+| Ruby app               | `Gemfile` → `rails`, `sinatra`                                               |
+| .NET project           | `*.csproj`, `*.fsproj`, or `global.json`                                     |
+| Java / Kotlin          | `pom.xml`, `build.gradle`, or `build.gradle.kts`                             |
+
+After detecting **any** match, record the stack in the analysis output and select the matching `project-analysis-*` sub-skill (Laravel, Symfony, Next.js, React, Node/Express, Zend/Laminas) — fall back to `project-analysis-core` if no framework-specific sub-skill applies.
 
 ### 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                                |
+| Signal                                                                | Type                                  |
+|-----------------------------------------------------------------------|---------------------------------------|
+| `artisan` + `laravel/framework`                                       | Laravel application                   |
+| `bin/console` + `symfony/framework-bundle`                            | Symfony application                   |
+| `composer.json` without `artisan` / `bin/console`                     | Composer package or legacy PHP        |
+| `package.json` with `next` / `nuxt` / `remix` / `sveltekit` / `astro` | Meta-framework SSR/SSG app            |
+| `package.json` with `express` / `fastify` / `koa` / `hapi`            | Node HTTP service                     |
+| `package.json` with `@nestjs/core`                                    | NestJS application                    |
+| `pyproject.toml` with `django` / `fastapi` / `flask`                  | Python web app                        |
+| `go.mod` with `gin-gonic/gin` / `labstack/echo` / `gofiber/fiber`     | Go HTTP service                       |
+| Module system (`app/Modules/`, `src/modules/`, `packages/*`)          | Modular monolith / monorepo           |
+| Multi-tenant signal (`customer_database`, tenant middleware, `RLS`)   | Multi-tenant SaaS                     |
+| `apps/*` + `packages/*` + `turbo.json` / `nx.json` / `pnpm-workspace` | Monorepo                              |
+
+### Legacy indicators (stack-aware)
+
+| Signal                                                                       | Meaning                       |
+|------------------------------------------------------------------------------|-------------------------------|
+| PHP: no `declare(strict_types=1)` in most files                              | Pre-modern PHP style          |
+| PHP: no typed properties / return types                                      | Legacy PHP (< 7.4)            |
+| PHP: no `phpstan.neon` / `rector.php`                                        | No static analysis            |
+| TS: `// @ts-ignore` / `// @ts-nocheck` density; `any` widespread             | Untyped TypeScript            |
+| TS: no `tsconfig.json` `strict: true`                                        | Loose TypeScript              |
+| JS: no ESLint config or `eslint.config.*`                                    | No linting                    |
+| Python: no type hints in most signatures; no `py.typed`                      | Untyped Python                |
+| Python: no `mypy.ini` / `pyrightconfig.json` / `ruff.toml`                   | No static analysis            |
+| Go: no `golangci.yml`                                                        | No lint pipeline              |
+| Rust: no `clippy.toml` and warnings ignored                                  | No lint hygiene               |
+| `var_dump()` / `console.log()` / `print()` / `fmt.Println()` left in code   | Legacy debugging patterns     |
+| No tests or very few tests                                                   | Low test coverage             |
+| Mixed naming conventions across the same module                              | Inconsistent standards        |
+
+### Build & tooling (stack-agnostic)
+
+| Check         | How to detect                                                                                                                                                       |
+|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Task runner   | `Makefile`, `Taskfile.yml`, `justfile`, `package.json scripts`, `composer.json scripts`                                                                             |
+| Docker        | `docker-compose.yml`, `compose.yaml`, `Dockerfile`                                                                                                                  |
+| CI/CD         | `.github/workflows/`, `.gitlab-ci.yml`, `.circleci/config.yml`, `azure-pipelines.yml`                                                                               |
+| Quality tools | PHP: `phpstan.neon`, `ecs.php`, `rector.php`. TS/JS: `eslint.config.*`, `.prettierrc*`, `tsconfig.json`. Python: `ruff.toml`, `mypy.ini`. Go: `.golangci.yml`. Rust: `clippy.toml` |
+| Editor config | `.editorconfig`                                                                                                                                                     |
+| Code review   | `CODEOWNERS`, PR templates (`.github/pull_request_template.md`)                                                                                                     |
+| Dependencies  | Lockfile presence: `composer.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `poetry.lock`, `uv.lock`, `go.sum`, `Cargo.lock`                            |
 
 ## Analysis phases
 
@@ -221,7 +259,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 - Detect framework, version, tech stack
 - Identify build tools and quality tooling
 - Classify: legacy vs. modern, monolith vs. modular
-- **Output:** `agents/analysis/overview.md`
+- **Output:** `agents/evidence/analysis/overview.md`
 
 ### Phase 2: Architecture
 
@@ -229,53 +267,53 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 - Identify architectural patterns (MVC, modules, services, repositories)
 - Detect multi-tenancy, queue system, caching
 - Count: models, controllers, services, jobs, commands
-- **Output:** `agents/analysis/architecture/*.md`
+- **Output:** `agents/evidence/analysis/architecture/*.md`
 
 ### Phase 3: Data layer
 
 - List all models with their connections, tables, and key relationships
-- Map DB schema: tables, foreign keys, indexes
+- 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`
+- **Output:** `agents/evidence/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 deps
-- **Output:** `agents/analysis/domains/{domain}.md` (one per domain)
+- Document inter-domain dependencies
+- **Output:** `agents/evidence/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`
+- **Output:** `agents/evidence/analysis/api/endpoints-v1.md`, `endpoints-v2.md`, `contracts.md`
 
 ### Phase 6: Service map
 
-- List all services with purpose, key methods, and deps
+- 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`
+- **Output:** `agents/evidence/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)
+- **Output:** `agents/evidence/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`
+- **Output:** `agents/evidence/analysis/architecture/infrastructure.md`, `agents/evidence/analysis/testing/test-map.md`
 
 ### Phase 9: Agent docs audit
 
-- List all existing docs in `agents/docs/`, `agents/contexts/`, module `agents/`
+- List all existing docs in `agents/reference/docs/`, `agents/settings/contexts/`, module `agents/`
 - Check for outdated docs (reference deleted files/classes)
 - Identify undocumented areas
 - Check for stale roadmaps
@@ -315,8 +353,8 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 
 ## Output format
 
-1. Structured analysis document in agents/analysis/
-2. Tech stack inventory with versions and deps
+1. Structured analysis document in agents/evidence/analysis/
+2. Tech stack inventory with versions and dependencies
 3. Architecture diagram or module map
 
 ## Auto-trigger keywords
@@ -329,7 +367,7 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 
 - 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/`.
+- Analysis documents go in `agents/evidence/analysis/`, not in `.augment/`.
 
 ## Do NOT
 
@@ -338,5 +376,5 @@ Each module gets its own file in `agents/analysis/modules/`. Format:
 - 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/` —
+- Do NOT duplicate content that already exists in `agents/reference/docs/` or `agents/settings/contexts/` —
   reference it instead. Analysis files complement existing docs, they don't replace them.

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

@@ -1,8 +1,20 @@
 ---
 name: project-docs
-description: "Use when looking for project-specific documentation. Knows which docs exist in agents/docs/ and agents/contexts/ and maps work areas to relevant docs."
+description: "Use when looking for project-specific documentation. Knows which docs exist in agents/reference/docs/ and agents/settings/contexts/ and maps work areas to relevant docs."
 source: package
 domain: process
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # project-docs
@@ -55,7 +67,7 @@ agents/
 
 ## Domain Contexts
 
-If `agents/contexts/domain/` exists, it contains **business domain knowledge** — industry terms,
+If `agents/settings/contexts/domain/` exists, it contains **business domain knowledge** — industry terms,
 regulations, workflows, and edge cases that the agent needs to understand the problem space.
 
 **When to read domain contexts:**
@@ -64,28 +76,28 @@ regulations, workflows, and edge cases that the agent needs to understand the pr
 - When writing validations, business rules, or data models for a specific domain
 
 **How to find the right file:**
-- List `agents/contexts/domain/` and read files whose name matches the work area
+- List `agents/settings/contexts/domain/` and read files whose name matches the work area
 - Files prefixed with `job-` describe industry/profession knowledge
 - When in doubt, read all domain context files — they are short orientation docs
 
 ## How to Find Relevant Docs
 
-1. **List `agents/contexts/`** — read any context file whose name matches the work area.
-2. **List `agents/contexts/domain/`** — read domain knowledge files relevant to the business logic.
-3. **List `agents/docs/`** — read detail docs for the specific topic you're working on.
+1. **List `agents/settings/contexts/`** — read any context file whose name matches the work area.
+2. **List `agents/settings/contexts/domain/`** — read domain knowledge files relevant to the business logic.
+3. **List `agents/reference/docs/`** — read detail docs for the specific topic you're working on.
 4. **Check module docs** — if working in a module, also check:
    - `app/Modules/{Module}/agents/` — module-specific docs
-   - `app/Modules/{Module}/agents/contexts/` — module-specific contexts (if exists)
-   - `app/Modules/{Module}/agents/contexts/domain/` — module-specific domain knowledge (if exists)
+   - `app/Modules/{Module}/agents/settings/contexts/` — module-specific contexts (if exists)
+   - `app/Modules/{Module}/agents/settings/contexts/domain/` — module-specific domain knowledge (if exists)
 
 ### Reading order
 
 | Step | What | Why |
 |---|---|---|
-| 1 | `agents/contexts/*.md` | Quick orientation — big picture in ~100 lines |
-| 2 | `agents/contexts/domain/job-*.md` | Domain knowledge — business terms, rules, edge cases |
-| 3 | Module `agents/contexts/` | Module-specific contexts (if working in a module) |
-| 4 | `agents/docs/*.md` | Deep dive — code examples, conventions, patterns |
+| 1 | `agents/settings/contexts/*.md` | Quick orientation — big picture in ~100 lines |
+| 2 | `agents/settings/contexts/domain/job-*.md` | Domain knowledge — business terms, rules, edge cases |
+| 3 | Module `agents/settings/contexts/` | Module-specific contexts (if working in a module) |
+| 4 | `agents/reference/docs/*.md` | Deep dive — code examples, conventions, patterns |
 
 ### Matching work areas to docs
 
@@ -104,7 +116,7 @@ Do NOT hardcode a mapping — always **list the directory** and pick by relevanc
 - **Don't skip docs because you "know" the pattern** — project-specific conventions often differ
   from standard framework patterns.
 - **Update docs when you change conventions** — if your change introduces a new pattern or
-  deprecates an old one, update the relevant doc in `agents/docs/`.
+  deprecates an old one, update the relevant doc in `agents/reference/docs/`.
 
 ## Cross-References
 

package/.agent-src/skills/prompt-engineering-patterns/SKILL.md

@@ -4,6 +4,18 @@ description: "Use when designing production-LLM prompts — few-shot, chain-of-t
 source: package
 domain: product
 status: active
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # prompt-engineering-patterns
@@ -142,5 +154,5 @@ Production prompts handle their own failure cases:
 
 - Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/prompt-engineering-patterns/SKILL.md` (MIT, © 2025 Microck) — restructured into a decision-framework shape; vendor `prompt_optimizer` Python snippets dropped (project-specific to Microck).
 - Cross-linked: [`prompt-optimizer`](../prompt-optimizer/SKILL.md), [`refine-prompt`](../refine-prompt/SKILL.md), [`mcp-builder`](../mcp-builder/SKILL.md), [`async-python-patterns`](../async-python-patterns/SKILL.md).
-- Provenance registry: `agents/contexts/skills-provenance.yml` (entry: `prompt-engineering-patterns`).
+- Provenance registry: `agents/settings/contexts/skills-provenance.yml` (entry: `prompt-engineering-patterns`).
 - Iron-Law floor: `verify-before-complete`, `skill-quality`, `non-destructive-by-default`.

package/.agent-src/skills/prompt-optimizer/SKILL.md

@@ -3,6 +3,18 @@ name: prompt-optimizer
 description: "Use when the user wants a prompt optimized for ChatGPT, Claude, Gemini, or another AI — 'make this prompt better', 'optimize for ChatGPT', 'rewrite my prompt' — even without saying 'optimize'."
 source: package
 domain: product
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # prompt-optimizer
@@ -130,4 +142,4 @@ Format per § Output format. Do **not** execute the optimized prompt yourself un
 
 - [`refine-prompt`](../refine-prompt/SKILL.md) — engine-inbound sibling; same `prompt_optimization` setting controls its mode
 - [`docs/guidelines/prompt-templates.md`](../../../docs/guidelines/prompt-templates.md) — 12-template catalogue cited from Develop step
-- AI Council session: `agents/council-responses/prompt-master-mini.json` (2026-05-17) — analysis behind template adoption and the 5-safe-dogma rejection <!-- council-ref-allowed: ADR decision trace -->
+- AI Council session: `agents/runtime/council/responses/prompt-master-mini.json` (2026-05-17) — analysis behind template adoption and the 5-safe-dogma rejection <!-- council-ref-allowed: ADR decision trace -->

package/.agent-src/skills/quality-tools/SKILL.md

@@ -8,8 +8,18 @@ execution:
   handler: shell
   allowed_tools: []
 recommended_for_user_types: [developer]
-
-
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # quality-tools

package/.agent-src/skills/react-native-setup/SKILL.md

@@ -3,6 +3,18 @@ name: react-native-setup
 description: "Use when setting up React Native or Expo dev environments — Xcode, Android Studio, CocoaPods, EAS, Metro, New Architecture — even when the user just says 'my RN build won't start'."
 source: package
 domain: devops
+workspaces:
+  - engineering
+packs:
+  - react
+lifecycle: active
+trust:
+  level: professional
+  confidence: high
+  human_review_required: false
+install:
+  default: false
+  removable: true
 ---
 
 # react-native-setup

package/.agent-src/skills/react-shadcn-ui/SKILL.md

@@ -3,6 +3,18 @@ name: react-shadcn-ui
 description: "Use when building React UI on shadcn/ui primitives + Tailwind — the apply/review/polish skill dispatched by `directives/ui/*` for the `react-shadcn` stack."
 source: package
 domain: engineering
+workspaces:
+  - engineering
+packs:
+  - react
+lifecycle: active
+trust:
+  level: professional
+  confidence: high
+  human_review_required: false
+install:
+  default: false
+  removable: true
 ---
 
 # react-shadcn-ui

package/.agent-src/skills/readme-reviewer/SKILL.md

@@ -7,6 +7,18 @@ execution:
   type: assisted
   handler: internal
   allowed_tools: []
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # readme-reviewer

package/.agent-src/skills/readme-writing/SKILL.md

@@ -7,6 +7,18 @@ execution:
   type: assisted
   handler: internal
   allowed_tools: []
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+lifecycle: active
+trust:
+  level: core
+  confidence: high
+  human_review_required: false
+install:
+  default: true
+  removable: false
 ---
 
 # readme-writing