{"id":51708859,"url":"https://github.com/ejklock/living-docs-skill","last_synced_at":"2026-07-21T00:58:49.725Z","repository":{"id":366017282,"uuid":"1274759471","full_name":"ejklock/living-docs-skill","owner":"ejklock","description":"Living Docs —  a AI agent skill that runs your project's documentation as a living system: constitution, ADRs, BDRs, PRDs, issues, research notes \u0026 Mermaid architecture diagrams under five no-drift governance invariants. OKF-formatted, stack-agnostic. Works with Claude Code, Cursor, Copilot, OpenCode \u0026 Pi.","archived":false,"fork":false,"pushed_at":"2026-07-20T17:13:35.000Z","size":646,"stargazers_count":6,"open_issues_count":0,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-07-21T00:58:18.941Z","etag":null,"topics":["adr","agent-skills","ai-agents","architecture-decision-records","bdr","claude-code","claude-skill","cursor","docs-as-code","documentation","github-copilot","knowledge-management","living-documentation","markdown","mermaid","okf","open-knowledge-format","prd","software-architecture","technical-writing"],"latest_commit_sha":null,"homepage":"https://github.com/ejklock/living-docs-skill","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ejklock.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-06-19T21:32:09.000Z","updated_at":"2026-07-21T00:26:26.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/ejklock/living-docs-skill","commit_stats":null,"previous_names":["ejklock/living-docs-skill"],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/ejklock/living-docs-skill","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ejklock%2Fliving-docs-skill","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ejklock%2Fliving-docs-skill/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ejklock%2Fliving-docs-skill/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ejklock%2Fliving-docs-skill/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ejklock","download_url":"https://codeload.github.com/ejklock/living-docs-skill/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ejklock%2Fliving-docs-skill/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":35704583,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-07-20T02:08:10.276Z","status":"ssl_error","status_checked_at":"2026-07-20T02:08:09.736Z","response_time":111,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["adr","agent-skills","ai-agents","architecture-decision-records","bdr","claude-code","claude-skill","cursor","docs-as-code","documentation","github-copilot","knowledge-management","living-documentation","markdown","mermaid","okf","open-knowledge-format","prd","software-architecture","technical-writing"],"created_at":"2026-07-16T19:00:21.321Z","updated_at":"2026-07-21T00:58:49.713Z","avatar_url":"https://github.com/ejklock.png","language":"Rust","funding_links":[],"categories":["Source Catalog"],"sub_categories":[],"readme":"# Living Docs\n\n**Run a project's documentation as a living system — not a write-once artifact that rots.**\n\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)\n[![Format: OKF](https://img.shields.io/badge/Format-OKF%20v0.1-blue.svg)](skills/okf-knowledge-format/reference/SPEC.md)\n[![Skill: agent-ready](https://img.shields.io/badge/Skill-agent--ready-success.svg)](#whats-in-the-box)\n[![Works with: Claude Code · Cursor · Copilot · OpenCode · Codex · Pi](https://img.shields.io/badge/Works%20with-Claude%20Code%20·%20Cursor%20·%20Copilot%20·%20OpenCode%20·%20Codex%20·%20Pi-8A2BE2.svg)](#installation)\n\n![Living Docs — the doc trail: constitution → PRD → ADR + BDR → issues → code](assets/doc-trail.svg)\n\nLiving Docs is an **AI agent skill** for **documentation-as-code** that keeps a\ncodebase's docs in sync with its code. It works with **Claude Code**, **Cursor**,\n**GitHub Copilot**, **OpenCode**, **Codex**, and **Pi** — any agent that loads\nmarkdown \"skills\" / instruction files. It is stack-agnostic: it governs *how* docs are\norganized and maintained (Architecture Decision Records, Behavior Decision\nRecords, PRDs, a constitution, a glossary, living\n[Mermaid](https://mermaid.js.org/) diagrams), never *what* technology a project\nuses.\n\nThe whole discipline collapses to one spine:\n\n\u003e **Every piece of knowledge has exactly one home, that home is indexed, and\n\u003e nothing structural ships without its doc.**\n\nEverything else — the constitution, ADRs, BDRs, PRDs, issues, research notes,\narchitecture diagrams, and the semantic context index — hangs off that spine.\n\n---\n\n## Why this exists\n\nMost documentation rots because there is no contract keeping it honest. Living\nDocs adds five governance invariants that an agent (or a human) can re-derive\nevery action from:\n\n1. **Docs-first.** Author the body in the repo (`docs/…`) *before* publishing\n   to any tracker or wiki. The repo file is the source of truth; the external\n   copy is a mirror.\n2. **One home per fact.** Each concept, decision, or requirement lives in\n   exactly one file. Cross-reference instead of copying — duplicated prose is\n   drift waiting to happen.\n3. **Indexed or it doesn't exist.** Every doc is reachable from an `index.md`.\n   No orphan files.\n4. **Supersede, never rewrite history.** Decisions and requirements are\n   append-only. When something changes, mark the old record superseded and\n   write a new one — never silently edit the past.\n5. **No structural change without its doc.** New module, moved files, schema\n   change, new data flow → update the relevant doc *and its diagram* in the\n   same change. No \"I'll document it later.\"\n\nThese invariants are carried **in YAML frontmatter as a fact contract** and wired\nto a deterministic checker (the `living-docs` CLI). The pitch is **not** novelty —\narc42 + ADR + C4 + docs-as-code is a well-trodden stack — it is the **explicit,\nagent-enforceable packaging** of it. See [Provenance](#provenance--honest-attribution).\n\n![The five no-drift invariants of Living Docs](assets/invariants.svg)\n\n---\n\n## The doc trail\n\nEvery change follows one chain, from the foundational source of truth down to\ncode:\n\n```mermaid\nflowchart LR\n  C[constitution] --\u003e P[PRD]\n  P --\u003e A[ADR]\n  P --\u003e B[BDR]\n  A --\u003e I[issues]\n  B --\u003e I\n  I --\u003e K[code]\n```\n\n| Artifact | Role |\n|---|---|\n| **constitution** | Foundational source of truth: what the product is, core data model, non-negotiables. |\n| **PRD** | What the system must do and why — feature/product requirement spec. |\n| **ADR** | How the system is structured — architectural/implementation decision and rationale. |\n| **BDR** | What the system must observably do — inputs, outputs, side effects, Given/When/Then scenarios. |\n| **issues** | Execution slices — discrete units of work that trace back to ADRs/BDRs. |\n| **code** | Implementation — every behavior, structure, and interface specified above, realized. |\n\n---\n\n## What's in the box\n\nThis repo bundles the Living Docs skill together with its two composition\ndependencies and the prior-art research that backs its honesty claims:\n\n| Path | What it is |\n|---|---|\n| [`skills/living-docs/`](skills/living-docs/) | The skill: the five invariants, the doc trail, per-doc-type conventions (`rules/`) and starter templates (`templates/`). |\n| [`skills/okf-knowledge-format/`](skills/okf-knowledge-format/) | The **format** standard the docs use — Open Knowledge Format (OKF): markdown + YAML frontmatter, required `type`, reserved `index.md`/`log.md`, bundle-relative links. The OKF spec is **vendored verbatim** from Google Cloud Platform. |\n| [`skills/research-artifacts/`](skills/research-artifacts/) | The research-note format and source discipline that feeds ADRs/PRDs (the `docs/research/` half of the trail). |\n| [`references/prior-art-landscape.md`](references/prior-art-landscape.md) | The sourced prior-art analysis — every part of Living Docs (the doc trail, the OKF format, the diagrams, the governance invariants) mapped to its established originator, so every \"credit, not invention\" claim has a checkable citation. |\n| [`cli/`](cli/) ([`living-docs check`](cli/)) | The **deterministic checker** for the mechanical invariants — frontmatter/`type`, indexing + reachability, link resolution, supersede integrity. A single self-contained Rust binary: native `serde_yaml` frontmatter parsing and native `pulldown-cmark` link extraction/resolution — no host tools (no lychee/yq/jq) needed. *A constraint without an instrument is a vibe*; this is the instrument. Wire it into CI. Install with `./install.sh cli` or `make cli-install`. |\n| [`cli/`](cli/) (`living-docs check --mermaid-only`) | Validates every fenced ```` ```mermaid ```` block **in-process** via the pure-Rust [`merman-core`](https://crates.io/crates/merman-core) parser — the real Mermaid grammar, not a hand-rolled check — and fails with a `file:line` pointer at the first broken diagram. **No Docker, no daemon, no Chromium** ([ADR 0013](docs/adr/0013-mermaid-validation-runs-in-process-via-merman-core-not-a-docker-mermaid-cli-shell-out.md)): the same self-contained binary does it. With no path argument it sweeps every git-tracked `.md` file in the repo. |\n| [`examples/linkly/`](examples/linkly/) | A worked, **lint-clean** end-to-end corpus (constitution → PRD → ADR + BDR → issue) for a fictional URL shortener — the discipline shown, not just described, and the fixture CI runs `living-docs check` against. |\n\nEach skill is self-describing — open its `SKILL.md` for the full operational\ndetail. Living Docs and OKF compose but do not overlap: **Living Docs governs\n*which* docs exist and the no-drift discipline; OKF governs *how* a knowledge\nbundle's markdown and frontmatter are shaped.**\n\n---\n\n## Installation\n\nThe skill is plain **markdown instruction files** — nothing to compile or install to use it. The optional `living-docs` checker is a single self-contained Rust binary with **no host-tool dependencies at all**: native frontmatter and link parsing (no lychee/yq/jq) and — since **v0.6.0** — in-process Mermaid validation via the pure-Rust `merman-core` parser, so `--mermaid-only` **no longer needs Docker**. Install it with `./install.sh cli` or `make cli-install`.\nInstalling Living Docs always means the same thing: **put the three `skills/`\ndirectories (or a generated rule file) where your tool discovers instructions,\nthen start a fresh session.** A cross-platform installer and a `Makefile` do this\nfor every supported tool. Clone once:\n\n```bash\ngit clone https://github.com/ejklock/living-docs-skill.git\ncd living-docs-skill\n```\n\n### Quick start — `install.sh` / `make`\n\n```bash\n./install.sh                 # Claude Code, global (~/.claude/skills) — the default\n./install.sh cursor          # Cursor rule in the current project\n./install.sh copilot         # GitHub Copilot instruction in the current project\n./install.sh opencode        # OpenCode (~/.config/opencode/skills)\n./install.sh codex           # Codex (~/.codex/skills)\n./install.sh pi              # Pi (~/.pi/agent/skills + AGENTS.md)\n./install.sh all             # every supported harness at once\n```\n\nUseful flags: `--project` (install into the current repo instead of the global\nuser dir), `--dir \u003cpath\u003e` (custom skills directory), `--uninstall`, `--dry-run`,\n`--help`. The same targets are available via `make`:\n\n```bash\nmake help            # list every target\nmake install         # Claude Code, global\nmake install-cursor  # or install-copilot / install-opencode / install-codex / install-pi / install-all\nmake project-claude  # install into the current project\nmake uninstall-all   # remove from every harness\nmake check           # full gate: version sync · living-docs check the example ·\n                     #   validate mermaid · hostile parser fixtures · bash -n all\n                     #   scripts · dry-run every harness\nmake build           # build the living-docs binary natively -\u003e target/release/living-docs\nmake cli-install     # install the living-docs binary onto PATH (native cargo install)\nmake test-fixtures   # run the hostile/negative fixtures guarding the parsers\n```\n\n### Where each tool loads from\n\n| Tool | Mechanism | Default location (global · `--project`) |\n|---|---|---|\n| **Claude Code** | native `SKILL.md` skills | `~/.claude/skills` · `.claude/skills` |\n| **OpenCode** | native `SKILL.md` skills (also reads `.claude/skills`) | `~/.config/opencode/skills` · `.opencode/skills` |\n| **Codex** | native `SKILL.md` skills | `~/.codex/skills` · `.codex/skills` |\n| **Cursor** | project rule | `.cursor/rules/living-docs.mdc` (project-scoped) |\n| **GitHub Copilot** | path-scoped instruction | `.github/instructions/living-docs.instructions.md` (project-scoped) |\n| **Pi** | skills dir + `AGENTS.md` pointer | `~/.pi/agent/skills` · `.pi/skills` |\n\n**Claude Code**, **OpenCode**, and **Codex** share the same model: they\nauto-discover folders of `SKILL.md` files from their skills directory, so the\ninstaller just copies the three skills there (OpenCode additionally reads\n`.claude/skills`, so a Claude install already covers it). For **Cursor** and\n**Copilot** the installer generates the rule/instruction file with the right\nfrontmatter header (`globs` / `applyTo` scoped to `docs/**` and `**/*.md`) from\n`living-docs/SKILL.md`. **Pi** has no native skills directory — after the skills\nare copied, reference them once from your `AGENTS.md`:\n\n```markdown\n## Living Docs\nFollow the documentation discipline in skills/living-docs/SKILL.md,\nskills/okf-knowledge-format/SKILL.md, and skills/research-artifacts/SKILL.md.\n```\n\nThen restart the session so the tool picks up the skills.\n\n### Skill content — served by the CLI, not copied to disk\n\nNative harnesses (Claude Code, OpenCode, Codex, Pi) only get each skill's slim\n`SKILL.md` stub (plus `okf-knowledge-format/reference/`, the vendored spec) — the\nfull per-doc-type conventions (`rules/`) and starter templates (`templates/`)\ntravel **inside the `living-docs` binary** ([ADR 0014](docs/adr/0014-the-cli-serves-skill-content-from-an-embedded-corpus-harness-skill-md-files-are-slim-stubs.md))\nand are reached with `living-docs skill`, not by reading files off disk:\n\n```bash\nliving-docs skill --list                          # every embedded skill and its topics\nliving-docs skill living-docs                      # the full living-docs/SKILL.md body\nliving-docs skill living-docs --topic adr           # just the adr topic's rules (+ template)\n```\n\nOutput is **context-aware**: piped or otherwise non-TTY output defaults to minified\nsingle-line JSON (the machine-friendly shape another agent parses); a real terminal\ngets human-readable plain text. `--json` and `--plain` override the autodetection in\neither direction and are mutually exclusive. This is why a native harness install is\na small, stable footprint on disk while the authoritative detail stays centralized in\none versioned binary — see [ADR 0014](docs/adr/0014-the-cli-serves-skill-content-from-an-embedded-corpus-harness-skill-md-files-are-slim-stubs.md).\n\n### Any other tool\n\nCopy `skills/living-docs/`, `skills/okf-knowledge-format/`, and\n`skills/research-artifacts/` into wherever that tool loads instructions from, or\njust read the `SKILL.md` files — they are plain markdown meant to be read by\nhumans and agents alike.\n\n### Companion skills (Matt Pocock) — recommended, not bundled\n\nLiving Docs *composes with* but does **not** bundle Matt Pocock's skills. His\n`grill-me` (design interview before a load-bearing decision) pairs directly with\nLiving Docs, and his `to-prd` / `to-issues` are kindred to the PRD/issues\nworkflow here. They are best installed **straight from the source** so they stay\ncanonical and up to date — his repo is MIT-licensed, so cloning and using it is\npermitted (keep his `LICENSE` notice if you copy files):\n\n```bash\n./install.sh pocock          # git clones his repo (default ~/.matt-pocock-skills)\n# or by hand:\ngit clone https://github.com/mattpocock/skills.git\n# his repo ships a `setup-matt-pocock-skills` skill that wires them up\n```\n\nSee [`ATTRIBUTION.md`](ATTRIBUTION.md) for how Living Docs relates to his work.\n\n---\n\n## When to invoke\n\n- Standing up documentation for a project (`docs/` structure, the docs index,\n  ADR/issue/BDR/constitution directories).\n- Writing or editing an **ADR**, **PRD**, **BDR**, **constitution**, or\n  **issue** → load the matching `rules/` + `templates/` file.\n- Recording **research** → the `research-artifacts` skill.\n- Drawing or updating an **architecture / data-flow / sequence diagram**\n  (living Mermaid, in-repo text that must match the code).\n- Defining a **term or acronym** → the glossary, one home per term.\n- A doc grew too large or mixes concerns → **split into a semantic index**.\n- Enforcing the **no-drift maintenance rule** after any structural change.\n\n---\n\n## Composition with other skills\n\nLiving Docs is deliberately small and composes with the rest of your toolchain\nrather than absorbing it: design grilling before a load-bearing ADR, an\narchitecture-improvement pass that reads the context index and ADRs, a\ndeep-research step that gathers the evidence `research-artifacts` then formats,\nand an implementation-review step that checks code honors the ADRs/BDRs. See the\n\"Composition with other skills\" section in\n[`skills/living-docs/SKILL.md`](skills/living-docs/SKILL.md) for the full map.\n\n\u003e The design-grilling step composes with **`grill-me`** by\n\u003e **Matt Pocock** ([github.com/mattpocock/skills](https://github.com/mattpocock/skills))\n\u003e — referenced, not bundled here. See [`ATTRIBUTION.md`](ATTRIBUTION.md).\n\n---\n\n## Provenance — honest attribution\n\n**This work instrumentalizes established practices; it does not invent them.**\n\"Living documentation\" is Cyrille Martraire's named methodology; ADRs are\nMichael Nygard's (supersede-don't-delete is the adr-tools convention); BDRs wrap\nSpecification by Example / BDD (Adzic; North); the file format is Google Cloud\nPlatform's OKF, vendored verbatim; the architecture diagrams are\n[Mermaid](https://mermaid.js.org/) (Knut Sveidqvist \u0026 the mermaid-js community).\nNone of the doc types are invented here. What is original is modest and concrete: the\n**composition + the governance invariants** carried in frontmatter as a fact contract\n**and enforced by a checker** — the *enforcement*, not the *invention*.\n\nFull credits and the per-source links are in\n[`ATTRIBUTION.md`](ATTRIBUTION.md) and\n[`references/prior-art-landscape.md`](references/prior-art-landscape.md).\n\n---\n\n## Contributing\n\nIssues and PRs welcome — the project dogfoods its own rules. See\n[`CONTRIBUTING.md`](CONTRIBUTING.md) for the repo layout, the invariants it holds\nitself to, how to refresh the vendored OKF spec, and how to validate a change —\n`make check` runs the full gate: version sync, the docs linter, the hostile parser\nfixtures, `bash -n` on every script, and a dry-run of every installer.\n\n---\n\n## FAQ\n\n**What is an \"agent skill\"?**\nA skill is a folder of markdown instructions (a `SKILL.md` plus optional `rules/`\nand `templates/`) that an AI coding agent loads and follows. Living Docs is a\nskill that teaches the agent how to keep documentation in sync with code.\n\n**Which tools does Living Docs work with?**\nClaude Code, OpenCode, and Codex (native `SKILL.md` skills), Cursor\n(`.cursor/rules`), GitHub Copilot (`.github/instructions`), and Pi (`AGENTS.md`).\nBecause the skill is plain markdown, any agent that reads instruction files can\nuse it. See [Installation](#installation).\n\n**How is this different from a documentation generator or a wiki?**\nLiving Docs is not a generator and not a hosting tool. It is a *discipline* — five\nno-drift governance invariants plus a doc trail (constitution → PRD → ADR + BDR →\nissues → code). The agent **follows** the discipline as it works; a deterministic\nchecker (`living-docs check`) **verifies** the mechanical half when you wire it into\nCI or the agent's loop. Prompt-level guidance plus a machine check — not one\npretending to be the other. Your docs live in the repo, in Git, next to the code.\n\n**What is an ADR / BDR / PRD?**\nAn **ADR** (Architecture Decision Record) captures *how* the system is structured\nand why. A **BDR** (Behavior Decision Record) captures *what* the system must\nobservably do (Given/When/Then). A **PRD** captures the product/feature\nrequirements. Each has a convention file and a starter template under\n[`skills/living-docs/`](skills/living-docs/).\n\n**What is OKF (Open Knowledge Format)?**\nA vendor-neutral format from Google Cloud Platform — markdown with YAML\nfrontmatter, a required `type`, reserved `index.md`/`log.md`, and bundle-relative\nlinks. Living Docs stores every doc as an OKF concept so the corpus stays\nportable and agent-parseable. The spec is vendored under\n[`skills/okf-knowledge-format/`](skills/okf-knowledge-format/).\n\n**What does the `living-docs check` checker catch — and not catch?**\nIt is a deterministic checker over a *documented input shape*, not a general markdown/YAML validator, and its three fragile parsers (link extraction, link resolution, frontmatter reading) are guarded by hostile/negative fixtures (`make test-fixtures`). One known limit: the **structural-graph** checks — directory-index membership and index reachability — read only **inline** links in `index.md`, so a file indexed *solely* via a **reference-style** link (`[x][ref]`) is not yet detected there and would be reported as a false-positive orphan. Link *validity* itself is checked natively by **pulldown-cmark**, which parses every link form (inline, titled, angle-bracket, reference-style, and images).\n\n**Is it tied to a specific language or framework?**\nNo. Living Docs is stack-agnostic — it governs documentation organization and\nlifecycle, not your tech stack.\n\n**Did you invent this?**\nNo, and the repo says so. Living Docs *composes* established practices (Martraire's\nliving documentation, Nygard's ADRs, Specification by Example for BDRs, Google's\nOKF). Full, sourced credits in [`ATTRIBUTION.md`](ATTRIBUTION.md) and\n[`references/prior-art-landscape.md`](references/prior-art-landscape.md).\n\n---\n\n## License\n\n[MIT](LICENSE) © 2026 Evaldo Klock.\n\nVendored third-party content under `reference/` directories remains subject to\nits own upstream license — see [`ATTRIBUTION.md`](ATTRIBUTION.md).\n\n---\n\n\u003csub\u003e**Keywords:** living documentation · documentation as code · docs-as-code ·\nAI agent skill · Claude Code skill · Cursor rules · GitHub Copilot instructions ·\nOpenCode · Codex · Pi · Architecture Decision Records (ADR) · Behavior Decision Records\n(BDR) · PRD · project constitution · glossary · Mermaid architecture diagrams ·\nsemantic index · Open Knowledge Format (OKF) · knowledge management · technical\nwriting · software architecture · markdown documentation · no-drift docs.\u003c/sub\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fejklock%2Fliving-docs-skill","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fejklock%2Fliving-docs-skill","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fejklock%2Fliving-docs-skill/lists"}