Skip to content
Skills Library
Programming · Writing

write-docstrings

/write-docstrings

Writes and reviews docstrings in this repo. Use when writing new docstrings, reviewing existing docstrings, or editing docstrings.

Licence
MIT
Last repository change
24.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 24.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Writes and reviews docstrings in this repo. Use when writing new docstrings, reviewing existing docstrings, or editing docstrings.

Original author description

Writes and reviews docstrings in this repo. Use when writing new docstrings, reviewing existing docstrings, or editing docstrings.

How it works

  1. Current migration stage
  2. Format: Google-style
  3. Example
  4. Incorrect example (do not do this!)
  5. Module and class docstrings
  6. Miscellaneous
Original SKILL.md headings · 70 lines, 371 words
SKILL.md preview
---
name: write-docstrings
description: Writes and reviews docstrings in this repo. Use when writing new docstrings, reviewing existing docstrings, or editing docstrings.
---

# Writing Docstrings

Required for: all public modules, classes, functions, and methods

## Current migration stage

Use Google-style docstrings as described below.

## Format: Google-style

1. First line is a simple summary in imperative or indicative mood, ending in a period
2. Use sections when relevant: `Args`, `Returns`, `Raises`, `Examples`
3. Do not place type information in docstrings, use type annotations only
4. Do not use leading articles in parameter, return, and error descriptions "a", "an", or "the"
5. Only use single backticks (e.g. `Spam`, not ``Spam``)
6. Start argument, attribute, return, and error descriptions with lowercase words;
   preserve capitalization of identifiers, proper names, and acronyms
7. Omit trailing periods from descriptions; keep the summary's final period
8. State actions or error conditions directly, without leading `if` clauses
9. Keep descriptions concise and avoid repeating types already in annotations
10. Use en dashes rather than em dashes

## Example

```python
def process_spam(input_data: list[tuple[str, int]], threshold: int = 2) -> dict[str, int]:
    """Process spam counts, dropping those below threshold.

    Args:
        input_data: spam counts to process
        threshold: minimum count threshold for inclusion

    Returns:
        mapping of categories to counts

    Raises:
        ValueError: threshold is negative

    Examples:
        >>> process_spam([("jalapeno", 5), ("regular", 3), ("jalapeno", 9), ("low sodium", 1)], 2)
        {"jalapeno": 14, "regular": 3}
    """
```

## Incorrect example (do not do this!)

```python
def process_spam(input_data: list[tuple[str, int]], threshold: int = 2) -> dict[str, int]:
    """spam counts, dropping those below threshold                 # ❌ Missing trailing period, needs sentence case, should be in imperative or indicative mood

    Args:
        input_data (list[str]): A list of spam counts to process.  # ❌ Has type, article, and unnecessary trailing period
        threshold (int): Minimum count threshold for inclusion     # ❌ Has type, article, and sentence-case description

    Returns:
        dict[str, int]: A dictionary mapping categories.           # ❌ Has type, article, and unnecessary trailing period
    """
```

## Module and class docstrings

- **Module docstrings:** single sentence describing the module's purpose; placed at the top of the file before any imports.
- **Class docstrings:** describe the class's purpose and any important attributes or invariants; placed immediately after the `class` line.

## Miscellaneous

- Prefer Unicode superscripts for single digit superscripts, e.g. Ų
- Never add ignores to the `pyproject.toml` formatting, linting, or type checking without explicitly asking

Versions

The database has no other skills named write-docstrings.

Database snapshot: 13.11.2026 · package version 1c9b93e46e15 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100writing-docstrings
    Use when writing, rewriting, or auditing Python docstrings that a documentation site is generated from, or when docstrings are long, narrate the code, or leave a reader of the generated reference unable to find their way. Triggers - "audit the docstrings", "docstring slop",…
  • 100write-code
    Write or review code in this repo. Use when writing new code, reviewing existing code, or editing code.
  • 100write-tests
    Write or review unit tests for code in this repo. Use when writing new tests, reviewing existing tests, or adding test coverage.
  • 95docstring
    Write docstrings for PyTorch functions and methods following PyTorch conventions. Use when writing or updating docstrings in PyTorch code.
  • 100update-docstrings
    Add or update docstrings, doc comments, and inline comments in source code — any language. Use when the user wants docstrings written or fixed, a conversion to a doc style (NumPy, TSDoc, rustdoc), or a comment cleanup. Source files only — README/ADR/prose docs belong to…
  • 100documentation-generation
    Generates project documentation including READMEs, docstrings (JSDoc, JavaDoc, Python docstrings), OpenAPI prose, and CI/CD doc pipelines. Use when asked to generate docs, write docstrings, automate documentation, or create README files.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.