← ClaudeAtlas

read-the-projects-origin-storylisted

Use when you are about to PROPOSE something to a young project or subproject — a design, a new capability, a discussion thread — and want to know why it is the way it is: who built it, what it was chosen over, what its authors already called incomplete, and which design arguments are still unresolved. Read the discussion arc that CREATED the repo before proposing to it. Its founding threads name the known-incomplete edges (so you don't report them as discoveries), the objections its own committers recorded (so you don't reopen them), and who actually cares about your area — none of which git history or CONTRIBUTING can tell you. For "does the ORIGINAL of this fork still have the same bug?" use port-the-report-upstream: that is code lineage, this is decision history. Trigger terms: new subproject, young repo, why does this exist, what did they already decide, project history, founding thread, VOTE thread, was this discussed before, prior discussion, before I propose, am I repeating something, is this wanted.
serhiy-bzhezytskyy/contrib-receipts · ★ 1 · Code & Development · score 75
Install: claude install-skill serhiy-bzhezytskyy/contrib-receipts
# Read the project's origin story before you propose anything ## Purpose Code tells you what a project *is*. Its founding discussion tells you what it was *for*, what it beat, what its own authors flagged as unfinished, and which arguments were left open. That context is what separates a proposal a maintainer can act on from one that re-litigates a settled decision or announces a gap the author declared themselves. The cost of skipping it is not just ignorance — it is confidently framing your work wrong. A defect you present as a discovery may be a known consequence of a fast initial port the author already warned about. A "missing capability" may be the exact thing the project was chosen *for*, making your report far more significant than you pitched it. Neither reading is available from the diff. ## When to use - The repo is young, or is a subproject of a larger foundation project (a port counts, but for a port's *code* lineage see port-the-report-upstream — this is its history). - You are about to propose a design, open a discussion thread, or frame a report as "this is missing." - A maintainer invites you to "start another thread about that" — find out who has already argued about it before you do. - You are writing the *framing* of work already done (an email, a PR body's Notes section, a case study) and want the strongest true claim. ## When NOT to use - Routine, self-contained bug fixes on a mature project. A one-line null guard does not need the 2015