Agent skill

Oss Documentation System

by FerroxLabs in FerroxLabs/wayland

Build comprehensive open source documentation with contributor guides, architecture docs, README templates, and documentation-as-code workflows Use when the user asks about oss documentation system…

Apache-2.0Auto-check passedDevelopment

Install Oss Documentation System

skills CLI
$ npx skills add FerroxLabs/wayland --skill oss-documentation-system -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install FerroxLabs/wayland oss-documentation-system --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/FerroxLabs/wayland.git skills-src && mkdir -p .claude/skills && cp -r skills-src/src/process/resources/skills-library/bodies/skills/software-engineering/oss-documentation-system .claude/skills/oss-documentation-system && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
oss-documentation-system
GitHub stars
608
Token cost
~3.3k tokens
SKILL.md length
547 words
Files
1
Skills in repo
1,194
Repo updated
First seen
Licence
Apache-2.0

At a glance

Build comprehensive open source documentation with contributor guides, architecture docs, README templates, and documentation-as-code workflows Use when the user asks about oss documentation system…

  • Works in 5 steps: Create a branch from main: git checkout… → Make changes with clear, atomic commits → Ensure tests pass: npm test → …
  • The user asks about oss documentation system
  • SKILL.md covers When to Use, README Template, Documentation and Contributing, plus 12 more sections
  • Calls npm and git

What it does

Oss Documentation System is an agent skill from FerroxLabs/wayland. Build comprehensive open source documentation with contributor guides, architecture docs, README templates, and documentation-as-code workflows Use when the user asks about oss documentation system, related techniques, best practices, or needs guidance in this domain. Do NOT use when the request is outside the scope of oss documentation system or requires a different specialized skill.

Its SKILL.md is about 3.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Technical documentation and Architecture decision records. The repository describes itself as: Wayland - The AI Agent That Perceives. Reasons. Acts. Evolves. The licence is Apache-2.0.

When your agent uses it

  • The user asks about oss documentation system
  • Related techniques
  • Needs guidance in this domain
  • The request is outside the scope of oss documentation system

Example prompts

  • “/oss-documentation-system”

Requirements

  • Python 3
  • Node.js

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Create a branch from main: git checkout -b fix/issue-42
  2. Make changes with clear, atomic commits
  3. Ensure tests pass: npm test
  4. Ensure linting passes: npm run lint
  5. Push and open a pull request

What it can do on your machine

Read from SKILL.md and the folder at commit 4c030c7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Oss Documentation System loads about 3.3k tokens when it runs. Until then it costs about 103 tokens; SKILL.md has 547 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~103
When it runs · the whole SKILL.md, loaded when a task matches
~3.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from FerroxLabs/wayland at commit 4c030c7, republished under its Apache-2.0 licence (© FerroxLabs). 547 words, ~3,348 tokens.

Download SKILL.mdSave it as .claude/skills/oss-documentation-system/SKILL.md (or your agent's skills folder).
name
oss-documentation-system
description
Build comprehensive open source documentation with contributor guides, architecture docs, README templates, and documentation-as-code workflows Use when the user asks about oss documentation system, related techniques, best practices, or needs guidance in this domain. Do NOT use when the request is outside the scope of oss documentation system or requires a different specialized skill.
license
Apache-2.0
metadata.author
foundry-skills
metadata.version
1.0.0
metadata.tags
best-practices checklist template guide step-by-step advanced python javascript
metadata.category
software-engineering
metadata.subcategory
developer-tools
metadata.disclaimer
none
metadata.difficulty
advanced

OSS Documentation System

You are an open source documentation architect who helps projects build comprehensive, maintainable documentation systems. You guide through README design, contributor guides, architecture documentation, and documentation-as-code workflows that scale with the project.

When to Use

Use this skill when:

  • User asks about oss documentation system techniques or best practices
  • User needs guidance on oss documentation system concepts
  • User wants to implement or improve their approach to oss documentation system

Do NOT use when:

  • The request falls outside the scope of oss documentation system
  • User needs a different specialized skill for their specific situation
  • The topic requires professional consultation beyond general guidance

README Template

Essential README Structure
markdown
# Project Name

Brief, compelling one-liner explaining what this project does.

[![CI](badge-url)](link) [![License](badge-url)](link)

## What is Project Name?

2-3 sentences: what problem does this solve, who is it for, why should they care?

## Features

- **Feature A**: Brief benefit-oriented description
- **Feature B**: Brief benefit-oriented description

## Quick Start

### Installation

```shell
add the package dependency project-name
Basic Usage
javascript
import { Project } from 'project-name';
const result = Project.doThing({ input: 'example' });
// Expected output: { status: 'success', data: '...' }

Documentation

Contributing

We welcome contributions. See CONTRIBUTING.md.

License

MIT - see LICENSE file for details.


### README Quality Checklist

- [ ] Project name and description clear within 5 seconds
- [ ] Installation takes fewer than 3 steps
- [ ] Working code example is copy-pasteable with expected output
- [ ] All badges are functional and current
- [ ] Links to deeper documentation work
- [ ] License is stated, contributing path is clear

## CONTRIBUTING.md Template

```markdown
# Contributing to [Project]

## Development Setup

### Prerequisites
- Node.js >= 18
- Git

### Local Setup

```shell
git clone [GitHub repository]
cd project
add the package dependency
npm test        # Verify setup
npm run dev     # Start development mode

Making Changes

Branch Workflow
  1. Create a branch from main: git checkout -b fix/issue-42
  2. Make changes with clear, atomic commits
  3. Ensure tests pass: npm test
  4. Ensure linting passes: npm run lint
  5. Push and open a pull request
Commit Messages

We use conventional commits:

  • feat: new features
  • fix: bug fixes
  • docs: documentation changes
  • test: test additions or fixes
  • chore: maintenance tasks

Pull Request Process

  1. Fill out the PR template completely
  2. Ensure CI passes
  3. Request review from a maintainer
  4. Address review feedback
PR Size Guidelines
  • Small (< 100 lines): Bug fixes, docs → Quick review
  • Medium (100-500 lines): Features, refactors → Standard review
  • Large (500+ lines): Consider splitting into smaller PRs

Reporting Bugs

Include: Steps to reproduce, expected vs actual behavior, environment details, minimal reproduction.

Requesting Features

Include: Problem description, proposed solution, alternatives considered, willingness to implement.

Getting Help

  • Questions: GitHub Discussions
  • Bugs: Open an issue with the bug template
  • Chat: Join our [Discord/Slack]

## Architecture Documentation

### Architecture Decision Record (ADR) Format

```markdown
# ADR-001: Use PostgreSQL for Primary Data Store

## Status
Accepted (2025-01-15)

## Context
We need a primary data store supporting complex queries with joins,
ACID transactions, JSON document storage, and horizontal read scaling.

## Decision
We will use PostgreSQL as the primary data store.

## Rationale
- Mature, well-tested, widely understood
- jsonb covers flexible schema needs
- Read replicas provide sufficient read scaling
- Team has existing expertise

## Alternatives Considered
- **MongoDB**: Flexible schema but weaker transaction support
- **MySQL**: Widely used but weaker JSON support

## Consequences
- Need connection pooling (pgBouncer) for high concurrency
- Migration tooling must support PostgreSQL dialects

## Review Date
2025-07-15 (6 months after adoption)
System Architecture Document Template
markdown
# Architecture Overview

## System Context

[External Users] → [CDN] → [Web App]
                              ↓
                         [API Gateway]
                         /    |    \
                    [Auth] [Core] [Search]
                      ↓      ↓      ↓
                   [DB]   [DB]  [Search Index]

## Component Descriptions
- **API Gateway**: Request routing, rate limiting, authentication
- **Core Service**: Business logic and data management

## Data Flow: Request Lifecycle
1. Client sends request to CDN/load balancer
2. Gateway validates authentication token
3. Request routed to appropriate service
4. Service processes request and queries database
5. Response returned through the same path

## Key Design Decisions
| Decision | ADR | Date | Status |
|----------|-----|------|--------|
| Primary database | ADR-001 | 2025-01 | Accepted |
| Authentication | ADR-002 | 2025-01 | Accepted |
| API versioning | ADR-003 | 2025-02 | Accepted |

Documentation-as-Code Workflows

Documentation Site Structure
docs/
  index.md
  getting-started/
    installation.md
    quick-start.md
    configuration.md
  guides/
    basic-usage.md
    advanced-features.md
    troubleshooting.md
  api/
    overview.md
    endpoints.md
  architecture/
    overview.md
    adrs/
      001-database.md
      002-authentication.md
  contributing/
    setup.md
    guidelines.md
    releasing.md
  mkdocs.yml
CI/CD for Documentation
yaml
# GitHub Actions: Build and deploy docs
name: Documentation
on:
  push:
    branches: [main]
    paths: ['docs/**', 'mkdocs.yml']
  pull_request:
    paths: ['docs/**', 'mkdocs.yml']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: install the package via pip mkdocs-material
      - run: mkdocs build --strict

  deploy:
    if: github.ref == 'refs/heads/main'
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: install the package via pip mkdocs-material
      - run: mkdocs gh-deploy --force
Documentation Linting
yaml
# .markdownlint.yml
default: true
MD013:
  line_length: 120
  code_blocks: false
  tables: false
MD033: false  # Allow inline HTML for badges
MD041: false  # First line heading (frontmatter)
yaml
# Documentation PR check
name: Docs Lint
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: DavidAnson/markdownlint-cli2-action@v16
        with:
          globs: '**/*.md'
      - uses: streetsidesoftware/cspell-action@v6
        with:
          files: '**/*.md'
      - uses: lycheeverse/lychee-action@v1
        with:
          args: '--no-progress docs/**/*.md README.md'

Documentation Types Guide

                Practical
                   │
     Tutorials     │    How-To Guides
     (Learning)    │    (Problem-solving)
                   │
Studying ──────────┼──────────── Working
                   │
     Explanation   │    Reference
     (Understanding)│   (Information)
                   │
               Theoretical
TypePurposeExample
TutorialTeach by doing, step-by-step"Build your first plugin"
How-To GuideSolve a specific problem"How to configure SSL"
ExplanationProvide understanding"How the cache works"
ReferenceDescribe the machinery precisely"API endpoint reference"
Show full SKILL.md (204 more words)Show less
Writing Guidelines
1. Start with the user's goal
   Bad: "The XConfig class provides configuration management."
   Good: "To customize behavior, create a configuration file."

2. Show, then explain - lead with a code example

3. Use consistent terminology - maintain a glossary

4. Test every code example in CI

5. Version your docs to match software versions

6. Progressive disclosure - start simple, add complexity as needed

7. PRs that change behavior must update relevant docs

Issue and PR Templates

Bug Report Template
yaml
# .github/ISSUE_TEMPLATE/bug_report.yml
name: Bug Report
description: Report a bug or unexpected behavior
labels: ['bug', 'needs-triage']
body:
  - type: textarea
    id: description
    attributes:
      label: Bug Description
    validations:
      required: true
  - type: textarea
    id: reproduction
    attributes:
      label: Steps to Reproduce
      value: |
        1.
        2.
        3.
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: Expected Behavior
    validations:
      required: true
  - type: textarea
    id: environment
    attributes:
      label: Environment
      value: |
        - OS:
        - Runtime version:
        - Package version:
    validations:
      required: true
Feature Request Template
yaml
# .github/ISSUE_TEMPLATE/feature_request.yml
name: Feature Request
description: Suggest a new feature or enhancement
labels: ['enhancement', 'needs-triage']
body:
  - type: textarea
    id: problem
    attributes:
      label: Problem Description
    validations:
      required: true
  - type: textarea
    id: solution
    attributes:
      label: Proposed Solution
    validations:
      required: true
  - type: textarea
    id: alternatives
    attributes:
      label: Alternatives Considered
  - type: dropdown
    id: willingness
    attributes:
      label: Would you be willing to submit a PR?
      options: ['Yes', 'Yes, with guidance', 'No']

Documentation Maintenance

Quarterly Documentation Audit
### Accuracy
- [ ] All code examples tested against current version
- [ ] API reference matches actual implementation
- [ ] Configuration options are complete and correct

### Completeness
- [ ] All public APIs documented
- [ ] Common use cases have how-to guides
- [ ] Migration guides exist for breaking changes

### Quality
- [ ] No broken links (automated check)
- [ ] No spelling errors (automated check)
- [ ] Consistent formatting and style

### Freshness
- [ ] Getting started guide works for a new user today
- [ ] Deprecated features marked clearly
- [ ] Version-specific docs labeled correctly

Process

  1. Gather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
  2. Analyze context. Review the information provided and identify key factors relevant to oss documentation system
  3. Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
  4. Present structured output. Deliver findings in the output format below with clear next steps
  5. Address follow-ups. Answer additional questions and refine recommendations based on feedback

Output Format

template
## Oss Documentation System Analysis

### Assessment
[Key findings and observations]

### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]

### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]

Edge Cases

  • Incomplete information: Ask clarifying questions before proceeding with recommendations
  • Conflicting requirements: Prioritize the most critical constraint and note trade-offs
  • Out of scope requests: Redirect to appropriate specialized skill or professional resource
  • Beginner vs advanced: Adjust depth and terminology based on user's experience level

Example

Input: "Help me with oss documentation system for my current situation"

Output:

Based on your situation, here is a structured approach to oss documentation system:

  1. Assessment: Evaluate your current state and identify key areas for improvement
  2. Strategy: Develop a targeted plan based on best practices
  3. Implementation: Execute the plan with specific, measurable steps
  4. Review: Monitor progress and adjust as needed

© FerroxLabs, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in src/process/resources/skills-library/bodies/skills/software-engineering/oss-documentation-system of FerroxLabs/wayland.

Open the folder on GitHubat commit 4c030c7

Compare with similar skills

Oss Documentation System next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Oss Documentation System compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Oss Documentation System this skillFerroxLabs/wayland608—~3.3kAutomated safety check: PassApache-2.0
Docsbrickbots/PiFinder250—~6.2kAutomated safety check: PassGPL-3.0
Evidence-Backed Documentation Writerbgauryy/octocode946—~2kAutomated safety check: PassMIT
Write Vibe ADRmistralai/mistral-vibe5.1k—~942Automated safety check: PassApache-2.0
Technical Documentation Templatesbybren-llc/safe-agentic-workflow421—~1.2kAutomated safety check: PassMIT
Prosestatic-web-server/static-web-server2.4k—~971Automated safety check: PassApache-2.0

Similar skills

  • Docs

    brickbots/PiFinder

    Author and edit PiFinder's user-facing documentation in the project's house style.

    250 GitHub stars~6.2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Writes, repairs and copyedits project docs against the Google developer documentation style guide, verifying claims in the repository before stating them.

    946 GitHub stars~2k tokensUpdated 4 days ago
    DevelopmentAuto-check passed
  • Write Vibe ADR

    mistralai/mistral-vibe

    Official

    Creates or updates concise Architecture Decision Records for the Mistral Vibe CLI and registers each one in the AGENTS.md decisions table.

    5.1k GitHub stars~942 tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Technical Documentation Templates

    bybren-llc/safe-agentic-workflow

    Documentation templates for ADRs, runbooks, architecture docs, and knowledge transfer documents. Use when creating Architecture Decision Records, writing…

    421 GitHub stars~1.2k tokensUpdated 2 mo ago
    DevelopmentAuto-check passed
  • Prose

    static-web-server/static-web-server

    Author or edit any prose for the Static Web Server (SWS) project — documentation, design docs, READMEs, PR descriptions, issue bodies, commit message bodies, or other human-readable text — following…

    2.4k GitHub stars~971 tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Agent Style

    pchalasani/claude-code-tools

    Literature-backed English technical-prose writing rules (agent-style, 21 rules).

    2k GitHub stars~1.4k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

More from FerroxLabs/wayland

All 1,194 skills in this repo
  • Star Office Helper

    FerroxLabs/wayland

    Install, start, connect, and troubleshoot visualization companion projects for Aion/OpenClaw, with Star-Office-UI as the default recommendation.

    608 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check: notes
  • Openclaw Setup

    FerroxLabs/wayland

    OpenClaw usage expert: Helps you install, deploy, configure, and use OpenClaw personal AI assistant.

    608 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed
  • Tvcontrol Setup

    FerroxLabs/wayland

    Set up TVControl end to end: install the connector, start TradingView Desktop with its control port open, load a watchlist export, add the indicators they use, and leave a working chart.

    608 GitHub stars~5.7k tokensUpdated yesterday
    Auto-check passed
  • Ab Testing Specialist

    FerroxLabs/wayland

    End-to-end guide for designing, running, and analyzing A/B tests including experiment design, statistical significance, sample size calculation, common pitfalls, and advanced testing patterns.

    608 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed
  • Academic Writer

    FerroxLabs/wayland

    Complete academic writing guide covering thesis and dissertation structure, journal article format using IMRaD, literature review methodology, citation management, the peer review process, and…

    608 GitHub stars~4.5k tokensUpdated yesterday
    Auto-check passed
  • Accessibility Auditor

    FerroxLabs/wayland

    Web accessibility expertise covering WCAG 2.2 conformance, audit methodology, ARIA patterns, keyboard navigation, screen reader testing, focus management, form accessibility, and automated vs manual…

    608 GitHub stars~4.1k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Oss Documentation System

What does Oss Documentation System do?

Build comprehensive open source documentation with contributor guides, architecture docs, README templates, and documentation-as-code workflows Use when the user asks about oss documentation system…. Oss Documentation System is an agent skill from FerroxLabs/wayland. Build comprehensive open source documentation with contributor guides, architecture docs, README templates, and documentation-as-code workflows Use when the user asks about oss documentation system, related techniques, best practices, or needs guidance in this domain.

When should I use Oss Documentation System?

Oss Documentation System fits situations like: the user asks about oss documentation system; related techniques; needs guidance in this domain; the request is outside the scope of oss documentation system.

How do I install Oss Documentation System in Claude Code?

Run `npx skills add FerroxLabs/wayland --skill oss-documentation-system -a claude-code`. Or copy the skill folder (src/process/resources/skills-library/bodies/skills/software-engineering/oss-documentation-system in FerroxLabs/wayland) into .claude/skills/oss-documentation-system in your project. Claude Code loads it when a task matches its description.

How do I install Oss Documentation System in Codex?

Run `npx skills add FerroxLabs/wayland --skill oss-documentation-system -a codex`. Or copy the skill folder (src/process/resources/skills-library/bodies/skills/software-engineering/oss-documentation-system in FerroxLabs/wayland) into .agents/skills/oss-documentation-system in your project. Codex loads it when a task matches its description.

Can I use Oss Documentation System in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add FerroxLabs/wayland --skill oss-documentation-system -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/oss-documentation-system, .gemini/skills/oss-documentation-system, .github/skills/oss-documentation-system and .opencode/skills/oss-documentation-system in your project.

What does Oss Documentation System need to run?

Going by SKILL.md and its folder, Oss Documentation System needs the command-line tools its instructions call (npm and git). Our summary lists: Python 3; Node.js.

Does Oss Documentation System access the network?

SKILL.md contains no URLs. Its commands use npm and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Oss Documentation System safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Oss Documentation System use?

Oss Documentation System is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Oss Documentation System use?

About 3.3k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Oss Documentation System?

Skills that share tags, products or a category with Oss Documentation System: Docs (brickbots/PiFinder, 250 stars), Evidence-Backed Documentation Writer (bgauryy/octocode, 946 stars), Write Vibe ADR (mistralai/mistral-vibe, 5.1k stars) and Technical Documentation Templates (bybren-llc/safe-agentic-workflow, 421 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Oss Documentation System?

FerroxLabs (a GitHub user) maintains it in FerroxLabs/wayland, which has 608 GitHub stars. The repository holds 1,194 skills in this directory. The repository was last updated on October 6, 2026.

Source: FerroxLabs/wayland on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.