# Oss Documentation System

> 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.

- Skill: `ferroxlabs/oss-documentation-system` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ferroxlabs/oss-documentation-system`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ferroxlabs/oss-documentation-system/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: Apache-2.0
- Author: FerroxLabs (https://skillmd.com/u/ferroxlabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ferroxlabs/oss-documentation-system

---


# 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

- [Getting Started Guide](docs/getting-started.md)
- [API Reference](docs/api.md)
- [Configuration](docs/configuration.md)
- [Examples](docs/examples/)

## Contributing

We welcome contributions. See [CONTRIBUTING.md](CONTRIBUTING.md).

## License

[MIT](LICENSE) - 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
```

| Type | Purpose | Example |
|------|---------|---------|
| Tutorial | Teach by doing, step-by-step | "Build your first plugin" |
| How-To Guide | Solve a specific problem | "How to configure SSL" |
| Explanation | Provide understanding | "How the cache works" |
| Reference | Describe the machinery precisely | "API endpoint reference" |

### 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