sg-docs

Create or repair documentation so the repo stays navigable for both humans and agents.

A documentation skill for maintaining docs, metadata, and governance-layout compliance across project surfaces.

Problem

What problem this solves

Docs decay quickly when product changes, metadata rules, or governance layouts are not reflected in the files that explain how the system works.

Outcome

What changes when it works

You get documentation that is closer to the current reality of the repo and easier to rely on during execution, including layout, metadata, and bug workflow docs that stay coherent with the tracker model.

Why It Matters

What this changes for a solo founder

This skill matters because stale docs create the same drag as stale code: wrong assumptions, weak handoffs, and repeated rediscovery.

When to use it

When the repo needs a new README, guide, or audit of existing docs
When implementation changed user-facing behavior or contracts
When the documentation surface feels inconsistent or stale
When legacy ShipGlows files at the project root need to move into the canonical shipglows_data layout

What you give it

A target file, doc mode, or documentation goal
The current repo and decision-doc context

What you get back

Generated or updated documentation
Governance-layout review when legacy root docs should move into shipglows_data
Metadata and technical-docs coherence when contracts change
A stronger documentation contract for future work
Better coherence between code and supporting docs
Skill documentation and public skill-page coherence when skill contracts change

Typical examples

/sg-docs readme
/sg-docs audit
/sg-docs migrate-layout
/sg-docs update docs after onboarding changes

Limits

It can improve documentation quality, but only the code proves real behavior
Docs still need product judgment when the underlying decision is unsettled
A local README refresh is not enough when the real issue is mixed governance layout or stale metadata contracts
Bug workflow docs should be checked for coherence across shipglows_data/workflow/TEST_LOG.md, shipglows_data/workflow/BUGS.md, dossier formats, and public skill pages
Docs audits should also verify skill-budget coherence with the ShipGlows skill budget audit script when skill docs change
Skill-contract changes belong to the internal 900 core build workflow; sg-docs keeps the docs and public surfaces coherent

Related Skills

See the rest of the loop around this move.

Plan & Decide

sg-context

Prime the relevant files and decisions before the thread starts guessing about the codebase.

A context-loading skill that retrieves the most relevant repo surface before implementation begins.

Open skill page

Plan & Decide

sg-spec

Turn a fuzzy request into an implementation-ready contract before code starts mutating the repo.

The spec-writing skill for shaping non-trivial work into a clear user story, behavior contract, executable task list, and chantier history.

Open skill page

Operate & Ship

sg-end

Close a task cleanly so the work is summarized, tracked, and ready for the next thread.

A task-closing skill for wrapping up implementation, documenting completion, and recording closure in the chantier flow when applicable.

Open skill page

Go Deeper

This public page explains the move. The repository explains the execution contract.

Use the public catalog for education and workflow selection. Move to the docs and GitHub when you want the operator-grade execution details behind the skill system.

Documentation Overview Open skills on GitHub Return to the skills hub