domain-docs

Locate and maintain package-level domain documentation in the OpenMeter repository.

2.2k|210|Updated Jun 6, 2023
One-click install
npx skills add https://github.com/openmeterio/openmeter --skill domain-docs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-docs
Source: https://github.com/openmeterio/openmeter/tree/main/.agents/skills/domain-docs
Command: npx skills add https://github.com/openmeterio/openmeter --skill domain-docs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Engineers working in the OpenMeter codebase often struggle to find authoritative documentation about product behavior, domain ownership, and cross-domain contracts, and package READMEs frequently become stale or bloated. This Skill routes domain work to the right package documentation and enforces standards for keeping it accurate and concise.

Core Features & Use Cases

  • Documentation Routing: Identifies the relevant package README for a task based on changed paths and domain ownership boundaries, such as billing, charges, ledger, or subscriptions.
  • Doc-Code Reconciliation: Guides interpretation when documentation and code disagree, treating contradictions as potential defects or stale docs rather than assuming either is correct.
  • README Authoring Standards: Provides rules for writing, revising, and placing domain READMEs, including what to include (invariants, contracts, lifecycle semantics) and what to omit (file inventories, filler, changelogs).
  • Use Case: During a code review of a subscription billing change, use this Skill to find the subscription, billing, and charges READMEs, verify the change does not falsify documented invariants, and update the affected README in the same change.

Quick Start

Use the domain-docs skill to find the relevant package domain documentation for the files changed in this pull request.

Frequently Asked Questions about domain-docs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find domain documentation for a code change in OpenMeter?

Start with the README at the package boundary nearest the changed code, then follow its links or inspect adjacent package READMEs when behavior crosses an ownership boundary. For example, charge lifecycle work starts in openmeter/billing/charges/README.md.

What should a package domain README include?

Include purpose and non-obvious vocabulary, ownership boundaries, invariants and their failure consequences, lifecycle and persistence semantics, contracts with neighboring domains, and intentional limitations. Omit file inventories, method catalogs, and generic repository conventions.

What should I do when documentation contradicts the code?

Neither automatically overrides the other. Code contradicting a documented invariant may be the defect under review, while docs contradicting established behavior may be stale. Resolve the discrepancy from surrounding code, tests, history, and the intended product outcome.

When should I not use domain documentation for a task?

Skip it for mechanical changes with no domain behavior, such as renames, formatting, or dependency bumps. The Skill is intended for work that depends on product behavior, domain ownership, or cross-domain contracts.

How large should a domain README be?

Treat roughly 200 lines or 12 KB as a signal to edit for focus, not as a hard quota. Keep one canonical explanation per topic and have other domains link to it rather than duplicating content.