docs-update

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

125 stars

Best use case

docs-update is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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

Teams using docs-update should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/docs-update/SKILL.md --create-dirs "https://raw.githubusercontent.com/hiromaily/go-crypto-wallet/main/.claude/skills/docs-update/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/docs-update/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How docs-update Compares

Feature / Agentdocs-updateStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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

Related Skills

makefile-update

125
from hiromaily/go-crypto-wallet

Makefile development workflow. Use when modifying Makefile or files in make/ directory.

docs-ssot

125
from hiromaily/go-crypto-wallet

Set up docs-ssot SSOT documentation structure — migrate existing docs, build, and validate

wallet-cli

125
from hiromaily/go-crypto-wallet

How to run watch, keygen, and sign wallet CLI commands. Use when executing wallet commands or testing wallet functionality.

typescript-development

125
from hiromaily/go-crypto-wallet

TypeScript/JavaScript development workflow for apps/ directory. Use when modifying TypeScript code in xrpl-grpc-server or JavaScript in eth-contracts.

solidity-development

125
from hiromaily/go-crypto-wallet

Solidity smart contract development workflow. Use when modifying smart contracts in apps/eth-contracts/contracts/.

shell-scripts

125
from hiromaily/go-crypto-wallet

Shell script development workflow. Use when modifying files in scripts/ directory or any *.sh files.

openspec-propose

125
from hiromaily/go-crypto-wallet

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

openspec-explore

125
from hiromaily/go-crypto-wallet

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

openspec-archive-change

125
from hiromaily/go-crypto-wallet

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

openspec-apply-change

125
from hiromaily/go-crypto-wallet

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

mockery

125
from hiromaily/go-crypto-wallet

Mock generation workflow for go-crypto-wallet. Activate whenever a developer asks to generate a mock for a new interface, add test coverage that requires a mock, or replace a manually-written test stub for a ports interface. Claude MUST use `make mockery` — never write mock struct code by hand.

label-context-mapping

125
from hiromaily/go-crypto-wallet

Maps GitHub labels to Skills and Context documents. Use when creating issues (github-issue-creation) or working on issues (fix-issue command).