documentation-and-adrs
Skill1 starsChanged 11 days agoMITView on GitHub
Document architectural decisions, API changes, and features. Use when something needs a written record. Do NOT use for code comments.
We split this skill into the rules it gives an agent
2 rules. 1 is common, 1 is distinctive, and 0 are very specific to this project.
1
Common
Most of the 61 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Document decisions, not just code.
- Common: line 74
No ADRs in a project with significant architectural choices
“Common” is measured: kept by at least 6 in 10 of the 61 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Documentation and ADRs
Document decisions, not just code. The most valuable documentation captures the why.
When to Use
- Making a significant architectural decision
- Choosing between competing approaches
- Adding or changing a public API
- Shipping a feature that changes user-facing behavior
- Onboarding new team members or agents
When NOT to Use
- Documenting obvious code or throwaway prototypes
Output Contract
Documentation artifacts — ADR markdown files (NNNN-title.md) with context, options, decision outcome, and consequences, inline documentation explaining the why (not the what), README with quick start and architecture overview, all files in docs/ or ADRs/ directory.
Core Workflows
Architecture Decision Records
→ See guides/ADR-GUIDE.md
ADR template, lifecycle, when to write them.
Inline Documentation
→ See guides/INLINE-DOCS.md
Comment the why, not the what.
README Structure
→ See guides/README.md
Quick start, commands, architecture overview.
Detailed Guides
| Guide | Content |
guides/ADR-GUIDE.md | ADR template, lifecycle, when to write |
guides/INLINE-DOCS.md | Comment principles, gotchas, API docs |
guides/README.md | README template, changelog format |
Quick Reference
ADR status: PROPOSED → ACCEPTED → (SUPERSEDED or DEPRECATED)
Comment the *why*, not the *what*.
Don't leave commented-out code.Red Flags
- Architectural decisions with no written rationale
- Public APIs with no documentation
- README that doesn't explain how to run
- Commented-out code instead of deletion
- No ADRs in a project with significant architectural choices
Other versions67 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 67
- addyosmani/agent-skills★ 112ksame name
- ollaya-dev/ollaya★ 1.4ksame name
- rizqinrr/viserys-agent★ 556same name
- shashankswe2020-ux/whoop-mcp★ 174same name
- muratgur/ordinus★ 111same name
- vinvcn/addyosmani-agent-skills-zh★ 46same name
- jmxt3/gitscape.ai★ 33same name
- sampleXbro/agentsmesh★ 24same name
- jaskirat1616/grok-skills★ 22same name
- JPeetz/agent-skills★ 14same name
57 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use constraint-driven-development, brainstorming and 3 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MrCipherSmithSkillconstraint-driven-development
Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.
Also in 13 projects that use this
OpenAISkillbrainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Also in 5 projects that use this
VercelSkillweb-design-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
Also in 4 projects that use this
GoogleSkilldiagnosing-bugs
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
Also in 3 projects that use this
MicrosoftSkillimpeccable
Use when the user wants to design, redesign, shape, critique, audit, polish, simplify, harden, animate, or otherwise improve a frontend interface: websites, landing pages, dashboards, product UI, components, forms, settings, onboarding, empty states, and native iOS or Android screens. Handles UX review, hierarchy, layout, typography, color, motion, UX copy, accessibility, responsive behavior, edge cases, and capturing or documenting design systems (DESIGN.md, tokens). Also for making bland UI bolder, loud UI quieter, or ambitious visual effects. Not for backend-only or non-UI tasks.
Also in 3 projects that use this
In this repository59 other files it gives its agents.
- AGENTS.mdAGENTS.md
- templates/CLAUDE.mdCLAUDE.md
- adapt-skillSkill
- api-and-interface-designSkill
- architecture-analysisSkill
- audit-skillSkill
- backend-api-masterySkill
- browser-testing-with-devtoolsSkill
- ci-cd-and-automationSkill
- clarify-skillSkill
- cli-toolsSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- context-engineeringSkill
- critique-skillSkill
- customize-opencodeSkill
- debugging-and-error-recoverySkill
- debugging-three-strikesSkill
- delight-skillSkill
- deprecation-and-migrationSkill
- dev-environment-auditSkill
- doubt-driven-developmentSkill
- engineering-fundamentalsSkill
- frontend-desktopSkill
- frontend-mobileSkill
- frontend-pwaSkill
- frontend-ui-engineeringSkill
- frontend-webSkill
- fullstack-shippingSkill
- gateSkill
- git-init-and-versioningSkill
- git-workflow-and-versioningSkill
- hard-skillSkill
- idea-refineSkill
- incremental-implementationSkill
- industrial-brutalist-uiSkill
- interview-meSkill
- minimalist-uiSkill
- multi-agent-orchestrationSkill
- observability-and-instrumentationSkill
- optimize-skillSkill
- output-skillSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- polish-skillSkill
- project-health-checkSkill
- project-metricsSkill
- redesign-skillSkill
- security-and-hardeningSkill
- self-improvementSkill
- shipping-and-launchSkill
- skill-creatorSkill
- skill-improverSkill
- soft-premium-uiSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- test-driven-developmentSkill
- typeset-skillSkill
- user-onboardingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

