docs-update
Documentation update workflow. Use when modifying files in docs/ directory or any markdown files (*.md).
Works with
---
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 SSOTMore 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.
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.
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.

