llm-wiki-roadmap-integration
Integrate repo-ecosystem work into an existing llm-wiki / knowledge-roadmap issue without creating duplicate GitHub issues.
Best use case
llm-wiki-roadmap-integration is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Integrate repo-ecosystem work into an existing llm-wiki / knowledge-roadmap issue without creating duplicate GitHub issues.
Teams using llm-wiki-roadmap-integration 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/llm-wiki-roadmap-integration/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How llm-wiki-roadmap-integration Compares
| Feature / Agent | llm-wiki-roadmap-integration | 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?
Integrate repo-ecosystem work into an existing llm-wiki / knowledge-roadmap issue without creating duplicate GitHub issues.
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.
SKILL.md Source
# LLM-Wiki Roadmap Integration
## Use when
- The user asks to "add what needs to be done" to an existing llm-wiki / knowledge-base issue portfolio
- The request spans both the central knowledge base and downstream repos
- There is a risk of creating duplicate umbrella issues instead of integrating existing work
## Core pattern
Do not default to creating new issues.
First determine whether the needed work already exists as:
1. an llm-wiki umbrella / roadmap issue
2. repo-specific remediation issues
3. a contract / policy issue tying the repo set together
If those already exist, integrate by editing the umbrella and cross-linking the dependency chain.
## Steps
1. Load context from the existing knowledge docs and roadmap artifacts.
- Read the llm-wiki unified review / operating model
- Read the latest issue-discovery handoff
- Read any tier-1 or repo-portfolio scorecards if the request mentions ecosystem or individual repos
- For current workspace-hub state, the highest-value docs are often:
- `docs/handoffs/2026-04-20-llm-wiki-strengthening-issue-discovery-exit-handoff.md`
- `docs/document-intelligence/llm-wiki-resource-doc-intelligence-operating-model.md`
- `docs/reports/2026-04-16-llm-wiki-resource-intelligence-unified-review.md`
- `docs/reports/llm-wiki-staged-batch-packs.md`
2. Search live GitHub issues before drafting anything.
- Look for the knowledge umbrella/epic
- Look for repo-specific remediation issues
- Look for a shared contract issue
- With `gh search issues`, prefer `--owner vamseeachanta` or explicit `repo:owner/name` qualifiers. Avoid relying on `user:vamseeachanta` inside a quoted query; the gh CLI can quote it into an invalid search string.
- Search both exact and broad terms, then deduplicate: `llm-wiki`, `"LLM Wiki"`, `knowledge/wikis`, `wiki knowledge`, repo-specific `repo:vamseeachanta/digitalmodel` queries.
3. Build the missing-work delta.
- Separate true gaps from already-open work
- If the gap is only missing integration, do not create new issues
- Inspect labels/status on the candidate issues, not just titles. `status:plan-review`, `status:plan-approved`, `wip:*`, and recent comments can change the correct next action.
- For llm-wiki roadmap reviews, always inspect the current umbrella body for later-added work streams. In this repo, #2390 may include Work Stream G for tier-1 repo routing/retrieval surfaces, which is easy to miss if only reading the older handoff.
4. Prefer this integration sequence:
- edit the existing umbrella/epic body to add a new work stream
- add the existing issue numbers as a grouped dependency set
- post a comment explaining why the new work stream belongs in the umbrella
- update the shared contract / parent issue to backlink the umbrella when useful
5. Verify after editing or reporting.
- re-read the umbrella body
- re-read the related issue body
- confirm the new section/comment actually rendered and uses the intended issue numbers
- If only producing a review summary, include the live repo split explicitly: central knowledge work in `workspace-hub`, individual-repo consumption/remediation issues such as `digitalmodel` #503 and workspace-hub tier-1 issues #2461-#2465.
## Reusable dependency model
For cross-repo knowledge work, use this framing:
- knowledge base / llm-wiki = durable cross-repo knowledge layer
- shared routing/index contract = portfolio-wide execution contract
- repo-specific remediation issues = landing pads for correct code/docs/tests placement
- daily freshness/audit issue = sustaining governance loop
## Why this works
This avoids duplicate issue trees and keeps the llm-wiki roadmap focused on compounding knowledge value while still acknowledging that knowledge only pays off when downstream repos have trusted routing surfaces.
## Pitfalls
- Do not create a second umbrella if an active roadmap issue already exists
- Do not create repo-specific issues if the repo remediation set already exists live
- Do not claim a repo-ecosystem gap is new without checking scorecards / handoffs / live issues
- Always verify the post-edit body and the cross-link comment
## Minimal deliverable
A successful run usually produces:
- one umbrella body edit
- one explanatory roadmap comment
- one backlink edit on the contract/parent issue
- zero new issues unless a true gap remainsRelated 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.
library-evaluation-integration
Create evaluation scripts and integration tests for Python scientific libraries in the digitalmodel package. Follows the established pattern from fluids, ht, meshio, sectionproperties, and pygmt evaluations.
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.
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/.
clean-worktree-integration-from-dirty-main
Land validated issue work from isolated worktrees when the main checkout is dirty by creating a fresh integration worktree, cherry-picking only implementation commits, re-running combined validation, and preparing push/closeout artifacts.