npm - @event4u/agent-config - Versions diffs - 1.33.0 → 1.35.0 - Mend

@event4u/agent-config 1.33.0 → 1.35.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (218) hide show

package/.agent-src/skills/accessibility-auditor/SKILL.md ADDED Viewed

@@ -0,0 +1,132 @@
+---
+name: accessibility-auditor
+description: "Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'."
+personas:
+  - frontend-engineer
+source: package
+domain: quality
+---
+# accessibility-auditor
+> Audit a UI surface against WCAG 2.2 AA, keyboard-only operation,
+> and screen-reader semantics. Output is a verdict with cited
+> failures, not a vibes check. Pair with
+> [`tailwind-engineer`](../tailwind-engineer/SKILL.md) for token-level
+> contrast fixes and [`ui-component-architect`](../ui-component-architect/SKILL.md)
+> for structural fixes (landmarks, heading order).
+## When to use
+- A new screen, component, or form lands and a11y has not been
+  reviewed yet.
+- A bug report mentions keyboard, screen reader, focus order,
+  contrast, or "user can't reach the X button".
+- A modal, dropdown, popover, tab strip, or tree view is being
+  introduced — these are the highest-yield bug zones.
+- German triggers: "barrierefrei prüfen", "Tastatur-Bedienung",
+  "Screenreader testen".
+Do NOT use when:
+- The visual design itself is the question (palette, type scale) —
+  route to [`fe-design`](../fe-design/SKILL.md).
+- The diff has no UI surface — accessibility audits without a UI are
+  speculation.
+- A specific component spec is missing entirely — get the component
+  built first via the stack-specific skill, then audit.
+## Procedure
+### 1. Identify the interaction surfaces
+List every interactive element on the screen: links, buttons,
+inputs, custom widgets (combobox, tab, dialog, tree). Each row
+gets a verdict in step 5; missing one is a coverage failure.
+### 2. Walk the four checklists
+**Perceivable** — text alternatives for non-text (`alt`, `aria-label`),
+contrast ≥ 4.5:1 for body / 3:1 for large or UI components, no
+colour-only state ("error in red" must also be iconic or text).
+**Operable** — every interactive element reachable by `Tab`, focus
+order matches visual order, focus indicator visible (≥ 3:1 against
+adjacent), `Esc` closes overlays, no keyboard traps.
+**Understandable** — labels associated (`label[for]` or wrapping),
+errors named in text (not just border colour), language attribute
+on `<html>`, predictable navigation across pages.
+**Robust** — landmarks present (`<header>`, `<nav>`, `<main>`,
+`<footer>`), heading order without skips, ARIA only when no native
+element exists, custom widgets follow ARIA-APG patterns.
+### 3. Run the keyboard pass
+`Tab` from page start: every interactive element receives focus,
+in visual order, with a visible indicator. `Shift-Tab` reverses
+cleanly. `Enter` / `Space` activate per role. Arrow keys work in
+composite widgets (tab strip, listbox, menu). `Esc` dismisses the
+top-most overlay only.
+### 4. Run the screen-reader pass
+Use VoiceOver (macOS), NVDA (Windows), or `aria-live` log
+inspection. Each surface announces: role, name, state, value,
+description (in that order). State changes (loading, expanded,
+selected, error) announce. Decorative images are silent.
+### 5. Score and report
+For each surface from step 1:
+| Surface | WCAG SC | Pass / Fail | Evidence |
+|---|---|---|---|
+| Submit button | 1.4.3 | Fail | contrast 3.1:1, expected 4.5:1 |
+| Modal | 2.1.2 | Fail | Tab leaves modal — focus trap missing |
+Verdict at the bottom: **AA-pass** (zero fails), **AA-pass-with-risk**
+(non-blocking gaps + plan), or **AA-fail** (blocking — fix before
+ship).
+## Output format
+```
+Scope:        <screen / component / route>
+Surfaces:     <count from step 1>
+Tools used:   <axe-core | manual | VoiceOver | NVDA — pick at least 2>
+Findings:
+  1. <SC>  <Pass/Fail>  <Evidence + file:line if known>
+  2. ...
+Verdict:      <AA-pass | AA-pass-with-risk | AA-fail>
+Top 3 fixes:  <ordered by user impact>
+```
+## Gotcha
+- `aria-label` on a `<button>` overrides its text content for
+  screen readers — only use when the visible text is not
+  descriptive (icon-only buttons).
+- `tabindex="-1"` removes from tab order *and* allows programmatic
+  focus; `tabindex="0"` adds to tab order. `tabindex >= 1` is
+  almost always wrong — fix the source order.
+- Native `<button>` and `<a>` come with role + keyboard for free;
+  reaching for `role="button"` on a `<div>` is a regression.
+- Contrast on disabled state has no WCAG threshold — but if the
+  user cannot tell it is disabled, that is a 1.4.1 failure on
+  state cue.
+## Do NOT
+- Do NOT declare AA-pass without a keyboard-only pass; an axe-core
+  green is necessary, not sufficient.
+- Do NOT add ARIA "to be safe" — wrong ARIA is worse than no ARIA.
+  Native semantics first.
+- Do NOT silence the audit on "internal-only tool" or "small user
+  base"; legal exposure does not scale with audience size in most
+  jurisdictions.
+- Do NOT close a finding by adjusting the test instead of the UI;
+  the user's experience is the ground truth, not the test report.

package/.agent-src/skills/adr-create/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: adr-create
 description: "Use when capturing an architectural decision — naming the file, picking the next ADR number, filling Status / Context / Decision / Consequences, and regenerating the index — even without saying 'ADR'."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

package/.agent-src/skills/adversarial-review/SKILL.md CHANGED Viewed

@@ -4,6 +4,7 @@ description: "ONLY when user explicitly requests adversarial review, devil's adv
 personas:
   - critical-challenger
 source: package
+domain: quality
 council_depth: deep
 ---

package/.agent-src/skills/agent-docs-writing/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: agent-docs-writing
 description: "Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure."
 source: package
+domain: process
 ---
 # agent-docs

package/.agent-src/skills/agents-md-thin-root/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: agents-md-thin-root
 description: "Use when editing AGENTS.md (package root) or templates/AGENTS.md (consumer) — enforces Thin-Root contract: hard char ceilings, ≥40% pointer ratio, mandatory emergency-triage block."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/ai-council/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: ai-council
 description: "Use when polling external AIs (OpenAI, Anthropic) outside the host session for a neutral second opinion on a roadmap, diff, prompt, or file set — or 'cross-check with another model'."
 source: package
+domain: process
 ---
 > **Experimental.** AI Council is not yet validated by external users. API costs apply per consultation.

package/.agent-src/skills/analysis-autonomous-mode/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: analysis-autonomous-mode
 description: "ONLY when user explicitly requests autonomous analysis, deep investigation, multi-step research, or 'dig into this end-to-end without asking me each step' — NOT for normal feature work."
 source: package
+domain: discovery
 ---
 # analysis-autonomous-mode

package/.agent-src/skills/analysis-skill-router/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: analysis-skill-router
 description: "Use when picking which analysis or project-analysis-* skill fits a request — routes by scope, framework, and symptom — even if the user just says 'analyze this' or 'dig into the codebase'."
 source: package
+domain: discovery
 ---
 # analysis-skill-router

package/.agent-src/skills/api-design/SKILL.md CHANGED Viewed

@@ -1,7 +1,10 @@
 ---
 name: api-design
 description: "Use when designing APIs, planning endpoints, REST conventions, versioning, or deprecation — even when the user just says 'expose this as an endpoint' without naming API design."
+personas:
+  - backend-architect
 source: package
+domain: engineering
 ---
 # api-design

package/.agent-src/skills/api-endpoint/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: api-endpoint
 description: "Use when the user says "create endpoint", "new API route", or "add controller". Creates a complete endpoint with Controller, FormRequest, Resource, route, and OpenAPI docs."
 source: package
+domain: engineering
 ---
 # api-endpoint

package/.agent-src/skills/api-testing/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: api-testing
 description: "Use when writing API endpoint tests — integration tests, contract validation, response assertions, mocked external services — even when the user says 'test this route' without naming API testing."
 source: package
+domain: quality
 ---
 # api-testing

package/.agent-src/skills/architecture-review-lens/SKILL.md ADDED Viewed

@@ -0,0 +1,137 @@
+---
+name: architecture-review-lens
+description: "Use when a diff may break system boundaries, dependency direction, or cross-service contracts — fifth judge dispatched by /review-changes alongside the four standard judges."
+personas:
+  - backend-architect
+  - senior-engineer
+source: package
+domain: quality
+---
+# architecture-review-lens
+> Fifth judge in the `/review-changes` family. Reviews a diff for
+> **architectural fit**, not correctness, security, tests, or style.
+> Catches what the other four miss: layer violations, wrong
+> dependency direction, leaking abstractions, and broken cross-service
+> contracts. Sibling of [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md)
+> et al. — never overlaps.
+## When to use
+- `/review-changes` dispatches its "architecture" slice to this skill.
+- A reviewer asks "does this belong here?", "should this be in
+  the domain layer?", or "is this leaking storage details?".
+- A diff adds a cross-service call, event, or contract.
+Do NOT use when:
+- The diff is documentation-only or a formatting-only change.
+- The concern is correctness — route to
+  [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md).
+- The concern is security — route to
+  [`judge-security-auditor`](../judge-security-auditor/SKILL.md).
+- The concern is naming or DRY — route to
+  [`judge-code-quality`](../judge-code-quality/SKILL.md).
+- The concern is *whether to make* the architectural change — route
+  to [`decision-record`](../decision-record/SKILL.md) first.
+## Procedure
+### 1. Anchor on the system shape
+Read the codebase's stated architecture (ADRs, AGENTS.md, module
+docs). If no shape is documented, infer it from folder structure
+and surface the gap. You are judging the diff against **the stated
+shape**, not a fantasy ideal.
+### 2. Inspect each changed file for fit
+For every changed file, answer:
+| Question | Smell when "no" |
+|---|---|
+| Does this file live in the right layer? | Layer violation |
+| Are imports flowing in the allowed direction? | Inverted dependency |
+| Does this leak a storage / framework detail? | Leaky abstraction |
+| Is the public API of the module still the same? | Contract drift |
+| Does a cross-service call respect its contract? | Contract break |
+Each smell is a finding with a file:line citation.
+### 3. Check the seams
+Pay special attention to:
+- New public methods on existing classes.
+- New imports that cross module boundaries.
+- New events, queue messages, or HTTP calls.
+- Removed deprecation warnings or feature flags.
+Cross-module / cross-service additions are the highest-leverage
+findings — surface them even at low individual severity.
+### 4. Issue a verdict per the judge contract
+| Verdict | When |
+|---|---|
+| `apply` | No architectural concerns; diff fits the stated shape |
+| `revise` | Findings exist; diff lands after the listed fixes |
+| `reject` | Architectural shape itself must be reconsidered (rare) |
+`reject` requires citing which ADR or stated shape would need to
+change — never reject for taste.
+### 5. Validate the verdict
+Verify before emitting: every finding has a `file:line` citation and
+a smell label from the taxonomy; the verdict matches the worst
+finding (`revise` if any finding exists, `apply` only when none);
+`reject` cites the ADR or stated shape that would need to change.
+Ensure no finding restates a concern owned by another judge.
+## Output format
+The verdict block carries these ordered fields:
+1. `Judge:` — fixed value `architecture-review-lens`
+2. `Model:` and `Target:` — model id from `.agent-settings.yml` and diff range
+3. `Verdict:` — exactly one of `apply` / `revise` / `reject`
+4. `Issues:` — numbered list, each with `file:line`, smell label, suggested fix
+```
+Judge:  architecture-review-lens
+Model:  <model id from .agent-settings.yml>
+Target: <branch / diff range>
+Verdict: apply | revise | reject
+Issues:
+1. 🔴 <finding>           file:line
+   Smell: layer-violation | inverted-dep | leak | contract-drift | contract-break
+   Suggested fix: <one sentence>
+2. 🟡 ...
+3. 🟢 ...
+```
+## Gotcha
+- The stated shape may be wrong. If the diff has a sound reason to
+  break it, do NOT raise a finding — recommend an ADR via
+  `decision-record` and approve the diff.
+- "Could be split into more files" is style, not architecture; route
+  to `judge-code-quality`.
+- A finding with no file:line citation is a vibe; reject your own
+  finding before issuing it.
+## Do NOT
+- Do NOT review correctness, security, tests, or style — those are
+  other judges.
+- Do NOT issue `reject` without naming the ADR or stated shape that
+  would need to change.
+- Do NOT raise findings against the *current* architecture if the
+  diff did not introduce them; this is a diff-judge, not a
+  codebase-audit.
+- Do NOT merge findings with another judge's output — the user needs
+  to see which lens raised each one.

package/.agent-src/skills/artisan-commands/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: artisan-commands
 description: "Use when creating or modifying Artisan commands. Covers clear signatures, safe execution flow, helpful output, and project conventions for console tooling."
 source: package
+domain: engineering
 ---
 # artisan-commands

package/.agent-src/skills/async-python-patterns/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: async-python-patterns
 description: "Use when writing Python asyncio code — picking between gather / TaskGroup / wait, structured concurrency, timeouts, cancellation, sync-bridging — decision framework only, cookbook externalized."
 source: package
+domain: engineering
 status: active
 refresh_trigger: "Python ships a new structured-concurrency primitive (post-TaskGroup), OR ≥30% of cited upstream cookbook examples become deprecated, OR the cited libraries (aiohttp, httpx, anyio, trio) cut a major version with breaking async surface changes."
 sunset_criterion: "When `https://docs.python.org/3/library/asyncio.html` ships an in-tree decision framework AND consumer projects no longer cite this skill in PR reviews for two consecutive review cycles."

package/.agent-src/skills/authz-review/SKILL.md CHANGED Viewed

@@ -1,7 +1,11 @@
 ---
 name: authz-review
 description: "Use when reviewing authorization end-to-end — route → gate → policy → query scope → response filter — before changes to permissions, tenants, ownership, or admin flows."
+personas:
+  - security-engineer
+  - backend-architect
 source: package
+domain: quality
 ---
 # authz-review

package/.agent-src/skills/aws-infrastructure/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: aws-infrastructure
 description: "Use when working with AWS resources — ECS Fargate, ECR, EFS, Secrets Manager, gomplate templates, multi-env deployments — even when the user says 'deploy to staging' without naming AWS."
 source: package
+domain: devops
 ---
 # aws-infrastructure

package/.agent-src/skills/blade-ui/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: blade-ui
 description: "Use when the project's frontend stack is Blade — dispatched by `directives/ui/{apply,review,polish}.py`. Covers views, components, partials, layouts, and view logic."
 source: package
+domain: engineering
 ---
 # blade-ui

package/.agent-src/skills/blast-radius-analyzer/SKILL.md CHANGED Viewed

@@ -1,7 +1,10 @@
 ---
 name: blast-radius-analyzer
 description: "Use BEFORE editing shared code — enumerates every call site, event consumer, queue worker, API client, migration, and test that a planned change will touch, with a file:line citation per dependency."
+personas:
+  - backend-architect
 source: package
+domain: discovery
 ---
 # blast-radius-analyzer

package/.agent-src/skills/bug-analyzer/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: bug-analyzer
 description: "Use when the user shares a Sentry error, Jira bug ticket, or error description and wants root cause analysis. Also for proactive bug hunting and code audits for hidden bugs."
 source: package
+domain: discovery
 council_depth: deep
 ---

package/.agent-src/skills/check-refs/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: check-refs
 description: "Use when verifying cross-references between skills, rules, commands, guidelines, and context documents are not broken after edits, renames, or deletions."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

package/.agent-src/skills/code-refactoring/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: code-refactoring
 description: "Use when the user says "refactor this", "rename class", or "move method". Safely refactors PHP code — finds all callers, updates downstream dependencies, and verifies with quality tools."
 source: package
+domain: engineering
 ---
 # refactorer

package/.agent-src/skills/code-review/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: code-review
 description: "Use when the user says "review this", "check my code", or wants feedback on changes. Reviews for correctness, quality, security, and coding standards."
 source: package
+domain: quality
 ---
 # code-review

package/.agent-src/skills/command-routing/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: command-routing
 description: "Use when the user invokes a slash command like /create-pr, /commit, /fix-ci, or pastes command file content — routes to the right command with context inference and GitHub API patterns."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/command-writing/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: command-writing
 description: "Use when creating or editing a slash command in .agent-src.uncompressed/commands/ — frontmatter, numbered steps, safety gates — even when the user just says 'add a /command for X'."
 source: package
+domain: process
 ---
 <!-- cloud_safe: degrade -->

package/.agent-src/skills/competitive-positioning/SKILL.md ADDED Viewed

@@ -0,0 +1,152 @@
+---
+name: competitive-positioning
+description: "Use when comparing this package to a peer / competitor — ours-vs-theirs verdict table, axis selection, adoption queue. Triggers on 'how do we compare to X', 'should we adopt their pattern'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product]
+---
+# competitive-positioning
+## When to use
+- A peer / reference / competitor repository was named and the team needs a structured comparison, not a vibes summary.
+- A pattern from another package is being considered for adoption and the trade-off needs to land in writing.
+- Positioning prose for a README / launch / pricing page needs an ours-vs-theirs decisions table to anchor on.
+Do NOT use for general repo audits (route to `analyze-reference-repo`),
+upstream-contribution decisions (route to `upstream-contribute`), or
+DCF-style valuation work (route to `dcf-modeling`).
+## Cognition cluster
+- **Mental model 1 — First principles.** Strip the comparison to the
+  outcome each package promises its user, not the feature lists. Two
+  packages with overlapping features can promise different outcomes
+  and therefore are not direct competitors. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 24 — Optionality.** A pattern that costs little to
+  adopt and preserves exit value beats a "better" pattern that locks
+  the package in. Score adoption cost AND exit cost on every row. See
+  `mental-models.md` § 24.
+- **Mental model 12 — Inversion.** For each axis, ask *"what would
+  we do if we wanted to lose on this axis?"* The answer surfaces the
+  invariants the comparison must preserve. See `mental-models.md` § 12.
+- **Product context-spine slot.** Read the **product** slot for
+  segment / focal job / non-goals before picking axes; the comparison
+  is only legitimate inside our own scope. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+## Procedure
+### 1. Frame the comparison
+Name the peer in one sentence: *"Package P promises outcome O for
+segment S."* If you cannot, the peer is not a peer; abort.
+### 2. Pick the axes
+3–7 axes, derived from the **product** spine slot, never from the
+peer's marketing site. Each axis must:
+- Be observable from the artefacts (repo, docs, package output).
+- Map to a real user outcome, not a feature checklist.
+- Be able to **separate** the two packages on at least the threshold
+  of "matters to a switch decision".
+### 3. Inspect both packages on each axis
+For every axis × package cell, capture:
+- **Evidence** — file path, doc URL, behaviour quote.
+- **Verdict** — clearly stronger / clearly weaker / parity / not
+  applicable.
+- **Cost-to-close** — if weaker, what would adopting their approach
+  cost in our scope? Mental-model-24 optionality: include exit cost.
+Cells without evidence are **not** parity; they are *unknown*.
+Surface them; do not silently call them ties.
+### 4. Run the inversion check and validate evidence
+For each axis where we win, ask: *"what change would make us lose
+this axis?"* If the answer is *"none, ever"*, the axis is invariant —
+flag it as a strategic moat, not a feature.
+Validate every cell against the evidence rule before continuing:
+verify each `clearly stronger` / `clearly weaker` row cites a file
+path, doc URL, or behaviour quote; check that no cell sits at
+parity without evidence; confirm at least one row separates the
+packages on a switch-decision-relevant outcome. Cells that fail
+this validation become *unknowns*, not parity.
+### 5. Produce the verdict table
+One row per axis. Columns: **axis · ours · theirs · verdict ·
+adopt? · rationale**. The `adopt?` column is the only opinion in
+the table.
+### 6. Hand back
+Hand the table to the requester; route adoption decisions to
+[`decision-record`](../decision-record/SKILL.md), upstream proposals
+to [`upstream-contribute`](../upstream-contribute/SKILL.md).
+## Related Skills
+**WHEN to use this**
+- Two packages are named and a verdict table is the unit of work.
+- A pattern from another package is on the table for adoption.
+- Positioning copy needs an anchor table.
+**WHEN NOT to use this**
+- The peer repo needs a generic walk-through first — route to
+  [`analyze-reference-repo`](../analyze-reference-repo/SKILL.md);
+  this skill consumes its output, never duplicates it.
+- The decision is to contribute back upstream — route to
+  [`upstream-contribute`](../upstream-contribute/SKILL.md).
+- The output is monetary value (DCF, valuation) — route to
+  [`dcf-modeling`](../dcf-modeling/SKILL.md).
+- The trade-off is across stakeholders inside our own team — route
+  to [`stakeholder-tradeoff`](../stakeholder-tradeoff/SKILL.md).
+## When the agent should load this
+- "Wie schlagen wir uns gegen X?"
+- "Sollten wir das Pattern aus Y übernehmen?"
+- "Bau mir die ours-vs-theirs Tabelle für die README."
+- "Wo verlieren wir gegen Package P?"
+- "Welche Achsen sind invariant für uns?"
+## Output
+A single Markdown block with:
+1. **Frame** — one-sentence promise of each package, segment named.
+2. **Axes** — bullet list of 3–7 axes with one-sentence rationale per axis.
+3. **Verdict table** — `axis · ours · theirs · verdict · adopt? · rationale`.
+4. **Invariants** — axes flagged as strategic moats with the inversion answer.
+5. **Adoption queue** — rows where `adopt? = yes`, ordered by cost-to-close.
+6. **Unknowns** — cells that lacked evidence; explicit, not collapsed to parity.
+## Gotcha
+- A verdict table without **unknowns** is suspect; nobody has
+  symmetric evidence on a peer at first pass.
+- `adopt? = yes` without cost-to-close + exit cost is wishful; the
+  optionality rule is non-negotiable.
+- Axes derived from the peer's site are reflective, not strategic;
+  re-derive from our own product spine slot.
+## Do NOT
+- Do NOT score before evidence — evidence first, verdict after.
+- Do NOT treat unknowns as parity to "complete" the table.
+- Do NOT lock adoption decisions in this skill — hand off to
+  `decision-record`.
+- Do NOT include monetary or roadmap framing — this is positioning,
+  not planning.

package/.agent-src/skills/composer-packages/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: composer-packages
 description: "Use when building or maintaining a Composer library — versioning, Laravel integration, autoloading, publishing to private registries — even when the user says 'release a new version'."
 source: package
+domain: engineering
 ---
 # composer-packages

package/.agent-src/skills/context-authoring/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: context-authoring
 description: "Use when filling in knowledge-layer context files — auth-model, tenant-boundaries, data-sensitivity, deployment-order, observability — interactive walkthrough that turns templates into reviewer fuel."
 source: package
+domain: process
 ---
 # context-authoring

package/.agent-src/skills/context-document/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: context-document
 description: "Use when the user says "create context", "document this area", or wants a structured snapshot of a codebase area for agent orientation."
 source: package
+domain: process
 ---
 # context

package/.agent-src/skills/conventional-commits-writing/SKILL.md CHANGED Viewed

@@ -2,6 +2,7 @@
 name: conventional-commits-writing
 description: "Use when writing commit messages or squash-merge titles — `feat:`, `fix:`, `chore:`, scopes, breaking changes — even when the user just says 'commit this' without naming Conventional Commits."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal