feat(skill): cross-pollinate the new tool wave into catalog routing (#275)

* feat(skill): cross-pollinate the new tool wave into catalog routing

Wire the recent tool skill wave into the two-layer routing graph so the
new tool skills are reachable from the methodology skills that own their
domains, and vice versa:

- methodology -> tool down-routes: platform-engineering -> kubernetes,
  terraform, telemetry, postgres, grafana; site-reliability-engineering ->
  telemetry, grafana; data-engineering and backend-engineering -> postgres;
  frontend-engineering -> mobile-development; verification-methodology ->
  playwright, documents; technical-documentation -> documents
- neckbeard: add mobile-development and documents routing rows plus
  change-surface coverage entries, and cross-link the lightweight
  test-hardening path to qa-methodology's bounded mutation-review material
- collaboration layer: chief-of-staff-methodology -> slack/notion/email,
  go-to-market -> crm, conditional-customer-success -> crm; fix the dead
  seo-content-optimization reference in go-to-market (now seo-audit)
- references/skill-triggers.md: add trigger rows for the 14 new skills
- bring go-to-market's description up to the quality validator's
  imperative-verb + negative-boundary requirement and regenerate catalogs

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

* fix(skill): add eval manifest for technical-documentation

The eval-coverage ratchet fails on modified skills without a schema-valid
manifest once coverage passes 50%. technical-documentation was modified by
the routing cross-pollination change and lacked one; add six output-quality
cases covering README authorship, API reference generation, CLI help design,
agent-facing docs, documentation-site IA, and troubleshooting sections.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

---------

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

.claude-plugin/marketplace.json

@@ -390,7 +390,7 @@
         "./go-to-market"
       ],
       "strict": false,
-      "description": "CMO methodology — positioning and messaging frameworks (April Dunford's positioning, message hierarchy), customer acquisition strategy (paid, organic, PLG, SLG), brand architecture (brand house vs house of brands), growth modeling (CAC/LTV by channel, cohort analysis), market entry strategy (beachhead, land-and-expand), competitive response (pricing wars, feature races, brand defense)."
+      "description": "Plan and execute go-to-market strategy — positioning and messaging frameworks (April Dunford's positioning, message hierarchy), customer acquisition strategy (paid, organic, PLG, SLG), brand architecture (brand house vs house of brands), growth modeling (CAC/LTV by channel, cohort analysis), market entry strategy (beachhead, land-and-expand), and competitive response (pricing wars, feature races, brand defense). Do not use for sales execution and pipeline management, product strategy, or visual brand identity design."
     },
     {
       "name": "grafana",

backend-engineering/SKILL.md

@@ -50,6 +50,10 @@ Backend engineering is the craft of building the server-side systems that power
 |-----------|-------------|
 | `scripts/n1-query-spotter.py` | Scanning Python source for potential N+1 query patterns (query-like calls inside loops); `--json` for CI-friendly output, exit 1 on findings |
 
+## Related Skills
+
+- [postgres](../postgres/SKILL.md) — diagnosing the PostgreSQL side of a database problem: configuration review, index and query-plan issues, vacuum/bloat, backups/PITR, replication and failover. Application-level data access patterns stay here; engine-level operations route there.
+
 ## Core Principles
 
 **The interface is the contract** — API boundaries are service-level contracts. Every endpoint signature, request schema, response format, and error code is a promise to consumers. Breaking changes are coordination problems, not version bumps.

bundles/neckbeard/SKILL.md

@@ -179,6 +179,7 @@ When a stage has a specialist skill, load it and follow it. The full table with
 | Security review, threat modeling, secure design | `secure-software-engineering` |
 | Accessibility (WCAG, keyboard/focus, error recovery) | `web-accessibility` |
 | Test strategy, regression testing, CI quality gates | `qa-methodology` |
+| Mobile app implementation (iOS/Android/Flutter/React Native) | `mobile-development` |
 | Docs / README / API reference | `technical-documentation` |
 | Verification verdicts and evidence | `verification-methodology` |
 | Release planning, versioning, pipeline promotion, readiness, rollout, or rollback design | `release-engineering` |

bundles/neckbeard/references/lightweight-test-hardening.md

@@ -44,6 +44,14 @@ The minimum verification set is:
 - lint, compilation, and changed-scope checks pass; and
 - changed-file security and public-metadata checks pass.
 
+When the repository already has a mutation-testing setup, record the mutant
+evidence in `qa-methodology`'s bounded mutation-review format
+([templates/mutation-review.md](../../qa-methodology/templates/mutation-review.md))
+and follow its mutation-guided hardening methodology
+([references/test-automation.md](../../qa-methodology/references/test-automation.md)).
+The evidence contract above still governs; the mutation-review record is the
+format, not a relaxation of the thresholds.
+
 A full mutation campaign, full-repository scan, or broad integration run is not
 required by this subtype unless the changed surface or repository policy makes
 it relevant. Record any boundary that was not exercised.

bundles/neckbeard/references/routing-table.md

@@ -46,12 +46,18 @@ defaults without qualification.
 | `programming-principles` | Change is primarily a refactoring (files renamed/moved/split without behavior change), code-review request, or quality assessment; diff touches many files with structural reorganization | Change is greenfield implementation or a targeted bug fix; no structural reorganization, review request, or quality assessment is the primary objective | Contract, ledger, boundary verification |
 | `backend-engineering` | Change modifies server-side logic, service architecture (clean/hexagonal/layered), database access patterns, API implementation code, middleware, or service-to-service integration | No server-side logic, service architecture, database access pattern, API implementation, middleware, or integration code is modified | Contract, ledger |
 | `frontend-engineering` | Change modifies client-side application code, component hierarchy, state management, browser APIs, or UI rendering logic | No client-side application code, component, state management, browser API, or UI rendering logic is modified | Contract, ledger |
+| `mobile-development` | Change creates or modifies mobile app source for iOS, Android, Flutter, or React Native (`*.swift`, Kotlin sources, Flutter `lib/` Dart files, React Native components and Metro config) | No mobile app source file is created or modified; the change is web frontend or backend only | Contract, ledger |
+| `documents` | A deliverable is required in office-document format (PDF, Word, Excel, PowerPoint) for human stakeholders — a report, memo, spreadsheet, or deck generated from the change | The deliverable is markdown or the repository's native format; no office-format artifact is requested | Contract, ledger |
 | `cli-builder` | Change creates or modifies a command-line interface: argument parsing, flag design, subcommands, `--json` output, `--dry-run` preview, or exit-code contracts | No CLI argument parsing, flag, subcommand, or CLI output contract is created or modified | Contract, ledger |
 | `data-engineering` | Change modifies database schemas, migration files (`migrations/`, `*.sql`), ETL/ELT pipelines, data quality checks, or analytical SQL | No schema, migration file, ETL/ELT pipeline, data quality check, or analytical SQL is created or modified | Contract, ledger |
 | `data-architect` | Change requires a data-model design artifact, storage-platform evaluation, data-governance definition (ownership, lineage, cataloging), or cross-system data-flow diagram before implementation | No data-model artifact, storage-platform evaluation, data-governance definition, or cross-system data-flow design is required; schema changes are mechanical | Contract, ledger |
 | `agent-evals-and-observability` | Change modifies AI/agent behavior: eval definitions, agent task contracts, grader bindings, trajectory fixtures, prompt templates, or agent observability/telemetry | No agent eval, task contract, grader, trajectory fixture, prompt template, or agent telemetry is created or modified | Contract, ledger |
 | `opensource-contributions` | **Conditional — public/OSS repos only.** Repository remote is public, an open-source license is present, and a `CONTRIBUTING.md` or equivalent contribution governance file exists (verify via repo remote or `gh api`); contribution norms, agent disclosure, or fork etiquette apply | Repository is private or enterprise-internal (non-public remote, no open-source license); record skip as "non-public repository." Also skip when no contribution-norm question arises even in a public repo | Contract, ledger |
 
+## Test-hardening evidence
+
+When the change is a focused regression guard for already-correct production behavior (the lightweight test-hardening path, [lightweight-test-hardening.md](lightweight-test-hardening.md)), the `qa-methodology` row supplies the evidence format: use its bounded mutation-review record ([templates/mutation-review.md](../../qa-methodology/templates/mutation-review.md)) and mutation-guided hardening methodology ([references/test-automation.md](../../qa-methodology/references/test-automation.md)) when the repository already runs mutation testing. The lightweight-path contract still governs applicability and evidence thresholds.
+
 ## Change-surface coverage
 
 Every mandated change surface maps to at least one row above. When a change
@@ -65,7 +71,9 @@ signal triggers:
 | Architecture | `software-architecture-analysis`, `c4-diagramming`, `adr-authoring` |
 | API/interface | `api-design-and-evolution` |
 | Data (schema/migration) | `data-engineering`, `data-architect` |
-| Implementation domain | `backend-engineering`, `frontend-engineering`, `cli-builder` |
+| Implementation domain | `backend-engineering`, `frontend-engineering`, `mobile-development`, `cli-builder` |
+| Mobile app code | `mobile-development` |
+| Office-format deliverables | `documents` |
 | Security | `secure-software-engineering`, `security-audit-methodology` |
 | AI/agent behavior | `agent-evals-and-observability` |
 | Documentation | `technical-documentation` |

chief-of-staff-methodology/SKILL.md

@@ -147,6 +147,9 @@ professionals for matters in their remit.
 - `product-methodology` for product decisions and prioritization.
 - `strategy-frameworks` for strategy choices and trade-offs.
 - `verification-methodology` for evidence-backed completion claims.
+- `slack` — channel triage and message search through the Slack Web API; confirmed posting only. The everyday read layer for "what was said, find it later."
+- `notion` — knowledge search, page and database reads through the Notion API; confirmed edits only.
+- `email` — transactional email sends and delivery verification (bounces, spam reports, event-webhook signature check) through SendGrid. Read-only discovery before any send.
 
 ## Portability
 

conditional-customer-success/SKILL.md

@@ -249,6 +249,7 @@ directories, or prose references for skills not yet landed.
 | [../product-adoption/SKILL.md](../product-adoption/SKILL.md) | Onboarding, activation, behavior change, feature discovery, sustained use | Provides adoption signals (activation, feature adoption, sustained use) as health dimensions |
 | [../product-experimentation/SKILL.md](../product-experimentation/SKILL.md) | Experiment design, readout, ship/no-ship decisions | Consumed when CS evidence suggests an experiment (e.g., intervention test for at-risk accounts) |
 | [../go-to-market/SKILL.md](../go-to-market/SKILL.md) | Acquisition campaigns, marketing conversion | Does NOT own. CS consumes acquisition context only. |
+| [../crm/SKILL.md](../crm/SKILL.md) | HubSpot CRM operations — contact records, deal pipeline views, confirmed deal stage changes | Provides account records and pipeline/health context for health/risk records and QBR preparation |
 
 ### Routes to (prose references — skills not yet landed)
 

data-engineering/SKILL.md

@@ -42,6 +42,10 @@ Data engineering is the operational backbone of data-driven systems. This method
 | `references/database-migrations.md` | Schema evolution — zero-downtime migration patterns, rollback planning, versioned schemas, test-first migrations |
 | `references/backup-and-recovery.md` | Backup strategies per data store type, RPO/RTO planning, WAL archiving, snapshot management, recovery plan template |
 
+## Related Skills
+
+- [postgres](../postgres/SKILL.md) — operating a PostgreSQL server itself: configuration review, index and query-plan diagnosis, vacuum/bloat management, WAL archiving and point-in-time recovery, replication and failover, upgrades. This skill owns the engine-specific runbooks; data-engineering owns the engine-neutral methodology.
+
 ## Core Principles
 
 **Data without integrity is noise** — No pipeline, model, or dashboard is worth more than the quality of the data feeding it. Validate at every boundary.

frontend-engineering/SKILL.md

@@ -27,6 +27,7 @@ Frontend engineering is the craft of building the user-facing layer of applicati
 | Client-side performance — bundle optimization, lazy loading, Core Web Vitals, render optimization | Editorial content and copy — owned by the content and marketing team, outside this skill's scope |
 | Frontend testing — component tests, integration tests, visual regression, accessibility tests | Code review and quality gates — that's the qa-methodology |
 | E2E test scenarios and user-flow coverage for frontend features | Operating the browser test tool (Playwright) — authoring/running specs, selectors, network mocking, scraping — route to [playwright](../playwright/SKILL.md) |
+| Mobile app implementation (iOS/Android/Flutter/React Native) | Mobile platform work — scaffolding, builds and code signing, device/emulator testing, store submission, mobile lifecycle — route to [mobile-development](../mobile-development/SKILL.md); this skill owns web frontends |
 | Build tooling — bundler config, TypeScript config, linting, formatting, dev environment | CI/CD pipeline infrastructure — that's the platform-engineer |
 
 ## Reference Files

go-to-market/SKILL.md

@@ -1,10 +1,11 @@
 ---
 name: go-to-market
-description: CMO methodology — positioning and messaging frameworks (April Dunford's
+description: Plan and execute go-to-market strategy — positioning and messaging frameworks
-  positioning, message hierarchy), customer acquisition strategy (paid, organic, PLG,
+  (April Dunford's positioning, message hierarchy), customer acquisition strategy (paid,
-  SLG), brand architecture (brand house vs house of brands), growth modeling (CAC/LTV
+  organic, PLG, SLG), brand architecture (brand house vs house of brands), growth modeling
-  by channel, cohort analysis), market entry strategy (beachhead, land-and-expand),
+  (CAC/LTV by channel, cohort analysis), market entry strategy (beachhead, land-and-expand),
-  competitive response (pricing wars, feature races, brand defense).
+  and competitive response (pricing wars, feature races, brand defense). Do not use for
+  sales execution and pipeline management, product strategy, or visual brand identity design.
 license: MIT
 metadata:
   tags: go-to-market, cmo, marketing, positioning, messaging, acquisition, brand-architecture,
@@ -49,9 +50,17 @@ skill_view('go-to-market', file_path='references/growth-modeling.md')
 
 The profile using this skill produces artifact pyramids. The response to any caller is the absolute path to `00-index.md`. See `artifact-pyramids` skill for the specification.
 
+## When not to use
+
+- **Sales execution and pipeline management** — this skill owns acquisition *strategy*, not running the funnel. CRM operations (contact lookup, deal pipeline views, confirmed stage changes) belong to [crm](../crm/SKILL.md).
+- **Product strategy and roadmap** — product vision, PMF, and prioritization belong to `product-strategy` and `product-methodology`.
+- **Visual brand identity design** — logo, palette, and brand systems belong to `brand-designer`.
+- **Marketing campaign execution** — this skill defines the channel strategy and positioning; operating the channel tools is the corresponding tool skill's job.
+
 ## Related Skills
 
-- `artifact-pyramids` — output contract
+- [artifact-pyramids](../artifact-pyramids/SKILL.md) — output contract
-- `product-strategy` — CPO methodology (product vision, PMF, market sizing)
+- [product-strategy](../product-strategy/SKILL.md) — CPO methodology (product vision, PMF, market sizing)
-- `brand-designer` — visual brand identity design
+- [brand-designer](../brand-designer/SKILL.md) — visual brand identity design
-- `seo-content-optimization` — organic search and content strategy
+- [seo-audit](../seo-audit/SKILL.md) — organic search audit and content strategy
+- [crm](../crm/SKILL.md) — HubSpot CRM operations: contact lookup, deal pipeline views, and confirmed deal stage changes

llms.txt

@@ -44,7 +44,7 @@
 - [frontend-engineering](frontend-engineering/SKILL.md): Build and maintain web frontends — component architecture, state management, API integration, responsive layout, client-side performance, and frontend testing patterns. Framework agnostic, focused on web frontend implementation. Do not use for backend service implementation, data engineering, or platform infrastructure work.
 - [ghost-cli](ghost-cli/SKILL.md): Manage Ghost CMS content from the terminal — create and list posts, pages, and tags, and fetch site info via the Ghost Admin API (v5/v6). Use when the user asks about ghost, cms, blog, blogging, posts, pages, tags, publishing, or site configuration.
 - [github-runner](github-runner/SKILL.md): Deploy, manage, and troubleshoot self-hosted GitHub Actions runners. Covers systemd service, Docker containers, Kubernetes (Actions Runner Controller), and the Scale Set Client. Use when setting up a CI runner, debugging registration failures, designing autoscaling, or hardening runner security.
-- [go-to-market](go-to-market/SKILL.md): CMO methodology — positioning and messaging frameworks (April Dunford's positioning, message hierarchy), customer acquisition strategy (paid, organic, PLG, SLG), brand architecture (brand house vs house of brands), growth modeling (CAC/LTV by channel, cohort analysis), market entry strategy (beachhead, land-and-expand), competitive response (pricing wars, feature races, brand defense).
+- [go-to-market](go-to-market/SKILL.md): Plan and execute go-to-market strategy — positioning and messaging frameworks (April Dunford's positioning, message hierarchy), customer acquisition strategy (paid, organic, PLG, SLG), brand architecture (brand house vs house of brands), growth modeling (CAC/LTV by channel, cohort analysis), market entry strategy (beachhead, land-and-expand), and competitive response (pricing wars, feature races, brand defense). Do not use for sales execution and pipeline management, product strategy, or visual brand identity design.
 - [grafana](grafana/SKILL.md): Operate, configure, provision, secure, and troubleshoot Grafana OSS, Enterprise, and Cloud, including dashboards, folders, data sources, annotations, alert rules, contact points, notification policies, silences, mute timings, service accounts, RBAC, plugins, APIs, and as-code workflows. Use for Grafana product work and Grafana-side integrations. Do not use for defining SLOs or paging policy, operating Prometheus/Loki/Tempo/InfluxDB backends, generic Docker/Kubernetes/Terraform/reverse-proxy work, plugin development, or authorized security assessments; use the corresponding specialist skill.
 - [gutenberg](gutenberg/SKILL.md): Search, download, and extract public-domain books from Project Gutenberg. Look up books by ID or keyword via gutendex, download plain-text and EPUB editions, strip licensing boilerplate, extract clean text from EPUB for illustrated works, and classify fiction vs non-fiction. Ships a portable CLI script with zero external dependencies. Use when the user says "gutenberg", "public domain", "download a book", "classic literature", "free ebook", "gutenberg.org", or names any public-domain title or author.
 - [haystack](haystack/SKILL.md): Expert skill for production search and NLP pipelines with Haystack (deepset). Pipeline DAG composition, document stores, retrievers, PromptBuilder (Jinja2), generators, evaluation, Hayhooks deployment. Use when building search pipelines or comparing NLP application frameworks.

platform-engineering/SKILL.md

@@ -23,9 +23,11 @@ Load this skill when the task involves:
 |---------|---------------|
 | Design a CI/CD pipeline | Pipeline structure, GitOps sync strategies, release automation |
 | Infrastructure as code plan | Terraform/OpenTofu module patterns, state management, Pulumi/Ansible patterns |
-| Container orchestration design | K8s pod lifecycle, Helm chart conventions, Kustomize overlays, Docker Compose |
+| Container orchestration design | K8s pod lifecycle, Helm chart conventions, Kustomize overlays, Docker Compose; operating a cluster (manifests, RBAC, workloads, upgrades) routes to [kubernetes](../kubernetes/SKILL.md) |
 | Service networking / mesh | Traefik/nginx/Caddy config, Tailscale/Headscale ACL, WireGuard, service mesh |
-| Observability strategy | Prometheus rules, Grafana dashboards-as-code, Loki logging, tracing |
+| Observability strategy | Prometheus rules, Grafana dashboards-as-code, Loki logging, tracing; operating the Prometheus/OTel/Loki stack (scrape, rules, retention) routes to [telemetry](../telemetry/SKILL.md), Grafana product work routes to [grafana](../grafana/SKILL.md) |
+| Infrastructure execution | Terraform/OpenTofu plan/apply workflow, state backends, drift detection, upgrades — route to [terraform](../terraform/SKILL.md) |
+| PostgreSQL operations | Server config review, indexes and query plans, vacuum/bloat, backups/PITR, replication — route to [postgres](../postgres/SKILL.md) |
 | Secret management design | Vault, SOPS, External Secrets Operator patterns |
 | Cloud architecture assessment | Multi-cloud patterns, provider foundations, cost governance |
 | Deployment pipeline review | Delivery-platform architecture; load [release-engineering](../release-engineering/SKILL.md) when defining the release model, promotion gates, rollout, or rollback policy |
@@ -95,6 +97,11 @@ The profile using this skill produces artifact pyramids. The response to any cal
 
 - `artifact-pyramids` — output contract specification
 - `docker-compose` — container lifecycle and multi-container Compose orchestration
+- `kubernetes` — cluster operations: manifests, RBAC, workloads, Helm, upgrades, troubleshooting
+- `terraform` — Terraform/OpenTofu execution: plan/apply workflow, state backends and locking, drift detection, upgrades and refactors
+- `telemetry` — Prometheus/OpenTelemetry Collector/Loki stack operations: scrape configs, rules files, retention, HA
+- `postgres` — PostgreSQL operations: configuration review, index and query-plan diagnosis, vacuum/bloat, backups/PITR, replication and failover
+- `grafana` — Grafana product work: dashboards, panels, data sources, alert rules, contact points, notification policies
 - `traefik` — reverse proxy and ingress configuration
 - `tailscale` — mesh networking and ACL policies
 - `implementation-planning` — work breakdown and dependency ordering

references/skill-triggers.md

@@ -96,3 +96,15 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "accessibility", "a11y", "WCAG", "ARIA", "accessible name", "screen reader", "keyboard navigation", "focus management", "focus trap", "dialog", "modal", "combobox", "listbox", "accessible form", "form validation", "error recovery", "accessible authentication", "color contrast", "reduced motion", "target size", "accessibility testing" | [web-accessibility](../web-accessibility/SKILL.md) |
 | "seo-audit", "seo audit" | [seo-audit](../seo-audit/SKILL.md) |
 | "test strategy", "regression testing", "CI failure triage", "test automation", "quality gates", "risk-based testing", "exploratory testing", "SDET", "agentic evals", "acceptance criteria testability", "QA career levels", "test design techniques", "P×I scoring", "SBTM charter", "flaky test quarantine", "mutation-guided test hardening", "surviving mutants", "mutation review evidence", "weak assertions revealed by mutation analysis", "diff-aware mutation testing" | [qa-methodology](../qa-methodology/SKILL.md) |
+| "Terraform", "OpenTofu", "terraform plan", "terraform apply", "terraform state", "terraform modules", "terraform backend", "drift detection", "infrastructure drift", "terraform upgrade", "terraform refactor", "tfops" | [terraform](../terraform/SKILL.md) |
+| "Prometheus", "prometheus.yml", "scrape config", "PromQL", "promtool", "OpenTelemetry Collector", "OTLP", "Loki", "LogQL", "telemetry stack", "Loki retention", "prometheus rules", "telemetry-check" | [telemetry](../telemetry/SKILL.md) |
+| "PostgreSQL", "postgres", "psql", "pg_stat_activity", "vacuum", "bloat", "WAL archiving", "point-in-time recovery", "postgres replication", "postgres failover", "postgres upgrade", "pgdiag", "PostgreSQL configuration" | [postgres](../postgres/SKILL.md) |
+| "Playwright", "E2E test", "end-to-end test", "headless browser", "browser automation", "Playwright config", "selectors", "network mocking", "pwrun" | [playwright](../playwright/SKILL.md) |
+| "vLLM", "LLM serving", "inference server", "continuous batching", "tensor parallelism", "OpenAI-compatible API", "vLLM deployment", "GPU inference", "LLM benchmarking" | [vllm](../vllm/SKILL.md) |
+| "PDF", "Word document", "docx", "Excel", "xlsx", "PowerPoint", "pptx", "generate a report", "convert to PDF", "office document", "document validation", "generate a deck" | [documents](../documents/SKILL.md) |
+| "mobile app", "iOS app", "Android app", "Flutter", "React Native", "App Store submission", "Play Store", "code signing", "Xcode", "emulator", "push notifications", "offline sync", "mobile testing" | [mobile-development](../mobile-development/SKILL.md) |
+| "Slack", "Slack channel", "Slack message", "Slack search", "Slack thread", "post to Slack", "slack-cli", "Slack Web API" | [slack](../slack/SKILL.md) |
+| "Notion", "Notion page", "Notion database", "Notion search", "notion-cli", "Notion API", "query Notion", "edit Notion" | [notion](../notion/SKILL.md) |
+| "SendGrid", "transactional email", "send email", "email deliverability", "bounced email", "spam report", "email webhook", "email-cli", "event webhook signature" | [email](../email/SKILL.md) |
+| "HubSpot", "CRM", "contact lookup", "deal pipeline", "pipeline view", "move a deal", "crm-cli", "HubSpot contact" | [crm](../crm/SKILL.md) |
+| "Stripe", "account balance", "payment intent", "subscription", "cancel subscription", "stripe-cli", "Stripe payments", "payment status" | [stripe](../stripe/SKILL.md) |

site-reliability-engineering/SKILL.md

@@ -26,7 +26,7 @@ A comprehensive methodology for designing, operating, and improving reliable pro
 | "Automate this operational task" | Toil assessment, automation decision tree, runbook pattern |
 ## When not to use
 
-Use [release-engineering](../release-engineering/SKILL.md) to plan releases, compose promotion and rollback gates, or coordinate a release train. Use [systematic-debugging](../systematic-debugging/SKILL.md) to find the cause of a specific failure.
+Use [release-engineering](../release-engineering/SKILL.md) to plan releases, compose promotion and rollback gates, or coordinate a release train. Use [systematic-debugging](../systematic-debugging/SKILL.md) to find the cause of a specific failure. Operating the telemetry stack itself — Prometheus scrape configs, OpenTelemetry Collector pipelines, Loki ingest and retention, Prometheus rules files — belongs to [telemetry](../telemetry/SKILL.md); this skill owns the SLI/SLO and alert *design* those rules implement. Grafana product work — dashboards, panels, Grafana-side alert rules, contact points, notification policies — belongs to [grafana](../grafana/SKILL.md).
 
 ## Reference Files
 

technical-documentation/SKILL.md

@@ -33,6 +33,10 @@ Technical documentation is the interface between a tool and its user. This metho
 | `references/agent-facing-docs.md` | Writing AGENTS.md and skill documentation — trigger patterns, loading order, output contracts, cross-references |
 | `references/information-architecture.md` | Structuring a documentation site — progressive disclosure, cross-referencing, search optimization, maintenance strategy |
 
+## Related Skills
+
+- [documents](../documents/SKILL.md) — producing office-format deliverables (PDF, Word, Excel, PowerPoint) from documentation content; doc-site and markup conventions stay here.
+
 ## Core Principles
 
 **Document the interface, not the implementation** — Users need to know what a function does, what it expects, and what it returns. How it works internally is for the source code.

technical-documentation/evals/evals.json

@@ -0,0 +1,78 @@
+{
+  "schema_version": 1,
+  "skill_name": "technical-documentation",
+  "evals": [
+    {
+      "id": "readme-quickstart",
+      "prompt": "I am writing a README for a small CLI tool that parses CSV files. What should the README contain and how should it be structured so a new user can go from zero to running the tool?",
+      "expected_output": "A README structured around getting the reader from install to first successful run: a one-paragraph project overview that states what the tool does (and does not do), the installation command, a minimal quickstart showing the exact command a new user runs with realistic sample input and output, then configuration options and common usage examples with every flag documented, then troubleshooting notes for the failures users actually hit, and finally pointers to related docs. The quickstart comes before the deep reference because the reader's first question is 'does this solve my problem and how do I run it?' Each example shows the command and its output so the reader can verify they are on track. The README documents the interface — flags, exit codes, file formats — not the implementation internals.",
+      "assertions": [
+        "The response opens with a short project overview and what the tool does and does not do",
+        "The response places a minimal quickstart with a real command and sample output before deep reference material",
+        "The response documents every flag, option, and exit code with worked examples",
+        "The response includes troubleshooting for failures users actually encounter",
+        "The response documents the interface rather than internal implementation"
+      ]
+    },
+    {
+      "id": "api-reference-generation",
+      "prompt": "We have a REST API with endpoints for creating and listing invoices and we want to document it. Our OpenAPI spec already exists. What does a good API reference look like and how do we generate and maintain it?",
+      "expected_output": "An API reference that is generated from the OpenAPI spec so it cannot drift from the implementation: a live preview or docs-as-code build that renders the spec, with a CI check that fails when the spec is out of sync with the code. Each endpoint page documents the URL and method, path and query parameters with types and defaults, request and response body examples, error responses with status codes and what each one means, and authentication requirements. Examples are concrete: a real request with a bearer token and the exact JSON response. The response covers keeping examples current by generating them from tests or fixtures, and explains when hand-written prose still adds value beyond the generated reference, such as conceptual guides that tie endpoints together.",
+      "assertions": [
+        "The response generates the reference from the OpenAPI spec and keeps it in sync via CI",
+        "The response covers path/query parameters, request and response examples, error codes, and auth per endpoint",
+        "The response uses concrete request and response examples rather than placeholders",
+        "The response keeps examples current by generating them from tests or fixtures",
+        "The response distinguishes generated reference pages from hand-written conceptual guides"
+      ]
+    },
+    {
+      "id": "cli-help-design",
+      "prompt": "We are designing the help output and man page for a CLI tool with subcommands (e.g. a deployment tool with deploy, rollback, status). What is good CLI help text and how do we structure the usage line, flags, and subcommand hierarchy?",
+      "expected_output": "A CLI help design centered on a usage line that teaches the command shape at a glance: the executable name, required positionals in order, and optional flags with their abbreviated forms (for example 'myctl deploy <environment> [--tag TAG] [--dry-run]'). The top-level help lists subcommands with one-line descriptions that say what each does and when to use it, and each subcommand's help repeats the full usage line, documents every flag with its type and default, and shows a concrete example. Exit codes are documented as part of the contract. Flag naming is consistent (verb-first subcommands, kebab-case long flags), help text stays one screen per command, and a man page mirrors the same structure for offline reading. The response calls out that help text is a user interface and should be treated with the same care as any other surface.",
+      "assertions": [
+        "The response designs a usage line that teaches the command shape with required positionals and optional flags",
+        "The response structures the subcommand hierarchy with one-line descriptions per subcommand",
+        "The response documents every flag with type and default plus a concrete example per subcommand",
+        "The response documents exit codes as part of the CLI contract",
+        "The response keeps help scannable and treats it as a user interface surface"
+      ]
+    },
+    {
+      "id": "agent-facing-docs",
+      "prompt": "Our repository is going to be worked on by AI agents and we want to write an AGENTS.md. What should it contain and how should it be written so an agent can operate effectively without being told everything every time?",
+      "expected_output": "An AGENTS.md written for the agent as a reader: it states the repository's conventions that affect behavior (commands to run for tests, lint, and builds; where configuration lives; how changes are validated; what not to touch), points to canonical references instead of repeating them, and uses trigger-oriented descriptions so the agent knows when to load which documentation or skill. Instructions are imperative and specific ('run make validate before committing', 'python3 -m pytest tests/ -q') rather than advisory. The file is kept short and layered — a top-level file with the always-relevant rules and deeper references for special cases — because an agent loads it on every session and context is finite. The response avoids duplicating what already exists in README or CONTRIBUTING and instead links to them, and it documents the output contract the repo expects from agent work.",
+      "assertions": [
+        "The response targets the agent as the reader with imperative, specific instructions",
+        "The response documents concrete commands for tests, lint, build, and validation",
+        "The response keeps the file short and layered with progressive disclosure for special cases",
+        "The response links to existing docs instead of duplicating README or CONTRIBUTING content",
+        "The response uses trigger-oriented descriptions so the agent knows when to load deeper material"
+      ]
+    },
+    {
+      "id": "doc-site-ia",
+      "prompt": "Our docs site has grown to 200 pages and readers keep getting lost. How should we structure the information architecture, cross-referencing, and search so the right page surfaces fast?",
+      "expected_output": "An information architecture plan organized around reader tasks rather than the internal org chart: a small set of top-level sections that mirror the main questions readers bring (getting started, guides by task, reference, troubleshooting), with progressive disclosure so overview pages summarize and link to deep dives instead of dumping everything inline. Cross-referencing follows a rule: link a concept at its first meaningful mention and link to the reference from every guide that uses it, so there is exactly one canonical page per concept and guides point at it. Search is designed for the content model — good titles and headings that match query vocabulary, redirects from old names, and no orphan pages (every page reachable from a section index). The response covers a maintenance convention: a page without an owner or an in-link is a candidate for deletion, because every doc is a liability.",
+      "assertions": [
+        "The response organizes IA around reader tasks with a small set of top-level sections",
+        "The response applies progressive disclosure with overviews linking to deep dives",
+        "The response defines a cross-referencing rule with one canonical page per concept",
+        "The response designs search around titles and headings matching query vocabulary with no orphan pages",
+        "The response includes a maintenance convention for pruning pages without owners or in-links"
+      ]
+    },
+    {
+      "id": "troubleshooting-doc",
+      "prompt": "Users keep hitting the same error when they configure our tool: the service fails to start with a certificate error. Write a troubleshooting section that actually helps them.",
+      "expected_output": "A troubleshooting section that opens with the symptom the reader is searching for — the exact error message or a plain-language version of it — and walks through the most likely cause to the fix: check that the certificate file path in the config matches the location named in the error, verify the file is in PEM format, confirm the CA bundle includes the issuing chain, and restart with the corrected config. Each step states what success looks like so the reader knows when they are done. The section shows the exact commands to run and the expected output for the healthy case, distinguishes the common misconfiguration from the rarer ones (expired certificate, hostname mismatch), and links to the config reference for the full option list. The fix steps are ordered by likelihood and cost so the reader tries the cheapest fix first.",
+      "assertions": [
+        "The response opens with the exact symptom and a plain-language error description",
+        "The response orders fix steps by likelihood and cost with the cheapest fix first",
+        "The response shows the exact commands and what success looks like after each step",
+        "The response distinguishes the common cause from rarer alternatives like expiry or hostname mismatch",
+        "The response links to the full configuration reference rather than duplicating it"
+      ]
+    }
+  ]
+}

verification-methodology/SKILL.md

@@ -38,6 +38,11 @@ Example: for “What’s new on Jellyfin?” in an environment with a configured
 
 Do not use this skill for open-ended exploration that has no artifact, claim, decision, or observable completion criterion. Use a research or discovery skill first, then return here when there is something falsifiable to verify.
 
+## Related Skills
+
+- [playwright](../playwright/SKILL.md) — browser-based E2E checks as a verification instrument: authoring and running specs against the real UI boundary.
+- [documents](../documents/SKILL.md) — producing verification reports or evidence packets as PDF/Word/Excel/PowerPoint deliverables.
+
 ## Reference Files
 
 | Reference | When to load |