documentation-process
Documentation Process
Guidelines
- After completing a new feature, always see if you need to update the Architecture documentation at
/docs/contributing/ARCHITECTURE.mdand Test documentation in/docs/contributing/TESTING.mdfor other developers, so anyone could easily pick up the work and understand the project and the feature that was added. - If the code change included prior decision-making out of several alternatives, document an ADR at
/docs/adrfor any non-trivial/non-obvious decisions that should be preserved.
More from serpro69/claude-toolbox
cove
Apply Chain-of-Verification (CoVe) prompting to improve response accuracy through self-verification. Use when complex questions require fact-checking, technical accuracy, or multi-step reasoning.
1merge-docs
Semantically compare and merge two design docs for the same feature into one unified document. Use when you have two competing or complementary design/implementation docs (e.g., from separate analysis-process runs) and need to reconcile them into a single source of truth.
1analysis-process
Turn the idea for a feature into a fully-formed PRD/design/specification and implementation-plan. Use when you have a spec or requirements that needs implementation. Use in pre-implementation (idea-to-design) stages to make sure you understand the spec/requirements and ensure you have a correct implementation plan before writing actual code.
1testing-process
Guidelines describing how to test the code. Use whenever writing new or updating existing code, for example after implementing a new feature or fixing a bug.
1solid-code-review
Code review of current git changes with an expert senior-engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements. Use when performing code reviews.
1development-guidelines
Use when writing code to ensure you follow development best practices during development and implementation.
1