@zimezone/z-command 1.0.0

package/templates/agents/workflow-orchestrator.agent.md

@@ -0,0 +1,48 @@
+---
+description: Workflow and process orchestration specialist
+---
+
+# Workflow Orchestrator
+
+You are an expert workflow orchestrator specializing in designing and implementing complex multi-step processes and automations.
+
+## Core Responsibilities
+
+- Design workflow architectures
+- Implement process automation
+- Coordinate multi-system processes
+- Handle error recovery
+- Monitor workflow execution
+- Optimize process efficiency
+
+## Workflow Patterns
+
+- Sequential workflows
+- Parallel execution
+- Conditional branching
+- Error handling and retries
+- Human-in-the-loop
+- Event-driven triggers
+
+## Orchestration
+
+- State management
+- Dependency handling
+- Timeout management
+- Idempotent operations
+- Compensation (saga pattern)
+
+## Tools & Technologies
+
+- Temporal, Prefect, Airflow
+- Step Functions, Cloud Workflows
+- Message queues
+- Event systems
+- Monitoring dashboards
+
+## Communication Style
+
+- Think in terms of states
+- Design for failure
+- Consider long-running processes
+- Plan for visibility

package/templates/skills/code-review/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: code-review
+description: Automated code review checklist. Use when reviewing PRs or code changes.
+license: MIT
+---
+
+# Code Review
+
+Comprehensive checklist for reviewing code changes.
+
+## Pre-Review Checklist
+
+Before starting the review:
+
+- [ ] Understand the context and requirements
+- [ ] Check if tests are included
+- [ ] Verify CI/CD passes
+
+## Review Categories
+
+### 1. Correctness
+
+- Does the code do what it's supposed to?
+- Are edge cases handled?
+- Are there potential bugs or race conditions?
+
+### 2. Design
+
+- Is the code well-structured?
+- Does it follow SOLID principles?
+- Is there unnecessary complexity?
+
+### 3. Readability
+
+- Are variable/function names clear?
+- Is the code self-documenting?
+- Are comments helpful (not redundant)?
+
+### 4. Performance
+
+- Are there obvious performance issues?
+- Is there unnecessary work being done?
+- Are there N+1 queries or similar patterns?
+
+### 5. Security
+
+- Is user input validated?
+- Are there potential injection vulnerabilities?
+- Is sensitive data handled properly?
+
+### 6. Testing
+
+- Are tests comprehensive?
+- Do tests cover edge cases?
+- Are tests maintainable?
+
+## Providing Feedback
+
+- Be specific and constructive
+- Explain the "why" behind suggestions
+- Differentiate between blocking and non-blocking issues
+- Acknowledge good code

package/templates/skills/security-review/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: security-review
+description: Security vulnerability detection based on OWASP Top 10. Use when reviewing code for security issues.
+license: MIT
+---
+
+# Security Review
+
+Proactive security review based on OWASP Top 10 and security best practices.
+
+## OWASP Top 10 Checklist
+
+### A01: Broken Access Control
+
+- [ ] Verify authorization checks on all endpoints
+- [ ] Check for IDOR vulnerabilities
+- [ ] Ensure principle of least privilege
+
+### A02: Cryptographic Failures
+
+- [ ] Sensitive data encrypted in transit (HTTPS)
+- [ ] Sensitive data encrypted at rest
+- [ ] Strong encryption algorithms used
+
+### A03: Injection
+
+- [ ] SQL queries use parameterized statements
+- [ ] User input is validated and sanitized
+- [ ] Command injection prevented
+
+### A04: Insecure Design
+
+- [ ] Security requirements defined
+- [ ] Threat modeling performed
+- [ ] Secure design patterns used
+
+### A05: Security Misconfiguration
+
+- [ ] Default credentials changed
+- [ ] Unnecessary features disabled
+- [ ] Error messages don't leak info
+
+### A06: Vulnerable Components
+
+- [ ] Dependencies are up to date
+- [ ] Known vulnerabilities addressed
+- [ ] Components from trusted sources
+
+### A07: Authentication Failures
+
+- [ ] Strong password policies
+- [ ] Multi-factor authentication available
+- [ ] Session management secure
+
+### A08: Data Integrity Failures
+
+- [ ] Input validation on all data
+- [ ] Integrity checks on critical data
+- [ ] Signed updates and migrations
+
+### A09: Logging Failures
+
+- [ ] Security events logged
+- [ ] Logs don't contain sensitive data
+- [ ] Log injection prevented
+
+### A10: SSRF
+
+- [ ] URL validation on server requests
+- [ ] Allowlist for external resources
+- [ ] Network segmentation in place
+
+## Severity Levels
+
+- **Critical**: Immediate exploitation possible
+- **High**: Significant risk, fix soon
+- **Medium**: Should be addressed
+- **Low**: Minor issue, fix when convenient

package/templates/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: systematic-debugging
+description: 4-phase root cause debugging process. Use when fixing bugs or investigating issues.
+license: MIT
+---
+
+# Systematic Debugging
+
+A structured approach to finding and fixing bugs.
+
+## Phase 1: Reproduce
+
+- Confirm the bug exists
+- Document exact steps to reproduce
+- Identify the expected vs actual behavior
+- Create a minimal test case
+
+## Phase 2: Isolate
+
+- Narrow down the problem area
+- Use binary search to find the failing component
+- Add logging or breakpoints strategically
+- Check recent changes that might have caused the issue
+
+## Phase 3: Identify Root Cause
+
+- Don't just fix symptoms
+- Trace the issue to its origin
+- Understand WHY it's happening
+- Consider related areas that might be affected
+
+## Phase 4: Fix and Verify
+
+- Make the minimal fix required
+- Add a regression test
+- Verify the fix doesn't break other functionality
+- Document the fix for future reference
+
+## Techniques
+
+### Root Cause Tracing
+
+- Follow the data flow backwards
+- Check all inputs and outputs
+- Verify assumptions at each step
+
+### Defense in Depth
+
+- Add validation at multiple layers
+- Fail fast with clear error messages
+- Log important state changes
+
+### Condition-Based Waiting
+
+- Avoid arbitrary sleep/delays
+- Wait for specific conditions
+- Use timeouts with clear error messages

package/templates/skills/test-driven-development/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: test-driven-development
+description: Guide for RED-GREEN-REFACTOR cycle. Use when writing tests or implementing features with TDD.
+license: MIT
+---
+
+# Test-Driven Development
+
+Follow the RED-GREEN-REFACTOR cycle for all development work.
+
+## Process
+
+### 1. RED - Write a Failing Test
+
+- Write a test that describes the desired behavior
+- Run the test to confirm it fails
+- The test should fail for the right reason
+
+### 2. GREEN - Make It Pass
+
+- Write the minimum code to make the test pass
+- Don't over-engineer or add extra features
+- Focus only on passing the current test
+
+### 3. REFACTOR - Clean Up
+
+- Improve code quality without changing behavior
+- Remove duplication
+- Improve naming and structure
+- All tests should still pass
+
+## Anti-Patterns to Avoid
+
+- Writing code before tests
+- Writing multiple tests before making any pass
+- Refactoring while tests are failing
+- Testing implementation details instead of behavior
+- Skipping the refactor step
+
+## Best Practices
+
+- Keep tests fast and isolated
+- Test behavior, not implementation
+- One assertion per test when possible
+- Use descriptive test names
+- Mock external dependencies

package/templates/skills/writing-plans/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: writing-plans
+description: Create detailed implementation plans. Use when planning new features or refactoring work.
+license: MIT
+---
+
+# Writing Implementation Plans
+
+Create clear, actionable implementation plans that can be executed step-by-step.
+
+## Plan Structure
+
+### 1. Goal Description
+
+- What problem are we solving?
+- What is the desired outcome?
+- What are the success criteria?
+
+### 2. Background Context
+
+- Current state of the system
+- Relevant constraints
+- Prior decisions and their rationale
+
+### 3. Proposed Changes
+
+Group by component, ordered by dependency:
+
+```markdown
+### Component Name
+
+#### [MODIFY] filename.ts
+
+- Change X to Y
+- Add validation for Z
+
+#### [NEW] newfile.ts
+
+- Purpose of this file
+- Key responsibilities
+```
+
+### 4. Implementation Steps
+
+Numbered, atomic steps:
+
+1. Create the new module
+2. Add tests for the new functionality
+3. Integrate with existing code
+4. Update documentation
+
+### 5. Verification Plan
+
+- Unit tests to add
+- Integration tests needed
+- Manual verification steps
+
+## Best Practices
+
+- Keep steps small and atomic
+- Include rollback considerations
+- Identify risks and mitigations
+- Estimate effort for each step
+- Mark dependencies between steps