tinysocs-docs-and-writing

Resolves documentation drift and enforces writing rules across TinySocs design docs and rule docs.

Updated Oct 12, 2025
One-click install
npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-docs-and-writing-lukefitzg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tinysocs-docs-and-writing
Source: https://github.com/lukefitzg/tinysocs/tree/main/.claude/skills/tinysocs-docs-and-writing
Command: npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-docs-and-writing-lukefitzg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? TinySocs documentation drifts: design-doc status headers contradict CLAUDE.md, rule counts disagree across files, and the two TinyDocs artifacts list different rule IDs. This Skill tells you which document to trust first, catalogs every known inconsistency with file:line evidence, and enforces the writing rules that prevent new drift. ## Core Features & Use Cases - Source-of-truth routing: Establishes the priority order docs/roadmap.md > design-doc status headers > CLAUDE.md when documents disagree about feature status. - Doc-drift ledger: A maintained table of 12 known inconsistencies (stale rule counts, wrong version strings, mismatched scheduled-task names, dead rule IDs in shipped docs) with an assigned fix owner for each. - TinyDocs synchronization rules: Keeps tinydocs/*.md and packaging/detection/rule_docs.yml aligned with the 19-rule enabled set whenever rules are enabled, disabled, or renamed. - Writing discipline: Date-stamp volatile numbers, no prices in docs, ASCII-only near PowerShell 5.1 content, cross-reference instead of restating facts. - Use Case: When asked to update docs/design/continuous-validation.md, you first learn its "not yet implemented" header is stale — the pipeline is built but blocked on a harness bug — and write the accurate status instead of trusting the header. ## Quick Start Ask the assistant to check whether CLAUDE.md's claim about rule signing being greenfield is still true and reconcile it against the design docs.

Frequently Asked Questions about tinysocs-docs-and-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I know which TinySocs doc to trust when they disagree?

Check docs/roadmap.md first — it is the freshest cross-cutting status tracker and self-flags where it disagrees with CLAUDE.md. Design-doc status headers come second, and CLAUDE.md's gap list is treated as most likely to be stale.

How do I keep tinydocs and rule_docs.yml in sync?

Both artifacts must track the 19-rule enabled set from docs/pilot-ruleset.md. Whenever a rule is enabled, disabled, or renamed in rules.yml or the v2 pack, update tinydocs/*.md and packaging/detection/rule_docs.yml in the same change so one never lags the other.

What writing rules apply to TinySocs documentation?

Date-stamp volatile numbers like rule counts, never include prices, keep plan docs uncommitted, use ASCII-only in anything PowerShell-adjacent, and cross-reference facts instead of restating them. Design-doc status headers must be updated in the same change that ships the code.

Can this skill edit CLAUDE.md to fix stale facts?

No. Skills flag staleness with file:line evidence and let the founder make the edit or explicitly delegate it as a scoped task. CLAUDE.md's rules remain binding even when specific facts in it are stale.

When should I not use this documentation skill?

Do not use it for customer-facing claims like competitive positioning or marketing rule counts — that belongs to tinysocs-external-positioning. It also does not decide whether a change is in scope for the pivot, which is tinysocs-change-control's job.