cs-libdoc

guidedoc teaches you "how to use X to do Y", while libdoc tells you "what each part of X looks like and how to configure it". The two are completely different in nature, with different writing styles, information sources, and granularities.

guidedoc being wrong may be due to unclear expression, but libdoc being wrong is a factual error — because its information source is the source code itself, and there is only one correct answer for types, default values, and signatures. The core rule of libdoc is no guessing, no copying and renaming, and reading the source code independently for each entry.

Comparison with guidedoc

	guidedoc	libdoc
Nature	Task-oriented (Tutorial / How-to)	Reference-oriented (Reference)
Answer	"How to achieve a goal with X"	"What each part of X looks like and how to configure it"
Granularity	One per feature / one per scenario	One per entry (component/function/command)
Information Source	Solution docs + user knowledge	Source code itself (type definitions, comments, default values)
Quantity	A few to a dozen	Dozens to hundreds

Complementary: Guides reference libdoc entries for detailed references ("See xxx for complete props"), and libdoc entries link back to corresponding guides in the "Related Entries" section.

What is an "entry"

An entry is the atomic documentation unit of libdoc, and its granularity is determined by the project type:

Project Type	Entry Granularity
UI Component Library	One component = one entry
Utility Function Library	One module or function family = one entry
API Client	One endpoint family = one entry
CLI Tool	One subcommand = one entry

Confirm the entry granularity during the initialization phase and keep it consistent later — changing granularity will disrupt the manifest and search.

Involved Paths

libdoc outputs are not under
codestable/
— API references are publishable products for external readers.

Entry documentation →
```
docs/api/{slug}.md
```
Entry manifest →
```
docs/api/manifest.yaml
```

docs/api/

is the default convention; if the project already has other conventions (such as

reference/

components/

), follow the project's existing rules — confirm this before starting.

manifest / Template / Source Code Extraction

Reference materials have been split into

reference.md

in the same directory:

Complete format and status semantics of
```
manifest.yaml
```
Frontmatter and body template for entry documentation
Source code extraction checklist (interface signatures, default values, export methods, etc.)

This skill's main body only retains process constraints: libdoc uses source code as the source of truth, no guessing, no copying and renaming the previous entry.

Workflow

Phase 1: Initialization — Scanning and Manifest

Goal: Produce the entry manifest and lock the documentation scope.

Confirm project type and entry granularity — What type of library is this? What is the entry granularity? Use
```
docs/api/
```
or the project's existing convention for the output path?
Scan the source code directory — Read the file structure under
```
source_root
```
, identify public exports, and group them logically
Generate
manifest.yaml
— All entries are initially
```
status: pending
```
; after saving to disk, validate the syntax with
```
validate-yaml.py --file docs/api/manifest.yaml --yaml-only
```
; show it to the user for review
User confirms the scope — The user can mark entries as
```
skipped
```
(internal implementation), adjust categories, merge or split entries; save the manifest to disk after confirmation

Phase 2: Generation — Single-entry or Batch

Mode A: Single-entry Mode

Suitable for 1-3 entries, or initial trial runs to confirm quality.

Select an entry → Read source_files → Generate according to the template → User review → Save to disk

After saving, validate with

validate-yaml.py --file {entry documentation path} --require doc_type --require entry --require status

Update the corresponding entry's
```
status: current
```
in
```
manifest.yaml
```

Mode B: Batch Mode

Suitable for a large number of

pending

entries in the manifest.

First create samples — Select 2-3 representative entries (different categories) from the manifest, go through "read source code → extract → generate according to template" and save them to disk, mark the status as
```
draft
```
first (do not directly set to current — in batch mode, samples serve as "style reference samples" and should be changed to current only after overall review)
User confirms quality standards — Review these 2-3 entries to confirm that the template, level of detail, and style meet expectations. This step cannot be skipped — 50 entries will be wasted if the user wants a different style
Batch generation — Process the remaining
```
pending
```
entries one by one through "read source code → extract → generate", subagents can be used for parallel processing; mark each generated entry as
```
status: draft
```
Overall review — After batch generation, show an overview (number of entries, number of skipped entries, number of pending confirmation entries); before review, run batch validation with
```
validate-yaml.py --dir docs/api --require doc_type --require entry --require status
```
, fix any errors first
Confirm and finalize — After user confirmation, batch change the status of samples and batch-generated entries to
```
status: current
```

Hard rules for batch mode:

Read source code independently for each entry — Even in batch mode, do not copy content from the previous entry and rename it. Two seemingly similar interfaces often have subtle differences, and copying and renaming will definitely miss them
Sample confirmation cannot be skipped — Reason as above
Mark entries with special source code structures (dynamic exports, code generation) as
skipped
with notes temporarily — Documentation guessed by force is more harmful than no documentation

Phase 3: Incremental Updates

Synchronize documentation after code changes.

Identify entries to update, choose any of the three entry points:
- ```
search-yaml.py
```
  to search for
```
status=outdated
```
  — Marked by architecture check or last update
- Compare source code files changed after
```
last_scanned
```
  in
```
manifest.yaml
```
- ```
search-yaml.py --sort-by last_reviewed --order asc
```
  to sort by the longest unreviewed entries first, select entries that "should be checked for accuracy" for active review
Re-read the source code → Compare with existing documentation → Incrementally update changed parts
Validate with
```
validate-yaml.py
```
to confirm that frontmatter is not damaged
Set
```
status: current
```
and fill in
```
last_reviewed
```
with the current date

Relationship with Other Workflows

Source	Relationship
`cs-feat-accept`	After acceptance, if new/modified public library interfaces are added → Push "Need to update libdoc?"
`cs-guide`	Guides reference libdoc for detailed references; libdoc links back to guides in the "Related Entries" section
`cs-arch` (check mode)	When it detects interface changes but libdoc is not synchronized, it marks the corresponding entry as `outdated` , which is handled in Phase 3 of this skill
`cs-feat-design`	Section 2 of the solution can be used as supplementary information source for libdoc (but source code takes precedence)
`cs-trick`	Cross-reference instead of duplicating content when libdoc's "Notes" overlap with tricks

Exit Conditions

Phase 1

```
manifest.yaml
```
has been saved to disk
The user has confirmed the entry scope (including reasons for skipped entries)
Entry granularity and output path have been confirmed

Phase 2 Single-entry

Entry documentation is generated according to the template, including complete frontmatter
API reference section information is extracted from source code (not fabricated)
User confirmation obtained
Corresponding entry's status in
```
manifest.yaml
```
has been updated

Phase 2 Batch

Samples (2-3 entries) have been confirmed by the user
All pending entries have been generated or marked as skipped
User has conducted an overall review
Status of all entries in
```
manifest.yaml
```
has been synchronized

Phase 3

All outdated entries have been updated or confirmed as not needing updates
No remaining outdated entries in
```
manifest.yaml
```
(unless the user explicitly delays)

Common Pitfalls

❌ Writing documentation without scanning the manifest — may miss entries or duplicate content
❌ Writing API references without reading the source code — libdoc's core value is accurately reflecting the source code
❌ Copying the previous entry and renaming it for the next — will definitely miss subtle differences
❌ Skipping sample confirmation in batch mode — 50 entries will be wasted
❌ Writing spec information (invariants, test constraints) into libdoc — belongs to
```
codestable/
```
❌ High overlap between libdoc and guidedoc content — overlap indicates that one of them has a wrong positioning
❌ Deleting lines directly in
```
manifest.yaml
```
— change to
```
status: skipped
```
and add a note
❌ Writing documentation for non-existent source code interfaces — use source code as the source of truth, do not fabricate

cs-libdoc

NPX Install

Tags

SKILL.md Content (Chinese)

cs-libdoc

Comparison with guidedoc

What is an "entry"

Involved Paths

manifest / Template / Source Code Extraction

Workflow

Phase 1: Initialization — Scanning and Manifest

Phase 2: Generation — Single-entry or Batch

Mode A: Single-entry Mode

Mode B: Batch Mode

Phase 3: Incremental Updates

Relationship with Other Workflows

Exit Conditions

Common Pitfalls