Przejdź do treści
Biblioteka skilli
Zarządzanie i produkt · Przegląd i audyt

docs-practices

/docs-practices

Ocenia, czy potrzebny jest trwały dokument, ADR, plan lub specyfikacja, i sprawdza ich zakres, jakość założeń oraz nazewnictwo.

Repozytorium
dalcom-skills ↗
Licencja
Apache-2.0
Ostatnia zmiana repozytorium
10.11.2026

Ocena i bezpieczeństwo

85/ 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ść20 / 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
2
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

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

Licencja

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

Co robi i kiedy

Ocenia, czy potrzebny jest trwały dokument, ADR, plan lub specyfikacja, i sprawdza ich zakres, jakość założeń oraz nazewnictwo.

Oryginalny opis (EN)

Use when deciding whether a durable document, ADR, plan, or spec is needed, or when checking its invariant quality, scope, and naming. Not for drafting prose or restructuring agent-consumed documents.

Jak działa

  1. What you need
  2. Keep a record only for a material invariant
  3. Scope, enforcement, and proof must be explicit
  4. Name everything a stranger can understand
  5. What you report
Sekcje z nagłówków SKILL.md, w oryginale · 29 linii, 659 słów
Podgląd SKILL.md
---
name: docs-practices
description: 'Use when deciding whether a durable document, ADR, plan, or spec is needed, or when checking its invariant quality, scope, and naming. Not for drafting prose or restructuring agent-consumed documents.'
---

# Docs practices

Decide whether a durable record is warranted, then hold it to invariant quality. The default answer is no new document. This covers proposed, drafted, or under-review durable documents, ADRs, plans, and specs for scope, naming, and lasting value. Drafting, ghostwriting, or restructuring prose on request is out of scope: judge need, scope, and naming only.

## What you need

You need the proposed or existing document path, or the claim that needs a durable home, plus the invariant the record would protect stated in one sentence. Existing sources already covering the topic, with the enforcement and proof each provides, come along when they exist.

## Keep a record only for a material invariant

Protect with a durable record only a material generalized invariant that future readers must obey or rely on. Notes about what happened, what was decided when, and what was learned once do not qualify. Lacking such an invariant means rejecting the proposal outright.

Before writing, search for a sufficient existing home and read the candidate sources. Reuse the sufficient source and add a pointer when it covers the invariant; write anew only when none suffices. Activity records, decision diaries, meeting notes, status logs, mini-learnings, and jargon never belong in durable records. Code comments never substitute for a missing record: fix the record or leave the gap explicit. Placeholders, deferred sections, follow-up promises, and excuses never ship as content.

## Scope, enforcement, and proof must be explicit

Each kept record states its scope of application, what enforces it, and what proof shows a violation. Remove material that applies once, applied in the past, or restates configuration the source of truth already owns. Accept only independent or adversarial evidence that detects a plausible material fault and survives equivalent refactors. Fixture inputs and setup are permitted; saved-output pins, literal snapshots, mock echoes, and source-text assertions are rejected. Weak tests are never admitted under any circumstances. Never weaken a lint or drop proof to meet a length or percentage goal; load-bearing clause identifiers, evidence rows, and measured facts stay where their consumer still needs them.

## Name everything a stranger can understand

By default, human-facing doc names, headings, sections, phases, and labels use short semantic readable names. Never name them with opaque codes such as A0, DEL1, ENG-01, or DES-02, bare numbers, coded prefixes, random letters, hashes, date prefixes, or Roman numerals. Replace each opaque label with a short semantic name describing the work. Require a link map before mass renames to track every affected link, pointer, and reference to its new target. Useful numbered procedure steps, quoted historical evidence, legal notices, and externally fixed machine or standard identifiers stay unchanged. A genuine externally fixed clause identifier stays with a human-readable label beside it; never invent new opaque codes for organization. The tree passes when no opaque label remains and every affected link resolves; a rename that breaks a link gets restored or repaired from verified evidence, then every affected link is re-verified.

Legal notices, license text, required attribution, and quoted evidence stay intact throughout. Never generalize a time-bound fact into a timeless rule. Missing authority or prerequisites stay reported as blocked with the exact missing item; finish reachable narrowing and renaming, then stop rather than inventing coverage. Uncertain ownership or scope means changing nothing in the uncertain region and reporting the boundary question as blocked. When repeated narrowing creates new broken references or ownership conflicts, keep the last verified state and return the remaining findings.

## What you report

A verdict per record: kept with its invariant, scope, enforcement, and proof, or rejected with the sufficient existing source or the reason no record applies. Plus the narrowed or renamed tree and a terminal report with kept, rejected, and blocked counts, every rename with its link map and updated links, and the link-check result. Whole-document deletion needs separate explicit approval for that exact set; rollback is version control or undo, and nothing is published, installed, or committed.
Pliki w paczce (2)
  • SKILL.md 4 KB
  • agents/openai.yaml 1 KB

Wersje

W bazie nie ma innych skilli o nazwie docs-practices.

Migawka bazy z 13.11.2026 · wersja paczki 83a3267e72fd (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

  • 82write-spec
    Pisze specyfikację docs/SPEC.md na podstawie plików odkryć lub wywiadu z właścicielem i zapisuje decyzję o budowie jako ADR.
  • 100plan-docs
    Tworzy dokumenty architektury, ADR i szczegółowe plany z historyjkami, synchronizowane z ClickUp.
  • 100vibe-adr-recall
    Przypomina zaakceptowane ADR z katalogu decyzji przy planowaniu i zapisuje ich uwzględnienie w planie implementacji.
  • 90documentation-criteria
    Ustala, jakiego dokumentu technicznego wymaga zmiana: PRD, ADR, specyfikacji UI, dokumentu projektu czy planu prac.
  • 100plan-review
    Sprawdza dokument planu pod kątem jakości i gotowości do sprintu, po wygenerowaniu planu.
  • 100ia-document-review
    Sprawdza strukturę i poprawność dokumentów, takich jak plan, specyfikacja czy ADR, porównując twierdzenia z kodem.

Uwagi i zgłoszenia

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