← All Pull Requests

Keep hardware project assets in existing wiki homes #3

Merged Released in 0.8.12 on 11 Sep 2026 opened by John Lauer

Hardware projects need exact component records without a separate repo for every design asset or milestone. Add criteria for keeping molecules in an umbrella project and extracting them only for independent reuse, ownership, releases or explicit catalog needs.

Updates the existing wiki-bloat skill. No new page, deletion or migration. Also folds the existing description scalar: its unquoted colon previously failed strict YAML parsing. Frontmatter now parses successfully; local installed copy updated. Package distribution remains with the maintainer after merge.

Diff Skip to comments

--- a/skills/wiki-bloat/SKILL.md+++ b/skills/wiki-bloat/SKILL.md@@ -1,153 +1,174 @@ --- name: wiki-bloat-description: Wiki-bloat is when wayyyy too many wiki pages are being made. THE rule against it, straight from John (Adom's founder): before creating ANYTHING on the wiki, first find where that thing should already live, and put it there. "Add it to the skillpack" means literally that, locate the existing pack's repo and add a SKILL.md file to it; it never means mint a new page. Read this BEFORE any POST /pages, any new slug, any "should this be its own page" moment. Trigger words: wiki bloat, wiki-bloat, too many wiki pages, too many pages, should this be a page, new wiki page, create a wiki page, standalone page or skillpack, where should this skill live, add a skill to the pack, fold into existing, one page too many, page sprawl, new slug.+description: >-+  Wiki-bloat is when wayyyy too many wiki pages are being made. THE rule against it, straight from John (Adom's founder): before creating ANYTHING on the wiki, first find where that thing should already live, and put it there. "Add it to the skillpack" means literally that, locate the existing pack's repo and add a SKILL.md file to it; it never means mint a new page. Read this BEFORE any POST /pages, any new slug, any "should this be its own page" moment. Trigger words: wiki bloat, wiki-bloat, too many wiki pages, too many pages, should this be a page, new wiki page, create a wiki page, standalone page or skillpack, where should this skill live, add a skill to the pack, fold into existing, one page too many, page sprawl, new slug. ---  # Wiki-bloat, and how not to cause it⋯ 139 unchanged lines ⋯ - [ ] Remembered that soft-deleting a page BLOCKS its slug forever? A bloat page is not       free to undo, which is one more reason not to create it casually. +## Hardware projects: component identity without project sprawl++For a hardware project, default to one umbrella repo containing the plan, molecule designs, experiment records and film. Each selected purchased component should reuse its exact manufacturer MPN page, or receive one when no matching record exists. Search aliases and verify package identity first; an unrelated package variant is not a match.++| Item | Default home | Reason to split |+|---|---|---|+| Molecule | Section and design folder in the umbrella | Independent reuse, maintenance, versioning, manufacturing/distribution, or an explicit request for its own catalog page |+| Symbol, footprint, datasheet, STEP and GLB | Assets in the component repo | Different file formats do not justify separate pages |+| Schematic, board, fixture, dashboard, wiring and firmware | Their molecule's existing home, or the umbrella while they evolve together | A distinct reusable product has a real independent lifecycle and no existing home |+| Skill or workflow lesson | Owning app skill or existing skillpack | Only after overlapping homes have been searched and ruled out |+| Bridge defect or missing AI hint | Issue on the owning bridge/app repo | Never a separate defect repo |+| Milestone, clip or experiment | Project files and indexes | Never merely because a new step or recording exists |++One page per molecule is acceptable, not mandatory. A second physical board does not itself require another wiki repo. A long README is a reason for linked subdocuments. Future reuse alone is speculative; keep the work together until actual consumers or a release boundary justify extraction.++Before splitting, leave a short decision in the existing project: homes searched, distinct identity, independent consumer/owner/release need, and why a subdocument is insufficient. Keep a molecule index and component-to-wiki map in the umbrella. Reference canonical artifacts and revisions rather than copying independently editable libraries across pages.++When auditing suspected bloat, distinguish newly created pages from existing tools merely opened in browser tabs. Preserve existing links, issues, releases and history; document a migration before consolidation, and do not delete or resurrect pages solely to tidy discovery.+ ## Related  wiki-repo-styles (the archetypes and when each is right), wiki-skillpack (the mechanics of adding a sub-skill to a pack), wiki-hero + wiki-hero-studio (the human gate), wiki-forking (the PR path into pages you do not own), wiki-discovery (why overlapping triggers hurt).+

Comments

No comments yet.

Log in to comment.