docs-update

Documentation update workflow. Use when modifying files in docs/ directory or any markdown files (*.md).

hiromaily/go-crypto-wallet37 installsMITSynced Aug 26

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
name: docs-update
description: Documentation update workflow. Use when modifying files in docs/ directory or any markdown files (*.md).
license: MIT
---

# Documentation Update Workflow

Workflow for documentation changes with SSOT awareness.

## Prerequisites

- **Use `git-workflow` Skill** for branch, commit, and PR workflow.
- **Understand SSOT structure** before editing any documentation.

## SSOT Awareness

**Critical**: Before editing documentation, identify if the file is an SSOT or references one.

### SSOT Locations

| Category                 | SSOT Location                            | Description                     |
| ------------------------ | ---------------------------------------- | ------------------------------- |
| Agent behavior           | `AGENTS.md`                              | Entry point for all agents      |
| Agent instruction design | `docs/ai/design.md`                      | Command/Skill/Rule architecture |
| Label definitions        | `docs/guidelines/task-classification.md` | All label types and meanings    |
| Label → Skill mapping    | `.claude/skills/label-context-mapping/`  | Operational routing             |
| Coding conventions       | `docs/guidelines/coding-conventions.md`  | Code style rules                |
| Security rules           | `docs/guidelines/security.md`            | Security requirements           |
| Testing standards        | `docs/guidelines/testing.md`             | Test requirements               |
| Workflow                 | `docs/guidelines/workflow.md`            | Development workflow            |

### SSOT Rules

1. **If editing an SSOT file**: Update carefully, as other files reference it
2. **If editing a non-SSOT file**: Ensure it references the SSOT, don't duplicate information
3. **If information conflicts**: The SSOT is authoritative; update the referencing file

## Applicable Files

| Path                  | Type        | Description                      |
| --------------------- | ----------- | -------------------------------- |
| `AGENTS.md`           | SSOT        | Agent behavior entry point       |
| `ARCHITECTURE.md`     | SSOT        | System architecture              |
| `docs/guidelines/`    | SSOT        | Project guidelines and standards |
| `docs/design/`        | Reference   | Design documents                 |
| `docs/chains/`        | Reference   | Chain-specific documentation     |
| `docs/ai/task-contexts/` | Context     | Task-specific procedures         |
| `internal/AGENTS.md`  | Scoped SSOT | Internal package guidelines      |
| `pkg/AGENTS.md`       | Scoped SSOT | Public package guidelines        |

## Documentation Hierarchy

```
AGENTS.md (entry point)
    │
    ├─ docs/ai/design.md (instruction system design)
    │
    ├─ docs/guidelines/ (guidelines and standards)
    │   ├─ task-classification.md (label definitions, SSOT)
    │   ├─ coding-conventions.md
    │   ├─ security.md
    │   ├─ testing.md
    │   ├─ workflow.md
    │   ├─ architecture.md
    │   ├─ code-generation.md
    │   └─ ...
    │
    └─ docs/ai/task-contexts/ (task-specific context)
        ├─ bug-fix.md, feature-add.md, etc.
        └─ chains/ (chain-specific)
```

## Workflow

### 1. Identify Document Type

Before editing, determine:

- Is this file an SSOT?
- Does this file reference an SSOT?
- What other files might be affected?

### 2. Check for Duplicated Information

If the information you're adding already exists elsewhere:

- Find the SSOT location
- Add a reference instead of duplicating

### 3. Make Changes

Follow markdown style guidelines:

- Use ATX-style headers (`#`, `##`, `###`)
- One blank line between sections
- Code blocks with language specifier
- Tables for structured data
- Relative links within docs

### 4. Verify Cross-References

After changes:

- [ ] Links work correctly
- [ ] SSOT references are accurate
- [ ] No information duplication
- [ ] Consistent formatting

## Markdown Style

### Headers

```markdown
# Top Level (document title)

## Section

### Subsection
```

### Code Blocks

Always specify language:

````markdown
```go
func example() {}
```
````

```bash
make go-lint
```

````

### Tables

Use tables for structured data:

```markdown
| Column 1 | Column 2 |
|----------|----------|
| Value 1  | Value 2  |
````

### Links

- Use relative links: `[link](../path/to/file.md)`
- Verify links work after moving files
- Update cross-references when renaming

## Self-Review Checklist

- [ ] SSOT location identified (if applicable)
- [ ] No duplicated information
- [ ] References point to correct SSOT
- [ ] Markdown renders correctly
- [ ] Links work
- [ ] Consistent formatting
- [ ] Tables align properly

## Commit & PR

Use `git-workflow` skill for commits:

- **Commit type**: `docs`
- **Scope**: Optional (or target area: `btc`, `eth`, `standards`, etc.)

Example: `docs(standards): update coding conventions for error handling`

## Related

- `git-workflow` - Branch, commit, PR workflow
- [AGENTS.md](../../../AGENTS.md) - Agent entry point
- [AI Agent Instruction Design](../../../docs/ai/design.md) - System design
- [Task Classification](../../../docs/guidelines/task-classification.md) - Label SSOT

More Writing & Documentation skills

paper-context-resolver

lllllllama/rigorpilot-skills

Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default.

450.8k

repo-intake-and-plan

lllllllama/rigorpilot-skills

Rigor Intake helper for README-first deep learning repo reproduction. Use when the task is specifically to scan a repository, read the README and common project files, extract documented commands, classify inference, evaluation, and training candidates, and return the smallest trustworthy reproduction plan to the main orchestrator. Do not use for environment setup, asset download, command execution, final reporting, paper lookup, or end-to-end orchestration.

450.0k

minimal-run-and-audit

lllllllama/rigorpilot-skills

Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized `repro_outputs/` files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.

449.9k

← All Writing & Documentation skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY