writing-comments

Solid

How to write JSDoc (/** */) and inline (//) comments in the Astro codebase, for contributors reading the source — not end users. Use whenever writing or editing comments in .ts/.js source, including comments added incidentally while fixing bugs or building features. Does not cover the @docs-generated config/error reference.

Web & Frontend 55 stars 2 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
58
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Writing Comments ## Purpose Comments in this repository are read by contributors, months or years after they were written, with none of the context you have right now. This skill defines who that reader is, what each kind of comment is for, and which patterns are banned. ## Scope Boundary This skill governs **contributor-facing** comments in the TypeScript/JavaScript source. It does **not** apply to end-user documentation: - JSDoc blocks tagged `@docs` in [`packages/astro/src/types/public/config.ts`](../../../packages/astro/src/types/public/config.ts) and [`packages/astro/src/core/errors/errors-data.ts`](../../../packages/astro/src/core/errors/errors-data.ts) are scraped by an external `docgen` tool and published to the Astro docs website. Follow [`packages/astro/src/core/errors/README.md`](../../../packages/astro/src/core/errors/README.md) for those, and get docs-team review — CI regenerates the reference when `types/public/**` changes. - Other JSDoc across `types/public/**` is surfaced to users through editor IntelliSense. Write it for Astro **users** building a site, not for contributors reading the source. Everything below is about the source a contributor reads at HEAD. ## The Reader Write for an Astro contributor who is competent in TypeScript but has **no access to your current context**: not this conversation, not the pull request, not the issue, not the diff. They see only the repository at HEAD. Two consequences follow directly: 1. **...

Details

Author
modem-dev
Repository
modem-dev/ossrules
Created
1 weeks ago
Last Updated
5 days ago
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

doc-comments

Use this skill whenever writing or editing Rust `//`, `///`, or `//!` comments in Biome, including comments added incidentally and end-user rustdoc inside lint/assist declarations. For lint/assist rustdoc, also load lint-rule-development for content requirements. Do not use for formatter handling of comments in user code.

55 Updated 5 days ago
modem-dev
Data & Documents Listed

comment-conventions

Language-agnostic code commenting and docblock conventions. Trigger on every source-code Edit/Write in any language (JS/TS, Python, PHP, Ruby, Go, Rust, Java, Kotlin, Swift, C/C++, C#, Elixir, Lua, Shell, etc.) — even when the user has not mentioned comments, docblocks, JSDoc/TSDoc/PHPDoc, docstrings, or documentation. Governs every comment authored or modified, every new function/method/class/component (which must get a compliant docblock), every inline comment (which must stay terse — no prose walls, no business-logic essays, no "step 1 / step 2" narration in the code path), and any non-compliant docblock encountered in the file being edited (which must be fixed in place — no need to ask first, except when the existing docblock is unusually long and clearly intentional, in which case leave it alone). Apply to all code authoring across all languages, every time source code is touched. When in doubt whether this skill applies to a code edit, invoke it. Skip only for non-code files (JSON/YAML/TOML configs, mar

0 Updated 2 weeks ago
rvanbaalen
Web & Frontend Listed

code-comments

Enforce a terse, low-comment style when writing or reviewing frontend code (React/JSX/TSX, CSS, general JS/TS) — deciding whether a component/function/line needs a comment, writing a JSDoc header, or explaining a workaround. Default to no comment; names and types carry the "what", commit messages carry the "why". Use whenever generating or reviewing frontend code, or when the user says a diff/PR "has too many comments", "comments are noisy", "explain less in code", or asks for a comment-style/discipline skill.

0 Updated 1 weeks ago
swaroopsm