← ClaudeAtlas

project-tech-designlisted

Use when you write or revise a technical design for this project — a document that settles an architecture, an entity model, a module boundary, or a subsystem, before any implementation plan exists. Also use when a review comment reopens such a decision.
ubermuda/loupe · ★ 2 · AI & Automation · score 65
Install: claude install-skill ubermuda/loupe
# Technical designs A technical design settles an architecture. An implementation plan settles tasks. Write the design first. Send every design to the Loupe app for review. **Invoke `loupe-documents` before you write.** That skill gives the format rules for the review UI. This skill gives the content rules. Write the document in ASD-STE100 Simplified Technical English. The writing rules are in `compressing-skills`. ## Verify each claim against the code Read the code before you state a fact about it. Never write a count from memory. One audit design stated five wrong numbers. It claimed 11 security call sites, and the code had 14. It claimed 22 silent handlers, and the code had 27. It claimed one privacy violation, and the code had 26. It also described a renaming workstream that did not exist, because every operation name was already correct. Run the search. Count the result. Put the number in the document. Say what you could not verify. Silence reads as confidence. ## Mark which entries are checked and which are estimates Proximity to evidence reads as evidence. A design document carried a section headed "What I verified in the code", holding real greps, and a list of costs beside it. Two of those costs were wrong, because the author wrote them before reading `.github/actions/setup`. They were estimates, and the verified section next to them made them look checked. The owner then ruled on that fence. A cost written at design time earns the same verification as a c