agentsclimarketplace

Docs components design

Skill onatm/agent-skills/docs-components-design

Skills for agents

Install
npx -y skills add onatm/agent-skills --skill docs-components-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Maintain technical design docs for services, components, workers, modules, and APIs. Use when implementation design, contracts, schema, integrations, runtime behavior, or operational concerns change.

SKILL.md

2.9 KB, as published. Nobody here has run it

Docs Components Design

Maintain technical design docs for implementation units. Put contracts, state, runtime behavior, and operational detail here rather than in feature or architecture docs.

Resource Map

  • Use assets/doc-starters/component-design-doc.md when creating or substantially rewriting a doc in docs/designs/.
  • Read references/component-design-example.md when you need a worked example of the expected technical depth.

When to Use

  • New service, worker, module, integration surface, or shared component
  • Changes to interfaces, contracts, schema, queues, state machines, or external integrations
  • Changes to concurrency, retries, failure handling, security boundaries, or operational behavior
  • Technical design updates that should not live in feature docs

Do Not Use

  • System or domain topology docs that belong in docs-architecture
  • User-facing feature behavior and goals that belong in docs-feature-design

Workflow

  1. Identify the implementation unit and current doc path.
  • Default location is docs/designs/
  • Reuse an existing design doc when one already exists
  1. Capture the technical shape of the change.
  • Problem and scope
  • Interfaces and contracts
  • Data model or state changes
  • Runtime behavior, failure modes, and operations
  • Security and ownership boundaries
  1. Keep feature and architecture boundaries clean.
  • Link to relevant feature docs instead of retelling the product story
  • Link to architecture docs instead of restating system topology
  1. Verify against the repo.
  • Commands, migrations, contracts, and runtime behavior match the current code
  • Design decisions still reflect the active implementation
  1. Trim low-value detail.
  • Avoid path dumps and copied code
  • Keep only the technical detail needed to understand and maintain the component

Writing Rules

  • Technical detail belongs here
  • Prefer concise summaries of contracts, schemas, and state over long pasted definitions
  • If one component supports multiple features, describe the reusable implementation capability rather than a single feature narrative
  • Make trade-offs, failure modes, and ownership explicit
  • The Technical Design sub-sections (Interfaces, Data Model, Runtime, Security) are a baseline — add domain-specific sections (Processing Flow, Algorithm, Examples, Configuration) at the same level when they clarify the design better than generic sub-sections would

Quality Checklist

  • The doc clearly names the component or service scope
  • Contracts, state, and runtime behavior are accurate
  • Operational and security details are current
  • Feature behavior is linked out rather than embedded
  • Architecture context is referenced rather than duplicated

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.