@sallmarta/eye-hate-agent 1.0.3 → 1.0.5

package/docs/templates/rules/agent-rules.md

@@ -32,7 +32,7 @@ Structure incoming requests before acting to reduce rework and catch ambiguity e
   5. Treat a user-provided list as full scope unless the user changes it.
   6. Confirm if the plan could materially change scope, output, or direction.
   7. Then proceed.
-- **3.2** Skip the intake checklist only for trivial single-step edits.
+- **3.2** **Lite Mode (Micro-Tasks):** Skip the 7-step intake checklist and SDD requirements ONLY if the user explicitly triggers Lite Mode (e.g., using a `/lite` slash command, or prefixing their request with "Lite task:") AND the task is a trivial, isolated edit (e.g., typo fix, single UI tweak). For Lite Mode, bypass PRD validation and execute immediately to save time.
 
 ## 4. Docs, Verification, and Completion
 

package/docs/templates/skills/{architecture/api-design → api-design}/SKILL.md

@@ -4,7 +4,7 @@ description: "Project-aware expert-role contract design for APIs, interfaces, re
 argument-hint: "Describe the boundary, interface, endpoint, message contract, or service behavior to design or review"
 ---
 
-# Interface & API Contract Design — Project-Aware
+# API Design
 
 Produces a **project-aware, expert-level contract design or design review** by reading the repository's project docs first, then applying a reusable method to the current boundary type.
 
@@ -19,23 +19,18 @@ This skill is intentionally reusable across:
 
 It should **not** assume one language, framework, transport, or architecture style until the project docs confirm them.
 
----
-
 ## Required Project Inputs
 
 | Document | Why it matters |
 | --- | --- |
-
 | `docs/project-docs/foundation/architecture.md` | Defines stack, architecture boundaries, dependency rules, and integration patterns |
 | `docs/project-docs/foundation/prd.md` | Clarifies scope, constraints, stakeholders, and non-goals |
-| `docs/project-docs/technical/testing.md` | Defines how the contract should be validated |
+| `docs/project-docs/development/testing.md` | Defines how the contract should be validated |
 | Relevant feature docs, API docs, or guidelines | Provide domain-specific rules, request/response shapes, workflows, and edge cases |
 | Existing code or contracts in the repo | Show local naming, layering, serialization, validation, and error conventions |
 
 If the repository lacks the contract-defining docs needed for the task, call that out and create or update the missing docs instead of inventing local rules in the skill.
 
----
-
 ## When To Use
 
 Use this skill when designing or reviewing one of these boundary types.
@@ -49,8 +44,6 @@ Use this skill when designing or reviewing one of these boundary types.
 | Event or message contract | payload schema, producer/consumer expectations, ordering, retry, dead-letter rules |
 | Module boundary | public interface, dependency direction, allowed imports, extension points |
 
----
-
 ## Procedure
 
 ### Step 1 — Identify the contract owner
@@ -141,8 +134,6 @@ Examples:
 
 The output should fit the repository style and include enough detail to implement safely without locking the repo into one stack-specific pattern that the docs do not support.
 
----
-
 ## Output Contract
 
 When using this skill, the output should include:
@@ -155,8 +146,6 @@ When using this skill, the output should include:
 6. verification strategy
 7. open questions that still require product or architecture decisions
 
----
-
 ## Quality Checks
 
 Use this checklist when reviewing an existing contract:
@@ -169,8 +158,6 @@ Use this checklist when reviewing an existing contract:
 - Does the contract create hidden coupling or leak implementation details?
 - Is there a clear verification strategy in `testing.md`?
 
----
-
 ## Anti-Patterns
 
 - Embedding one stack's rules into the skill instead of reading project docs
@@ -180,19 +167,21 @@ Use this checklist when reviewing an existing contract:
 - Ignoring versioning, compatibility, or migration concerns for externally visible contracts
 - Over-designing the contract far beyond the current scope in `prd.md`
 
----
-
-## Natural Prompt Shapes
-
-- "Design the contract for this API or service boundary."
-- "Check whether this endpoint or DTO shape is designed correctly."
-- "Define the interface, error contract, and validation rules for this boundary."
-- "Review whether this event or repository contract matches the architecture."
+## Output Contract
 
----
+When using this skill, the output should include:
+1. the boundary type
+2. the project docs consulted
+3. the proposed contract shape
+4. validation and error rules
+5. ownership and dependency implications
+6. verification strategy
+7. open questions that still require product or architecture decisions
 
-## Example Requests
+## Neutral Prompt Shape
+`@agent use api-design on [Target Entity/Feature] focusing on [Specific Constraints/Version].`
 
+## Example Prompt
 - "Design the repository contract for this feature"
 - "Review this controller and DTO boundary"
 - "Design an event payload for this workflow"

package/docs/templates/skills/{auditing/full-verification → code-audit}/SKILL.md

@@ -1,37 +1,32 @@
 ---
-name: full-verification
+name: "code-audit"
 description: "Project-aware expert-role broad verification that reads project docs first, classifies the verification target, and routes to the best specialist skill for executable or non-executable checks across code, contracts, docs, architecture, quality, security, reliability, and project health."
 argument-hint: "Describe what should be verified against the contract, project docs, guidelines, code, APIs, architecture, or repository state"
 ---
 
-# Full Verification — Project-Aware
+# Code Audit
 
 Provides an **expert, project-aware broad verification entry point** for requests that ask whether something is correct, consistent, healthy, complete, or aligned with the repository's contract and project docs.
 
 This skill is **routing-first**. Its primary job is to identify the dominant verification question and route to the single best specialist skill rather than duplicating every verification procedure itself.
 
-This skill is intentionally **not tied to any single stack or framework**. When executable checks are needed, it should select the correct framework, commands, and conventions from the project's `technical/testing.md`, `foundation/architecture.md`, and local repository patterns.
-
----
+This skill is intentionally **not tied to any single stack or framework**. When executable checks are needed, it should select the correct framework, commands, and conventions from the project's `development/testing.md`, `foundation/architecture.md`, and local repository patterns.
 
 ## Required Project Inputs
 
 | Document | Why it matters |
 | --- | --- |
 | EHA Rules | Defines routing, ownership, precedence, and the active skill model |
-
-| `docs/project-docs/technical/testing.md` | Defines executable and non-executable verification rules, commands, and fallback policy |
-| `docs/project-docs/foundation/architecture.md` | Defines boundaries, stack, interfaces, dependency rules, and runtime assumptions |
-| `docs/project-docs/foundation/prd.md` | Defines goals, scope, non-goals, and success criteria |
+| `docs/project-docs/foundation/architecture.md` | Defines boundaries, dependencies, stack choices, and anti-violation rules |
+| `docs/project-docs/development/testing.md` | Defines available validation and evidence strength |
+| `docs/project-docs/foundation/prd.md` | Clarifies scope, non-goals, and project stage |
 | `docs/project-docs/foundation/status.md` | Defines maturity, roadmap, active workstreams, and readiness context |
 | Relevant guideline docs under `docs/project-docs/technical-guidelines/` | Define technical standards such as API, logging, database, error-handling, code style, or design patterns |
 | Relevant code, tests, docs, contracts, and repository artifacts | Provide the actual evidence surfaces to verify against |
 
 If required project docs are missing, surface that gap explicitly and limit confidence rather than guessing.
 
----
-
-## When To Use
+## When to Use
 
 | Trigger | Example request |
 | --- | --- |
@@ -43,15 +38,12 @@ If required project docs are missing, surface that gap explicitly and limit conf
 
 Use a specialist skill directly when the dominant question is already obvious:
 
-- `test-authoring` for executable verification strategy, stack-aware test selection, and test-writing decisions
+- `system-tester` for executable verification strategy, stack-aware test selection, and test-writing decisions
 - `code-audit` for code correctness, bug, risk, security, and boundary review
-- `parity` for repository drift across docs, platform instruction surfaces, skills, prompts, and summaries
-- `project-elevation` for forward-looking improvement and readiness planning
-- `analysis` for root-cause reasoning, trade-off evaluation, and requirement or decision analysis
+- `parity-audit` for repository drift across docs, platform instruction surfaces, skills, prompts, and summaries
+- `system-analysis` for root-cause reasoning, trade-off evaluation, and requirement or decision analysis
 - `api-design` for API, schema, interface, or boundary contract design and review
 
----
-
 ## Procedure
 
 ### Step 1 — Identify the verification target
@@ -86,12 +78,11 @@ Prefer the single strongest verification path unless the user explicitly asks fo
 
 | Dominant verification question | Route to |
 | --- | --- |
-| How should this be verified, tested, or regression-checked in the current stack? | `test-authoring` |
+| How should this be verified, tested, or regression-checked in the current stack? | `system-tester` |
 | Is this code correct, safe, consistent, and free of obvious bugs or boundary violations? | `code-audit` |
 | Does this API or interface contract match the docs, code, and boundary rules? | `api-design` |
-| Do the docs, platform instruction surfaces, skills, prompts, and repository artifacts still agree? | `parity` |
-| What should improve next, and how healthy or mature is this project at its current stage? | `project-elevation` |
-| Do the requirements, trade-offs, design decisions, or explanations hold up? | `analysis` |
+| Do the docs, platform instruction surfaces, skills, prompts, and repository artifacts still agree? | `parity-audit` |
+| Do the requirements, trade-offs, design decisions, or explanations hold up? | `system-analysis` |
 
 Example prompt shapes by verification category:
 
@@ -108,7 +99,7 @@ Example prompt shapes by verification category:
 
 When executable validation is required, choose the appropriate framework and commands from project docs and local repo conventions.
 
-Examples of the decision pattern:
+**Examples** of the decision pattern:
 
 - Go project -> use the Go testing approach documented in `testing.md`
 - Python project -> use the Python testing approach documented in `testing.md`
@@ -126,7 +117,20 @@ State:
 - what evidence and checks should be used
 - what remains outside the chosen verification path
 
----
+## Quality Check
+
+- No finding without evidence from the target artifact
+- No severity inflation
+- No style nitpicks disguised as bugs
+- No architecture complaint without reference to actual project boundaries
+- No recommendation that ignores project stage or available validation
+
+## Anti-Pattern
+
+- Calling something dead code without checking workspace usage
+- Calling something a bug without defining the failure condition
+- Criticizing a pattern that the project explicitly chose in `architecture.md`
+- Recommending wide rewrites before testing a local fix or a smaller boundary change
 
 ## Output Contract
 
@@ -141,33 +145,11 @@ When using this skill, the output should include:
 7. any residual risks or uncovered verification areas
 8. whether user direction is required before deciding between conflicting docs and implementation
 
----
-
-## Quality Checks
-
-- Route to the single best specialist skill unless the user explicitly asks for a broader sweep
-- Do not duplicate another skill's full procedure inside this skill
-- Do not assume frameworks or commands before checking the project docs
-- Keep executable and non-executable verification clearly separated
-- State when confidence is limited by missing docs or missing evidence
-- Do not assume docs or implementation win when the repository does not define authority for the disputed fact
-
----
-
-## Anti-Patterns
-
-- Treating verification as synonymous with writing tests
-- Hardcoding stack-specific frameworks into the skill text
-- Routing a docs-drift problem to `code-audit`
-- Routing a forward-looking improvement question to `analysis`
-- Running a multi-skill sweep by default when one dominant verification path would answer the request
-- Claiming the repository passed a check when the relevant evidence or command was never examined
-
----
-
-## Example Requests
+## Neutral Prompt Shape
+`@agent use code-audit on [Target File/Change] focusing on [Specific Risks/Boundaries].`
 
-- "Verify this feature against the project docs, contract, and actual code"
-- "Check whether this API matches the docs, code, and guideline standards"
-- "Evaluate this project for health, maturity, architecture drift, and consistency"
-- "Use the right verification approach for this stack and tell me what to run"
+## Example Prompt
+- "Audit this service for boundary violations"
+- "Review this change for correctness risks"
+- "Check this module for dead code and duplication"
+- "Audit this workflow implementation for operability gaps"

package/docs/templates/skills/db-schema-design/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: "db-schema-design"
+description: "Project-aware expert-role database schema and modeling design. Reads project docs first, then produces a schema design, migration plan, or query optimization strategy consistent with the current repository constraints."
+argument-hint: "Describe the domain entities, tables, relationships, or queries to design or review"
+---
+
+# Database Schema Design
+
+Produces a **project-aware, expert-level database schema design or review** by reading the repository's project docs first, then applying a rigorous data modeling method.
+
+This skill is reusable across:
+
+- Relational Databases (PostgreSQL, MySQL, Aurora, etc)
+- Document / NoSQL Databases (MongoDB, DynamoDB, etc)
+- In-memory / Cache Models (Redis, Memcache, etc)
+- Event Stores (Kafka, Pulsar, etc)
+
+It should **not** assume a specific database engine, ORM, or normalization strategy until the project docs confirm them.
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/project-docs/development/database.md` | Defines the actual database engines, ORMs, migration tools, naming conventions, and constraints. |
+| `docs/project-docs/foundation/architecture.md` | Defines where data logic lives (e.g., repository layer) and integration boundaries. |
+| `docs/project-docs/foundation/prd.md` | Clarifies the feature scale, expected data volume, and access patterns. |
+| `docs/project-docs/development/testing.md` | Defines how data layer code and migrations should be validated. |
+
+If the repository lacks the database docs needed for the task, call that out and create or update the missing docs instead of inventing local rules in the skill.
+
+## When to Use
+
+Use this skill when designing or reviewing one of these boundary types:
+
+| Boundary type | Typical artifacts |
+| --- | --- |
+| Schema Creation | Tables, columns, types, constraints, foreign keys, indexes |
+| Migrations | Up/Down migration scripts, data backfills, zero-downtime strategies |
+| Query Optimization | EXPLAIN plans, index selection, join reduction |
+| Data Modeling | Domain entities, aggregates, document embedding vs referencing |
+| Caching | Cache keys, TTL strategies, eviction policies |
+
+## Procedure
+
+### Step 1 — Identify the Engine and Tools
+Extract from `database.md`:
+- the primary database engine (e.g., Postgres 15)
+- the schema management/migration tool (e.g., Prisma, Flyway, Alembic)
+- the application access pattern (raw SQL vs Query Builder vs ORM)
+
+### Step 2 — Identify the Access Patterns
+Extract from `prd.md` and feature docs:
+- Read/Write ratios (is it write-heavy or read-heavy?)
+- Data volume expectations
+- Latency requirements
+- Multi-tenant data segregation rules (if any)
+
+### Step 3 — Design the Schema Shape
+Design the minimal schema that supports the required behavior.
+Specify:
+- Entity names and relationships (1:1, 1:N, M:N)
+- Strict data types (prefer specific types like `UUID` or `TIMESTAMPTZ` over generic strings if the engine supports it)
+- Constraints (NOT NULL, UNIQUE, CHECK)
+- Primary and Foreign keys
+
+### Step 4 — Define Indexing and Performance Strategies
+Define the indexes required for the access patterns identified in Step 2.
+- Consider composite indexes for multi-column queries.
+- Consider partial/filtered indexes for specific status queries.
+- Avoid over-indexing to protect write performance.
+
+### Step 5 — Design the Migration Plan
+Specify how the schema will be deployed safely:
+- Can this be applied without locking tables?
+- Does it require a multi-phase zero-downtime migration (e.g., Add column -> write to both -> backfill -> drop old column)?
+- How will the rollback (down migration) function?
+
+### Step 6 — Define Verification Requirements
+Use `testing.md` to decide how this will be validated.
+Examples:
+- Schema validation tests
+- Query performance benchmarks
+- Migration dry-run tests
+
+## Quality Check
+
+Use this checklist when reviewing an existing schema or PR:
+
+- Does the schema follow the project's naming conventions (e.g., snake_case vs camelCase)?
+- Are foreign keys properly enforcing referential integrity?
+- Are appropriate constraints in place to prevent bad data at the database level?
+- Will the migration lock a critical table in production?
+- Is there a clear separation between the database schema and the application's domain model?
+
+## Anti-Pattern
+
+- Assuming an ORM is used when the project strictly uses raw SQL.
+- Suggesting a heavy relational model for a project that uses a document database.
+- Proposing migrations that lock large tables (e.g., adding a column with a default value in older Postgres versions) without a zero-downtime strategy.
+- Ignoring data types and using strings for dates, JSON, or booleans.
+- Forgetting to define a rollback strategy for a destructive migration.
+
+## Output Contract
+
+When using this skill, the output should include:
+
+1. the database engine and tools being targeted
+2. the project docs consulted
+3. the proposed schema / entity model
+4. indexes and constraints
+5. the migration strategy and risk assessment
+6. verification strategy
+7. open questions regarding data volume or access patterns
+
+## Neutral Prompt Shape
+`@agent use db-schema-design on [Target Feature/Entity] focusing on [Specific Requirement/Database Type].`
+
+## Example Prompt
+- "Design the schema migration for the new order tracking feature."
+- "Optimize the indexing for this query based on read-heavy patterns."

package/docs/templates/skills/devops-ci-cd/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: "devops-ci-cd"
+description: "Project-aware expert-role for CI/CD pipeline design and implementation. Reads project docs first, enforces build caching, security gates, test execution, and deployment safety."
+argument-hint: "Describe the workflow, pipeline, or deployment stage to build or review"
+---
+
+# DevOps CI/CD
+
+Produces a **project-aware, expert-level CI/CD pipeline implementation** by reading the repository's project docs first, then applying robust deployment engineering practices.
+
+This skill is reusable across CI providers (GitHub Actions, GitLab CI, Jenkins) and deployment targets (AWS, GCP, Vercel, Kubernetes).
+
+It should **not** assume a specific CI provider or deployment strategy until the project docs confirm them.
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/project-docs/operations/ci-cd.md` | Defines the required CI provider, branch protection rules, required jobs, and deployment environments. |
+| `docs/project-docs/development/testing.md` | Defines which test suites must run and their coverage thresholds. |
+| `docs/project-docs/operations/security.md` | Defines required security scanning tools (SAST, DAST, dependency checks). |
+
+If the repository lacks the CI/CD docs needed for deployment, call that out and create or update the missing docs instead of blindly writing deployment scripts.
+
+## When to Use
+
+Use this skill when building or reviewing one of these boundary types.
+
+| Boundary type | Typical artifacts |
+| --- | --- |
+| Continuous Integration (CI) | Build scripts, linter checks, test runners, Docker builds. |
+| Continuous Deployment (CD) | Terraform/Pulumi execution, environment promotion, artifact publishing. |
+| Security & Compliance | Dependabot configuration, secret scanning, static analysis gates. |
+| Pipeline Optimization | Caching strategies, matrix builds, job parallelization. |
+
+## Procedure
+
+### Step 1 — Identify the Pipeline Engine and Target
+Extract from `ci-cd.md`:
+- The CI platform (e.g., GitHub Actions).
+- The deployment target (e.g., AWS ECS).
+- Authentication mechanisms (e.g., OIDC vs long-lived secrets).
+
+### Step 2 — Define the Build Matrix and Caching
+- Ensure language-specific dependencies (node_modules, pip cache, go mod cache) are aggressively cached to reduce build times.
+- If building Docker images, implement layer caching.
+
+### Step 3 — Enforce Testing and Security Gates
+Consult `testing.md` and `security.md`:
+- The pipeline MUST block merges if linters or tests fail.
+- The pipeline MUST block merges if critical security vulnerabilities are detected.
+
+### Step 4 — Implement Safe Deployment Strategies
+If deploying to production:
+- Ensure the pipeline respects environment segregation.
+- Implement rollback capabilities or canary/blue-green deployment steps if specified in `ci-cd.md`.
+- Never hardcode secrets in the pipeline file; always use the CI provider's secrets manager.
+
+### Step 5 — Verify Pipeline Robustness
+Ensure the pipeline:
+- Only triggers on appropriate branches or tags.
+- Has reasonable timeout limits to prevent hung jobs.
+- Cleans up temporary artifacts after execution.
+
+## Quality Check
+
+
+Use this checklist when reviewing an existing CI/CD configuration:
+
+- Are dependencies and build outputs being cached?
+- Are secrets injected securely via environment variables?
+- Does a failing test or linter correctly fail the entire job?
+- Is the deployment step locked down to specific branches or environments?
+- Are timeouts explicitly defined to prevent runaway costs?
+
+## Anti-Pattern
+
+- Hardcoding API keys or passwords directly in the YAML file.
+- Writing a pipeline that deploys to production from any branch.
+- Skipping tests to make the pipeline run faster.
+- Downloading dependencies without verifying lockfiles.
+
+## Output Contract
+
+When using this skill, the output should include:
+
+1. the project docs consulted
+2. the proposed pipeline architecture (triggers, jobs, steps)
+3. the caching and optimization strategies used
+4. the security and testing gates enforced
+5. the final pipeline YAML or script
+
+## Neutral Prompt Shape
+`@agent use devops-ci-cd on [Target Pipeline/Workflow] focusing on [Specific Optimizations/Security Gates].`
+
+## Example Prompt
+- "Create a GitHub Actions workflow that implements the CI caching strategy."
+- "Review this Jenkinsfile for security issues and hardcoded secrets."
+- "Design a deployment pipeline that supports blue-green rollout."

package/docs/templates/skills/observability/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: "observability"
+description: "Project-aware expert-role for system observability and SRE engineering. Reads project docs first, enforces structured logging, tracing context injection, PII masking rules, and actionable metric generation."
+argument-hint: "Describe the component, service, or workflow to instrument with observability"
+---
+
+# Observability
+
+Produces a **project-aware, expert-level observability implementation** by reading the repository's project docs first, then applying Site Reliability Engineering (SRE) standards for logging, metrics, and tracing.
+
+This skill is reusable across logging frameworks (Winston, Logback, Zap), tracing standards (OpenTelemetry), and telemetry backends (Prometheus, Datadog, ELK).
+
+It should **not** assume a specific logging library or metric format until the project docs confirm them.
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/project-docs/operations/observability.md` | Defines the required logging frameworks, metric standards, alerting thresholds, and tracing architectures. |
+| `docs/project-docs/operations/compliance.md` | Defines PII (Personally Identifiable Information) masking and data retention rules. |
+| `docs/project-docs/foundation/architecture.md` | Defines how context (e.g., request IDs, user IDs) flows across service boundaries. |
+
+If the repository lacks the observability docs needed to understand the current stack, call that out and create or update the missing docs instead of inventing arbitrary logging formats.
+
+## When to Use
+
+Use this skill when tasked with improving system visibility or instrumenting code.
+
+| Boundary type | Typical artifacts |
+| --- | --- |
+| Application Logging | Structured JSON logs, error stack traces, context injection. |
+| Distributed Tracing | Spans, span contexts, OpenTelemetry configuration. |
+| Application Metrics | Counters, gauges, histograms (e.g., request latency, error rates). |
+| Alerting & Dashboards | Prometheus rules, Datadog monitors, Grafana dashboard JSON. |
+
+## Procedure
+
+### Step 1 — Extract Standards
+Extract from `observability.md`:
+- The approved logging library.
+- Required log levels (e.g., `DEBUG` in dev, `INFO` in prod).
+- Required structured fields (e.g., `requestId`, `tenantId`).
+
+### Step 2 — Enforce Compliance and PII Masking
+Extract from `compliance.md`:
+- Identify fields that MUST NEVER be logged (e.g., passwords, credit card numbers, raw request bodies).
+- Implement redaction/masking at the logger configuration level if possible.
+
+### Step 3 — Instrument Tracing Context
+When instrumenting a request flow:
+- Ensure trace IDs (like `x-b3-traceid` or OpenTelemetry headers) are parsed at the entry point.
+- Ensure the trace ID is attached to ALL subsequent log emissions and downstream HTTP calls.
+
+### Step 4 — Define Actionable Metrics
+Instead of generic logs, emit actionable metrics for:
+- Throughput (requests per second).
+- Error rates (4xx vs 5xx).
+- Latency/Duration (histograms of processing time).
+
+### Step 5 — Standardize Error Handling
+When logging exceptions:
+- Always log the full stack trace for unhandled errors.
+- Do not swallow errors (e.g., `catch (e) { log(e.message) }` loses the stack trace).
+- Ensure the log distinguishes between client errors (validation) and server errors (crashes).
+
+## Quality Check
+
+Use this checklist when reviewing observability code:
+
+- Are logs structured (JSON) rather than plain text strings?
+- Is context (like Request ID) present in every log entry for a transaction?
+- Are sensitive fields (tokens, passwords, PII) explicitly redacted?
+- Are metrics using standardized naming conventions (e.g., snake_case for Prometheus)?
+- Are errors logged with stack traces and sufficient context to debug without guessing?
+
+## Anti-Pattern
+
+- `console.log()` or equivalent generic print statements in production code.
+- Logging the entire raw HTTP Request or Response object.
+- Silently swallowing exceptions without logging them.
+- Emitting high-cardinality data (like User IDs) as metric labels/tags instead of log fields.
+
+## Output Contract
+
+When using this skill, the output should include:
+
+1. the project docs consulted
+2. the instrumentation code (logging, tracing, or metrics)
+3. the structured payload shape being emitted
+4. the PII masking and security constraints verified
+5. how the new telemetry can be validated (e.g., local mock server, stdout check)
+
+## Neutral Prompt Shape
+`@agent use observability on [Target Service/Component] focusing on [Specific Metrics/Logs].`
+
+## Example Prompt
+- "Instrument this service with structured logging and trace context."
+- "Review this controller to ensure PII is masked before logging."
+- "Design Prometheus metrics for this asynchronous background job."