38 skills · sorted by relevance
Review and refine source-code comments and documentation attached to functions or other declarations. The skill removes redundant explanations, checks outdated TODOs, and preserves concise, evidence-based reasons and constraints that maintainers cannot readily infer from the code.
Review newly added comments, docstrings, and changelog entries so future readers can understand the current code. Revise development history, redundant explanations, and unclear shorthand while preserving constraints that the code cannot explain on its own.
Create and maintain code comments, API specifications, documentation sites, and user guides. Apply consistent formats, document parameters and errors, validate code examples, and report which parts of the code have been documented.
Write docstrings for PyTorch functions and methods following PyTorch conventions. Use when writing or updating docstrings in PyTorch code.
The English summary is being prepared. Showing the original description.
Generate comprehensive documentation for undocumented or poorly documented codebases. Use when a user asks to document code, add JSDoc/docstrings, create README files, generate architecture docs, explain what a codebase does, produce onboarding guides, or document internal APIs. Works with any language.
The English summary is being prepared. Showing the original description.
Write concise docstrings for functions. Use when a junior developer needs help describing inputs, outputs, and errors.
The English summary is being prepared. Showing the original description.
MkDocs documentation project reference covering CLI commands, mkdocs.yml configuration, Material theme setup, and plugin integration. Bundled references include complete CLI parameters, all mkdocs.yml settings with valid values, Material theme customization options, and plugin configs for mkdocstrings, mermaid2, mkdocs-gen-files, mkdocs-literate-nav, and mkdocs-typer2. Use when initializing a MkDocs site, configuring mkdocs.yml, customizing the Material theme, integrating plugins, building static docs from Markdown, or generating API documentation from Python docstrings.
The English summary is being prepared. Showing the original description.
ALWAYS invoke for any task involving docstrings, JSDoc/TSDoc, or REST API documentation — even when the request seems handleable without it. Enforces Microsoft contract-first conventions and a bare-minimum rule that Claude won't apply by default: never restate the signature, drop @param/@returns that only echo names and types, always document @throws, and document data shapes as WHAT not WHY. Covers Python docstring styles (Google/NumPy/Sphinx), TSDoc tags and @inheritDoc, and API doc patterns for NestJS/Express/FastAPI/Django. Trigger on: adding or auditing docstrings, redundant or missing tags, deleting comment rot, or producing a documentation-health report. Do not skip for documentation tasks — consistent conventions are the whole point.
The English summary is being prepared. Showing the original description.
Turn source code into project documentation, from a README with installation steps and examples to API references, architecture diagrams, developer guides, and changelogs. Match the scope and comment format to the project's size and programming language.
Set consistent Python conventions for naming, formatting, type checking, and documentation. Configure ruff and mypy or pyright, write clear function descriptions, and organize README and changelog content so a team can maintain shared standards.
Generate Python code for Dataverse integrations with error handling, retries, logging, and shared connection management. Include type hints, usage examples, and queries that retrieve only the records and columns needed for the task.
Generate Python code for Dataverse SDK workflows, including retries, bulk data changes, efficient queries, table metadata, and large file uploads. The skill also covers pandas integration and asks for type hints, docstrings, and official API references.
Add or improve Google-style docstrings, the explanations embedded in Python code, for modules and classes. Document constructor arguments, public methods, configuration fields, and enum values while preserving existing documentation that already meets the project’s conventions.
Use when adding docstrings, creating API documentation, or building documentation sites. Invoke for OpenAPI/Swagger specs, JSDoc, doc portals, tutorials, user guides.
The English summary is being prepared. Showing the original description.
Update documentation across the repo after API changes. Finds stale references in docs, examples, docstrings, and fixes them.
The English summary is being prepared. Showing the original description.
Write any link or URL so it resolves where it is rendered, not where it lives in the repo. Use when authoring or editing a link — in docs, source docstrings, READMEs (incl. npm-published), or product UI: docs cross-refs, "see SECURITY.md", universal `/_/` routes, GitHub URLs.
The English summary is being prepared. Showing the original description.
Audit, write, and improve developer documentation using Google's Developer Documentation Style Guide and Technical Writing courses. Use this skill for any documentation work, even when the user names no style guide: "audit our docs", "review this README", "write a README", "getting started guide", "how-to or tutorial", "API reference", "docstrings", "CLI help text", "changelog or release notes", "migration guide", or "our docs are confusing". Also use it when writing docs from code, rewriting a doc for clarity, fixing headings, procedures, or code samples, or enforcing consistent voice and terminology across a docs set — prefer it over editing documentation unaided. Covers reader and doc-type fit, second person and active voice, procedures, headings, lists and tables, code samples and placeholders, link text, notices, the word list, timeless docs, and accessibility. For code comments and naming, see clean-code. For marketing or landing-page copy, see storybrand-messaging.
The English summary is being prepared. Showing the original description.
Review generated or changed documentation before it ships — READMEs, API references, docstrings, PHPDoc/JSDoc, changelogs, tutorials, and doc sites. Best used reactively after an agent writes or edits docs, after code changes documented behavior, or before publishing docs. Use when the user says 'review the docs', 'is this documentation accurate', 'update the docs', 'write a README', 'document this API', 'add a docstring', or 'add a changelog entry'. Core job: verify every referenced function, flag, endpoint, config key, and code sample against the source; catch docs-vs-code drift; strip filler and unverifiable claims. DO NOT USE for production code review (use clean-code-guard), test review (use test-guard), marketing copy or blog posts, prose style editing of non-technical writing, or documentation site theming.
The English summary is being prepared. Showing the original description.
Generates and validates technical documentation including docstrings, OpenAPI/Swagger specs, JSDoc annotations, doc portals, and user guides.
The English summary is being prepared. Showing the original description.
One-shot efficiency audit of a file, diff, or whole repo across BOTH axes at once: over-engineered code (reinvented stdlib, needless abstractions, speculative config) AND bloated prose (verbose comments, padded docstrings, redundant doc sections). Neither a pure code-minimizer nor a pure prose compressor does both in one pass. That's the point. Ranked report, biggest saving first; changes nothing. Use when the user says "chisle audit", "/chisle-audit", "audit this for bloat", "what can I cut", "review this PR for over-engineering and verbosity".
The English summary is being prepared. Showing the original description.
Write effective code comments, READMEs, and technical documentation following intent-first principles. Use when adding comments, writing docstrings, creating READMEs, or updating any documentation.
The English summary is being prepared. Showing the original description.
Applies an ASD-STE100-derived register to operator and procedural text. Use when writing runbooks or steps. Do not use for docstrings, ADRs, or rationale.
The English summary is being prepared. Showing the original description.
Updates documentation after code changes with quality gates, slop detection, and accuracy checks. Use when code changes require corresponding doc updates.
The English summary is being prepared. Showing the original description.
Generate comprehensive test case documentation from test code, test framework output, existing test docs, and source code context. Use when documenting test suites, creating test specifications, generating test coverage reports, onboarding developers to testing practices, or preparing QA documentation. Analyzes test functions (pytest, unittest) to extract test names, docstrings, assertions, and organization, then produces structured markdown with both overview-level summaries and detailed test case specifications including purpose, preconditions, steps, expected results, and test data. Triggers when users ask to document tests, generate test specifications, create test reports, summarize test coverage, or explain what tests do.
The English summary is being prepared. Showing the original description.