@event4u/agent-config 1.33.0 → 1.35.0

package/docs/contracts/mental-models.md

@@ -0,0 +1,336 @@
+---
+stability: stable
+---
+
+
+# Mental Models — Top-30 Cross-Role Reference
+
+> **Status:** active · **Stability:** stable · **Owner:** unified-senior-roles Block K4
+> · **Hard cap:** 30 models · **R23 mitigation:** additions require removing one (zero-sum)
+
+A ranked, citation-only reference. Senior skills cite a model by
+its number when the cognition step it triggers needs framing prose
+the skill would otherwise re-invent. The doc is not auto-loaded
+and never appears in a prompt unless a skill names a row.
+
+## How this list was built
+
+Council iter-1 (Anthropic `claude-sonnet-4-5` + OpenAI `gpt-4o`,
+2026-05-05) Q2 verdict: **Ranked Top-30**, cross-role bias.
+Channel-specific (CAC/LTV-as-model, ad-auction, SEO keyword),
+C-suite strategy (Blue Ocean, Porter's Five Forces), and sales
+pipeline (BANT, MEDDIC) **explicitly cut** — they are domain
+heuristics, not cross-role cognition tools. Additions require
+removing one.
+
+Each entry: title · domain · ≤ 8-line summary · one citation example
+from a shipped skill (path is the proof of provenance, not a load
+instruction).
+
+## The 30 models
+
+### 1. First-principles thinking
+
+Strip the problem to assumptions you can defend from physics, contract,
+or hard data. Re-derive the answer from those, not by analogy to past
+decisions. The expensive part is identifying which "principle" is
+actually load-bearing vs. inherited belief; the cheap part is the
+re-derivation. Use when an inherited approach feels stale and you
+suspect the real constraint moved.
+*Cited by:* `.agent-src.uncompressed/skills/improve-before-implement/`
+(challenges weak requirements before code is written).
+
+### 2. Jobs-to-be-Done (JTBD)
+
+A user "hires" a product to make progress in a specific situation;
+the job is the situation × motivation × expected outcome, not the
+demographic. The unit of analysis is the **switch event** — what
+caused them to fire the previous solution. JTBD reframes feature
+requests as evidence of an unmet job, not feature gaps.
+*Cited by:* `.agent-src.uncompressed/skills/po-discovery/`
+(reframes fuzzy product asks via job-shape).
+
+### 3. Pareto principle (80/20)
+
+Roughly 80% of effects come from 20% of causes. The lift is in
+**identifying** the 20% — which user segment, which test failure,
+which N+1 query — not in re-stating the ratio. Anti-pattern: using
+80/20 as permission to ignore the long tail without measuring it.
+*Cited by:* `.agent-src.uncompressed/skills/performance-analysis/`
+(N+1 detection prioritizes the 20% of queries causing 80% of latency).
+
+### 4. Second-order thinking
+
+Ask "and then what?" until the chain breaks down. First-order picks
+what looks best now; second-order weighs the consequences of the
+consequences. Most "obvious" decisions die at second-order — the
+optimization that ships now creates the maintenance debt that kills
+velocity in 6 months.
+*Cited by:* `.agent-src.uncompressed/skills/adversarial-review/`
+(stress-tests a plan by walking past the immediate verdict).
+
+### 5. Opportunity cost
+
+The real cost of any choice is the **next-best alternative you did
+not pick**, not the dollar / time spent. A 2-week feature is not
+"2 weeks expensive" — it is the highest-value 2-week feature you
+chose not to ship instead. Naming the alternative makes the cost
+legible; pretending there isn't one is the failure mode.
+*Cited by:* `.agent-src.uncompressed/skills/rice-prioritization/`
+(scores compete for capacity; non-shipped items are the cost basis).
+
+### 6. Theory of constraints
+
+System throughput is bounded by exactly one constraint at a time.
+Improving any non-constraint resource is local optimization with
+zero system effect — usually negative, since it loads the actual
+constraint harder. The discipline: identify, exploit, subordinate,
+elevate, then find the next constraint.
+*Cited by:* `.agent-src.uncompressed/skills/funnel-analysis/`
+(identifies the single funnel stage that bounds conversion throughput).
+
+### 7. MVP (Minimum Viable Product)
+
+The smallest thing that produces real evidence about whether the
+hypothesis holds. MVP is a **measurement instrument**, not a
+junior-grade product. The trap is shipping an MVP that cannot
+distinguish "user behavior validates the hypothesis" from "user
+behavior was driven by something else"; that is just a small
+product.
+*Cited by:* `.agent-src.uncompressed/skills/po-discovery/`
+(scopes a discovery slice that produces a learning, not a feature).
+
+### 8. Build-Measure-Learn
+
+A loop: build the smallest test, measure the actual signal, decide
+to persevere or pivot. The skill is in **shortening the loop** —
+weeks beat months because months let teams rationalize a failed
+hypothesis. The loop is the artefact; any individual cycle is just
+one iteration.
+*Cited by:* `.agent-src.uncompressed/skills/test-driven-development/`
+(the build-measure-learn loop applied to one function at a time).
+
+### 9. Hypothesis-driven development
+
+State the hypothesis as a falsifiable sentence with a metric and a
+threshold **before** writing the code. "If we do X, metric Y will
+move by Z." Without the threshold, the team will declare any
+movement victory. With it, the team learns from the misses.
+*Cited by:* `.agent-src.uncompressed/skills/project-analysis-hypothesis-driven/`
+(competing hypotheses + validation loops + evidence-based conclusions).
+
+### 10. Reversible vs. irreversible decisions
+
+One-way doors deserve a high bar; two-way doors deserve a low bar
+plus speed. The bias under uncertainty: shipping a reversible
+decision early is almost always cheaper than the meeting required
+to decide. The skill is recognizing irreversibility — usually data
+shape, public API surface, or hiring.
+*Cited by:* `.agent-src.uncompressed/skills/decision-record/`
+(records the reversal-criteria so the irreversibility verdict is auditable).
+
+### 11. DX as first-class concern
+
+Developer experience is a leading indicator of throughput; it is not
+a polish task. Slow tests, fragile local setup, and surprising tool
+output compound — every developer pays the tax every day. Treat DX
+issues like user-facing bugs, with severity and SLA. The compounding
+math makes "fix it later" almost always wrong.
+*Cited by:* `.agent-src.uncompressed/skills/test-performance/`
+(test-suite latency is a developer-facing metric, optimized as such).
+
+### 12. Conway's Law
+
+The systems an organization builds mirror its communication structure.
+Re-orgs propagate to architecture; architecture changes that fight the
+org chart fail. The lever is bidirectional: pick the architecture you
+want, then engineer the communication paths that produce it.
+*Cited by:* `.agent-src.uncompressed/skills/api-design/`
+(bounded-context choices follow team boundaries, not the other way around).
+
+### 13. Occam's Razor
+
+Among hypotheses that fit the evidence equally well, prefer the one
+that introduces the fewest new entities. In debugging, the boring
+explanation (typo, off-by-one, stale cache) is usually correct. The
+trap is **assuming** instead of **falsifying** — Occam suggests
+order of investigation, not a verdict.
+*Cited by:* `.agent-src.uncompressed/skills/systematic-debugging/`
+(reproduce → isolate → hypothesize, simplest hypothesis first).
+
+### 14. Meadows leverage points
+
+Donella Meadows' ranking: the highest-leverage interventions in a
+system are paradigm shifts, then goals, then rules — far above
+parameter tweaks. Most "improvement" effort fights parameters
+(numbers, delays) at the bottom of the ranking. Climb the ranking
+before optimizing.
+*Cited by:* `.agent-src.uncompressed/skills/architecture-review-lens/`
+(boundary / dependency-direction issues are higher-leverage than tweaks).
+
+### 15. Signal vs. noise
+
+Every metric is a sum of underlying signal and measurement noise.
+A change of size N is meaningful only if N exceeds the noise floor
+for that metric × that horizon. The discipline: estimate the noise
+band first, then evaluate the change. Without the noise band, every
+movement looks like a trend.
+*Cited by:* `.agent-src.uncompressed/skills/funnel-analysis/`
+(stage-to-stage drop is read against the typical week-on-week noise).
+
+### 16. Leading vs. lagging indicators
+
+Lagging indicators (revenue, churn, retention) are accurate and
+late. Leading indicators (activation events, repeat-use, support
+volume) are noisy and early. Operating on lagging alone means the
+team learns about problems after they cost money. Pair them: lagging
+is the score, leading is the steering wheel.
+*Cited by:* `.agent-src.uncompressed/skills/dashboard-design/`
+(RED / USE / Golden Signals split leading from lagging explicitly).
+
+### 17. Churn as health metric
+
+Retention curves expose what acquisition cannot: whether the product
+delivers ongoing value. A flat retention tail means the product
+works for the survivors; a sliding tail means the underlying job is
+not getting done. Churn is upstream of CAC payback — fix it first,
+then scale.
+*Cited by:* `.agent-src.uncompressed/skills/funnel-analysis/`
+(retention bend distinguishes activation problems from product-fit).
+
+### 18. Pull vs. push systems
+
+Pull systems start work when downstream capacity opens; push systems
+start work when upstream capacity is free. Push optimizes individual
+utilization, pull optimizes flow. Most software teams claim pull and
+operate push (queues filling up, sprints overcommitted, WIP
+unmanaged). The fix is WIP limits, not motivation.
+*Cited by:* `.agent-src.uncompressed/skills/laravel-horizon/`
+(queue-balance strategies are pull-vs-push policy in concrete form).
+
+### 19. Shift-left
+
+Move quality / security / accessibility checks earlier in the
+lifecycle — to the developer's machine, the PR, the design — where
+the cost of fixing is order-of-magnitude lower. The trade-off:
+shift-left adds friction at the front; the math holds when defect
+escape rate drops faster than the friction cost.
+*Cited by:* `.agent-src.uncompressed/skills/threat-modeling/`
+(threats enumerated before implementation, not after pen-test).
+
+### 20. Latency vs. throughput
+
+Optimizing one usually hurts the other; the trade-off is structural,
+not implementation-detail. Batch processing trades latency for
+throughput; real-time pipelines trade throughput for latency. The
+mistake is optimizing without naming which one matters for the user
+job at hand.
+*Cited by:* `.agent-src.uncompressed/skills/database/`
+(index strategy and query batching surface the trade-off explicitly).
+
+### 21. Trust boundaries
+
+Every system has explicit lines across which inputs cannot be
+trusted: client → server, tenant A → tenant B, free tier → paid
+tier, public endpoint → internal service. Threats enter at boundary
+crossings; defense lives at the crossing, not deeper. Drawing the
+boundary correctly is half the security work.
+*Cited by:* `.agent-src.uncompressed/skills/threat-modeling/`
+(produces trust boundaries + abuse cases mapped to files).
+
+### 22. Defense in depth
+
+No single control is sufficient; layer entry validation, business
+rules, environment hardening, and instrumentation so a bypass at
+one layer is caught at the next. The trap is mistaking redundancy
+for security theatre — each layer must have an independent failure
+mode, not a copy of the previous one.
+*Cited by:* `.agent-src.uncompressed/skills/defense-in-depth/`
+(turns local fix into structural one across four guard layers).
+
+### 23. Blast radius
+
+Before changing shared code, enumerate every call site, event
+consumer, queue worker, API client, migration, and test that the
+change touches. The radius is the work; the diff is the artefact.
+Underestimating radius is the failure mode that breaks production
+when the change "looked small".
+*Cited by:* `.agent-src.uncompressed/skills/blast-radius-analyzer/`
+(file:line citation per dependency, BEFORE the edit).
+
+### 24. Iron triangle (scope / time / quality)
+
+Scope, time, and quality are coupled — fix two, the third moves.
+Pretending to fix all three is how teams ship at low quality and
+call it on-time. The honest move is naming which two are fixed and
+which one absorbs the variance, BEFORE the work starts.
+*Cited by:* `.agent-src.uncompressed/skills/refine-ticket/`
+(AC sharpening forces explicit scope decisions before estimation).
+
+### 25. Definition of Done
+
+A shared, auditable description of what "done" means for a unit of
+work — tests, docs, deployment, comms. Without one, every team
+member ships their personal threshold and disputes downstream. The
+discipline is making it visible, agreed, and consistently applied —
+not the specific items on it.
+*Cited by:* `.agent-src.uncompressed/skills/verify-completion-evidence/`
+(fresh evidence is required before any "done" claim).
+
+### 26. Postmortem-driven learning
+
+Incidents are signal-rich; the team that captures the signal beats
+the team that hides the incident. Blameless postmortems separate
+contribution from blame, surface systemic causes, and produce
+mitigations that reduce future incident rate — not just the count
+of one-off fixes.
+*Cited by:* `.agent-src.uncompressed/skills/incident-commander/`
+(severity framing + comms cadence + post-mortem skeleton).
+
+### 27. Tech debt as interest
+
+Tech debt has a principal (the shortcut taken) and an interest
+payment (the ongoing tax on velocity). Carrying the debt is the
+right call when the principal is repayable and the interest is
+small; the failure is treating ongoing high-interest debt as a
+fixed cost. Track it like a balance sheet.
+*Cited by:* `.agent-src.uncompressed/skills/tech-debt-tracker/`
+(interest-vs-principal framing, prioritisation by carrying cost).
+
+### 28. Mise en place
+
+Prepare every input — data, fixtures, dependencies, decisions —
+before the cooking step starts. Switching between prep and cook is
+where errors enter. In software, the analogue is staged commits,
+prepared test fixtures, and decisions locked before implementation.
+The discipline is the savings, not the metaphor.
+*Cited by:* `.agent-src.uncompressed/skills/existing-ui-audit/`
+(inventory before any non-trivial UI edit, hard gate).
+
+### 29. Premortem
+
+Before kickoff, assume the project failed and ask why — names the
+risks the team already knows but has not voiced. The trick is the
+past-tense framing; "what could go wrong" surfaces less than "it
+failed, what happened". Cheap; high signal-to-noise; the residual
+output is a risk register the team actually defends.
+*Cited by:* `.agent-src.uncompressed/skills/risk-officer/`
+(blast-radius framing, mitigations, residual-risk verdict pre-commit).
+
+### 30. Inversion
+
+Instead of asking "how do I succeed at X?", ask "how would I
+guarantee failure at X?" — then avoid that. Inversion exposes the
+non-obvious failure modes that direct planning misses, especially
+in security, ops, and people problems where the failure surface is
+larger than the success surface.
+*Cited by:* `.agent-src.uncompressed/skills/adversarial-review/`
+(devil's-advocate stress-test poking holes in a plan).
+
+## Adding or removing a model
+
+Hard cap is 30. Adding a 31st requires removing one and naming the
+swap in the PR description — the council verdict (R23) is that the
+list earns its weight only if every entry is load-bearing. Removal
+criteria: ≤ 1 citation across the catalog after one minor release,
+or superseded by a more general entry.

package/docs/contracts/persona-schema.md

@@ -0,0 +1,136 @@
+---
+stability: beta
+---
+
+# Persona Schema — two-tier (Core / Specialist)
+
+> **Status:** active · **Stability:** beta · **Owner:** road-to-better-skills-and-profiles Block A
+> · **Linter:** `scripts/skill_linter.py § lint_persona`
+> · **Source-of-truth dir:** `.agent-src.uncompressed/personas/`
+> · **Council verdict:** iter-1 A-OQ1 (c) — hybrid
+
+Locks the canonical persona shape: a uniform frontmatter across both
+tiers, a 5-section spine for Core, and a 7-section spine for Specialist
+(Core-5 + Critical Rules + Workflows). Existing Core personas are
+**not migrated** — the schema accepts the v1 shape that already ships.
+
+## § 1 — Frontmatter (uniform across tiers)
+
+| Key | Type | Required | Notes |
+|---|---|---|---|
+| `id` | string | yes | lowercase-hyphenated, must match filename stem |
+| `role` | string | yes | human-readable role name |
+| `description` | string | yes | one sentence, ≤ 160 chars |
+| `tier` | enum | yes | `core` \| `specialist` |
+| `mode` | string | optional | advisory link to a role-contract workflow mode |
+| `version` | string | yes | semver; bump on breaking changes |
+| `source` | enum | yes | `package` \| `project` |
+
+`personas:` is the consumer-side citation key (used in skill
+frontmatter); it is **not** part of a persona's own frontmatter.
+
+## § 2 — Tier definitions
+
+### `core` — always-loaded cast
+
+The six lenses every multi-lens skill leans on by default:
+`developer` · `senior-engineer` · `product-owner` · `stakeholder`
+· `critical-challenger` · `ai-agent`. Stable v1 shape; council
+verdict explicitly forbids migration to the 7-section spine — it
+would dilute the always-loaded cost without adding signal.
+
+### `specialist` — opt-in lens
+
+Domain-narrow voices a skill cites only when its specific axis is in
+play (e.g. `qa` for testability, `backend-architect` for system
+boundaries). Specialists carry the 7-section spine because their
+narrower scope justifies — and benefits from — explicit Critical
+Rules and Workflows blocks (pattern adopted from
+`alirezarezvani/claude-skills`).
+
+## § 3 — Required sections per tier
+
+### Core (5 sections, ≤ 120 lines)
+
+1. **Focus** — one paragraph, the lens.
+2. **Mindset** — bullets, default assumptions and skepticism.
+3. **Unique Questions** — ≥ 3 questions no other persona asks verbatim.
+4. **Output Expectations** — how findings are phrased.
+5. **Anti-Patterns** — what this persona must refuse to do.
+
+### Specialist (7 sections, ≤ 100 lines)
+
+1. **Focus**
+2. **Mindset**
+3. **Unique Questions** — ≥ 3, same heuristic
+4. **Output Expectations**
+5. **Anti-Patterns**
+6. **Critical Rules** — non-negotiable invariants this lens enforces
+   (e.g. "every new branch needs a failing test before the fix").
+   Bulleted, declarative, ≤ 8 items.
+7. **Workflows** — concrete review / inspection steps the persona
+   runs against the skill's input. Numbered, deterministic, ≤ 6 steps.
+
+`Composes well with` is permitted as an additional section in either
+tier (kept for v1 personas that ship it; not required, not budget-counted
+beyond the global line cap).
+
+## § 4 — Size budgets
+
+| Tier | Section count | Line cap | Rationale |
+|---|---|---|---|
+| `core` | 5 | ≤ 120 | always-loaded, stay lean |
+| `specialist` | 7 | ≤ 100 | opt-in, denser per section |
+
+The line cap is enforced by `lint-skills` against the full file
+including frontmatter and trailing blank line.
+
+## § 5 — Schema enforcement
+
+The linter (A2 work) enforces:
+
+- frontmatter shape (table in § 1)
+- tier enum
+- required sections per tier (§ 3)
+- size budget per tier (§ 4)
+- ≥ 3 bullets in `Unique Questions`
+- `id` matches filename stem
+- description ≤ 160 chars
+
+Specialist authors must use the template at
+`.agent-src.uncompressed/personas/_template-specialist/persona.md`.
+Core authors continue to use
+`.agent-src.uncompressed/templates/persona.md` (unchanged).
+
+## § 6 — Persona inventory (v1 snapshot)
+
+| ID | Tier | Mode | Status |
+|---|---|---|---|
+| `developer` | core | developer | shipped |
+| `senior-engineer` | core | reviewer | shipped |
+| `product-owner` | core | product-owner | shipped |
+| `stakeholder` | core | planner | shipped |
+| `critical-challenger` | core | reviewer | shipped |
+| `ai-agent` | core | developer | shipped |
+| `qa` | specialist | tester | shipped (existing 6-section shape; A-track migration to 7-section spine planned alongside A3 batch) |
+
+A3 adds four specialists drafted natively against the 7-section
+spine: `backend-architect` · `eloquent-tamer` · `security-engineer`
+· `frontend-engineer`.
+
+## § 7 — Versioning
+
+Section rename / add / remove → ADR + linter update + persona migrations
+in the same PR. Tier rename or new tier is breaking and requires a
+major version bump in the package release notes. Size-cap tightening
+is breaking when it forces existing personas to lose content; size-cap
+loosening is non-breaking.
+
+## See also
+
+- [`skill-domains`](skill-domains.md) — sister taxonomy for skills
+- [`role-contracts`](../guidelines/agent-infra/role-contracts.md) — workflow-mode axis personas compose with
+- `.agent-src.uncompressed/personas/README.md` — authoring entry point + Core-6 cast
+- `.agent-src.uncompressed/personas/_template-specialist/persona.md` — specialist starter
+- `.agent-src.uncompressed/templates/persona.md` — core starter (v1, unchanged)
+- `road-to-better-skills-and-profiles.md` — Block A (schema lock + extension)

package/docs/contracts/skill-domains.md

@@ -0,0 +1,143 @@
+---
+stability: beta
+---
+
+# Skill Domains — 6-domain taxonomy
+
+> **Status:** active · **Stability:** beta · **Owner:** road-to-better-skills-and-profiles Block B
+> · **Linter:** `scripts/skill_linter.py` enforces the `domain:` field against this allow-list
+> · **Schema:** `scripts/schemas/skill.schema.json` § `domain`
+
+Locks the canonical 6-domain taxonomy that classifies every skill in
+`.agent-src.uncompressed/skills/`. Each skill MUST declare exactly one
+`domain:` value from the allow-list below in its `SKILL.md` frontmatter.
+
+## § 1 — Allow-list
+
+```
+engineering · product · quality · devops · process · discovery
+```
+
+Unknown values fail `lint-skills`. Missing `domain:` fails `lint-skills`.
+No multi-domain assignment — pick the dominant axis.
+
+## § 2 — Domain definitions
+
+### `engineering`
+
+Application and framework code authoring — controllers, models,
+services, jobs, validation, queues, mail, broadcasting, ORMs, and
+language-level idioms (PHP, async patterns, error handling). The
+"writing the app" axis. Where the agent ships features into the
+production codebase.
+
+**Examples:** `eloquent` · `laravel-validation` · `php-coder`
+
+### `product`
+
+Discovery, refinement, and ticket / prompt shaping before code is
+written. Turns a fuzzy ask into a refined backlog item, an estimated
+unit of work, or a model-ready prompt. The "what should we build"
+axis — upstream of engineering.
+
+**Examples:** `refine-ticket` · `estimate-ticket` · `refine-prompt`
+
+### `quality`
+
+Test authoring, review, and verification gates. Pest, Playwright,
+the judge family, code review, threat modelling, security audits,
+testing anti-patterns. The "is it correct, safe, and reviewable"
+axis — runs alongside or after engineering.
+
+**Examples:** `pest-testing` · `judge-bug-hunter` · `review-routing`
+
+### `devops`
+
+Infrastructure, deployment, runtime, and observability. AWS, Docker,
+Terraform, Terragrunt, CI pipelines, Traefik, Grafana, secrets,
+DevContainers, package publishing. The "how it runs in production"
+axis.
+
+**Examples:** `terraform` · `github-ci` · `docker`
+
+### `process`
+
+Workflow, orchestration, and meta-tooling. Git workflow, slash-command
+routing, subagent orchestration, agent docs, skill / rule / command
+authoring, learnings capture, branch finishing, PR mechanics. The
+"how the agent works the codebase" axis.
+
+**Examples:** `git-workflow` · `command-routing` · `subagent-orchestration`
+
+### `discovery`
+
+Audit, diagnostic, and investigative analysis. Bug hunting, blast
+radius mapping, data flow tracing, performance and security audits,
+framework-specific project analysis, hypothesis-driven debugging.
+The "understand what's there before changing it" axis.
+
+**Examples:** `bug-analyzer` · `blast-radius-analyzer` · `project-analysis-laravel`
+
+## § 3 — Boundary heuristics (when in doubt)
+
+- **engineering vs quality** — does the skill **write production code**
+  (engineering) or **assert / review** production code (quality)?
+- **engineering vs devops** — does the artifact run **inside the app**
+  (engineering) or **around the app** (devops)?
+- **product vs process** — does the skill produce a **work item**
+  (product) or **drive the workflow** that delivers work items
+  (process)?
+- **discovery vs quality** — discovery **reads to understand**;
+  quality **reads to gate / approve**. A judge skill is `quality`; a
+  blast-radius skill is `discovery`.
+- **discovery vs engineering** — if the skill ends in a production
+  edit, it's `engineering`; if it ends in a written analysis or
+  finding, it's `discovery`.
+
+Tiebreaker: pick the axis that matches the skill's **primary output
+artifact**, not its auxiliary side-effects.
+
+## § 4 — Skill assignment by domain
+
+Snapshot from B3 back-fill (regenerate via `python3 scripts/_emit_domain_table.py`).
+Source-of-truth for the assignment is each skill's `domain:` frontmatter —
+this table is a derived view, kept readable for reviewers.
+
+### engineering (36)
+
+`api-design`, `api-endpoint`, `artisan-commands`, `async-python-patterns`, `blade-ui`, `code-refactoring`, `composer-packages`, `database`, `dependency-upgrade`, `dto-creator`, `eloquent`, `error-handling-patterns`, `fe-design`, `flux`, `jobs-events`, `laravel`, `laravel-horizon`, `laravel-mail`, `laravel-middleware`, `laravel-notifications`, `laravel-pennant`, `laravel-pulse`, `laravel-reverb`, `laravel-scheduling`, `laravel-validation`, `livewire`, `migration-creator`, `multi-tenancy`, `openapi`, `performance`, `php-coder`, `php-debugging`, `php-service`, `react-shadcn-ui`, `sql-writing`, `websocket`
+
+### product (12)
+
+`dcf-modeling`, `estimate-ticket`, `feature-planning`, `funnel-analysis`, `okr-tree-modeling`, `prompt-engineering-patterns`, `prompt-optimizer`, `refine-prompt`, `refine-ticket`, `rice-prioritization`, `technical-specification`, `unit-economics-modeling`
+
+### quality (25)
+
+`adversarial-review`, `api-testing`, `authz-review`, `code-review`, `defense-in-depth`, `design-review`, `judge-bug-hunter`, `judge-code-quality`, `judge-security-auditor`, `judge-test-coverage`, `mobile-e2e-strategy`, `pest-testing`, `playwright-testing`, `quality-tools`, `readme-reviewer`, `review-routing`, `security`, `security-audit`, `skill-reviewer`, `test-driven-development`, `test-performance`, `testing-anti-patterns`, `threat-modeling`, `validate-feature-fit`, `verify-completion-evidence`
+
+### devops (13)
+
+`aws-infrastructure`, `dashboard-design`, `devcontainer`, `docker`, `github-ci`, `grafana`, `logging-monitoring`, `react-native-setup`, `secrets-management`, `sentry-integration`, `terraform`, `terragrunt`, `traefik`
+
+### process (48)
+
+`adr-create`, `agent-docs-writing`, `agents-md-thin-root`, `ai-council`, `check-refs`, `command-routing`, `command-writing`, `context-authoring`, `context-document`, `conventional-commits-writing`, `copilot-agents-optimization`, `copilot-config`, `description-assist`, `developer-like-execution`, `file-editor`, `finishing-a-development-branch`, `git-workflow`, `guideline-writing`, `jira-integration`, `learning-to-rule-or-skill`, `lint-skills`, `markitdown`, `mcp`, `mcp-builder`, `md-language-check`, `merge-conflicts`, `module-management`, `override-management`, `persona-writing`, `project-docs`, `readme-writing`, `readme-writing-package`, `receiving-code-review`, `repomix-packer`, `requesting-code-review`, `roadmap-management`, `roadmap-writing`, `rtk-output-filtering`, `rule-writing`, `script-writing`, `sequential-thinking`, `skill-improvement-pipeline`, `skill-management`, `skill-writing`, `subagent-orchestration`, `token-optimizer`, `upstream-contribute`, `using-git-worktrees`
+
+### discovery (19)
+
+`analysis-autonomous-mode`, `analysis-skill-router`, `blast-radius-analyzer`, `bug-analyzer`, `data-flow-mapper`, `deep-reading-analyst`, `existing-ui-audit`, `performance-analysis`, `project-analysis-core`, `project-analysis-hypothesis-driven`, `project-analysis-laravel`, `project-analysis-nextjs`, `project-analysis-node-express`, `project-analysis-react`, `project-analysis-symfony`, `project-analysis-zend-laminas`, `project-analyzer`, `systematic-debugging`, `universal-project-analysis`
+
+**Total: 153 skills.**
+
+## § 5 — Versioning
+
+Domain rename or new-domain proposal → ADR + lint-skills allow-list
+update + back-fill of affected skills in the same PR. Domain
+deletion is breaking and requires a major version bump in the package
+release notes.
+
+## See also
+
+- [`skill-quality`](../../.agent-src.uncompressed/rules/skill-quality.md) — frontmatter contract for skills
+- [`rule-classification`](rule-classification.md) — sister taxonomy for rules (kernel vs auto)
+- `road-to-better-skills-and-profiles.md` — Block B (taxonomy lock + back-fill + folder reorg)