{
  "markdown": "**Claude Code skills for taking a project from raw idea to merged PR** — greenfield or brownfield — plus documentation tooling and a self-improvement loop.\n\nThis repo is a [Claude Code plugin marketplace](https://code.claude.com/docs/en/plugin-marketplaces). One command installs everything:\n\n```\n/plugin marketplace add julienlegoux/skills\n/plugin install lx@lx-engine\n```\n\nSkills are then namespaced: `/lx:define-scope`, `/lx:okf-docs`.\n\n---\n\n## 🗺️ The planning-to-PR pipeline\n\nThe core of this repo is a chain of skills that carries work all the way to reviewable pull requests. Each skill's output is the next skill's input. There are two entry points — a new project, or an existing codebase — and they converge on the same epic → issue → PR machinery, which then *loops*: an epic closes, its review reports become the next epic.\n\n<picture>\n  <source media=\"(prefers-color-scheme: dark)\" srcset=\"assets/pipeline-dark.png\">\n  <source media=\"(prefers-color-scheme: light)\" srcset=\"assets/pipeline-light.png\">\n  <img alt=\"The pipeline: two entry points (raw idea, existing code) feed the Plan stage; Plan feeds Build (create-issues → implement-epic → implement-issue → merged PR → close-epic); close-epic loops back for the next epic, and the opt-in review skills write their reports into docs/reviews/, which triage-reports turns into epic 0 and feeds back into create-issues.\" src=\"assets/pipeline-light.png\">\n</picture>\n\nSolid arrows are the path work takes; dotted ones are optional entries and hand-offs (`implement-issue` runs standalone too, and every review skill is opt-in).\n\n### 🌱 Greenfield — plan a new project\n\n| Stage | Skill | What it does |\n|---|---|---|\n| 0️⃣ | [`define-concept`](skills/define-concept/SKILL.md) | *Optional.* Talk a still-forming idea into shape and record what *you* validate into `CONCEPT.md` — no ledger, no checklist |\n| 1️⃣ | [`define-scope`](skills/define-scope/SKILL.md) | Turn a raw idea into a decided `docs/planning/SCOPE.md` via a decision ledger *you* triage |\n| 2️⃣ | [`define-specs`](skills/define-specs/SKILL.md) | Decide the one-way technical doors — stack, architecture, data, auth — into `SPECS.md` |\n| 3️⃣ | [`define-conventions`](skills/define-conventions/SKILL.md) | Instantiate your personal conventions baseline; only *deviations* get decided |\n| 4️⃣ | [`check-prerequisites`](skills/check-prerequisites/SKILL.md) | Probe what the plan depends on — toolchains, services, keys — into `PREREQUISITES.md`, and hand you the list only *you* can close |\n| 5️⃣ | [`split-epics`](skills/split-epics/SKILL.md) | Cut the scope into epic folders, each with a GitHub milestone + tracking issue |\n\n### 🏗️ Brownfield — change an existing app\n\n| Stage | Skill | What it does |\n|---|---|---|\n| 1️⃣ | [`map-codebase`](skills/map-codebase/SKILL.md) | Reverse-engineer `SPECS.md` + `CONVENTIONS.md` by reading the code, not interviewing you |\n| 2️⃣ | [`define-change`](skills/define-change/SKILL.md) | Audit one change's blast radius, decide *how it lands*, emit an `EPIC_N.md` `create-issues` consumes unchanged |\n\n### 🔨 Build — both paths\n\n| Skill | What it does |\n|---|---|\n| [`create-issues`](skills/create-issues/SKILL.md) | Turn one epic into right-sized GitHub sub-issues (~one 500-line PR each) |\n| [`implement-issue`](skills/implement-issue/SKILL.md) | Take one issue from `open` to a focused, test-first PR — bookkeeping included |\n| [`implement-epic`](skills/implement-epic/SKILL.md) | Supervise a whole epic: delegate each issue to `implement-issue`, watch CI, merge green PRs, repeat |\n| [`close-epic`](skills/close-epic/SKILL.md) | Land the epic: verify its real state against GitHub and git, promote drift into `DRIFT.md`, close the milestone, clean up worktrees and branches |\n\n### 🔍 Review companions\n\nAudit skills that check the pipeline's output without modifying it:\n\n| Skill | Reviews |\n|---|---|\n| [`review-epics`](skills/review-epics/SKILL.md) | Plan → epic conversion: epics, milestones, tracking issues vs. the source plan |\n| [`review-issues`](skills/review-issues/SKILL.md) | Epic → issue conversion: sizing, coverage, sub-issue wiring |\n| [`review-implementation`](skills/review-implementation/SKILL.md) | The code an epic actually shipped: its merged diff vs. the acceptance criteria, `CONVENTIONS.md` and the accepted drift |\n\nAll three write a prioritized report into `docs/reviews/`, named `<YYYY-MM-DD>-<kind>-<subject>.md` — `2026-08-11-issues-epic-4.md` — instead of silently \"fixing\" things. And that report is itself an input:\n\n| Skill | What it does |\n|---|---|\n| [`triage-reports`](skills/triage-reports/SKILL.md) | Fold the accumulated reports into one triaged remediation epic (`epic-0`) that `create-issues` consumes unchanged — which is what closes the loop |\n\n## 📚 Knowledge tooling (OKF)\n\n| Skill | What it does |\n|---|---|\n| [`okf-docs`](skills/okf-docs/SKILL.md) | Write & structurally validate docs in Google's **Open Knowledge Format** — markdown + YAML frontmatter bundles readable by humans and agents alike |\n| [`okf-lint`](skills/okf-lint/SKILL.md) | Semantic linter for OKF bundles: contradictions, index drift, duplicate concepts, stale timestamps — everything a mechanical validator can't see |\n\n## 🧰 Machine setup\n\n| Skill | What it does |\n|---|---|\n| [`setup`](skills/setup/SKILL.md) | Prepare *your machine* for the skills above — today, the [`external-reviewer`](https://github.com/julienlegoux/external-reviewer) CLI the review skills hand their analysis pass to: install it, get a credential in place, and choose which model answers for `light` / `standard` / `heavy` |\n\nThe one skill whose deliverable is outside any repository: a binary on your `PATH`, a credential in your own store, and one config file under your profile. The reviewers detect it on their own — nothing to pass, and everything still runs natively without it.\n\n## 🗣️ Feedback\n\n| Skill | What it does |\n|---|---|\n| [`send-feedback`](skills/send-feedback/SKILL.md) | File what just went wrong as an issue on this repo — your words quoted verbatim, context offered rather than assumed, private paths redacted, nothing posted without your OK |\n\nShips **in** the plugin on purpose: it exists for people who don't have a clone to fix\nthings in. The repo is public with issues enabled, so any GitHub account can file one —\nvia `gh` if it's authenticated, otherwise a prefilled browser URL. No token is ever\nbundled and none is needed.\n\n## 🔁 Meta — *not shipped in the plugin*\n\nThese two author the repo itself: they need a clone, git, and push rights, so installing the plugin can't make them useful. They live in `meta/` and are installed by hand — fork the repo and junction them in:\n\n```powershell\nNew-Item -ItemType Junction -Path \"$HOME\\.claude\\skills\\improve-skill\" -Target \"<repo>\\meta\\improve-skill\"\n```\n\n| Skill | What it does |\n|---|---|\n| [`create-skill`](meta/create-skill/SKILL.md) | Add a skill to this repo — prove the need repeats, place it against the existing ones, draft it to the authoring contract |\n| [`improve-skill`](meta/improve-skill/SKILL.md) | Fold lessons from the current session back into the skill that caused them: diagnose → propose → apply → commit |\n\n---\n\n## 📦 Repo layout\n\n```\n├── .claude-plugin/\n│   ├── marketplace.json          ← marketplace \"lx-engine\"\n│   └── plugin.json               ← plugin \"lx\" (bundles every skill below)\n├── skills/                       ← the plugin: published, auto-discovered\n│   ├── _shared/\n│   │   ├── bundle-interfaces.md  ← rules for anything written under docs/\n│   │   ├── ledger-interfaces.md  ← the decision doc, for ledger-driven skills\n│   │   ├── pipeline-interfaces.md ← epic/issue schemas, for epic-to-PR skills\n│   │   ├── review-interfaces.md  ← grading and the report, for the reviewers\n│   │   ├── external-reviewer.md  ← the optional external pass, read only when it is installed\n│   │   └── feedback-interfaces.md ← the closing reflex, for every published skill\n│   ├── define-scope/SKILL.md\n│   ├── define-specs/SKILL.md\n│   └── ...one folder per skill\n├── meta/                         ← outside the plugin, installed by hand\n│   ├── _shared/authoring-interfaces.md\n│   ├── create-skill/SKILL.md\n│   └── improve-skill/SKILL.md\n├── docs/                         ← documentation bundle\n└── README.md\n```\n\nEvery folder under `skills/` holds one skill (`SKILL.md` + supporting files) and is auto-discovered by the plugin. `_shared/` has no `SKILL.md`, so discovery skips it — and anything outside `skills/` is invisible to the plugin entirely, which is what keeps `meta/` local.\n\n### Shared contracts\n\nWhat the skills agree on lives in `skills/_shared/`, split by audience so no skill carries rules that don't apply to it:\n\n| Interface | Defines | Audience |\n|---|---|---|\n| [`bundle-interfaces.md`](skills/_shared/bundle-interfaces.md) | English content, bundle & link rules, reserved `index.md`/`log.md`, committing what you write | every skill that writes under `docs/` |\n| [`ledger-interfaces.md`](skills/_shared/ledger-interfaces.md) | the decision doc schema, the batch-triage and deep-dive passes, the reopening rule | the ledger-driven planning skills |\n| [`pipeline-interfaces.md`](skills/_shared/pipeline-interfaces.md) | epic & issue schemas, status lifecycle, the drift register, GitHub facts on integration branches | the epic-to-PR skills |\n| [`review-interfaces.md`](skills/_shared/review-interfaces.md) | severity scale, what makes a finding, GitHub verification, the probe that hands the analysis pass to an external model (invocation in `external-reviewer.md`), the `docs/reviews/` report contract | the planning reviewers, plus `triage-reports` from the reading end |\n| [`feedback-interfaces.md`](skills/_shared/feedback-interfaces.md) | the closing reflex: when it fires, the attribution and generality filters, silence when nothing clears them, `improve-skill` vs `send-feedback` | every skill under `skills/` **except** `send-feedback` |\n| [`authoring-interfaces.md`](meta/_shared/authoring-interfaces.md) | how a skill in this repo is shaped: description contract, progressive disclosure, tiered prescriptiveness | `create-skill`, `improve-skill` |\n\nOne file per contract, no generated copies, so an edit is live everywhere at once. The five under `skills/_shared/` are read as `../_shared/<file>` and ship with the plugin; the trade is that a published skill folder is not portable on its own — the repo is the unit. The sixth is read as `<repo>/meta/_shared/<file>`, because its two consumers are installed away from the repo and resolve it first anyway.\n\n## 🛠️ Developing\n\nThere is no install step. Point your skills directory at the clone once — the plugin at the repo root, then each `meta/` skill on its own — and the file you edit is the file Claude Code runs:\n\n```powershell\nNew-Item -ItemType Junction -Path \"$HOME\\.claude\\skills\\lx-engine\"     -Target \"<repo>\"\nNew-Item -ItemType Junction -Path \"$HOME\\.claude\\skills\\create-skill\"  -Target \"<repo>\\meta\\create-skill\"\nNew-Item -ItemType Junction -Path \"$HOME\\.claude\\skills\\improve-skill\" -Target \"<repo>\\meta\\improve-skill\"\n```\n\nThen, after editing: `/reload-plugins` in the session, and\n\n```\nclaude plugin validate .\nclaude plugin details lx@skills-dir    # confirms what was actually discovered\n```\n\nOr let [`improve-skill`](meta/improve-skill/SKILL.md) run the loop — it diagnoses, edits and commits in one pass.\n\n## 📄 License\n\nPersonal toolkit — use freely, adapt liberally.\n",
  "bytes": 11427,
  "sha": "ee703f91974b776ce2a56d4c7bb42b05a2c426ec0ac4d3fe2d3061f66aab67c6",
  "repo_slug": "julienlegoux/skills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/okf_julienlegoux_skills_docs_index_md_17a031c0/readme"
}