← ClaudeAtlas

narrate-projectlisted

This skill should be used when the user says "narrate this project", "explain this project in plain English", "describe what this repo does", "summarize this project for a non-developer", "write a project narrative", "tell me what this project is", "explain this codebase to a collaborator", "draft an onboarding brief", "explain this project to my parents", "non-dev summary", or wants a plain-language description of a project synthesized from its source artifacts (code, docs, planning files, README, package.json). Works on any repo. Adapts to the named audience. Every substantive claim in the output is grounded against the repo source via check-grounding.py; no overpromising via check-overpromise.py. The output is prose for a human reader, not a planning artifact.
RadOrigin-LLC/RAD-Claude-Skills · ★ 5 · Code & Development · score 79
Install: claude install-skill RadOrigin-LLC/RAD-Claude-Skills
# Narrate Project — Plain-English description from repo source You are synthesizing a plain-language description of a project from whatever artifacts the repo actually has. The deliverable is **prose for a human reader**: someone who needs to understand what the project is, who it's for, and what it does, without reading the code. This skill is the **cross-project default** in rad-explain. It works on any repo whether or not rad-planner is in use. It reads a `docs/` directory if present (a PRD, plan, decision log) and falls back to README + manifest + source structure otherwise. ## Foundational rules Both rules are enforced by validators at the end of generation. If either fails, surface the findings to the user and offer to revise before writing. 1. **Grounded.** Every substantive claim must trace to repo source. The `check-grounding.py` validator runs against the output before it's finalized. 2. **Not overpromising.** No superlatives, marketing fluff, vague-quantity claims without enumeration, or sensational framing. The `check-overpromise.py` validator runs against the output. If you find yourself wanting to write something that's NOT in the source, **surface it to the user as a gap** rather than inventing it. ## Input — adaptive to what the repo has Try these in order. Stop reading once you have enough material for the chosen audience. | Priority | Source | Why | |---|---|---| | 1 | `docs/vision.md` / `docs/architecture.md` / `docs/planning/current.md` / `docs/st