@event4u/agent-config 5.10.0 → 6.0.0

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

@@ -1,79 +0,0 @@
----
-model_tier: medium
-name: sql-writing
-description: "Use when writing raw SQL — MariaDB/MySQL syntax, parameterization, raw migrations, seeders with `DB::statement` — even when the user just pastes a query and asks 'why is this slow' without naming SQL."
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# sql
-
-## When to use
-
-Use when writing or reviewing raw SQL queries, migrations with raw statements, or seeders with raw SQL.
-
-Do NOT use when:
-- Eloquent/Query Builder queries (use `eloquent` or `database` skill)
-- Schema design (use `database` skill)
-
-## Procedure: Write raw SQL
-
-1. **Inspect call site & choose approach** — identify every dynamic value flowing into the query, then pick: query builder when possible. Raw SQL only when query builder can't express the query.
-2. **Parameterize** — Every variable must use `?` binding or named `:param`. Never interpolate PHP variables into SQL strings.
-3. **Use MariaDB syntax** — Not PostgreSQL or MSSQL. Check `php/sql.md` for MariaDB-specific patterns.
-4. **Verify** — Run EXPLAIN on complex queries. Check that no PHP interpolation (`"$var"`, `'{$var}'`) appears in SQL.
-
-```
-NEVER build SQL strings with PHP variable interpolation or concatenation.
-ALWAYS use parameterized queries or query builder.
-```
-
-## Conventions
-
-→ See guideline `php/sql.md` for parameterization patterns, common mistakes, MariaDB syntax reference.
-
-## Quick reference
-
-```php
-// ✅ Safe
-DB::select('SELECT * FROM users WHERE email = ?', [$email]);
-
-// ❌ SQL injection
-DB::select("SELECT * FROM users WHERE email = '{$email}'");
-```
-
-### Validate
-
-1. Verify every variable in SQL uses parameter binding (`?` or named `:param`).
-2. Confirm MariaDB/MySQL syntax — not PostgreSQL or MSSQL.
-3. Run EXPLAIN on complex queries to check index usage.
-4. Check that no PHP variable interpolation (`"$var"`, `'{$var}'`) appears in SQL strings.
-
-## Output format
-
-1. Parameterized SQL query using MariaDB/MySQL syntax
-2. EXPLAIN output for performance-critical queries
-
-## Gotcha
-
-- MariaDB and MySQL have subtle syntax differences.
-- The model writes `$variable` in SQL strings instead of `?` placeholders.
-- `GROUP BY` with `ONLY_FULL_GROUP_BY` requires all non-aggregated columns.
-- Use SQL types (`NULL`, `1/0`, `JSON_ARRAY()`) — not PHP equivalents.
-
-## Do NOT
-
-- Do NOT interpolate PHP variables into SQL strings — always parameterize.
-- Do NOT use PHP syntax (arrays, booleans, null) in raw SQL — use SQL equivalents.
-- Do NOT write raw SQL when the query builder can express the same thing clearly.
-
-## Auto-trigger keywords
-
-- raw SQL
-- SQL query
-- parameterized query
-- MariaDB syntax
-- SQL injection

package/.agent-src/skills/tailwind-engineer/SKILL.md

@@ -1,148 +0,0 @@
----
-model_tier: medium
-name: tailwind-engineer
-description: "Use when writing or reviewing Tailwind CSS — utility-first, design-token discipline, no inline-style drift, responsive variants, dark mode — even on 'style this' or 'mach das hübsch'."
-personas:
-  - frontend-engineer
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# tailwind-engineer
-
-> Apply utility-first discipline. Reach for design tokens before
-> arbitrary values, compose with `@apply` only where it earns its
-> keep, and reject inline `style=` drift. The skill is the **how**
-> for any Tailwind-stack screen; pair with
-> [`existing-ui-audit`](../existing-ui-audit/SKILL.md) for the **what
-> already exists** and [`fe-design`](../fe-design/SKILL.md) for the
-> **why**.
-
-## When to use
-
-- Writing or reviewing Tailwind classes in Blade, Livewire, or React
-  components.
-- A diff introduces inline `style=` for dynamic values, hex codes
-  not in `tailwind.config`, or `!important`.
-- Class lists balloon past ~12 utilities and the component is
-  hard to read or duplicate.
-- German triggers: "stile mit Tailwind", "design tokens nutzen",
-  "warum nicht inline?".
-
-Do NOT use when:
-
-- The stack is not Tailwind (vanilla CSS, CSS-in-JS, MUI) — skip.
-- The question is component shape, not styling — route to
-  [`ui-component-architect`](../ui-component-architect/SKILL.md).
-- An accessibility issue is the symptom (focus ring, contrast, hit
-  area) — route to [`accessibility-auditor`](../accessibility-auditor/SKILL.md).
-
-## Procedure
-
-### 1. Resolve to design tokens first
-
-Inspect `tailwind.config.{js,ts}` (or the equivalent `@theme` block)
-and identify the configured tokens. Map every requested colour,
-radius, spacing, shadow, font-size to a configured token. If the design hands you `#3B82F6`, use
-`bg-blue-500` (or the project's named token). Arbitrary values
-(`bg-[#3B82F6]`, `mt-[17px]`) are a smell — accept only with a
-one-line comment naming the design source.
-
-### 2. Compose, don't inline
-
-Inline `style="..."` is allowed only for **runtime-computed values**
-the build cannot know (server-pushed colour, animated transform
-target). Static values inline are a regression — replace with a
-utility, an arbitrary value, or a token extension.
-
-### 3. Order classes for scan-ability
-
-Group by axis: layout → box-model → typography → colour → state
-→ responsive. Most projects pin this with `prettier-plugin-tailwindcss`;
-if the plugin is configured, run it; if not, follow the order
-manually. Reviewer should read intent in one pass.
-
-### 4. Extract only when duplicated ≥ 3 times
-
-The first two repetitions are noise; the third is a pattern.
-Extract via:
-
-| Mechanism | When |
-|---|---|
-| Component (Blade/Livewire/React) | Different content, same shell |
-| Class string constant | Same shell, different consumers in same file |
-| `@apply` in CSS | Cross-file shared visual primitive (button, badge) |
-| Tailwind plugin | Tokens or variants, not classes |
-
-`@apply` for a one-off is a regression — keep utilities inline
-until the third use earns extraction.
-
-### 5. Responsive + dark + state in that order
-
-Class order within an axis: base → `sm:` → `md:` → `lg:` → `xl:` →
-`dark:` → state (`hover:`, `focus:`, `disabled:`, `aria-*:`).
-Mixing the order makes diffs noisy. State on top of dark on top
-of responsive matches Tailwind's cascade and reads top-down.
-
-## Output format
-
-When reviewing or proposing styles, return:
-
-1. Token map — every colour, spacing, radius, shadow, font-size mapped
-   to its configured token; arbitrary values flagged with the design
-   source they cite.
-2. Class list — ordered (layout → box-model → typography → colour →
-   state → responsive); inline-style use justified per element.
-3. Extraction + risk call-out — component / constant / `@apply` / none
-   with reason; risks named (arbitrary values, `!important`, dark-mode
-   gaps, non-token references).
-
-Concrete shape:
-
-```
-Element:        <selector or component name>
-Token map:      <colour/spacing/etc → config token>
-Class list:     <ordered classes>
-Inline style:   <only if runtime-computed; else "none">
-Extraction:     <component | constant | @apply | none — reason>
-Risks:          <arbitrary values, !important, dark-mode gaps>
-```
-
-## Gotcha
-
-- `space-x-*` / `space-y-*` collide with `flex-wrap` and RTL — use
-  `gap-*` on the flex/grid parent unless the design demands otherwise.
-- `dark:` variants need a token map in both modes; one-sided dark
-  styling is half a feature.
-- Arbitrary values (`mt-[17px]`) survive Tailwind upgrades but
-  break the design system; they accumulate silently.
-- `@apply` inside component CSS interacts with PurgeCSS — keep it
-  in files Tailwind scans, not in vendor CSS.
-- **Anti-AI-slop: gradients.** Unless audit-pinned or brief-explicit,
-  avoid the default purple-to-blue / cyan-to-pink gradients on white —
-  they read as auto-generated. Reach for a single accent from the
-  token map, or a duotone built from configured tokens.
-- **Anti-AI-slop: typography.** Unless audit-pinned, avoid surfacing
-  the system stack (`font-sans` fallback to Arial / Helvetica / Inter
-  via system defaults) as the *visible* body face. If `tailwind.config`
-  pins a font family, use it; if not, treat the missing token as a
-  gap to flag, not a license to ship the OS default.
-- **Anti-AI-slop: layout.** Unless audit-pinned, the centered hero +
-  3-column features + CTA stack is the AI-template tell. Break the
-  grid intentionally (asymmetric column split, overlap, diagonal
-  flow) when the brief allows; cite the design brief's `aesthetic:`
-  line if `fe-design`'s aesthetic-direction section produced one.
-
-## Do NOT
-
-- Do NOT add `!important` to win a specificity fight; restructure
-  the cascade or extract the conflicting style.
-- Do NOT introduce a new colour outside `tailwind.config` without
-  also adding the token; one-off hex codes drift the system.
-- Do NOT use `@apply` to avoid utility verbosity inside a single
-  component — extract the component instead.
-- Do NOT ship `style=` for static values; that is a CSS regression
-  the linter will not catch.

package/.agent-src/skills/technical-specification/SKILL.md

@@ -1,251 +0,0 @@
----
-model_tier: inherit
-name: technical-specification
-description: "Use when the user says "write a spec", "create RFC", "write a PRD", or "document this decision". Writes technical specifications, PRDs, RFCs, and ADRs with clear structure."
-domain: product
-council_depth: deep
-workspaces:
-  - product
-packs:
-  - product-basic
-trust:
-  level: professional
-install:
-  removable: true
----
-
-# technical-specification
-
-## When to use
-
-Use this skill when:
-- Writing a technical specification for a new feature or system
-- Writing a Product Requirements Document (PRD) when user pain leads and solution shape follows
-- Creating an architecture decision record (ADR)
-- Documenting a technical RFC (Request for Comments)
-- Planning a significant technical change that needs team review
-
-Do NOT use when:
-- Trivial changes (a good PR description is enough)
-- Implementation work (use `feature-planning` or `php-coder` skill)
-
-## Procedure: Write a spec
-
-### Technical Specification (full)
-
-For complex features or systems. Stored in `agents/features/` or module `agents/features/`.
-
-```markdown
-# Technical Specification: {Title}
-
-## Status
-{ Draft | In Review | Approved | Implemented | Superseded }
-
-## Summary
-{2-3 sentences explaining what this spec proposes and why.}
-
-## Problem
-{What pain point or limitation does this address?}
-
-## Goals
-- {Specific, measurable goal}
-- {Another goal}
-
-## Non-Goals
-- {What this spec explicitly does NOT cover}
-
-## Proposed Solution
-
-### Overview
-{High-level description of the approach.}
-
-### Detailed Design
-{Technical details — data models, APIs, algorithms, flows.}
-
-### Alternatives Considered
-| Alternative | Pros | Cons | Why rejected |
-|---|---|---|---|
-
-## Migration Plan
-{How to transition from current state to the proposed solution.}
-
-## Risks and Mitigations
-| Risk | Likelihood | Impact | Mitigation |
-|---|---|---|---|
-
-## Open Questions
-- [ ] {Unresolved question}
-
-## References
-- {Links to related docs, tickets, or external resources}
-```
-
-### Product Requirements Document (PRD)
-
-For features whose **shape is product-driven** rather than implementation-driven —
-when "what users get" matters more than "how the code is wired". Use a PRD
-when a Technical Specification would over-index on internals and under-index
-on user value. Stored in `agents/features/` next to the technical spec when
-both exist.
-
-```markdown
-# PRD: {Title}
-
-## Status
-{ Draft | In Review | Approved | Shipped | Parked }
-
-## Problem
-{The user-visible pain. One paragraph. Cite evidence — support tickets,
-analytics, user quotes — not assumptions.}
-
-## Success Criteria
-- {Measurable outcome with a number and a timeframe}
-- {Another measurable outcome}
-
-## Non-Goals
-- {What this PRD explicitly does NOT cover — protect scope}
-
-## User Stories
-- As a {role}, I want to {action}, so that {outcome}.
-- As a {role}, I want to {action}, so that {outcome}.
-
-## Major Modules
-{The 3-7 functional building blocks the feature decomposes into. One
-sentence each — what it does, not how. Implementation lives in the
-technical spec, not here.}
-
-- **{Module name}** — {one-sentence responsibility}
-- **{Module name}** — {one-sentence responsibility}
-
-## Open Questions
-- [ ] {Unresolved product question — pricing, permission, copy, edge case}
-
-## References
-- {Links to research, related PRDs, technical spec when it exists}
-```
-
-**PRD vs Technical Specification — when to pick which:**
-
-- **PRD first** when the user pain is clear but the solution shape is not
-  ("users can't share dashboards" → PRD scopes the problem; spec follows).
-- **Spec first** when the solution shape is clear but the implementation
-  is non-trivial ("rebuild auth on OAuth2" → spec leads; PRD often skipped).
-- **Both** when the feature is large enough that product and engineering
-  decisions belong in different artifacts.
-
-### Architecture Decision Record (ADR)
-
-For significant technical decisions. Stored in `agents/decisions/`.
-
-```markdown
-# ADR-{number}: {Title}
-
-## Status
-{ Proposed | Accepted | Deprecated | Superseded by ADR-{N} }
-
-## Context
-{What is the issue? What forces are at play?}
-
-## Decision
-{What is the change that we're proposing or have agreed to implement?}
-
-## Consequences
-
-### Positive
-- {Benefit}
-
-### Negative
-- {Drawback or tradeoff}
-
-### Neutral
-- {Other notable consequences}
-```
-
-### Lightweight RFC
-
-For smaller decisions that need team input. Can be a PR description or a short doc.
-
-```markdown
-# RFC: {Title}
-
-## Proposal
-{What do you want to do?}
-
-## Why
-{Why is this needed?}
-
-## How
-{Brief technical approach.}
-
-## Impact
-{What does this change? Who is affected?}
-
-## Open for feedback until: {date}
-```
-
-## Writing guidelines
-
-### Be specific, not vague
-
-```
-❌ "The system should be fast"
-✅ "API response time should be < 200ms at p95 for list endpoints"
-```
-
-### Include constraints
-
-- Performance requirements (latency, throughput)
-- Compatibility requirements (PHP version, browser support)
-- Security requirements (authentication, data sensitivity)
-- Scale requirements (data volume, concurrent users)
-
-### Show your reasoning
-
-Don't just present the solution — show **why** it was chosen over alternatives.
-The "Alternatives Considered" section is often the most valuable part.
-
-### Keep it actionable
-
-A spec should be implementable by someone who wasn't in the original discussion.
-If a developer reads only this document, they should be able to build it.
-
-## Integration with other systems
-
-- **Feature plans** reference specs when technical depth is needed.
-- **Roadmaps** are generated from specs after approval.
-- **ADRs** are referenced from `AGENTS.md` or module docs for historical context.
-- **Sessions** link to the spec being implemented.
-
-## Output format
-
-1. Technical specification document with architecture decisions
-2. API contracts, data models, and sequence diagrams
-3. Implementation plan with dependencies
-
-## Auto-trigger keywords
-
-- technical spec
-- PRD
-- product requirements
-- RFC
-- ADR
-- architecture decision
-
-### Validate
-
-- Verify every section of the spec template is filled in (no placeholders left).
-- Confirm constraints and limitations are explicit, not implied.
-- Check that the spec answers: What, Why, How, What not, and When.
-
-## Gotcha
-
-- A spec without constraints is fiction — always include technical limitations, timeline, and scope boundaries.
-- The model tends to write specs that describe the ideal solution without acknowledging existing code.
-- Don't write specs for trivial features — a spec is overhead that's only worth it for complex changes.
-
-## Do NOT
-
-- Do NOT write specs without researching the codebase first.
-- Do NOT present only one option — always consider alternatives.
-- Do NOT leave specs in "Draft" forever — push for a decision.
-- Do NOT implement before the spec is reviewed (for significant changes).

package/.agent-src/skills/threat-modeling/SKILL.md

@@ -1,197 +0,0 @@
----
-model_tier: high
-name: threat-modeling
-description: "Use when adding auth, webhooks, uploads, queues, secrets, tenant boundaries, or public endpoints — produces trust boundaries + abuse cases mapped to files, BEFORE implementation."
-personas:
-  - security-engineer
-domain: quality
-council_depth: deep
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# threat-modeling
-
-> You are a reviewer specialized in **pre-impl threat analysis**.
-> Your only job is to produce a compact threat model for a planned change —
-> actors, assets, trust boundaries, abuse cases, and the minimum controls
-> the implementer must add. You do **not** audit existing code end-to-end,
-> you do **not** review diffs, you do **not** implement controls — sibling
-> skills handle those.
-
-## When to use
-
-* The change adds or modifies authentication, authorization, or permission checks
-* The change adds a public endpoint, webhook, file upload, queue worker,
-  scheduled task, or third-party integration
-* The change touches sensitive data, tenant boundaries, secrets, billing flows,
-  or admin-only capabilities
-* A `security-sensitive-stop-rule` trigger fired and the agent must produce a
-  risk review before patching
-
-Do NOT use when:
-
-* The change is a cosmetic refactor or documentation-only edit — skip entirely
-* The change is a diff ready for review — route to
-  [`judge-security-auditor`](../judge-security-auditor/SKILL.md)
-* The concern is a full-codebase security posture review — route to
-  [`security-audit`](../security-audit/SKILL.md)
-* The concern is end-to-end authorization enforcement — route to
-  [`authz-review`](../authz-review/SKILL.md)
-* The concern is output/log leakage on an existing API — route to
-  [`data-exposure-review`](../data-exposure-review/SKILL.md)
-* The concern is implementing the controls once identified — route to
-  [`security`](../security/SKILL.md)
-
-## Procedure
-
-### 1. Anchor on the planned change
-
-Read the task description (ticket, feature plan, spec) and the entrypoints
-the change will touch. You are modelling **the stated change**, not the
-whole system. If the change is unclear from available context, stop and ask
-before continuing — never invent a threat model for an imagined feature.
-
-### 2. Inspect the execution path
-
-Trace the path once through existing code:
-
-- Where does untrusted input enter? (route, webhook, queue payload, CLI arg,
-  uploaded file, imported record)
-- Which actor types cross this path? (anonymous, authenticated user, admin,
-  service account, queue worker, cron)
-- What assets does the path touch? (PII, credentials, internal IDs, billing,
-  tenant-scoped records, files, secrets)
-- Where are the privilege boundaries? (auth gate, authorization layer, tenant
-  scope, admin gate)
-
-### 3. Model the risks
-
-For every distinct abuse case, answer:
-
-| Field | What to fill in |
-|---|---|
-| Entry point | route / job / webhook + concrete file |
-| Actor | who can trigger it |
-| Precondition | what must be true (auth state, data state) |
-| Impact | concrete damage (data loss, privilege escalation, DoS, leakage) |
-| Current control | what exists today |
-| Missing control | what the change must add |
-
-Prioritize by **impact × plausibility**, not by novelty. Skip generic
-OWASP bullets unless you can anchor them in a concrete file or line.
-
-### 4. Convert risks to engineering actions
-
-For each prioritized abuse case, propose the **smallest effective control**
-and name the exact file/layer it belongs in:
-
-- input validation → where
-- authorization check → where
-- rate limiting → where
-- output filtering → where
-- safer default → where
-- logging / alerting → where
-
-State whether a new **negative test** is required and what condition it
-must assert (e.g. *"POST /imports with tenant-B id from tenant-A session
-returns 403"*).
-
-## Validation
-
-Before finalizing the threat model, confirm:
-
-1. Every entry point has at least one identified control owner
-2. Every 🔴 abuse case has either an existing control or a required new one
-3. Every 🔴 abuse case has at least one proposed negative test
-4. You have NOT produced generic advice — every risk cites a file, route, or job
-5. You have NOT proposed offensive testing steps, exploit chains, or bypass ideas
-6. If the change is out of scope for threat modelling (no trust boundary
-   crossed), you have said so explicitly and stopped
-
-## Output format
-
-```
-Skill:   threat-modeling
-Target:  <feature / ticket / change summary>
-
-Actors:   <list, one per line>
-Assets:   <list, one per line>
-Entry points:   <route / job / webhook — file:line>
-Trust boundaries:   <where untrusted → trusted crossings happen>
-
-Abuse cases (prioritized):
-  🔴  <name> — entry point · actor · precondition
-      Impact: <concrete damage>
-      Current control: <what exists>
-      Missing control: <what to add, where>
-      Required test: <negative assertion>
-  🟡  ...
-  🟢  ...
-
-Implementation plan:
-  1. <control>, <file/layer>
-  2. ...
-
-Missing tests:
-  1. <assertion>, <test file>
-```
-
-Severity: 🔴 exploitable by external actor with current or no privilege /
-🟡 exploitable only with elevated privilege or partial auth / 🟢 defense-in-depth
-improvement, not a concrete exploit path.
-
-Required fields (ordered):
-
-1. **Skill** and **Target** — one-line change summary
-2. **Actors**, **Assets**, **Entry points**, **Trust boundaries**
-3. **Abuse cases** — prioritized; every entry cites entry point + actor + impact + current + missing control + required test
-4. **Implementation plan** — ordered controls mapped to files/layers
-5. **Missing tests** — ordered negative assertions
-
-Runtime confirmation (e.g. *"reproduce the abuse against staging"*, *"query
-the DB to confirm scope leakage exists today"*) is a follow-up for the
-implementer — **this skill does not execute tools, reproduce exploits, or
-run tests**.
-
-## Gotcha
-
-* **Generic OWASP bullets without a file anchor** — "SQL injection risk" is
-  noise unless you cite the query. Drop it or anchor it.
-* **Confusing authentication with authorization** — a logged-in user is not an
-  authorized user. Model authorization as a distinct boundary even when auth
-  is already enforced upstream.
-* **Treating queue workers and webhooks as trusted** — they carry attacker-
-  influenced payloads. Model them as untrusted entry points.
-* **Modelling the whole system when the change is narrow** — the model is
-  scoped to the planned change. Out-of-scope risks belong to `security-audit`.
-* **Producing offensive test steps** — you name abuse cases and required
-  controls, not exploit procedures.
-
-## Do NOT
-
-* NEVER produce exploit chains, payloads, or bypass techniques — if the task
-  asks for offensive work, stop and refuse per `never-help-build-offensive-cyber-capability`
-* NEVER return a threat model out of politeness when no trust boundary is crossed — say so and stop
-* NEVER treat "internal" or "behind the WAF" as a substitute for a control
-* NEVER approve a plan without at least one negative test per 🔴 abuse case
-* NEVER silently fall back to a generic checklist when the diff context is missing — ask instead
-
-## References
-
-- **STRIDE threat model** — Microsoft Security Development Lifecycle, Shostack
-  *Threat Modeling: Designing for Security* (2014). Framing basis for the
-  Actors / Assets / Entry Points / Trust Boundaries / Abuse Cases rubric.
-  [learn.microsoft.com/en-us/security/engineering/threat-modeling-tool-threats](https://learn.microsoft.com/en-us/security/engineering/threat-modeling-tool-threats)
-- **OWASP ASVS v4.0.3** — Authorization (V4), Validation & Encoding (V5),
-  Session Management (V3) — default baseline for "Missing control" entries.
-  [owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)
-- **OWASP Top 10 2021** — A01 Broken Access Control, A04 Insecure Design,
-  A05 Security Misconfiguration — cross-reference when naming abuse cases.
-  [owasp.org/Top10/](https://owasp.org/Top10/)
-- [`authz-review`](../authz-review/SKILL.md),
-  [`data-exposure-review`](../data-exposure-review/SKILL.md),
-  [`security`](../security/SKILL.md),
-  [`security-audit`](../security-audit/SKILL.md) — sibling review / impl skills.