Add comprehensive 9-stage development workflow skill with: - Universal language and framework support (Python, JS, Dart, Go, Rust, Java, etc.) - Code review automation - Security and compliance validation (OWASP Top 10) - Architecture audit across 6 dimensions - Multi-perspective PR review (6 stakeholder angles) - Interactive issue resolution - Safe git operations with quality gates Includes: - master-workflow.md: Production-ready skill with full documentation - README.md: Installation and usage guide - CONTRIBUTING.md: Contribution guidelines - LICENSE: MIT License - .gitignore: Standard ignores for development The Master Workflow skill: - Works with any programming language or framework - Executes 9 stages in optimized sequence - Provides 35-60 minutes of comprehensive code review - Ensures security standards before production - Safe branch protection and quality gates Ready for marketplace publication. Co-Authored-By: Claude <noreply@anthropic.com>
776 lines
21 KiB
Markdown
776 lines
21 KiB
Markdown
---
|
|
name: master-workflow
|
|
title: Master Development Workflow - Universal Code Quality Pipeline
|
|
version: 1.0.0
|
|
author: Svrnty Development Team
|
|
category: code-review
|
|
keywords: [code-review, quality-assurance, security, ci-cd, git, architecture-audit, pr-review, universal]
|
|
description: Comprehensive 9-stage development workflow combining code review, security compliance, architecture audit, and multi-perspective PR review. Language-agnostic and framework-independent - works with any project (Python, JavaScript, Dart, Go, Rust, etc).
|
|
icon: ✓
|
|
activation_phrases:
|
|
- "@master"
|
|
- "master workflow"
|
|
- "complete workflow"
|
|
- "finish session"
|
|
- "full pipeline"
|
|
- "wrap up and push"
|
|
- "final review and push"
|
|
- "ready to merge"
|
|
- "complete everything and push"
|
|
- "full quality check"
|
|
min_claude_version: 3.5
|
|
compatibility:
|
|
- Python
|
|
- JavaScript/TypeScript
|
|
- Dart/Flutter
|
|
- Go
|
|
- Rust
|
|
- Java
|
|
- C/C++
|
|
- Ruby
|
|
- PHP
|
|
- Any language
|
|
languages:
|
|
- Language-agnostic
|
|
- Framework-agnostic
|
|
- Platform-independent
|
|
---
|
|
|
|
# Master Development Workflow Skill
|
|
|
|
**The Universal Code Quality & Release Pipeline**
|
|
|
|
A comprehensive, end-to-end development workflow that works with **ANY programming language, framework, or project type**. Combines code review, security compliance, codebase auditing, and multi-perspective PR review into ONE powerful pipeline.
|
|
|
|
**Works with:**
|
|
- Python, JavaScript/TypeScript, Dart, Go, Rust, Java, C/C++, Ruby, PHP, and more
|
|
- Frontend, Backend, Full-stack, Desktop, Mobile, CLI projects
|
|
- Any git-based repository (GitHub, GitLab, Gitea, self-hosted)
|
|
- Monorepos, microservices, or single projects
|
|
|
|
---
|
|
|
|
## Purpose
|
|
|
|
This skill automates the complete quality assurance process before code reaches production. It ensures your code meets the highest standards across:
|
|
|
|
- **Code Quality** - Readability, complexity, duplication analysis (language-agnostic)
|
|
- **Security** - OWASP Top 10, secrets detection, dependency scanning
|
|
- **Architecture** - Design patterns, coupling, maintainability
|
|
- **Testing** - Coverage assessment, test quality
|
|
- **Performance** - Algorithm optimization, resource efficiency
|
|
- **Multi-perspective Review** - Product, Dev, QA, Security, DevOps, Design angles
|
|
|
|
Works with any project type, any language, any framework.
|
|
|
|
---
|
|
|
|
## When to Use
|
|
|
|
Activate this skill when you want to:
|
|
|
|
- ✅ Complete a feature branch with ALL quality checks (any language/framework)
|
|
- ✅ Finish a development session with comprehensive review
|
|
- ✅ Ensure code meets highest standards across quality, security, architecture
|
|
- ✅ Validate security compliance before merging
|
|
- ✅ Perform full codebase audit and identify technical debt
|
|
- ✅ Get multi-perspective stakeholder feedback
|
|
- ✅ Prepare code for enterprise/production deployment
|
|
- ✅ Automate deploy preparation and release process
|
|
|
|
**Works with:**
|
|
- Python projects (Django, FastAPI, Flask, async, etc)
|
|
- JavaScript/TypeScript projects (React, Vue, Node, NestJS, etc)
|
|
- Dart/Flutter projects (mobile, web, desktop)
|
|
- Go projects (microservices, CLI, web)
|
|
- Rust projects (systems, web, embedded)
|
|
- Java projects (Spring Boot, microservices, Android)
|
|
- And any other language/framework
|
|
|
|
---
|
|
|
|
## The 9-Stage Pipeline
|
|
|
|
### Stage 1: Git Status & Preparation (2-3 minutes)
|
|
|
|
**Objective:** Establish baseline and verify readiness
|
|
|
|
**Actions:**
|
|
1. Check git status to identify all changes
|
|
2. Verify current branch is NOT main/master/trunk/production
|
|
3. Display file count, additions, deletions summary
|
|
4. Show recent commit history for context
|
|
5. Confirm readiness to proceed
|
|
|
|
**Language/Framework:** Language-independent (uses git)
|
|
|
|
**Output Format:**
|
|
```
|
|
STAGE 1: GIT STATUS & PREPARATION
|
|
✓ Current branch: feature/my-feature (not main/master)
|
|
✓ Modified files: 12 files, 687 additions, 156 deletions
|
|
✓ New files: 3
|
|
✓ Recent commits:
|
|
- abc123 feat: Add new feature
|
|
- def456 fix: Bug fix
|
|
- ghi789 docs: Update docs
|
|
✓ Ready to proceed
|
|
```
|
|
|
|
---
|
|
|
|
### Stage 2: Immediate Code Review (5-10 minutes)
|
|
|
|
**Objective:** Review recent changes for quality issues
|
|
|
|
**Scope:** Focus on modified/added files from git diff
|
|
|
|
**Universal Review Checklist:**
|
|
- Code readability and naming conventions
|
|
- Duplicated code (DRY violations)
|
|
- Proper error handling throughout
|
|
- Exposed secrets or API keys
|
|
- Input validation implemented
|
|
- Test coverage for changes
|
|
- Performance considerations
|
|
- Memory leaks or resource issues
|
|
- Thread safety/concurrency issues
|
|
- Backwards compatibility
|
|
- Language-specific best practices
|
|
|
|
**Works with:**
|
|
- Python (PEP 8, type hints, docstrings)
|
|
- JavaScript/TypeScript (ES standards, JSDoc)
|
|
- Dart (Dart style guide, null safety)
|
|
- Go (Go conventions, error handling)
|
|
- Rust (ownership, borrowing, safety)
|
|
- Java (naming conventions, design patterns)
|
|
- Any language...
|
|
|
|
**Output Format:**
|
|
```
|
|
STAGE 2: CODE REVIEW (Recent Changes)
|
|
Files reviewed: 12
|
|
|
|
CRITICAL ISSUES (Must fix before push)
|
|
🔴 [src/auth.ts:145] Hardcoded API key exposed
|
|
Fix: Move to environment variable
|
|
🔴 [lib/database.py:78] SQL injection vulnerability
|
|
Fix: Use parameterized queries
|
|
|
|
WARNINGS (Should address)
|
|
🟡 [src/handler.go:234] Missing error handling
|
|
Suggestion: Add error check and logging
|
|
🟡 [tests/integration_test.rs:456] Test cases incomplete
|
|
Suggestion: Add edge case tests
|
|
|
|
SUGGESTIONS (Consider improving)
|
|
🟢 [src/utils/helpers.js:89] Code duplication detected
|
|
Suggestion: Extract to shared utility
|
|
🟢 [lib/main.dart:23] Large method (45 lines)
|
|
Suggestion: Break into smaller methods
|
|
```
|
|
|
|
---
|
|
|
|
### Stage 3: Full Codebase Architecture & Quality Audit (10-15 minutes)
|
|
|
|
**Objective:** Comprehensive analysis across 6 dimensions
|
|
|
|
**Six Dimensions of Analysis:**
|
|
|
|
#### 3.1 Architecture & Design
|
|
- Overall structure and organization
|
|
- Design patterns in use and adherence
|
|
- Module boundaries and separation of concerns
|
|
- Dependency management and coupling
|
|
- Architectural decisions and technical debt
|
|
|
|
#### 3.2 Code Quality
|
|
- Complexity hotspots (cyclomatic complexity)
|
|
- Code duplication analysis (DRY violations)
|
|
- Naming conventions and consistency
|
|
- Documentation coverage (docstrings, comments)
|
|
- Code smells and anti-patterns
|
|
- Language-specific best practices adherence
|
|
|
|
#### 3.3 Security
|
|
- Common vulnerabilities (OWASP Top 10)
|
|
- Input validation and sanitization
|
|
- Authentication and authorization checks
|
|
- Secrets management practices
|
|
- Dependency vulnerabilities
|
|
- Language-specific security issues
|
|
|
|
#### 3.4 Performance
|
|
- Algorithmic complexity issues
|
|
- Database query optimization opportunities
|
|
- Memory usage patterns and leaks
|
|
- Caching opportunities
|
|
- Resource leak prevention
|
|
- Language-specific performance anti-patterns
|
|
|
|
#### 3.5 Testing
|
|
- Test coverage assessment and percentage targets
|
|
- Test quality and effectiveness
|
|
- Missing test scenarios
|
|
- Integration vs unit test balance
|
|
- Critical path test coverage
|
|
- Test organization and best practices
|
|
|
|
#### 3.6 Maintainability
|
|
- Technical debt assessment
|
|
- Coupling and cohesion metrics
|
|
- Ease of future changes
|
|
- Onboarding friendliness
|
|
- Documentation quality
|
|
- Code consistency across project
|
|
|
|
**Output Format:**
|
|
```
|
|
STAGE 3: CODEBASE AUDIT (6 Dimensions)
|
|
|
|
ARCHITECTURE & DESIGN: 82/100
|
|
✓ Good modular structure
|
|
✓ Clear separation of concerns
|
|
⚠ High coupling in payments module (8 dependencies)
|
|
Action: Consider refactoring payment service
|
|
|
|
CODE QUALITY: 76/100
|
|
✓ Good naming conventions overall
|
|
⚠ 14% code duplication detected
|
|
⚠ 4 methods with high complexity
|
|
Action: Extract shared logic, simplify methods
|
|
|
|
SECURITY: 71/100
|
|
✗ 2 critical vulnerabilities (see Stage 2)
|
|
✓ Input validation mostly implemented
|
|
⚠ Plaintext storage of API keys
|
|
Action: Move secrets to environment, fix vulnerabilities
|
|
|
|
PERFORMANCE: 79/100
|
|
✓ No obvious N+1 query patterns
|
|
⚠ 2 unoptimized database queries
|
|
✓ Good caching strategy overall
|
|
Action: Review queries in ReportService
|
|
|
|
TESTING: 65/100
|
|
✓ Test organization good
|
|
⚠ 58% code coverage (target: 80%)
|
|
⚠ Missing integration tests for critical paths
|
|
Action: Add 25+ tests
|
|
|
|
MAINTAINABILITY: 80/100
|
|
✓ Clear code structure
|
|
✓ Good documentation
|
|
⚠ Some inconsistent patterns
|
|
Action: Standardize error handling approach
|
|
|
|
OVERALL SCORE: 75/100
|
|
Verdict: Good codebase with actionable improvements
|
|
```
|
|
|
|
---
|
|
|
|
### Stage 4: Security & Compliance Validation (8-12 minutes)
|
|
|
|
**Objective:** Ensure security standards and compliance
|
|
|
|
**OWASP Top 10 Assessment:**
|
|
- A1: Injection (SQL, NoSQL, command)
|
|
- A2: Broken Authentication
|
|
- A3: Sensitive Data Exposure
|
|
- A4: XML External Entities (XXE)
|
|
- A5: Broken Access Control
|
|
- A6: Security Misconfiguration
|
|
- A7: Cross-Site Scripting (XSS)
|
|
- A8: Insecure Deserialization
|
|
- A9: Using Components with Known Vulnerabilities
|
|
- A10: Insufficient Logging & Monitoring
|
|
|
|
**Enterprise Security Controls:**
|
|
- Authentication & MFA implementation
|
|
- Authorization and RBAC/ABAC
|
|
- Data protection (encryption at rest/transit)
|
|
- Keys encryption and key management
|
|
- API security and rate limiting
|
|
- Secrets management
|
|
- Dependency security scanning
|
|
- TLS/SSL configuration
|
|
- CORS and security headers
|
|
- Audit logging
|
|
- Incident response capability
|
|
|
|
**Language-specific security checks:**
|
|
- Python: pickle/yaml deserialization, SQL injection, import security
|
|
- JavaScript: eval, DOM XSS, npm audit vulnerabilities
|
|
- Dart/Flutter: plugin security, native bridge vulnerabilities
|
|
- Go: goroutine leaks, race conditions
|
|
- Rust: unsafe blocks, panic handling
|
|
- Java: serialization vulnerabilities, Spring Security configuration
|
|
|
|
**Output Format:**
|
|
```
|
|
STAGE 4: SECURITY & COMPLIANCE VALIDATION
|
|
|
|
OWASP TOP 10 ASSESSMENT
|
|
|
|
A1: Injection ✗ ISSUES FOUND
|
|
🔴 SQL injection in user_service.py:78
|
|
CVSS: 9.8 (Critical)
|
|
Recommendation: Use parameterized queries
|
|
|
|
A2: Broken Authentication ✓ PASS
|
|
✓ JWT tokens properly validated
|
|
✓ Logout clears tokens correctly
|
|
|
|
A3: Sensitive Data Exposure ✗ ISSUES FOUND
|
|
🔴 Hardcoded API key in config.js:45
|
|
CVSS: 9.1 (Critical)
|
|
Recommendation: Use environment variables
|
|
|
|
[... A4-A10 ...]
|
|
|
|
ENTERPRISE SECURITY CONTROLS
|
|
|
|
Authentication: ✓ GOOD
|
|
✓ Proper authentication mechanism
|
|
⚠ MFA not implemented (optional)
|
|
|
|
Authorization: ✓ GOOD
|
|
✓ Access control implemented
|
|
✓ Permission checks in place
|
|
|
|
Secrets Management: ✗ NEEDS ATTENTION
|
|
🔴 Hardcoded keys in source
|
|
⚠ No .env in .gitignore
|
|
Recommendation: Use secrets vault
|
|
|
|
Dependency Security: ✓ GOOD
|
|
✓ No critical vulnerabilities detected
|
|
✓ Dependencies reasonably current
|
|
|
|
CRITICAL ISSUES REQUIRING FIX
|
|
- 2 critical vulnerabilities (CVSS > 9.0)
|
|
- Must resolve before production deployment
|
|
|
|
COMPLIANCE STATUS: CONDITIONAL PASS
|
|
Passes security with critical issues noted
|
|
```
|
|
|
|
---
|
|
|
|
### Stage 5: Multi-Perspective PR Review (5-8 minutes)
|
|
|
|
**Objective:** Get comprehensive feedback from 6 stakeholder perspectives
|
|
|
|
#### 5.1 Product Manager Perspective
|
|
- Business value and ROI impact
|
|
- Feature alignment with roadmap
|
|
- User experience and usability
|
|
- Market timing and competitive advantage
|
|
- Documentation for stakeholders
|
|
|
|
#### 5.2 Developer/Engineer Perspective
|
|
- Code quality and best practices
|
|
- Architectural patterns and design
|
|
- Performance implications
|
|
- Scalability considerations
|
|
- Maintainability and readability
|
|
- Technical debt implications
|
|
- Language and framework best practices
|
|
|
|
#### 5.3 Quality Engineer Perspective
|
|
- Test coverage completeness
|
|
- Edge case and regression testing
|
|
- Performance testing needs
|
|
- Integration testing coverage
|
|
- Testing best practices adherence
|
|
|
|
#### 5.4 Security Engineer Perspective
|
|
- Vulnerability identification
|
|
- Data handling and privacy
|
|
- Authentication/authorization
|
|
- Compliance requirements
|
|
- Security incident potential
|
|
|
|
#### 5.5 DevOps/Infrastructure Perspective
|
|
- CI/CD pipeline compatibility
|
|
- Deployment strategy
|
|
- Monitoring and observability
|
|
- Infrastructure requirements
|
|
- Scaling and performance
|
|
- Rollback strategy
|
|
|
|
#### 5.6 UI/UX Designer Perspective (if applicable)
|
|
- Visual consistency with design system
|
|
- Accessibility (WCAG compliance)
|
|
- User interaction flow
|
|
- Mobile responsiveness
|
|
- Usability and clarity
|
|
|
|
**Output Format:**
|
|
```
|
|
STAGE 5: MULTI-PERSPECTIVE PR REVIEW
|
|
|
|
PRODUCT MANAGER PERSPECTIVE
|
|
✓ Feature aligns with roadmap
|
|
✓ Addresses customer pain point
|
|
✓ Good UX improvements
|
|
⚠ Documentation missing for stakeholders
|
|
Recommendation: Add product documentation
|
|
|
|
DEVELOPER PERSPECTIVE
|
|
✓ Code quality is good (76/100)
|
|
✓ Follows architectural patterns
|
|
⚠ 2 critical security issues must be fixed
|
|
⚠ Technical debt in auth module
|
|
Recommendation: Fix vulnerabilities, plan refactor
|
|
|
|
QA ENGINEER PERSPECTIVE
|
|
⚠ Test coverage at 58% (target: 80%)
|
|
⚠ Missing integration tests
|
|
✓ Unit tests well-organized
|
|
Recommendation: Add 25+ tests
|
|
|
|
SECURITY ENGINEER PERSPECTIVE
|
|
✗ 2 critical vulnerabilities found
|
|
✗ Hardcoded secrets in source
|
|
✓ Proper authentication
|
|
Recommendation: Fix immediately, use secrets vault
|
|
|
|
DEVOPS PERSPECTIVE
|
|
✓ No infrastructure changes needed
|
|
✓ Compatible with CI/CD pipeline
|
|
✓ Performance acceptable
|
|
⚠ Missing monitoring for new endpoints
|
|
Recommendation: Add observability
|
|
|
|
DESIGN PERSPECTIVE (if applicable)
|
|
✓ Follows design system
|
|
✓ WCAG AA compliant
|
|
⚠ Loading state missing
|
|
Recommendation: Add visual feedback
|
|
|
|
OVERALL RECOMMENDATION
|
|
Ready for merge with critical issues fixed
|
|
```
|
|
|
|
---
|
|
|
|
### Stage 6: Feedback Synthesis & Prioritization (3-5 minutes)
|
|
|
|
**Objective:** Consolidate all findings and create action plan
|
|
|
|
**Synthesis Actions:**
|
|
1. Consolidate all critical issues from Stages 2-5
|
|
2. Identify high-priority items requiring immediate fix
|
|
3. Group suggestions by category
|
|
4. Create prioritized action summary
|
|
5. Estimate remediation effort
|
|
6. Identify blocking issues preventing push
|
|
|
|
**Output Format:**
|
|
```
|
|
STAGE 6: FEEDBACK SYNTHESIS & PRIORITIZATION
|
|
|
|
CRITICAL BLOCKERS (Must fix to proceed)
|
|
[Security] SQL injection vulnerability (Estimated: 10 mins)
|
|
[Security] Hardcoded API key (Estimated: 5 mins)
|
|
[Testing] Integration tests missing (Estimated: 30 mins)
|
|
|
|
HIGH PRIORITY (Should fix before push)
|
|
[Quality] Code duplication (Estimated: 20 mins)
|
|
[Quality] Simplify complex methods (Estimated: 25 mins)
|
|
|
|
MEDIUM PRIORITY (Nice to address)
|
|
[Performance] Optimize queries (Estimated: 45 mins)
|
|
[Testing] Increase coverage to 80% (Estimated: 40 mins)
|
|
|
|
LOW PRIORITY (Future improvements)
|
|
[Monitoring] Add observability (Estimated: 25 mins)
|
|
|
|
QUICK WINS (< 5 minutes)
|
|
[Quality] Add missing docstrings
|
|
[Maintenance] Update outdated comments
|
|
|
|
BLOCKING ISSUES: 3
|
|
✗ Security vulnerabilities (2)
|
|
✗ Missing tests (1)
|
|
|
|
ESTIMATED TIME TO FIX BLOCKERS: 45 minutes
|
|
TOTAL ESTIMATED REMEDIATION: 3-4 hours
|
|
|
|
VERDICT: Cannot push until critical blockers are resolved
|
|
Next Step: Ask which issues to fix before proceeding
|
|
```
|
|
|
|
---
|
|
|
|
### Stage 7: Interactive Issue Resolution (Variable)
|
|
|
|
**Objective:** Assist with fixing critical issues
|
|
|
|
**Decision Point:** Are there blocking issues?
|
|
|
|
**IF CRITICAL/HIGH ISSUES EXIST:**
|
|
1. List all blocking issues in priority order
|
|
2. Ask which issues user wants to address
|
|
3. Assist with targeted code fixes for each issue
|
|
4. Run minimal re-validation after each fix
|
|
5. Verify resolution of addressed issues
|
|
6. Return to Stage 6 if new issues introduced
|
|
7. Proceed to Stage 8 when resolved
|
|
|
|
**IF NO BLOCKING ISSUES:**
|
|
- Proceed directly to Stage 8
|
|
|
|
---
|
|
|
|
### Stage 8: Final Pre-Push Verification (2-3 minutes)
|
|
|
|
**Objective:** Confirm everything is ready before push
|
|
|
|
**Pre-push Checklist:**
|
|
1. Run git status - confirm expected changes
|
|
2. Verify all unintended changes are excluded
|
|
3. Confirm NOT on main/master/trunk/production
|
|
4. Verify upstream tracking is configured
|
|
5. Confirm remote is properly configured
|
|
6. Review final commit message
|
|
7. Confirm no unresolved critical issues remain
|
|
|
|
**Safety Gates:**
|
|
- Prevent push to protected branches
|
|
- Warn if critical issues unresolved
|
|
- Require explicit confirmation before push
|
|
|
|
---
|
|
|
|
### Stage 9: Safe Git Operations & Push to Origin (2-3 minutes)
|
|
|
|
**Objective:** Execute safe git operations and push
|
|
|
|
**Automated Git Workflow:**
|
|
|
|
**Step 1: Stage All Changes**
|
|
```bash
|
|
git add .
|
|
```
|
|
|
|
**Step 2: Create Commit with Quality Summary**
|
|
```bash
|
|
git commit -m "[type] Brief description
|
|
|
|
- Quality: X improvements from audit
|
|
- Security: Y vulnerabilities fixed
|
|
- Tests: Z new test cases added
|
|
- Documentation: Updated as needed
|
|
|
|
Quality Pipeline: Automated master workflow
|
|
"
|
|
```
|
|
|
|
**Step 3: Verify Tracking & Remote**
|
|
```bash
|
|
git branch -vv
|
|
git remote -v
|
|
```
|
|
|
|
**Step 4: Push to Origin**
|
|
```bash
|
|
git push origin [current-branch]
|
|
```
|
|
|
|
**Step 5: Display Confirmation**
|
|
|
|
---
|
|
|
|
## Total Execution Time
|
|
|
|
- **Typical project (50-100 files changed):** 35-50 minutes
|
|
- **Small project (10-20 files changed):** 20-30 minutes
|
|
- **Large project (200+ files changed):** 60-90 minutes
|
|
- **Quick review mode (`--quick`):** 10-15 minutes (Stages 1-2 only)
|
|
|
|
---
|
|
|
|
## Safety Features & Quality Gates
|
|
|
|
### Branch Protection
|
|
- Prevents pushing to main/master/trunk/production
|
|
- Warns if on protected branch
|
|
- Requires explicit confirmation
|
|
- Verifies tracking branch exists
|
|
|
|
### Git Safety
|
|
- Shows git status before changes
|
|
- Displays file summaries
|
|
- Shows complete commit message for review
|
|
- Verifies upstream tracking
|
|
- Confirms remote configuration
|
|
- Shows commit hash after push
|
|
- Prevents force push
|
|
|
|
### Quality Gates
|
|
- Blocks push if critical issues unresolved
|
|
- Identifies all blocking issues upfront
|
|
- Prioritizes issues by severity
|
|
- Assists with targeted fixes
|
|
- Re-validates after fixes
|
|
- Allows waiving non-critical issues
|
|
|
|
### Security Validation
|
|
- OWASP Top 10 assessment
|
|
- Secrets/API keys detection
|
|
- Dependency vulnerability scanning
|
|
- Authentication/authorization review
|
|
- Data protection verification
|
|
- Compliance requirements check
|
|
|
|
### Code Quality Assurance
|
|
- Readability and naming standards
|
|
- Duplication detection (DRY)
|
|
- Error handling coverage
|
|
- Test coverage assessment
|
|
- Performance issue identification
|
|
- Complexity hotspot analysis
|
|
|
|
---
|
|
|
|
## Usage Examples
|
|
|
|
### Basic Invocation
|
|
```
|
|
User: "@master"
|
|
[All 9 stages execute in sequence]
|
|
```
|
|
|
|
### With Natural Language
|
|
```
|
|
User: "complete workflow"
|
|
User: "finish session"
|
|
User: "wrap up and push"
|
|
```
|
|
|
|
### Quick Review Only
|
|
```
|
|
User: "@master --quick"
|
|
[Runs Stages 1-2 only for fast feedback - 10 minutes]
|
|
```
|
|
|
|
### Security-Focused
|
|
```
|
|
User: "@master --security"
|
|
[Prioritizes Stages 4 & 5]
|
|
```
|
|
|
|
### Review Without Push
|
|
```
|
|
User: "@master --review-only"
|
|
[Runs all stages but stops at Stage 8 - no push]
|
|
```
|
|
|
|
---
|
|
|
|
## Works With Any Language/Framework
|
|
|
|
**Backend:**
|
|
- Python (Django, FastAPI, Flask)
|
|
- JavaScript/Node (Express, NestJS, Fastify)
|
|
- Go (net/http, Gin, Echo)
|
|
- Rust (Axum, Rocket, Actix)
|
|
- Java (Spring Boot, Quarkus)
|
|
- Ruby (Rails, Sinatra)
|
|
- PHP (Laravel, Symfony)
|
|
|
|
**Frontend:**
|
|
- React, Vue, Angular, Svelte
|
|
- Flutter (Dart)
|
|
- SwiftUI (iOS)
|
|
- Android (Kotlin, Java)
|
|
- Desktop (Electron, Tauri, Qt)
|
|
|
|
**Data:**
|
|
- Python (Pandas, NumPy, scikit-learn)
|
|
- R (tidyverse, ggplot2)
|
|
- SQL (any database)
|
|
- Spark, Hadoop
|
|
|
|
**DevOps/Infrastructure:**
|
|
- Terraform, Ansible, CloudFormation
|
|
- Docker, Kubernetes configurations
|
|
- CI/CD pipelines (GitHub Actions, GitLab CI, etc)
|
|
|
|
**Any other project type...**
|
|
|
|
---
|
|
|
|
## Key Benefits
|
|
|
|
| Aspect | Without Skill | With Master Skill |
|
|
|--------|--------------|------------------|
|
|
| **Setup** | Manual, varies by language | One command: `@master` |
|
|
| **Time** | 60-120+ minutes | 35-60 minutes |
|
|
| **Consistency** | Varies by reviewer, language | Standardized across all languages |
|
|
| **Coverage** | Partial, depends on knowledge | Comprehensive (9 stages) |
|
|
| **Safety** | Multiple manual checks | Unified quality gates |
|
|
| **Confidence** | Medium | High |
|
|
|
|
---
|
|
|
|
## Requirements
|
|
|
|
- Git repository initialized and configured
|
|
- Current branch is not main/master/trunk/production
|
|
- Upstream tracking configured (`git branch -u`)
|
|
- Claude with read/write file access and bash capability
|
|
|
|
## Compatibility
|
|
|
|
- Works with any git repository (GitHub, GitLab, Gitea, self-hosted)
|
|
- Language-agnostic (Python, JS, Dart, Go, Rust, Java, etc)
|
|
- Framework-independent (works with any framework)
|
|
- Project-type independent (backend, frontend, data, DevOps, etc)
|
|
|
|
## Limitations
|
|
|
|
- Requires git to be initialized
|
|
- Cannot push without upstream configured
|
|
- Cannot review binary files
|
|
- Architecture analysis is pattern-based
|
|
|
|
---
|
|
|
|
## Installation
|
|
|
|
1. Save this skill to your Claude Code skills directory
|
|
2. Invoke with `@master` or natural language triggers
|
|
3. Follow the 9-stage pipeline through completion
|
|
|
|
## Support & Feedback
|
|
|
|
For improvements or issues, please visit the skill repository or contact the maintainers.
|
|
|
|
---
|
|
|
|
## Version History
|
|
|
|
### Version 1.0.0 (Initial Release)
|
|
- 9-stage comprehensive workflow
|
|
- Language-agnostic design
|
|
- Code review automation
|
|
- Security compliance validation
|
|
- Multi-perspective analysis
|
|
- Safe git operations
|
|
- Works with any project type
|
|
|
|
---
|
|
|
|
**Last Updated:** 2024-10-31
|
|
**Status:** Production Ready
|
|
**Marketplace Ready:** Yes
|
|
**Universality:** Works with any language, framework, project type
|
|
|
|
Universal Code Quality Pipeline for All Developers
|