{"enrichment":{"faq":[{"a":"Documentation and ADRs guides you to structure each ADR with a clear title, context explaining the problem, decision statement, alternatives considered, and consequences. Store records in `docs/decisions/` so your team and AI agents can trace why technical choices were made. Include enough detail that someone unfamiliar with the project understands both the reasoning and trade-offs without needing to ask the original author.","q":"How to write architecture decision records?"},{"a":"Documentation and ADRs recommends writing ADRs whenever you make significant architectural choices\u2014database selections, framework decisions, API design patterns, or major refactors. Capture decisions early rather than retroactively; this preserves engineering context for onboarding and helps future maintainers (including AI agents) understand not just what was built, but why certain alternatives were rejected.","q":"When should I write ADRs for my project?"},{"a":"Documentation and ADRs suggests a template with sections for title, status, context (the problem driving the decision), decision (what you chose), alternatives (options you considered and rejected), and consequences (trade-offs and impacts). This structure ensures decisions are documented consistently across your project and captures the reasoning needed for long-term maintenance and knowledge transfer.","q":"What is an ADR template for technical decisions?"},{"a":"Documentation and ADRs emphasizes recording alternatives considered and why each was rejected in your ADR's alternatives section. Explicitly state the trade-offs: what you gained by choosing your solution and what you sacrificed. This prevents future engineers from re-debating settled decisions and helps new team members understand the constraints and priorities that shaped your architecture.","q":"How do I document design trade-offs and rejected alternatives?"},{"a":"Documentation and ADRs recommends writing inline comments for non-obvious code behavior, gotchas, and the reasoning behind complex logic\u2014not for self-explanatory code. Link comments to related ADRs when architectural decisions influenced implementation. This preserves context for maintainers and reduces onboarding friction, especially when AI agents need to understand intent beyond syntax.","q":"What inline documentation best practices should I follow?"},{"a":"Documentation and ADRs suggests establishing standards that include a clear README with project purpose, setup instructions, and links to decision records; API documentation; and a `docs/decisions/` folder for ADRs. Consistent structure helps new team members and AI agents navigate your project's technical landscape and understand both current architecture and the reasoning behind it.","q":"How should I structure a project README and documentation standards?"}],"shadow_tags":["decision-capture","architectural-rationale","knowledge-preservation","design-tradeoffs","team-onboarding","future-context","technical-record","code-rationale","api-specification"],"summary_rewrite":"Documentation and ADRs helps teams record the reasoning behind significant technical decisions through structured Architecture Decision Records. Store decisions in `docs/decisions/` with context, alternatives considered, and consequences so future engineers and AI agents understand not just what was built, but why."},"files":[{"bytes":8734,"path":".github/skills/documentation-and-adrs/SKILL.md","sha256":"7fed35f9c5b95d8e3623ad24d78d209c3267ab62d7157fc03954c76a7e58adf4","url":"https://skillfed.io/files/shashankswe2020-ux/whoop-mcp/documentation-and-adrs/33b4f473/SKILL.md"}],"id":"shashankswe2020-ux/whoop-mcp/documentation-and-adrs","links":{"html":"https://skillfed.io/shashankswe2020-ux/whoop-mcp/documentation-and-adrs","md":"https://skillfed.io/shashankswe2020-ux/whoop-mcp/documentation-and-adrs.md","repo":"https://github.com/shashankswe2020-ux/whoop-mcp"},"meta":{"agents_supported":[],"first_seen":"2026-07-28","forks":38,"language":"TypeScript","last_updated":"2026-07-24","license":"MIT","name":"documentation-and-adrs","publisher":"shashankswe2020-ux","stars":136},"relations":{"categories":["documentation","software-engineering","knowledge-management"],"similar":[{"id":"addyosmani/agent-skills/documentation-and-adrs"},{"id":"shashankswe2020-ux/whoop-mcp/api-and-interface-design"},{"id":"shashankswe2020-ux/whoop-mcp/using-agent-skills"},{"id":"shashankswe2020-ux/whoop-mcp/spec-driven-development"},{"id":"shashankswe2020-ux/whoop-mcp/test-driven-development"},{"id":"shashankswe2020-ux/whoop-mcp/incremental-implementation"},{"id":"shashankswe2020-ux/whoop-mcp/shipping-and-launch"},{"id":"shashankswe2020-ux/whoop-mcp/debugging-and-error-recovery"},{"id":"shashankswe2020-ux/whoop-mcp/code-simplification"},{"id":"shashankswe2020-ux/whoop-mcp/ci-cd-and-automation"}]},"slug":{"owner":"shashankswe2020-ux","repo":"whoop-mcp","skill":"documentation-and-adrs"},"version":"33b4f473"}