GL
Skill19 starsChanged 9 months agoMITView on GitHub
Grand Library: Full-stack documentation skill that transforms project ideas into comprehensive specification suites. Guides greenfield projects from idea to spec, or analyzes existing codebases to fill documentation gaps. Run /GL for a getting-started guide, or /GL:survey to begin.
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 4 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
Look for .claude/svk-meta.json in the current project.
- Very specific: line 22
Read the svk_repo path and installed_version from the metadata file.
- Very specific: line 24
Run: git -C <svk_repo> tag --sort=-v:refname | head -1 to get the latest tag.
- Distinctive: line 26
If they match, skip — the user is up to date.
- Distinctive: line 27
If the latest tag is newer, show this message ONCE (never repeat in this session):
- Distinctive: line 33
If the git commands fail (offline, repo moved, etc.), skip silently.
- Distinctive: line 35
Important: Do NOT block or delay the user's actual command.
- Very specific: line 103
Run /clear between each phase for fresh context windows.
- Very specific: line 113
Check progress anytime with /GL:status.
- Very specific: line 130
All Grand Library artifacts are written to a .docs/ directory in the project root:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- SVK Version Check — runs once per session on first skill invocation --><svk-version-check>
**On first invocation this session**, silently perform a version check:- Look for
.claude/svk-meta.jsonin the current project. If it doesn't exist, skip this check entirely. - Read the
svk_repopath andinstalled_versionfrom the metadata file. - Run:
git -C <svk_repo> fetch --tags --quiet 2>/dev/null - Run:
git -C <svk_repo> tag --sort=-v:refname | head -1to get the latest tag. - Compare the installed version against the latest tag (strip the leading
v). - If they match, skip — the user is up to date.
- If the latest tag is newer, show this message ONCE (never repeat in this session):
SVK Update Available: v{latest} is available (you're on v{installed}).
- Update now: I can pull and reinstall the changed skills in this session
- Update later: Start a new chat and run
/SVK:update
- If the git commands fail (offline, repo moved, etc.), skip silently. Never show errors from version checking.
Important: Do NOT block or delay the user's actual command. Perform this check, show the notification if needed, then proceed with the command they invoked.
</svk-version-check>
Grand Library
A full-stack documentation skill that eliminates coin-flip decisions by making every choice explicit, validated, and written down.
"Every undocumented decision is a coin flip when an LLM builds your project."
Getting Started
Grand Library runs as a multi-phase pipeline. Each phase is a separate command with its own fresh context window.
Quick Start
/GL:surveyThis begins by discovering your project — greenfield or existing code — and proposing a documentation plan. Follow the prompts; each phase tells you what was produced and what to run next.
Full Pipeline
┌─────────────────────────────────────────────────────────────────────┐
│ GRAND LIBRARY v1.0 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ /GL:survey Phase 0 — Project Discovery │
│ ════════════ Detect: greenfield or existing code? │
│ Greenfield: ask high-level vision questions │
│ Existing: scan codebase, build index, identify what exists │
│ Output: PROJECT_BRIEF.md, DOC_MANIFEST.md │
│ │ │
│ ▼ │
│ /GL:interview Phase 1 — Deep Interview │
│ ════════════════ Topic-by-topic structured Q&A │
│ Adaptive branching within topics │
│ Research-backed options for micro-decisions │
│ Output: DECISIONS/*.md (per-topic), updated PROJECT_BRIEF.md │
│ │ │
│ ▼ │
│ /GL:draft Phase 2 — Document Generation │
│ ═══════════ Wave-based parallel doc writing │
│ Wave 1: Foundation docs (overview, architecture, data model) │
│ → User validates Wave 1 → │
│ Wave 2+: Feature specs, flows, references, creative docs │
│ Output: .docs/<all-documents>.md │
│ │ │
│ ▼ │
│ /GL:reconcile Phase 3 — Reconciliation (Opus) │
│ ════════════════ Cross-check ALL docs for contradictions │
│ Identify gaps, unanswered questions, implicit assumptions │
│ Verify every decision from interview is reflected in docs │
│ Output: RECONCILIATION_REPORT.md, updated docs │
│ │
│ /GL:status Check progress anytime │
│ /GL:repos Browse forkable open source repo catalogue │
│ /GL:update Re-interview a topic, regenerate affected docs │
│ /GL:add Add a new document to the suite │
│ │
└─────────────────────────────────────────────────────────────────────┘Typical Workflow
Run /clear between each phase for fresh context windows.
/GL:survey— Discover the project, propose doc manifest/clear/GL:interview— Deep topic-by-topic Q&A (may need multiple sessions)/clear/GL:draft— Generate all documents (validate Wave 1 before continuing)/clear/GL:reconcile— Cross-check everything, resolve conflicts
Check progress anytime with /GL:status.
Foundation Patterns
| Pattern | How Grand Library Uses It |
| Thin Orchestrator | /GL:draft orchestrator spawns doc-writing subagents |
| Signal-Based Indexing | Existing code scanning in survey, domain pack loading |
| Progressive Disclosure | Skill structure, domain pack INDEX.md → on-demand knowledge |
| Structured Handoff | DECISIONS/*.md, PROJECT_BRIEF.md, doc frontmatter |
Output Structure
All Grand Library artifacts are written to a .docs/ directory in the project root:
.docs/
├── STATE.json
├── PROJECT_BRIEF.md
├── DOC_MANIFEST.md
├── DECISIONS/
│ ├── architecture.md
│ ├── token-model.md
│ └── ...
├── <generated docs>
└── RECONCILIATION_REPORT.mdModel Allocation
| Phase | Component | Model |
| Survey | Code scanning subagents | Haiku |
| Survey | Orchestrator / doc manifest | User's context |
| Interview | Conversation | User's context |
| Interview | Research subagents | Sonnet |
| Interview | Fork opportunity verification | Haiku |
| Repos | Catalogue browsing | User's context |
| Repos | Live verification | Haiku |
| Draft | Doc-writing subagents | Opus |
| Reconcile | Cross-check + gap analysis | Opus |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

