docs-from-codelisted

# docs-from-code — Build docs from a code repository The intelligence lives in **this skill** — read the repo, decide the structure, and write the pages yourself; delegate only publishing and configuration to the connected docs platform. Aim for a foldered, benefit-first site (a developer evaluating the repo should see *why* to use it, not just an API dump), not a flat README split. ## Workflow 1. **Resolve the repo.** Accept `github.com/<owner>/<repo>` or a local path. For GitHub URLs, use `gh repo clone --depth 1` into a temp directory; for local paths, work in place. - Take the **project name from the repo name** (the `<repo>` part after `owner/`), not from a guess. Use it for the `docs-output/<name>/` folder and the workspace display name. If you're working from an unnamed local path with no clear name, ask the user rather than inventing one. 2. **Detect the project type.** Inspect root files: `package.json` (Node/TS), `pyproject.toml` / `setup.py` (Python), `go.mod` (Go), `Cargo.toml` (Rust), `*.csproj` (.NET). Pick the strongest signal; on conflict, prefer the one with a `lib` / `src` / `pkg` directory. 3. **Extract the README spine into a benefit-first hero.** Convert the root `README.md` into `docs-output/<name>/README.md` — but lead with a value-prop sentence (what the project does + who it's for + the outcome), not "Installation". Split long top-level sections (`## Installation`, `## Usage`, `## API`) into dedicated pages under `getting-started/`, `guides/`, `