feat: Initialize Claude Skills repository with Master Workflow skill
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>
This commit is contained in:
Svrnty
commit
7bd3bf3643
46
.gitignore
vendored
Normal file
46
.gitignore
vendored
Normal file
@ -0,0 +1,46 @@
|
|||||||
|
# IDE and Editor
|
||||||
|
.vscode/
|
||||||
|
.idea/
|
||||||
|
*.swp
|
||||||
|
*.swo
|
||||||
|
*~
|
||||||
|
.DS_Store
|
||||||
|
|
||||||
|
# Node
|
||||||
|
node_modules/
|
||||||
|
npm-debug.log
|
||||||
|
yarn-error.log
|
||||||
|
|
||||||
|
# Python
|
||||||
|
__pycache__/
|
||||||
|
*.py[cod]
|
||||||
|
*$py.class
|
||||||
|
.env
|
||||||
|
.venv
|
||||||
|
env/
|
||||||
|
venv/
|
||||||
|
|
||||||
|
# Build directories
|
||||||
|
dist/
|
||||||
|
build/
|
||||||
|
*.egg-info/
|
||||||
|
|
||||||
|
# Test coverage
|
||||||
|
.coverage
|
||||||
|
htmlcov/
|
||||||
|
coverage/
|
||||||
|
|
||||||
|
# Temporary files
|
||||||
|
*.tmp
|
||||||
|
*.temp
|
||||||
|
.trash/
|
||||||
|
temp/
|
||||||
|
|
||||||
|
# OS
|
||||||
|
Thumbs.db
|
||||||
|
.DS_Store
|
||||||
|
|
||||||
|
# Project specific
|
||||||
|
.claude/
|
||||||
|
.claude-docs/
|
||||||
|
.claude-skills/
|
||||||
205
CONTRIBUTING.md
Normal file
205
CONTRIBUTING.md
Normal file
@ -0,0 +1,205 @@
|
|||||||
|
# Contributing to Claude Skills
|
||||||
|
|
||||||
|
Thank you for your interest in contributing to the Claude Skills repository!
|
||||||
|
|
||||||
|
## Getting Started
|
||||||
|
|
||||||
|
1. Fork the repository
|
||||||
|
2. Create a feature branch (`git checkout -b feature/skill-name`)
|
||||||
|
3. Make your changes
|
||||||
|
4. Test thoroughly
|
||||||
|
5. Create a pull request
|
||||||
|
|
||||||
|
## Skill Development Guidelines
|
||||||
|
|
||||||
|
### Structure
|
||||||
|
Each skill should follow this format:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
name: skill-name
|
||||||
|
title: Human-Readable Title
|
||||||
|
version: 1.0.0
|
||||||
|
author: Your Name
|
||||||
|
category: category-name
|
||||||
|
keywords: [keyword1, keyword2, ...]
|
||||||
|
description: Clear description of what the skill does
|
||||||
|
icon: ✓
|
||||||
|
activation_phrases:
|
||||||
|
- "@skill-name"
|
||||||
|
- "phrase one"
|
||||||
|
- "phrase two"
|
||||||
|
min_claude_version: 3.5
|
||||||
|
compatibility:
|
||||||
|
- Language1
|
||||||
|
- Language2
|
||||||
|
---
|
||||||
|
|
||||||
|
# Skill Name
|
||||||
|
|
||||||
|
[Detailed documentation...]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Required Sections
|
||||||
|
|
||||||
|
- **Name**: Unique identifier (kebab-case)
|
||||||
|
- **Title**: Human-readable name
|
||||||
|
- **Description**: Clear, concise description
|
||||||
|
- **Activation Phrases**: At least 3-5 common ways to invoke
|
||||||
|
- **Purpose**: Why someone would use this skill
|
||||||
|
- **Usage**: How to use it
|
||||||
|
- **Features**: What it does
|
||||||
|
- **Examples**: Real-world examples
|
||||||
|
- **Requirements**: What's needed to use it
|
||||||
|
|
||||||
|
### Optional Sections
|
||||||
|
|
||||||
|
- **Compatibility**: Languages, frameworks, platforms
|
||||||
|
- **Performance**: Time estimates, resource usage
|
||||||
|
- **Limitations**: What it can't do
|
||||||
|
- **Troubleshooting**: Common issues
|
||||||
|
- **Roadmap**: Planned improvements
|
||||||
|
|
||||||
|
## Quality Standards
|
||||||
|
|
||||||
|
### Documentation
|
||||||
|
- [ ] Clear purpose and use cases
|
||||||
|
- [ ] Real-world examples included
|
||||||
|
- [ ] Prerequisites documented
|
||||||
|
- [ ] Output format explained
|
||||||
|
- [ ] Limitations noted
|
||||||
|
|
||||||
|
### Functionality
|
||||||
|
- [ ] Works language-agnostic (or clearly documents limitations)
|
||||||
|
- [ ] Handles errors gracefully
|
||||||
|
- [ ] Provides helpful feedback
|
||||||
|
- [ ] Safe operations (no destructive changes without confirmation)
|
||||||
|
- [ ] Security best practices followed
|
||||||
|
|
||||||
|
### Format
|
||||||
|
- [ ] Valid YAML frontmatter
|
||||||
|
- [ ] Proper markdown formatting
|
||||||
|
- [ ] No spelling errors
|
||||||
|
- [ ] Links work correctly
|
||||||
|
- [ ] Code examples are accurate
|
||||||
|
|
||||||
|
## Categories
|
||||||
|
|
||||||
|
Skills should be categorized as:
|
||||||
|
|
||||||
|
- **code-review**: Code quality and review automation
|
||||||
|
- **security**: Security analysis and validation
|
||||||
|
- **architecture**: Architecture and design patterns
|
||||||
|
- **testing**: Testing and test coverage
|
||||||
|
- **documentation**: Documentation generation and management
|
||||||
|
- **refactoring**: Code refactoring assistance
|
||||||
|
- **performance**: Performance optimization
|
||||||
|
- **devops**: DevOps and deployment
|
||||||
|
- **utilities**: General utilities
|
||||||
|
|
||||||
|
## Naming Conventions
|
||||||
|
|
||||||
|
- Skill names: `kebab-case` (e.g., `master-workflow`)
|
||||||
|
- Titles: Title Case with clear description
|
||||||
|
- Activation phrases: Natural language phrases users would say
|
||||||
|
- File names: `skill-name.md`
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
Before submitting:
|
||||||
|
|
||||||
|
1. **Syntax Check**
|
||||||
|
- Valid YAML frontmatter
|
||||||
|
- Proper markdown syntax
|
||||||
|
- No broken links
|
||||||
|
|
||||||
|
2. **Functionality Test**
|
||||||
|
- Invoke the skill multiple ways
|
||||||
|
- Test with different project types
|
||||||
|
- Verify all features work
|
||||||
|
- Test error cases
|
||||||
|
|
||||||
|
3. **Documentation Review**
|
||||||
|
- Clear and complete
|
||||||
|
- Examples work
|
||||||
|
- Requirements documented
|
||||||
|
- Limitations noted
|
||||||
|
|
||||||
|
## Pull Request Process
|
||||||
|
|
||||||
|
1. Create a descriptive PR title
|
||||||
|
2. Include a summary of changes
|
||||||
|
3. Reference any related issues
|
||||||
|
4. Ensure all checks pass
|
||||||
|
5. Request review from maintainers
|
||||||
|
|
||||||
|
### PR Template
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Description
|
||||||
|
[Brief description of the skill]
|
||||||
|
|
||||||
|
## Type of Change
|
||||||
|
- [ ] New skill
|
||||||
|
- [ ] Enhancement to existing skill
|
||||||
|
- [ ] Bug fix
|
||||||
|
- [ ] Documentation update
|
||||||
|
|
||||||
|
## Checklist
|
||||||
|
- [ ] Documentation is clear and complete
|
||||||
|
- [ ] Examples are included and tested
|
||||||
|
- [ ] YAML frontmatter is valid
|
||||||
|
- [ ] Markdown formatting is correct
|
||||||
|
- [ ] No spelling errors
|
||||||
|
- [ ] Code examples are accurate
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
[Describe how you tested the skill]
|
||||||
|
|
||||||
|
## Additional Notes
|
||||||
|
[Any additional context]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Skill Ideas
|
||||||
|
|
||||||
|
We're always looking for new skills in these areas:
|
||||||
|
|
||||||
|
- **Code Analysis**: Static analysis, complexity detection, pattern matching
|
||||||
|
- **Security**: Vulnerability scanning, OWASP validation, secrets detection
|
||||||
|
- **Documentation**: Auto-documentation, changelog generation, API docs
|
||||||
|
- **Testing**: Test generation, coverage analysis, test best practices
|
||||||
|
- **DevOps**: Deployment validation, infrastructure review, CI/CD checks
|
||||||
|
- **Refactoring**: Automated refactoring suggestions, code improvements
|
||||||
|
- **Performance**: Performance optimization, bottleneck detection
|
||||||
|
- **Git**: Git workflow automation, commit message validation
|
||||||
|
|
||||||
|
## Code of Conduct
|
||||||
|
|
||||||
|
- Be respectful and inclusive
|
||||||
|
- Provide constructive feedback
|
||||||
|
- Ask questions when unclear
|
||||||
|
- Help others learn and grow
|
||||||
|
- Focus on the problem, not the person
|
||||||
|
|
||||||
|
## Questions?
|
||||||
|
|
||||||
|
- Check existing issues for answers
|
||||||
|
- Create a new issue if needed
|
||||||
|
- Join discussions in pull requests
|
||||||
|
- Be patient and respectful
|
||||||
|
|
||||||
|
## Recognition
|
||||||
|
|
||||||
|
Contributors will be:
|
||||||
|
- Listed in the repository
|
||||||
|
- Credited in changelog
|
||||||
|
- Acknowledged in documentation
|
||||||
|
- Featured on the marketplace
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
By contributing, you agree that your contributions will be licensed under the same license as the project (see LICENSE file).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Thank you for contributing to Claude Skills!
|
||||||
21
LICENSE
Normal file
21
LICENSE
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2024 Svrnty Development Team
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
295
README.md
Normal file
295
README.md
Normal file
@ -0,0 +1,295 @@
|
|||||||
|
# Claude Skills Repository
|
||||||
|
|
||||||
|
A collection of professional, production-ready Claude AI skills for developers.
|
||||||
|
|
||||||
|
## Skills
|
||||||
|
|
||||||
|
### Master Workflow (v1.0.0)
|
||||||
|
|
||||||
|
**Universal Code Quality & Release Pipeline**
|
||||||
|
|
||||||
|
A comprehensive 9-stage development workflow that works with ANY programming language, framework, or project type.
|
||||||
|
|
||||||
|
**Features:**
|
||||||
|
- ✅ Code review automation
|
||||||
|
- ✅ Security compliance validation (OWASP Top 10)
|
||||||
|
- ✅ Architecture & quality audit (6 dimensions)
|
||||||
|
- ✅ Multi-perspective PR review (6 stakeholder angles)
|
||||||
|
- ✅ Interactive issue resolution
|
||||||
|
- ✅ Safe git operations with quality gates
|
||||||
|
- ✅ Language-agnostic (Python, JavaScript, Dart, Go, Rust, Java, etc.)
|
||||||
|
- ✅ Framework-independent
|
||||||
|
- ✅ Works on any project type
|
||||||
|
|
||||||
|
**Activation Phrases:**
|
||||||
|
- `@master`
|
||||||
|
- "complete workflow"
|
||||||
|
- "finish session"
|
||||||
|
- "full pipeline"
|
||||||
|
- "wrap up and push"
|
||||||
|
- And more...
|
||||||
|
|
||||||
|
**Usage:**
|
||||||
|
```
|
||||||
|
@master
|
||||||
|
```
|
||||||
|
|
||||||
|
**Time Estimate:** 35-60 minutes (full pipeline) or 10-15 minutes (quick mode)
|
||||||
|
|
||||||
|
**Perfect For:**
|
||||||
|
- Feature branches ready for PR review
|
||||||
|
- Release preparation
|
||||||
|
- Code ready to merge to main
|
||||||
|
- Security-critical changes
|
||||||
|
- Complex architectural changes
|
||||||
|
- Team code reviews
|
||||||
|
- Enterprise deployments
|
||||||
|
|
||||||
|
**Included:**
|
||||||
|
- 9-stage quality assurance pipeline
|
||||||
|
- Automated code review
|
||||||
|
- Security and compliance checks
|
||||||
|
- Architecture audit
|
||||||
|
- Multi-perspective feedback
|
||||||
|
- Issue resolution assistance
|
||||||
|
- Safe push to origin
|
||||||
|
|
||||||
|
## Repository Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
.
|
||||||
|
├── README.md # This file
|
||||||
|
├── master-workflow.md # Master workflow skill
|
||||||
|
├── LICENSE # License information
|
||||||
|
└── CONTRIBUTING.md # Contribution guidelines
|
||||||
|
```
|
||||||
|
|
||||||
|
## Quick Start
|
||||||
|
|
||||||
|
1. Copy the skill file to your Claude Code skills directory:
|
||||||
|
```bash
|
||||||
|
cp master-workflow.md ~/.claude/skills/
|
||||||
|
```
|
||||||
|
|
||||||
|
2. In Claude Code, invoke with:
|
||||||
|
```
|
||||||
|
@master
|
||||||
|
```
|
||||||
|
|
||||||
|
3. Follow the 9-stage pipeline to completion
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
### Option 1: Manual Installation
|
||||||
|
```bash
|
||||||
|
cp master-workflow.md ~/.claude/skills/
|
||||||
|
```
|
||||||
|
|
||||||
|
### Option 2: From This Repository
|
||||||
|
```bash
|
||||||
|
git clone https://git.openharbor.io/svrnty/claude-skills.git
|
||||||
|
cp claude-skills/master-workflow.md ~/.claude/skills/
|
||||||
|
```
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
- Claude Code (latest version)
|
||||||
|
- Git repository initialized
|
||||||
|
- Not on main/master/trunk/production branch
|
||||||
|
- Upstream tracking configured
|
||||||
|
|
||||||
|
## Compatibility
|
||||||
|
|
||||||
|
**Languages:** Python, JavaScript/TypeScript, Dart, Go, Rust, Java, C/C++, Ruby, PHP, and any other language
|
||||||
|
|
||||||
|
**Frameworks:** Language and framework-agnostic
|
||||||
|
|
||||||
|
**Project Types:**
|
||||||
|
- Backend services
|
||||||
|
- Frontend applications
|
||||||
|
- Full-stack projects
|
||||||
|
- Mobile apps
|
||||||
|
- Desktop applications
|
||||||
|
- CLI tools
|
||||||
|
- Data science projects
|
||||||
|
- DevOps/Infrastructure
|
||||||
|
- Monorepos
|
||||||
|
- Microservices
|
||||||
|
|
||||||
|
**Platforms:** Any platform with Git support (GitHub, GitLab, Gitea, self-hosted)
|
||||||
|
|
||||||
|
## Features
|
||||||
|
|
||||||
|
### Stage 1: Git Status & Preparation
|
||||||
|
- Verify repository state
|
||||||
|
- Check branch safety
|
||||||
|
- Confirm readiness
|
||||||
|
|
||||||
|
### Stage 2: Code Review
|
||||||
|
- Recent changes analysis
|
||||||
|
- Code quality assessment
|
||||||
|
- Security issue detection
|
||||||
|
- Readability check
|
||||||
|
|
||||||
|
### Stage 3: Architecture Audit
|
||||||
|
- 6-dimensional analysis (Architecture, Quality, Security, Performance, Testing, Maintainability)
|
||||||
|
- Design pattern evaluation
|
||||||
|
- Technical debt assessment
|
||||||
|
- Coupling analysis
|
||||||
|
|
||||||
|
### Stage 4: Security & Compliance
|
||||||
|
- OWASP Top 10 validation
|
||||||
|
- Enterprise security controls
|
||||||
|
- Dependency vulnerability scanning
|
||||||
|
- Secrets detection
|
||||||
|
|
||||||
|
### Stage 5: Multi-Perspective Review
|
||||||
|
- Product Manager perspective
|
||||||
|
- Developer perspective
|
||||||
|
- QA Engineer perspective
|
||||||
|
- Security Engineer perspective
|
||||||
|
- DevOps perspective
|
||||||
|
- UI/UX Designer perspective
|
||||||
|
|
||||||
|
### Stage 6: Synthesis & Prioritization
|
||||||
|
- Consolidate all findings
|
||||||
|
- Create action plan
|
||||||
|
- Estimate remediation effort
|
||||||
|
- Identify quick wins
|
||||||
|
|
||||||
|
### Stage 7: Issue Resolution
|
||||||
|
- Interactive issue fixing
|
||||||
|
- Targeted assistance
|
||||||
|
- Re-validation
|
||||||
|
|
||||||
|
### Stage 8: Pre-Push Verification
|
||||||
|
- Final safety checks
|
||||||
|
- Branch confirmation
|
||||||
|
- Remote verification
|
||||||
|
|
||||||
|
### Stage 9: Safe Git Push
|
||||||
|
- Automated commit
|
||||||
|
- Quality summary
|
||||||
|
- Secure push to origin
|
||||||
|
|
||||||
|
## Usage Modes
|
||||||
|
|
||||||
|
### Full Pipeline (Default)
|
||||||
|
```
|
||||||
|
@master
|
||||||
|
```
|
||||||
|
Executes all 9 stages (35-60 minutes)
|
||||||
|
|
||||||
|
### Quick Review
|
||||||
|
```
|
||||||
|
@master --quick
|
||||||
|
```
|
||||||
|
Stages 1-2 only (10-15 minutes)
|
||||||
|
|
||||||
|
### Security-Focused
|
||||||
|
```
|
||||||
|
@master --security
|
||||||
|
```
|
||||||
|
Prioritizes Stages 4-5
|
||||||
|
|
||||||
|
### Review Only
|
||||||
|
```
|
||||||
|
@master --review-only
|
||||||
|
```
|
||||||
|
All stages except push
|
||||||
|
|
||||||
|
### Force Mode
|
||||||
|
```
|
||||||
|
@master --force
|
||||||
|
```
|
||||||
|
Skip blockers and push (use with caution)
|
||||||
|
|
||||||
|
## Language Support
|
||||||
|
|
||||||
|
Tested and optimized for:
|
||||||
|
|
||||||
|
**Popular Languages:**
|
||||||
|
- Python (Django, FastAPI, Flask, async)
|
||||||
|
- JavaScript/TypeScript (React, Vue, Node, NestJS)
|
||||||
|
- Dart (Flutter, web, desktop)
|
||||||
|
- Go (microservices, CLI)
|
||||||
|
- Rust (systems, web, embedded)
|
||||||
|
- Java (Spring Boot, Android)
|
||||||
|
- Ruby (Rails, Sinatra)
|
||||||
|
- PHP (Laravel, Symfony)
|
||||||
|
|
||||||
|
**And supports any other language...**
|
||||||
|
|
||||||
|
## Performance
|
||||||
|
|
||||||
|
**Stage Breakdown:**
|
||||||
|
- Stage 1 (Git Prep): 2-3 minutes
|
||||||
|
- Stage 2 (Code Review): 5-10 minutes
|
||||||
|
- Stage 3 (Architecture Audit): 10-15 minutes
|
||||||
|
- Stage 4 (Security): 8-12 minutes
|
||||||
|
- Stage 5 (Multi-perspective): 5-8 minutes
|
||||||
|
- Stage 6 (Synthesis): 3-5 minutes
|
||||||
|
- Stage 7 (Issue Resolution): Variable
|
||||||
|
- Stage 8 (Verification): 2-3 minutes
|
||||||
|
- Stage 9 (Push): 2-3 minutes
|
||||||
|
|
||||||
|
**Total:** 35-60 minutes for full pipeline
|
||||||
|
|
||||||
|
## Safety Features
|
||||||
|
|
||||||
|
- ✅ Branch protection (prevents main/master pushes)
|
||||||
|
- ✅ Quality gates (blocks push if critical issues)
|
||||||
|
- ✅ Secret detection (finds exposed API keys)
|
||||||
|
- ✅ Confirmation gates (requires explicit approval)
|
||||||
|
- ✅ Re-validation (after fixes)
|
||||||
|
- ✅ Rollback-friendly (clean commit history)
|
||||||
|
|
||||||
|
## Contributing
|
||||||
|
|
||||||
|
See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines on:
|
||||||
|
- Bug reports
|
||||||
|
- Feature requests
|
||||||
|
- Improvements
|
||||||
|
- Language-specific enhancements
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
[See LICENSE file](LICENSE)
|
||||||
|
|
||||||
|
## Support
|
||||||
|
|
||||||
|
For issues or questions:
|
||||||
|
1. Check the skill documentation
|
||||||
|
2. Review the 9-stage pipeline guide
|
||||||
|
3. Create an issue in the repository
|
||||||
|
|
||||||
|
## Roadmap
|
||||||
|
|
||||||
|
Future enhancements planned:
|
||||||
|
- [ ] Language-specific linting integration
|
||||||
|
- [ ] Framework-specific best practices
|
||||||
|
- [ ] CI/CD pipeline integration
|
||||||
|
- [ ] Custom rule sets
|
||||||
|
- [ ] Multi-language projects support
|
||||||
|
- [ ] Docker-based analysis
|
||||||
|
- [ ] Pre-commit hook integration
|
||||||
|
|
||||||
|
## Changelog
|
||||||
|
|
||||||
|
### v1.0.0 (2024-10-31)
|
||||||
|
- Initial release
|
||||||
|
- 9-stage pipeline
|
||||||
|
- Universal language support
|
||||||
|
- Security validation
|
||||||
|
- Multi-perspective review
|
||||||
|
- Safe git operations
|
||||||
|
|
||||||
|
## Author
|
||||||
|
|
||||||
|
Svrnty Development Team
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Status:** Production Ready
|
||||||
|
**Marketplace Compatible:** Yes
|
||||||
|
**Universal:** Works with any language, framework, project type
|
||||||
775
master-workflow.md
Normal file
775
master-workflow.md
Normal file
@ -0,0 +1,775 @@
|
|||||||
|
---
|
||||||
|
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
|
||||||
Loading…
Reference in New Issue
Block a user