aigroup-workflow 2.1.1 → 2.2.0

package/skills/code-reviewer/references/report-template.md

@@ -1,109 +0,0 @@
-# Report Template
-
-## Full Review Report Template
-
-```markdown
-# Code Review: [PR Title]
-
-## Summary
-[1-2 sentence overview of the changes and overall assessment]
-
-**Verdict**: [ ] Approve | [x] Request Changes | [ ] Comment
-
-## Critical Issues (Must Fix)
-
-### 1. [File:Line] Security: SQL Injection Risk
-- **Current**: String interpolation in query
-- **Suggested**: Use parameterized query
-- **Impact**: Potential data breach
-
-```typescript
-// Current (vulnerable)
-const query = `SELECT * FROM users WHERE id = ${id}`;
-
-// Suggested (secure)
-const query = 'SELECT * FROM users WHERE id = $1';
-db.query(query, [id]);
-```
-
-## Major Issues (Should Fix)
-
-### 1. [File:Line] Performance: N+1 Query
-- **Current**: Fetching users in loop
-- **Suggested**: Use eager loading with include
-- **Impact**: ~100 extra DB queries per request
-
-### 2. [File:Line] Logic: Missing edge case
-- **Current**: No handling for empty array
-- **Suggested**: Add guard clause
-- **Impact**: Potential runtime error
-
-## Minor Issues (Nice to Have)
-
-### 1. [File:Line] Naming: Unclear variable name
-- **Current**: `d`
-- **Suggested**: `createdDate`
-
-### 2. [File:Line] Style: Inconsistent formatting
-- **Current**: Mixed quotes
-- **Suggested**: Use single quotes consistently
-
-## Positive Feedback
-- Clean separation of concerns in service layer
-- Comprehensive input validation on DTOs
-- Good test coverage for edge cases
-- Excellent error messages
-
-## Questions for Author
-- What's the expected behavior when X happens?
-- Should this support pagination for large datasets?
-- Is the retry logic intentional or accidental?
-
-## Test Coverage Assessment
-- [ ] Happy path tested
-- [x] Error cases tested
-- [ ] Edge cases tested (missing empty array test)
-- [x] Integration tests present
-
-## Checklist
-- [x] No security vulnerabilities
-- [ ] Performance is acceptable (N+1 issue)
-- [x] Code is readable
-- [x] Tests are adequate
-- [x] Documentation is present
-```
-
-## Verdict Guidelines
-
-| Verdict | When to Use |
-|---------|-------------|
-| **Approve** | No blocking issues, minor suggestions only |
-| **Request Changes** | Critical or major issues must be fixed |
-| **Comment** | Questions need answers, no blocking issues |
-
-## Severity Definitions
-
-| Severity | Definition | Examples |
-|----------|------------|----------|
-| **Critical** | Security risk, data loss, crashes | SQL injection, auth bypass |
-| **Major** | Significant performance, maintainability | N+1 queries, god functions |
-| **Minor** | Style, naming, small improvements | Variable names, formatting |
-
-## Time Boxing
-
-| Section | Suggested Time |
-|---------|----------------|
-| Context & understanding | 5 minutes |
-| Critical/security review | 10 minutes |
-| Logic & performance | 15 minutes |
-| Tests review | 10 minutes |
-| Writing report | 10 minutes |
-| **Total** | ~50 minutes |
-
-## Quick Checks Before Submitting
-
-- [ ] All critical issues have clear remediation
-- [ ] Major issues explain the impact
-- [ ] At least one positive comment included
-- [ ] Questions are specific and answerable
-- [ ] Verdict matches the issues found

package/skills/code-reviewer/references/review-checklist.md

@@ -1,88 +0,0 @@
-# Review Checklist
-
-## Comprehensive Review Checklist
-
-| Category | Key Questions |
-|----------|---------------|
-| **Design** | Does it fit existing patterns? Right abstraction level? |
-| **Logic** | Edge cases handled? Race conditions? Null checks? |
-| **Security** | Input validated? Auth checked? Secrets safe? |
-| **Performance** | N+1 queries? Memory leaks? Caching needed? |
-| **Tests** | Adequate coverage? Edge cases tested? Mocks appropriate? |
-| **Naming** | Clear, consistent, intention-revealing? |
-| **Error Handling** | Errors caught? Meaningful messages? Logged? |
-| **Documentation** | Public APIs documented? Complex logic explained? |
-
-## Review Process
-
-### 1. Context (5 min)
-- [ ] Read PR description
-- [ ] Understand the problem being solved
-- [ ] Check linked issues/tickets
-- [ ] Note expected changes
-
-### 2. Structure (10 min)
-- [ ] Review file organization
-- [ ] Check architectural fit
-- [ ] Verify design patterns used
-- [ ] Note any breaking changes
-
-### 3. Code Details (20 min)
-- [ ] Review logic correctness
-- [ ] Check edge cases
-- [ ] Verify error handling
-- [ ] Look for security issues
-- [ ] Check performance concerns
-- [ ] Review naming clarity
-
-### 4. Tests (10 min)
-- [ ] Verify test coverage
-- [ ] Check test quality
-- [ ] Look for edge case tests
-- [ ] Ensure mocks are appropriate
-
-### 5. Final Pass (5 min)
-- [ ] Note positive patterns
-- [ ] Prioritize feedback
-- [ ] Write summary
-
-## Category Deep Dive
-
-### Design Questions
-- Does this change belong in this file/module?
-- Is the abstraction level appropriate?
-- Could this be simpler?
-- Does it follow existing patterns?
-- Is it extensible without modification?
-
-### Logic Questions
-- What happens with null/undefined inputs?
-- Are boundary conditions handled?
-- Could there be race conditions?
-- Is the order of operations correct?
-- Are all code paths tested?
-
-### Security Questions
-- Is all user input validated?
-- Are SQL queries parameterized?
-- Is output properly encoded?
-- Are secrets handled safely?
-- Is authentication checked?
-- Is authorization enforced?
-
-### Performance Questions
-- Are there N+1 query patterns?
-- Is data fetched efficiently?
-- Are expensive operations cached?
-- Could this cause memory leaks?
-- Is pagination implemented?
-
-## Quick Reference
-
-| Review Focus | Time % |
-|--------------|--------|
-| Context & PR description | 10% |
-| Architecture & design | 20% |
-| Code logic & details | 40% |
-| Tests & coverage | 20% |
-| Final review & summary | 10% |

package/skills/code-reviewer/references/spec-compliance-review.md

@@ -1,258 +0,0 @@
-# Spec Compliance Review
-
----
-
-## Two-Stage Review Architecture
-
-```
-                    ┌─────────────────────┐
-                    │   Implementation    │
-                    └──────────┬──────────┘
-                               │
-                    ┌──────────▼──────────┐
-                    │  STAGE 1: Spec      │
-                    │  Compliance Review  │
-                    └──────────┬──────────┘
-                               │
-              ┌────────────────┴────────────────┐
-              │                                  │
-      ┌───────▼───────┐                ┌────────▼────────┐
-      │   ✗ Issues    │                │   ✓ Compliant   │
-      │     Found     │                │                 │
-      └───────┬───────┘                └────────┬────────┘
-              │                                  │
-              │                        ┌────────▼────────┐
-              │                        │  STAGE 2: Code  │
-              │                        │  Quality Review │
-              │                        └────────┬────────┘
-              │                                  │
-              │                    ┌─────────────┴─────────────┐
-              │                    │                           │
-              │            ┌───────▼───────┐         ┌────────▼────────┐
-              │            │   ✗ Issues    │         │   ✓ Approved    │
-              │            │     Found     │         │                 │
-              │            └───────┬───────┘         └─────────────────┘
-              │                    │
-              └────────────────────┴────────────────────┐
-                                                        │
-                                              ┌─────────▼─────────┐
-                                              │ Return to Author  │
-                                              └───────────────────┘
-```
-
-**Critical:** Complete Stage 1 (spec compliance) BEFORE Stage 2 (code quality). Never review code quality for functionality that doesn't meet the specification.
-
----
-
-## Stage 1: Spec Compliance Review
-
-### Core Directive
-
-> "The implementer finished suspiciously quickly. Their report may be incomplete, inaccurate, or optimistic."
-
-Approach every review with professional skepticism. Verify claims independently.
-
-### The Three Verification Categories
-
-#### Category 1: Missing Requirements
-
-**Check for features that were requested but not implemented.**
-
-| Question | How to Verify |
-|----------|---------------|
-| Did they skip requested features? | Compare PR to original requirements line by line |
-| Are edge cases handled? | Check error paths, empty states, boundaries |
-| Were error scenarios addressed? | Look for try/catch, error boundaries, validation |
-| Is the happy path complete? | Trace through primary use case manually |
-
-```markdown
-## Example Review Finding
-
-**Missing Requirement:** Issue #42 requested "password must be at least 8 characters"
-
-**Found in code:**
-```typescript
-// No length validation present
-function validatePassword(password: string) {
-  return password.length > 0;  // Only checks non-empty
-}
-```
-
-**Status:** ❌ Incomplete - minimum length validation missing
-```
-
-#### Category 2: Unnecessary Additions
-
-**Check for scope creep and over-engineering.**
-
-| Question | How to Verify |
-|----------|---------------|
-| Features beyond specification? | Compare to original requirements |
-| Over-engineering? | Is complexity justified by requirements? |
-| Premature optimization? | Is performance cited without measurements? |
-| Unrequested abstractions? | Are there helpers/utils for one-time use? |
-
-```markdown
-## Example Review Finding
-
-**Unnecessary Addition:** Added caching layer not in requirements
-
-**Found in code:**
-```typescript
-// Original requirement: "Fetch user by ID"
-// Actual implementation:
-class CachedUserRepository {  // Not requested
-  private cache = new Map();
-  private ttl = 60000;
-
-  async getUser(id: string) {
-    if (this.cache.has(id)) { ... }
-    // 50 lines of cache logic
-  }
-}
-```
-
-**Status:** ⚠️ Scope creep - discuss before merging
-```
-
-#### Category 3: Interpretation Gaps
-
-**Check for misunderstandings of requirements.**
-
-| Question | How to Verify |
-|----------|---------------|
-| Different understanding of requirements? | Ask author to explain their interpretation |
-| Unclarified assumptions? | Look for comments like "assuming..." |
-| Ambiguous specs resolved incorrectly? | Compare to similar existing features |
-
-```markdown
-## Example Review Finding
-
-**Interpretation Gap:** "Sort by date" implemented as ascending
-
-**Requirement stated:** "Sort by date" (ambiguous)
-
-**Author implemented:** Oldest first (ascending)
-
-**Expected:** Most recent first is typical UX pattern
-
-**Status:** ❓ Clarify - which sort order was intended?
-```
-
----
-
-## Why Order Matters
-
-### Stage 1 Must Come First
-
-| Scenario | Waste from Wrong Order |
-|----------|------------------------|
-| Skip Stage 1 | Review 500 lines of code quality, then discover wrong feature was built |
-| Stage 2 First | Suggest refactoring, then realize the code shouldn't exist |
-| Combined | Mix concerns, miss systematic issues |
-
-### Separation of Concerns
-
-- **Stage 1 (Spec):** Does it do the right thing?
-- **Stage 2 (Quality):** Does it do the thing right?
-
-Code quality review is meaningless if the code doesn't implement the correct functionality.
-
----
-
-## Spec Compliance Checklist
-
-### Before You Start
-
-- [ ] Read the original issue/ticket completely
-- [ ] Identify all explicit requirements
-- [ ] Identify implicit requirements from context
-- [ ] Note any acceptance criteria listed
-
-### During Review
-
-**Missing Requirements:**
-- [ ] All required features present
-- [ ] Edge cases covered (empty, null, max values)
-- [ ] Error handling as specified
-- [ ] Happy path fully functional
-- [ ] UI matches mockups/specs if provided
-
-**Unnecessary Additions:**
-- [ ] No unrequested features
-- [ ] No speculative abstractions
-- [ ] No premature optimizations
-- [ ] Scope matches requirements exactly
-
-**Interpretation Gaps:**
-- [ ] Author's understanding matches spec
-- [ ] Ambiguities resolved correctly
-- [ ] Assumptions are documented and valid
-- [ ] Behavior matches similar existing features
-
-### After Review
-
-- [ ] Document all findings with file:line references
-- [ ] Categorize as missing/unnecessary/interpretation
-- [ ] Prioritize: blocking vs. non-blocking issues
-
----
-
-## Output Format
-
-### Compliant Result
-
-```markdown
-## Spec Compliance Review: ✅ PASS
-
-All requirements verified:
-- ✅ User can upload profile image (req #1)
-- ✅ Image resized to 200x200 (req #2)
-- ✅ Invalid formats rejected with error message (req #3)
-- ✅ Progress indicator during upload (req #4)
-
-**Proceed to:** Code Quality Review
-```
-
-### Issues Found
-
-```markdown
-## Spec Compliance Review: ❌ ISSUES FOUND
-
-### Missing Requirements
-
-1. **Progress indicator not implemented** (req #4)
-   - File: `ProfileUpload.tsx`
-   - Expected: Progress bar during upload
-   - Found: No progress indication
-
-2. **Error messages not user-friendly** (req #3)
-   - File: `ProfileUpload.tsx:45`
-   - Expected: "Please upload a JPG or PNG file"
-   - Found: "Error: INVALID_FORMAT"
-
-### Unnecessary Additions
-
-1. **Image cropping feature not requested**
-   - File: `ImageCropper.tsx` (new file, 150 lines)
-   - Impact: Adds complexity, delays delivery
-   - Recommendation: Remove or create separate PR
-
-**Action Required:** Address missing requirements before code quality review
-```
-
----
-
-## Common Mistakes to Avoid
-
-| Mistake | Why It's Wrong |
-|---------|----------------|
-| Reviewing code style before spec compliance | Wasted effort if wrong thing was built |
-| Assuming spec was followed | Verify independently |
-| Skipping edge cases | Bugs hide in boundaries |
-| Accepting "we can add it later" | Technical debt accumulates |
-| Missing scope creep | Unreviewed code enters codebase |
-
----
-
-*Content adapted from [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (@obra), MIT License.*

package/skills/cpp-pro/SKILL.md

@@ -1,115 +0,0 @@
----
-name: cpp-pro
-description: Writes, optimizes, and debugs C++ applications using modern C++20/23 features, template metaprogramming, and high-performance systems techniques. Use when building or refactoring C++ code requiring concepts, ranges, coroutines, SIMD optimization, or careful memory management — or when addressing performance bottlenecks, concurrency issues, and build system configuration with CMake.
-license: MIT
-metadata:
-  author: https://github.com/Jeffallan
-  version: "1.1.0"
-  domain: language
-  triggers: C++, C++20, C++23, modern C++, template metaprogramming, systems programming, performance optimization, SIMD, memory management, CMake
-  role: specialist
-  scope: implementation
-  output-format: code
-  related-skills: rust-engineer, embedded-systems
----
-
-# C++ Pro
-
-Senior C++ developer with deep expertise in modern C++20/23, systems programming, high-performance computing, and zero-overhead abstractions.
-
-## Core Workflow
-
-1. **Analyze architecture** — Review build system, compiler flags, performance requirements
-2. **Design with concepts** — Create type-safe interfaces using C++20 concepts
-3. **Implement zero-cost** — Apply RAII, constexpr, and zero-overhead abstractions
-4. **Verify quality** — Run sanitizers and static analysis; if AddressSanitizer or UndefinedBehaviorSanitizer report issues, fix all memory and UB errors before proceeding
-5. **Benchmark** — Profile with real workloads; if performance targets are not met, apply targeted optimizations (SIMD, cache layout, move semantics) and re-measure
-
-## Reference Guide
-
-Load detailed guidance based on context:
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Modern C++ Features | `references/modern-cpp.md` | C++20/23 features, concepts, ranges, coroutines |
-| Template Metaprogramming | `references/templates.md` | Variadic templates, SFINAE, type traits, CRTP |
-| Memory & Performance | `references/memory-performance.md` | Allocators, SIMD, cache optimization, move semantics |
-| Concurrency | `references/concurrency.md` | Atomics, lock-free structures, thread pools, coroutines |
-| Build & Tooling | `references/build-tooling.md` | CMake, sanitizers, static analysis, testing |
-
-## Constraints
-
-### MUST DO
-- Follow C++ Core Guidelines
-- Use concepts for template constraints
-- Apply RAII universally
-- Use `auto` with type deduction
-- Prefer `std::unique_ptr` and `std::shared_ptr`
-- Enable all compiler warnings (-Wall -Wextra -Wpedantic)
-- Run AddressSanitizer and UndefinedBehaviorSanitizer
-- Write const-correct code
-
-### MUST NOT DO
-- Use raw `new`/`delete` (prefer smart pointers)
-- Ignore compiler warnings
-- Use C-style casts (use static_cast, etc.)
-- Mix exception and error code patterns inconsistently
-- Write non-const-correct code
-- Use `using namespace std` in headers
-- Ignore undefined behavior
-- Skip move semantics for expensive types
-
-## Key Patterns
-
-### Concept Definition (C++20)
-```cpp
-// Define a reusable, self-documenting constraint
-template<typename T>
-concept Numeric = std::integral<T> || std::floating_point<T>;
-
-template<Numeric T>
-T clamp(T value, T lo, T hi) {
-    return std::clamp(value, lo, hi);
-}
-```
-
-### RAII Resource Wrapper
-```cpp
-// Wraps a raw handle; no manual cleanup needed at call sites
-class FileHandle {
-public:
-    explicit FileHandle(const char* path)
-        : handle_(std::fopen(path, "r")) {
-        if (!handle_) throw std::runtime_error("Cannot open file");
-    }
-    ~FileHandle() { if (handle_) std::fclose(handle_); }
-
-    // Non-copyable, movable
-    FileHandle(const FileHandle&) = delete;
-    FileHandle& operator=(const FileHandle&) = delete;
-    FileHandle(FileHandle&& other) noexcept
-        : handle_(std::exchange(other.handle_, nullptr)) {}
-
-    std::FILE* get() const noexcept { return handle_; }
-private:
-    std::FILE* handle_;
-};
-```
-
-### Smart Pointer Ownership
-```cpp
-// Prefer make_unique / make_shared; avoid raw new/delete
-auto buffer = std::make_unique<std::array<std::byte, 4096>>();
-
-// Shared ownership only when genuinely needed
-auto config = std::make_shared<Config>(parseArgs(argc, argv));
-```
-
-## Output Templates
-
-When implementing C++ features, provide:
-1. Header file with interfaces and templates
-2. Implementation file (when needed)
-3. CMakeLists.txt updates (if applicable)
-4. Test file demonstrating usage
-5. Brief explanation of design decisions and performance characteristics