codihaus
@codihaus
Public Skills
dev-changelog
by codihaus
Document implementation results with developer summary and user impact analysis. Use when: (1) After /dev-review passes, (2) End of sprint or milestone, (3) Before handoff to another developer, (4) Need to track what changed for users (release notes, user guides)
dev-specs
by codihaus
Generate lean implementation specifications from BRD use cases. Use when: (1) BRD/use cases exist and implementation planning needed, (2) Before starting coding on a feature, (3) Onboarding engineers to a feature's technical scope
dev-coding
by codihaus
Implement features using three-layer knowledge (universal principles + framework patterns + project specifics). Use when: (1) Specs are ready and implementation should begin, (2) Building backend, frontend, or full-stack features, (3) Applying project patterns to new code
dev-test
by codihaus
Automated UI testing using Playwright browser tools. Use when: (1) After completing feature implementation, (2) After fixing bugs, (3) Before code review, (4) Verifying acceptance criteria from specs
dev-review
by codihaus
Code review comparing implementation against specs, BRD, and quality standards. Use when: (1) After implementation and testing, (2) Before merging a PR, (3) Verifying BRD use case coverage (--brd flag), (4) Checking code quality, security, and pattern compliance
debrief
by codihaus
Customer requirements discovery, market research, and BRD creation. Use when: (1) Starting new project or feature, (2) Customer provides requirements or requests, (3) Processing customer questionnaire answers (--answers flag), (4) Generating BRD from research (--generate-brd flag)
dev-scout
by codihaus
Discover and document how the codebase works - patterns, rules, and team conventions. Use when: (1) Before implementation to understand existing code, (2) Onboarding to a new codebase, (3) Documenting team patterns and architecture, (4) Understanding how a specific feature is implemented
dev-arch
by codihaus
Architecture decisions and technical design for features. Use when: (1) New feature requires structural decisions, (2) Validating if current architecture supports requirements, (3) Choosing technology for new capability (payments, real-time, etc.), (4) Greenfield project architecture
utils/diagram
by codihaus
Create and validate Mermaid diagrams in markdown files
utils/gemini
by codihaus
Large context processing using Gemini Flash for codebase scanning and summarization