oss-wiki-development-arc
Three-phase methodology (Substrate → Depth → Quality) for building open-source engineering wikis efficiently. Skip 70%+ of empirical iteration cost by pre-loading the pattern.
Best use case
oss-wiki-development-arc is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Three-phase methodology (Substrate → Depth → Quality) for building open-source engineering wikis efficiently. Skip 70%+ of empirical iteration cost by pre-loading the pattern.
Teams using oss-wiki-development-arc 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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/oss-wiki-development-arc/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How oss-wiki-development-arc Compares
| Feature / Agent | oss-wiki-development-arc | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Three-phase methodology (Substrate → Depth → Quality) for building open-source engineering wikis efficiently. Skip 70%+ of empirical iteration cost by pre-loading the pattern.
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.
Related Guides
SKILL.md Source
# OSS-Wiki Development Arc — Three-Phase Methodology
**Empirical basis:** Traced across 38 iterations of [llm-wiki](https://github.com/vamseeachanta/llm-wiki) (iter-22 → iter-59, V1 → V17 audit lineage). Phases were observed, not designed; this skill codifies them so future wiki projects can pre-load the pattern.
## The 3-Phase Pattern
| Phase | Audit-version range | Iters observed | Marginal-cost signature | Exit criterion |
|-------|--------------------|----------------|------------------------|----------------|
| **1. Substrate** | V1 → V11 | ~27 | Cheap breadth wins | substrate-fill marginal-cost > marginal-value |
| **2. Depth** | V12 → V15 | ~7 | Compounding per-page value via 4-element recipe | median per-iter line-growth <50% + thin-starter cohort exhausted |
| **3. Quality** | V15 → V17 | ~2 | Diagnose-then-execute closure | 4-criterion publication-readiness gate met |
Each phase has a distinct iter-shape, distinct success metric, and distinct saturation signal. Mixing phases (e.g., depth-expanding while substrate is incomplete) wastes effort because depth-content depends on substrate-resolvers being citable.
## When To Use This Skill
- Bootstrapping a new engineering/marine/scientific OSS wiki (greenfield)
- Resuming work on a stalled wiki (which phase are we in?)
- Diagnosing wiki-development thrash ("we keep adding pages but nothing improves")
- Auditing a wiki for publication readiness
## When NOT To Use
- Closed/internal documentation projects (audit-trail, governance constraints differ)
- Single-page reference docs (no substrate/depth/quality distinction)
- Wikis whose authoritative content is mirrored from elsewhere (use sync tooling, not this arc)
## Phase Invocation
Read the phase-specific reference before kicking off iter-N+1. Each reference is self-contained — a future agent can apply it without reading the others.
- **Phase 1 — Substrate:** `references/phase-1-substrate.md`
- 4-agent fanout (audit + 2-3 content lanes + bridge)
- Goal: every concept page links to a resolver page; every entity has a stub; substrate-completeness measured per-wiki
- **Phase 2 — Depth:** `references/phase-2-depth.md`
- Top-N inbound-citation candidate selection
- 4-element recipe per expanded page (worked example + comparison table + ≥30 outbound intra-wiki links + cross-link to entity/source)
- 3-cohort growth-profile (thin-starter +200-300% / mid-tier +100-130% / already-expanded +35-50%)
- **Phase 3 — Quality:** `references/phase-3-quality.md`
- Diagnose-then-execute 2-iter cycle
- 4-criterion gate: orphans ≤3 + unidir-bridges=0 + frontmatter consistency + link-integrity ≥99%
Supporting references applicable to all phases:
- `references/audit-template.md` — audit-doc structure + V1→V17 measurement-discipline progression
- `references/iter-shape-recipes.md` — 4-agent fanout default; bundled-sequential exception (W231 race-block lesson)
- `references/cross-wiki-bridges.md` — sister-pair pattern; sibling-template recognition; substantive (not "see also") bridge content
## Saturation-Detection Signals
Before kicking off another iter in the current phase, verify the saturation signal hasn't fired:
| Phase 1 → 2 transition | Phase 2 → 3 transition | Phase 3 → publish |
|------------------------|------------------------|-------------------|
| Substrate-fill audit identifies <3 high-value gaps per wiki | Median per-iter line-growth across top-N pages drops <50% | All 4 closure criteria green simultaneously across 1 audit cycle |
| Cross-wiki edge-density plateaus | Thin-starter cohort exhausted (no <100-line top-citation pages remain) | Frontmatter mismatch count = 0 |
| Resolver-coverage ≥95% on canonical concept set | Already-expanded cohort dominates the next-target list | unidir-bridges = 0 (every cross-wiki link is reciprocated) |
If a saturation signal fires while in-phase, **transition** rather than spend another substrate-iter or depth-iter; the marginal value has collapsed.
## Reference Exemplar
[vamseeachanta/llm-wiki](https://github.com/vamseeachanta/llm-wiki) — public OSS wiki where this arc was empirically traced. Repository structure, audit-doc lineage (`docs/audits/V1.md` … `V17.md`), and iter-shape decisions are all visible.
## Critical Cost-Avoidance
A future wiki using this skill should:
1. Start with the **audit-doc skeleton** (see `audit-template.md`) on iter-1, not iter-15. Most of llm-wiki's measurement-discipline gain happened V12→V15; loading it pre-baked saves ~10 iters of audit-format churn.
2. Adopt the **4-agent fanout default** from iter-1. Solo-author iters were the dominant low-throughput pattern in llm-wiki's V1-V8.
3. Track **inbound-citation count per page** from iter-1 (substrate-phase metric is just count; depth-phase ranks by it). This avoids retroactive instrumentation.
4. Resist the urge to depth-expand before substrate is saturated. Depth-content references resolvers; if resolvers are stubs, the cross-links don't compound.Related Skills
llm-wiki-weekly-freshness
Class-level governance workflow for keeping llm-wiki-style markdown knowledge bases current, public-safe, graph/index-valid, and useful for code development. Use when reviewing llm-wiki architecture/content, scanning new LLM concepts, maintaining public knowledge graphs, producing an issue roadmap, or running recurring freshness cadence.
llm-wiki-source-extraction-coverage
Doc-type-aware extraction contract for llm-wiki source ingestion with measurable coverage and source-anchored traceability. Use when (1) ingesting a PDF, DOCX, XLSX, PPTX, HTML, or scanned-image source into a wiki `sources/` page, (2) computing the pre-extraction estimate (what fraction of the source we expect to recover) and post-extraction yield (what fraction we actually recovered), (3) anchoring wiki claims back to specific page / paragraph / cell / slide positions in the source so a reviewer can re-verify or revise against the actual document, (4) deciding whether OCR fallback or manual transcription is needed. Codifies workspace-hub's existing OCR fallback chain and python-docx / openpyxl / trafilatura patterns into a format-specific routing table. Companion to research/llm-wiki-page-shape-contract (Rule 7 input-layer pages) and research/llm-wiki — this skill is the defense against silent extraction failure.
llm-wiki-public-private-routing
Firewall between the public llm-wiki repo (vamseeachanta/llm-wiki, MIT + CC-BY-4.0) and per-client private wikis (vamseeachanta/llm-wiki-<client>, e.g. llm-wiki-mkt-a per #2746). Use when (1) deciding whether a converted wiki page lands in public or private surface, (2) applying the project-name abstraction rule to public-bound content, (3) evaluating the public- availability exception that lets actual project names pass through unmodified, (4) promoting content from private to public after sanitization. Encodes the 2026-05-20 user routing directive verbatim: exact client results → private; abstracted (project-name only) → public; project name + all key data publicly available → exception applies. Companion to research/llm-wiki-page-shape-contract (which calls this skill at Rule 8) and research/llm-wiki-source-extraction-coverage (which produces the source pages this skill decides where to send).
llm-wiki-page-shape-contract
Enforce the page-shape contract when a repo-side document or analysis output gets converted into an llm-wiki page. Use when (1) running `scripts/knowledge/llm_wiki.py ingest`, (2) writing or rewriting a wiki page from docs/reports/*, docs/handoffs/*, scripts/review/results/*, or calc citation outputs, (3) deciding whether a page should be split into a folder of sub-pages, (4) reviewing wiki PRs for length / diagram / divide-and-conquer compliance. Codifies the Karpathy + Astro-Han + lewislulu page rules applied to workspace-hub's domain-wiki layout under /mnt/local-analysis/llm-wiki/wikis/<domain>/. Sibling to research/llm-wiki (which owns the CLI ops) — this skill is the quality gate every converted page must clear before commit.
llm-wiki-cadence-governance
Weekly governance workflow for keeping an llm-wiki repository current, code-development-useful, and connected to actionable GitHub issue planning.
llm-wiki-audit-feedback-loop
Durable feedback loop for correcting llm-wiki pages without losing the correction to chat history. Use when (1) a human notices a wiki page is wrong, outdated, or contradicts a source, (2) processing the `audit/` inbox of a domain wiki, (3) reviewing what feedback has been resolved vs deferred, (4) needing to leave a comment on a specific text range that survives line- number drift. Implements the anchored-text audit file pattern from lewislulu/llm-wiki-skill, adapted for workspace-hub's domain-wiki layout under /mnt/local-analysis/llm-wiki/wikis/<domain>/. Extends the 5-op model (compile/ingest/query/lint) from research/llm-wiki with the missing `audit` op. Never silently delete feedback — rejected audits stay archived with rejection rationale.
client-llm-wiki-factory
Operator checklist for instantiating a new per-client private llm-wiki repo under workspace-hub [#2746](https://github.com/vamseeachanta/workspace-hub/issues/2746) + [#2731](https://github.com/vamseeachanta/workspace-hub/issues/2731) D4 (amended) naming convention `llm-wiki-<client>`.
metadata-only-wiki-sweep-workflow
Disciplined inventory process for cataloging documents by filename/path without content claims, using parent-centric grouping to prevent stub proliferation
exclude-wiki-Codex-md-from-harness-line-limit-hook
Fix false-positive pre-commit failures where workspace-hub's AGENTS.md line-limit hook blocks edits to auto-generated wiki schema files under knowledge/wikis/.
repair-legacy-llm-wiki-frontmatter-dates
Diagnose and repair legacy llm-wiki source pages that have ingested timestamps but are missing required added/last_updated frontmatter dates.
parallel-llm-wiki-gap-to-issues
Use parallel subagents to mine remaining LLM-wiki/document-intelligence gaps, de-duplicate against existing GitHub issues, then create only the strongest bounded follow-on issues.
llm-wiki-ecosystem-gap-to-issues
Review the workspace-hub LLM-wiki/document-intelligence ecosystem, identify high-leverage gaps, and create grounded GitHub feature issues without duplicating existing work.