write-docstrings
/write-docstrings
Writes and reviews docstrings in this repo. Use when writing new docstrings, reviewing existing docstrings, or editing docstrings.
- Author
- rowansci ↗
- Repository
- rowan-python ↗
- Licence
- MIT
- Last repository change
- 24.10.2026
Assessment and security
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
No signals detected. Repository changed on 24.10.2026, without references to retired models or APIs.
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
- Current migration stage
- Format: Google-style
- Example
- Incorrect example (do not do this!)
- Module and class docstrings
- Miscellaneous
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.