br4zz4:docs

Organize project documentation into a closed eight-folder structure with routing rules and templates.

Updated May 25, 2025
One-click install
npx skills add https://github.com/oporpino/commons --skill br4zz4-docs-oporpino
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: br4zz4:docs
Source: https://github.com/oporpino/commons/tree/main/ai/shared/skills/br4zz4%3Adocs
Command: npx skills add https://github.com/oporpino/commons --skill br4zz4-docs-oporpino

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams accumulate scattered, inconsistently named documentation across repos — docs in root folders, READMEs with hundreds of lines, orphaned RFCs and ADRs. This Skill enforces a single documentation layout under .project/docs/ with a deterministic routing table, so every document lands in exactly one of eight closed categories with consistent naming, frontmatter, and indexing. ## Core Features & Use Cases - Deterministic routing table: A 10-question decision table routes any document to specs/, plans/, features/, learnings/, architecture/, guides/, reference/<scope>/, or rules/<scope>/ — first affirmative answer wins. - Templates per category: Ready-made Markdown templates for business rules (Given/When/Then with R-XXX IDs), learnings, specs, plans, features (Gherkin), reference docs, guides, and architecture decisions, all with mandatory certainty frontmatter. - Naming and language conventions: English snake_case filenames, Portuguese content, timestamp prefixes for specs/plans derived via git log --follow, and updated: dates from the last touching commit. - Migration and inventory guidance: Rules for finding orphaned docs (rfcs/, root-level .md files, modules/*/docs/), batch git mv pitfalls, and index maintenance in README.md and RULES.md. - Use Case: When documenting a new business rule like "membership renewal requires payment", the Skill routes it to rules/membership/, applies the R-XXX template with Given/When/Then, links the validating test, and updates RULES.md. ## Quick Start Ask the AI to document a business rule or learning using the br4zz4:docs skill, and it will route the content to the correct folder, apply the right template, and update the documentation indexes.

Frequently Asked Questions about br4zz4:docs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where a new documentation file should go?▼

Apply the routing table from top to bottom and stop at the first affirmative answer. Specs cover planned or executed changes, plans cover implementation steps, rules cover Given/When/Then business logic, and reference covers how the system works.

How should business rules be documented in a project?▼

Write each rule as a single file in rules/<scope>/ using the R-XXX template with Given/When/Then sections, a sequential ID from RULES.md, mandatory certainty frontmatter, and a link to the validating test or a note that none exists yet.

What naming convention should documentation files use?▼

Filenames use English snake_case with no accents, spaces, or capitals, while content is written in Portuguese. Specs and plans get a YYYYMMDDHHMMSS timestamp prefix, features use USER-XXX prefixes, and other categories use short descriptive names.

Can I create a new folder inside .project/docs for a special topic?▼

No. The first level of .project/docs is a closed set of exactly eight folders: specs, plans, features, learnings, architecture, guides, reference, and rules. Any new document must be routed into one of these via the routing table.

How do I derive the timestamp for a spec file that lacks a prefix?▼

Run git log --follow --format=%ad --date=format:%Y%m%d%H%M%S on the file and take the oldest entry. The --follow flag is required because without it git returns the rename commit instead of the creation commit.

What does the certainty field in documentation frontmatter mean?▼

The certainty field is mandatory in every category and records how the content was verified: high means it came from the original document or verified code, medium means partially reconstructed from code, and low means mostly inferred or contradictory with the code.