Przejdź do treści
Biblioteka skilli
Programowanie · Pisanie

documentation

/documentation

Generuje docstringi, JSDoc, dokumentację API i aktualizacje README, które odzwierciedlają bieżący kod.

Repozytorium
gabbe ↗
Licencja
CC-BY-4.0
Ostatnia zmiana repozytorium
24.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 24.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

CC-BY-4.0, otwarta.

Co robi i kiedy

Generuje docstringi, JSDoc, dokumentację API i aktualizacje README, które odzwierciedlają bieżący kod.

Oryginalny opis (EN)

Generate docstrings, JSDoc, API docs, and README updates that reflect current code. Use when: docs, docstring, JSDoc, README, API docs, document this, add documentation.

Jak działa

  1. Goal
  2. Steps
  3. Constraints
  4. Output Format
  5. Security & Guardrails
Sekcje z nagłówków SKILL.md, w oryginale · 142 linii, 982 słów
Podgląd SKILL.md
---
name: documentation
description: "Generate docstrings, JSDoc, API docs, and README updates that reflect current code. Use when: docs, docstring, JSDoc, README, API docs, document this, add documentation."
license: CC-BY-SA-4.0
metadata:
  source: "agents/skills/coding/documentation.skill.md"
  tags: "coding"
  core: "true"
  context_cost: "medium"
---
# Documentation Skill

## Goal
Generate accurate, useful documentation for public APIs, modules, and the project README. Documentation describes WHY and WHAT (not HOW — the code shows how). All examples must be working code.

## Steps

1. **Identify what needs documentation**
   - Public functions, methods, and classes (not private internals)
   - API endpoints (generate from OpenAPI spec or create if missing)
   - Complex business logic with non-obvious behavior
   - README sections that are outdated or missing

2. **Write function/method docstrings**

   **TypeScript (JSDoc):**
   ```typescript
   /**
    * Creates a new user account and sends a verification email.
    *
    * @param dto - User creation data (email, name, password)
    * @returns The created user without sensitive fields
    * @throws {EmailAlreadyExistsError} If email is already registered
    * @throws {WeakPasswordError} If password doesn't meet requirements
    *
    * @example
    * const user = await createUser({
    *   email: 'alice@example.com',
    *   name: 'Alice',
    *   password: 'SecureP@ss123'
    * });
    * // Returns: { id: 'uuid', email: 'alice@example.com', name: 'Alice' }
    */
   async function createUser(dto: CreateUserDto): Promise<UserDto>
   ```

   **PHP (PHPDoc):**
   ```php
   /**
    * Creates a new user account and sends a verification email.
    *
    * @param CreateUserData $data User creation data
    * @return UserResource The created user resource
    * @throws EmailAlreadyExistsException If email is already registered
    *
    * @example
    * $user = $this->createUser->handle(new CreateUserData(
    *     email: 'alice@example.com',
    *     name: 'Alice',
    * ));
    */
   public function handle(CreateUserData $data): UserResource
   ```

   **Python (Google Style / Sphinx):**
   ```python
   def create_user(dto: CreateUserDto) -> UserDto:
       """Creates a new user account and sends a verification email.

       Args:
           dto (CreateUserDto): User creation data (email, name, password).

       Returns:
           UserDto: The created user without sensitive fields.

       Raises:
           ValueError: If email is already registered.

       Example:
           >>> user = create_user(CreateUserDto(email="alice@example.com", ...))
           >>> print(user.id)
       """
       ...
   ```

3. **Verify examples are working**
   - Every code example in documentation must actually work
   - Run the example code to verify it doesn't throw or produce wrong output
   - If the example would require a running server/DB: note the prerequisite clearly

4. **Update README_FULL.md**
   - README sections to check:
     - **Getting Started**: install + first run commands
     - **Available commands**: from AGENTS.md Section 2 (keep in sync)
     - **Architecture overview**: high-level description + link to C4 diagrams
     - **Contributing**: how to run tests, branch naming, PR process
     - **Environment variables**: list all required env vars with descriptions
   - README must reflect the CURRENT state of the project, not aspirations

5. **Generate API documentation**
   If OpenAPI spec exists at `docs/api/openapi.yaml`:
   ```bash
   # Scalar API docs (modern UI)
   npx @scalar/cli serve docs/api/openapi.yaml

   # Redoc (alternative)
   npx @redocly/cli preview-docs docs/api/openapi.yaml
   ```

6. **Generate module documentation** (if tooling configured)
   ```bash
   # TypeDoc for TypeScript
   npx typedoc src/ --out docs/typedoc/

   # JSDoc for JavaScript
   npx jsdoc src/ -r -d docs/jsdoc/

   # Laravel Scribe for PHP APIs
   php artisan scribe:generate

   # MkDocs (Python)
   uv run mkdocs build
   ```

7. **Check for outdated documentation**
   - Scan for function signatures in docs that don't match current code
   - Check for documented parameters that no longer exist
   - Check for examples that import from paths that have moved

## Constraints
- Only document PUBLIC API surface (not private implementation details)
- NEVER document what the code obviously does — document WHY it works that way
- All code examples must be verified working
- Do not create documentation files unless explicitly requested — update existing ones

## Output Format
Updated docstrings in modified files + updated README sections. Report: "[N] functions documented, README sections updated: [list]."

## Security & Guardrails

### 1. Skill Security (Documentation)
- **Secret Leakage via Examples**: In Step 2, the agent generates code examples. A critical risk is the LLM hallucinating real, valid API keys, internal network IP addresses, or production passwords it saw elsewhere in the codebase and embedding them into the documentation examples. The agent MUST strictly use RFC-compliant documentation placeholders (e.g., `example.com`, `192.0.2.1`, `sk-proj-xxxx`) and run a secret-scanner regex over all generated docblocks before writing them.
- **Vulnerability Broadcasting**: When documenting "WHY" (Step 1), the agent might inadvertently document explicit instructions on how to bypass intended limitations (e.g., `@note This function is vulnerable to timing attacks, so limit its use`). Documenting a vulnerability without fixing it provides a roadmap for attackers. The agent must flag any newly discovered structural weakness for immediate patching via the `debug.skill` rather than passively documenting it.

### 2. System Integration Security
- **Executable Documentation Execution (Code Execution)**: Step 3 requires the agent to "Verify examples are working." If the agent autonomously runs arbitrary Python or Bash examples it just generated to test them, it could execute dangerous commands (e.g., `os.system("rm -rf tmp")` accidentally generated in a file-cleanup tutorial). The evaluation of generated examples MUST be statically analyzed or executed in a strictly disconnected, read-only `/tmp` sandbox.
- **OpenAPI Desync**: In Step 5, API docs are generated. If the agent updates a docblock to say a parameter is "optional," but the backend still strictly requires it, clients using the generated OpenAPI spec will fail. The documentation skill must never dictate truth; it must strictly mirror the static type bindings (TypeScript/PHP) of the actual code. The agent is prohibited from assuming API behavior that isn't statically typed.

### 3. LLM & Agent Guardrails
- **Hallucinated Parameters**: The LLM might hallucinate elegant, helpful parameters in the documentation (e.g., documenting a `retry_count` parameter that the developer *should* have added, but didn't). This causes immense developer friction. The agent must rigidly extract parameter lists directly via AST (Abstract Syntax Tree) parsing tools, strictly forbidding the LLM from appending speculative kwargs.
- **Outdated Context Blindness**: In Step 7, the agent checks for outdated documentation. The LLM might read a doc block that says "Requires Admin privileges," see that the code doesn't check for Admin privileges, and *remove the documentation* instead of realizing the code has a critical Missing Authorization bug. The agent must default to assuming the *more secure* constraint is correct and escalate discrepancies to the `ops-security` persona.

Wersje

RepozytoriumWynikLicencja
Ta strona · andreibesleaga/gabbe100CC-BY-4.0
software-combined/SC_AI100Apache-2.0
DaveSkender/Stock.Indicators100Apache-2.0
mcouthon/agents100MIT
YLfjuk/deltafold100MIT
comet-ml/opik100Apache-2.0
runwield/runwield100MIT
anthropics/knowledge-work-plugins100Apache-2.0
luocfprime/labtasker100Apache-2.0

Migawka bazy z 13.11.2026 · wersja paczki 9fdade9eaa38 (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100documentation-generation
    Generuje dokumentację projektu: README, docstringi (JSDoc, JavaDoc, Python), opisy OpenAPI i potoki dokumentacji w CI/CD.
  • 100api-docs-generator
    Generuje dokumentację API z kodu, w tym specyfikacje OpenAPI, JSDoc i docstringi Pythona, dla API, endpointów REST i funkcji bibliotek.
  • 100doc-gen
    Generuje dokumentację z kodu źródłowego: docstringi, pliki README i referencje API.
  • 100code-documenter
    Generuje dokumentację dla niedokumentowanych lub słabo udokumentowanych baz kodu: JSDoc, docstringi, README, dokumentację architektury, przewodniki wdrożeniowe i opisy wewnętrznych API w dowolnym języku.
  • 100docs-guard
    Recenzuje wygenerowaną lub zmienioną dokumentację przed publikacją: README, referencje API, docstringi, changelogi i tutoriale, pod kątem zgodności z kodem.
  • 100code-documentation
    Generuje dokumentację baz kodu: referencje API, docstringi, pliki README i przewodniki użycia.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.