@event4u/agent-config 1.33.0 → 1.34.0

package/.agent-src/skills/rtk-output-filtering/SKILL.md

@@ -2,6 +2,7 @@
 name: rtk-output-filtering
 description: "Use when running verbose CLI commands — wraps them with rtk (Rust Token Killer) for 60-90% token savings. Covers installation, configuration, and usage patterns."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

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

@@ -2,6 +2,7 @@
 name: rule-writing
 description: "Use when creating or editing a rule in .agent-src.uncompressed/rules/ — trigger wording, always vs auto classification, size budget — even when the user just says 'add a rule for X'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

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

@@ -2,6 +2,7 @@
 name: script-writing
 description: "Use when adding or editing any script under `scripts/` — `--quiet` flag, `_lib/script_output` helpers, silent Taskfile wiring, Iron-Law carve-outs — even when you just say 'add a check script for X'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

package/.agent-src/skills/secrets-management/SKILL.md

@@ -2,6 +2,7 @@
 name: secrets-management
 description: "Use when picking a secrets store, designing rotation, or wiring scanning gates — multi-cloud (Vault, AWS, Azure, GCP), CI, and Kubernetes — decision framework, provider deep-dives externalized."
 source: package
+domain: devops
 status: active
 refresh_trigger: "A cited provider deprecates an auth method, OR External Secrets Operator ships a major version with breaking CRD changes, OR ≥30% of cited scanner tools change their gate semantics."
 sunset_criterion: "When provider docs (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) all converge on a single rotation + scanning standard AND consumer projects no longer cite this skill in PR reviews for two consecutive review cycles."

package/.agent-src/skills/security/SKILL.md

@@ -2,6 +2,7 @@
 name: security
 description: "Use when applying security best practices — authentication, authorization via Policies, CSRF protection, input sanitization, rate limiting, or secure coding."
 source: package
+domain: quality
 ---
 
 # security

package/.agent-src/skills/security-audit/SKILL.md

@@ -2,6 +2,7 @@
 name: security-audit
 description: "ONLY when user explicitly requests: security audit, vulnerability scan, or penetration test review. NOT for regular feature work."
 source: package
+domain: quality
 ---
 
 # security-audit

package/.agent-src/skills/sentry-integration/SKILL.md

@@ -2,6 +2,7 @@
 name: sentry-integration
 description: "Use when the user shares a Sentry URL, says "check Sentry", or wants to investigate production errors. Uses Sentry MCP tools for deep analysis."
 source: package
+domain: devops
 ---
 
 # Sentry Skill

package/.agent-src/skills/sequential-thinking/SKILL.md

@@ -2,6 +2,7 @@
 name: sequential-thinking
 description: "ONLY when user explicitly requests: step-by-step reasoning, structured problem decomposition, or iterative analysis. NOT for regular coding tasks."
 source: package
+domain: process
 ---
 
 # sequential-thinking

package/.agent-src/skills/skill-improvement-pipeline/SKILL.md

@@ -2,6 +2,7 @@
 name: skill-improvement-pipeline
 description: "ONLY when user explicitly requests: run the skill improvement pipeline after a learning was detected. Orchestrates capture, classify, create, validate, and apply."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/skill-management/SKILL.md

@@ -2,6 +2,7 @@
 name: skill-management
 description: "Use when compressing, decompressing, refactoring, or improving existing skills. Covers the full skill lifecycle from verbose → sharp → maintained."
 source: project
+domain: process
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: skill-reviewer
 description: "Use when reviewing, auditing, or optimizing skills — validates against the 7 Skill Killers checklist and produces fix recommendations."
 source: package
+domain: quality
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: skill-writing
 description: "Use when deciding 'should this be a skill or a rule?', creating/improving/reviewing agent skills, SKILL.md frontmatter, or procedure sections — even without saying 'skill-writing'."
 source: project
+domain: process
 ---
 
 # skill-writing

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

@@ -2,6 +2,7 @@
 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."
 source: package
+domain: engineering
 ---
 
 # sql

package/.agent-src/skills/stakeholder-tradeoff/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: stakeholder-tradeoff
+description: "Use when stakeholders pull a decision in different directions — frames each lens, builds a trade-off matrix, surfaces the cost of every choice — even if the user just says 'PO and ops disagree'."
+personas:
+  - product-owner
+  - stakeholder
+  - critical-challenger
+source: package
+domain: product
+---
+
+# stakeholder-tradeoff
+
+> Make explicit who pays and who benefits when a decision pulls
+> stakeholders in different directions. Builds a **stakeholder ×
+> criterion matrix** so the trade-off is visible, not hidden in
+> politics. Sibling of [`decision-record`](../decision-record/SKILL.md)
+> — that one locks the choice; this one surfaces the *human cost*
+> of each option before the lock.
+
+## When to use
+
+- PO, ops, support, and engineering disagree on an approach and the
+  user wants the disagreement made legible.
+- A decision benefits one segment at the cost of another (free vs
+  paid users, internal vs external, region A vs region B).
+- A roadmap step has *un*declared trade-offs and the user wants
+  them surfaced before commit.
+- German triggers: "Wer zahlt was?", "Stakeholder-Konflikt",
+  "Trade-off zwischen X und Y".
+
+Do NOT use when:
+
+- One stakeholder owns the decision unambiguously — surface their
+  decision and stop.
+- The trade-off is technical-only (perf vs storage) — route to
+  [`decision-record`](../decision-record/SKILL.md).
+- The trade-off is risk-only — route to
+  [`risk-officer`](../risk-officer/SKILL.md).
+
+## Procedure
+
+### 1. Identify the stakeholders
+
+Each by **role**, not name. Roles are stable across people —
+"on-call engineer" not "Anna". Include silent stakeholders the
+room forgot (support, finance, legal, end-users, future-team).
+
+### 2. Capture each stakeholder's lens
+
+For each stakeholder:
+
+- **What they want** — outcome, in their voice.
+- **What they fear** — the failure mode they cannot accept.
+- **What they will trade** — what they will give up to get the
+  outcome.
+
+If a lens is missing, mark `unknown` and surface it — do NOT invent
+a position the stakeholder did not state.
+
+### 3. Build the matrix
+
+| Criterion | PO | Ops | Support | Eng | End-user | ... |
+|---|---|---|---|---|---|---|
+| Time-to-ship | + | – | 0 | – | + | |
+| Operational load | 0 | – | – | – | + | |
+| ...
+
+`+` benefits, `–` costs, `0` neutral. The columns are stakeholders;
+the rows are criteria. Criteria that score `0` everywhere are
+noise — drop.
+
+### 4. Surface the trade-off
+
+Pick the top 2-3 criteria where the matrix splits stakeholders
+hardest. State the trade-off in plain language:
+
+> *"Picking option X means PO ships faster, but on-call carries
+> more pages. Picking option Y means on-call sleeps, but PO slips
+> two weeks."*
+
+If no option splits the matrix unfavourably, the trade-off is
+imaginary — surface that and stop.
+
+### 5. Recommend a path
+
+Pick the option whose `–` cells are owned by stakeholders who can
+execute mitigations. Avoid options where the cost lands on a
+stakeholder who has no voice in the room. State the recommendation
+explicitly with a one-sentence rationale.
+
+### 6. Validate the matrix
+
+Verify before emitting: every stakeholder has wants / fears / trades
+filled or marked `unknown`, the matrix has no row that scores `0`
+everywhere, the trade-off paragraph names a concrete cost (not just
+"there is a trade-off"), and the recommendation cites which `–`
+cells the named owner can execute. Ensure no silent stakeholder
+column is missing.
+
+## Output format
+
+The trade-off report is a single block with these ordered fields:
+
+1. `Decision:` — one sentence framing the choice
+2. `Stakeholders:` — bullet list, each with wants / fears / trades
+3. `Matrix:` — markdown table with criteria rows and stakeholder columns
+4. `Trade-off in plain language:` — one paragraph naming the cost
+5. `Recommendation:`, `Rationale:`, `Next:` — explicit choice +
+   rationale + handoff target
+
+```
+Stakeholder trade-off
+Decision: <one sentence>
+
+Stakeholders:
+  - <role>  wants: <outcome>     fears: <failure>     trades: <what>
+  - ...
+
+Matrix:
+  | Criterion       | <SH 1> | <SH 2> | ... |
+  | ...
+
+Trade-off in plain language:
+  <one paragraph>
+
+Recommendation: <option>
+Rationale:      <one sentence>
+Next:           /decision-record  to lock the choice
+```
+
+## Gotcha
+
+- The room is rarely all the stakeholders. Add the silent ones
+  explicitly (support, future-team, end-users).
+- A `+` everywhere column is suspect; either a stakeholder
+  understated the cost or you understated the cost.
+- The "happy path" recommendation is the option with the cost on
+  someone who is *not in the room*. Resist it.
+
+## Do NOT
+
+- Do NOT label stakeholders by name — roles only.
+- Do NOT score before listing the stakeholders' own words; agent
+  ventriloquism is the failure mode.
+- Do NOT pick the option that scores best on *all* stakeholders —
+  if it exists, the trade-off was imaginary; surface that.
+- Do NOT lock the choice in this skill; hand off to
+  `decision-record`.

package/.agent-src/skills/subagent-orchestration/SKILL.md

@@ -2,6 +2,7 @@
 name: subagent-orchestration
 description: "Use when orchestrating implementer/judge subagents — seven modes (do-and-judge ±two-stage, do-in-steps/parallel/worktrees, do-competitively, judge-with-debate) — models from .agent-settings.yml."
 source: package
+domain: process
 ---
 
 # subagent-orchestration
@@ -159,6 +160,18 @@ step is under ~30 minutes. The branch-creation, context-switch, and
 worktree-cleanup cost dominates. Stick with mode 1 (do-and-judge)
 or mode 3 (do-in-steps) for those.
 
+**Competitive variant — per-candidate isolation.** Mode 5
+(`do-competitively`) + worktrees: each candidate runs in its own
+worktree (no cross-candidate state leak). Selection rules:
+
+- **No auto-merge.** Orchestrator never merges candidate branches.
+  Hard Floor per [`non-destructive-by-default`](../../rules/non-destructive-by-default.md) —
+  applies even under standing autonomy. ADR-005 records reasoning.
+- **Ranked presentation.** Judge ranks 1..N with one-line
+  justifications; user picks winner.
+- **Loser worktrees stay.** Orchestrator does not auto-delete losing
+  worktrees — user keeps option to harvest a partial idea before cleanup.
+
 ## Status taxonomy — every subagent return uses one envelope
 
 Every implementer or judge return must conform to

package/.agent-src/skills/systematic-debugging/SKILL.md

@@ -2,6 +2,7 @@
 name: systematic-debugging
 description: "Use when hitting a bug, test failure, crash, or unexpected behavior — enforces reproduce → isolate → hypothesize → verify before any fix — even when the user just says 'this is broken' or 'quick fix'."
 source: package
+domain: discovery
 council_depth: deep
 ---
 

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

@@ -0,0 +1,130 @@
+---
+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
+source: package
+domain: engineering
+---
+
+# 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.
+
+## 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/tech-debt-tracker/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: tech-debt-tracker
+description: "Use when surfacing tech debt as trackable items — interest-vs-principal framing, prioritisation by carrying cost, repayment plan — even if the user just says 'this codebase is a mess'."
+personas:
+  - senior-engineer
+  - product-owner
+  - critical-challenger
+source: package
+domain: process
+---
+
+# tech-debt-tracker
+
+> Turn vague "this is messy" complaints into a **ranked debt ledger**
+> with carrying-cost estimates and a repayment plan the team can
+> execute. Frames debt as **principal** (the gap) plus **interest**
+> (what we keep paying because the gap exists). Output is copy-paste
+> ready; ticket / backlog write-back is user-gated.
+
+## When to use
+
+- The user lists code smells, dead code, or "we should refactor X"
+  and wants them turned into trackable items.
+- A retro surfaced multiple debt complaints; the team needs them
+  ranked, not all addressed at once.
+- A new initiative is about to add features on top of debt; the
+  team wants the carrying cost surfaced before committing.
+- German triggers: "Tech-Debt-Liste", "wo bremst es uns?",
+  "Aufräumen-Plan".
+
+Do NOT use when:
+
+- The user wants a single bug fixed — route to `/bug-fix`.
+- The complaint is about process, not code (slow CI, noisy alerts) —
+  surface as ops debt, not code debt; consider escalating to PO.
+- The "debt" is actually a missing feature — route to `po-discovery`.
+
+## Procedure
+
+### 1. Inspect inputs and collect candidate debt items
+
+Read the input (retro notes, code-review threads, pasted complaints,
+agent observations). Analyze each source for one candidate per
+bullet, no editing yet.
+
+### 2. Classify each item
+
+| Class | Examples |
+|---|---|
+| Code debt | Smells, duplication, dead code, weak tests, missing types |
+| Architecture debt | Coupling, layer violations, missing seams |
+| Operations debt | Manual deploys, alert fatigue, runbook gaps |
+| Knowledge debt | Stale docs, single-owner systems, missing onboarding |
+
+Items spanning two classes split into two entries — never merge.
+
+### 3. Estimate principal and interest
+
+For each item:
+
+- **Principal** — rough effort to repay (S / M / L; days, not hours).
+- **Interest** — what we keep paying *every week / sprint / month*
+  because the debt exists. Quantify or mark `unknown` (unknown
+  interest is itself a finding — surface it).
+
+Carrying cost = `interest × time-until-repaid`. High principal +
+zero interest → leave it. Low principal + recurring interest →
+top of the queue.
+
+### 4. Rank by `interest ÷ principal`
+
+Sort descending. The top ten are the candidates. Items below the
+top ten get a single line each (so they are not lost) but no
+deeper analysis — debt-list bloat is itself a debt.
+
+### 5. Shape a repayment plan
+
+For the top 3-5 items:
+
+- **Repayment shape** — single PR · multi-PR series · campaign ·
+  re-architecture.
+- **Owner role** — engineering · ops · PO · platform team.
+- **Trigger** — what makes us pay this *next* (e.g. "before adding
+  feature X", "when test runtime > 10 min", "next quarterly").
+
+Items without a trigger sit forever. A trigger that is "someday"
+is no trigger — push back.
+
+### 6. Issue a verdict
+
+| Verdict | When to issue |
+|---|---|
+| `track` | Items added to the ledger; no immediate action |
+| `pay-now` | One or more items have a trigger that already fired |
+| `block` | New feature work blocked until top item is repaid (rare) |
+
+### 7. Validate the ledger
+
+Verify before emitting: every top item has a class, principal,
+interest (or `unknown`), trigger, and owner; the ranking matches
+`interest ÷ principal`; tail items have one line each. Ensure no
+"someday" triggers and no agent-owned repayment owners slipped in.
+
+## Output format
+
+The ledger is a single block with these ordered fields:
+
+1. `Inventory:` — count and classes touched
+2. `Top items:` — numbered list ranked by `interest ÷ principal`,
+   each with class, principal, interest, trigger, owner, shape
+3. `Tail:` — one-line bullets for tracked-but-deferred items
+4. `Verdict:` — exactly one of `track` / `pay-now` / `block`
+5. `Next:` — handoff target (`/adr-create` or backlog write-back)
+
+```
+Tech-Debt Ledger
+Inventory: <count> items, <classes touched>
+
+Top items (interest ÷ principal):
+  1. [arch] <item>             Principal: M  Interest: high (3 hrs/sprint)
+        Trigger: <condition>  Owner: <role>  Shape: <PR / series / campaign>
+  2. [code] <item>             Principal: S  Interest: med  ...
+  ...
+
+Tail (tracked, no immediate action):
+  - <item>
+  - <item>
+
+Verdict: track | pay-now | block
+Next:    /adr-create (if a tradeoff lock is needed) | backlog write-back
+```
+
+## Gotcha
+
+- "Refactor X" is not a debt item — it is a wish. The item must
+  name *the gap* and *what it costs*.
+- Interest the team cannot measure is real but invisible. Mark
+  `unknown` and ask a probe ("how often do you hit this?") rather
+  than inventing a number.
+- A debt list with no trigger is paperwork. Reject items the team
+  has no plan to ever repay.
+
+## Do NOT
+
+- Do NOT enumerate every smell in the codebase — the top ten plus
+  a tail is the contract.
+- Do NOT propose repayment owners the agent itself owns; debt
+  repayment belongs to a human role.
+- Do NOT push items into Jira / Linear without explicit ask;
+  output is copy-paste ready, write-back is gated.
+- Do NOT silently inflate principal estimates to discourage repayment
+  the team should do.

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

@@ -2,6 +2,7 @@
 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."
 source: package
+domain: product
 council_depth: deep
 ---
 

package/.agent-src/skills/terraform/SKILL.md

@@ -2,6 +2,7 @@
 name: terraform
 description: "Use when writing Terraform — AWS modules, resources, variables, outputs, remote state — even when the user just says 'provision this infra' or 'add an S3 bucket' without naming Terraform."
 source: package
+domain: devops
 ---
 
 # terraform

package/.agent-src/skills/terragrunt/SKILL.md

@@ -2,6 +2,7 @@
 name: terragrunt
 description: "Use when working with Terragrunt — DRY multi-env configs, module dependencies, remote state orchestration — even when the user just says 'deploy this to staging and prod' without naming Terragrunt."
 source: package
+domain: devops
 ---
 
 # terragrunt

package/.agent-src/skills/test-driven-development/SKILL.md

@@ -2,6 +2,7 @@
 name: test-driven-development
 description: "Use when implementing a feature, fixing a bug, or refactoring — write a failing test first, then the code — even if the user just says 'add this function' or 'fix this bug'."
 source: package
+domain: quality
 ---
 
 # test-driven-development

package/.agent-src/skills/test-performance/SKILL.md

@@ -2,6 +2,7 @@
 name: test-performance
 description: "Use when optimizing test suite performance — database setup, seeder optimization, parallel testing, CI pipeline efficiency, or RefreshDatabase alternatives."
 source: package
+domain: quality
 ---
 
 # test-performance

package/.agent-src/skills/testing-anti-patterns/SKILL.md

@@ -2,6 +2,7 @@
 name: testing-anti-patterns
 description: "Use BEFORE writing or changing tests, adding mocks, or putting test-only methods on production classes — five Iron Laws and gates against mocking-the-mock, production pollution, silent partial mocks."
 source: package
+domain: quality
 ---
 
 # testing-anti-patterns

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

@@ -1,7 +1,10 @@
 ---
 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
 source: package
+domain: quality
 council_depth: deep
 ---
 

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

@@ -2,6 +2,7 @@
 name: token-optimizer
 description: "Use BEFORE any verbose CLI run, large file read, doc conversion, or near-context handoff — single decision tree keyed by intent that cites the canonical token-saving asset. Consult before the action."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

package/.agent-src/skills/traefik/SKILL.md

@@ -2,6 +2,7 @@
 name: traefik
 description: "Use when setting up Traefik as a local reverse proxy — real domains on 127.0.0.1, trusted HTTPS via mkcert, automatic service discovery, and multi-project routing."
 source: package
+domain: devops
 ---
 
 # Traefik Skill