@bradtaylorsf/alpha-loop 1.0.0

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

@@ -0,0 +1,58 @@
+---
+name: code-review
+description: Code review standards for automated and manual reviews. Use when reviewing code changes.
+auto_load: true
+priority: high
+---
+
+# Code Review Skill
+
+## Trigger
+When reviewing code changes (PR review, post-implementation review).
+
+## Review Checklist
+
+### 1. Requirements Compliance
+- [ ] All acceptance criteria met
+- [ ] No scope creep (unnecessary changes)
+- [ ] Edge cases handled
+
+### 2. Code Quality
+- [ ] Follows project conventions (check CLAUDE.md)
+- [ ] No `any` types in TypeScript
+- [ ] Functions are small and focused
+- [ ] No dead code or commented-out code
+- [ ] No `console.log` left in production code
+
+### 3. Security (OWASP Top 10)
+- [ ] No SQL injection (use parameterized queries)
+- [ ] No XSS (sanitize user input)
+- [ ] No command injection (validate shell args)
+- [ ] Auth/authz checks in place
+- [ ] No secrets in code
+
+### 4. Testing
+- [ ] New code has tests
+- [ ] Tests cover happy path AND error cases
+- [ ] Tests are deterministic (no flaky tests)
+- [ ] Test names describe behavior, not implementation
+
+### 5. Performance
+- [ ] No N+1 queries
+- [ ] No unnecessary re-renders
+- [ ] Large lists paginated
+
+## Action on Findings
+
+- **CRITICAL**: Fix immediately before merge
+- **WARNING**: Fix now if possible, create issue if not
+- **SUGGESTION**: Note for future improvement
+
+## Output Format
+
+```markdown
+### Review Summary
+**Status**: PASS | FAIL
+**Issues fixed**: N
+**Issues deferred**: N (with issue links)
+```

package/templates/skills/git-workflow/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: git-workflow
+description: Git branch naming, commit conventions, and PR workflow. Use for all git operations.
+auto_load: true
+priority: high
+---
+
+# Git Workflow Skill
+
+## Trigger
+When creating branches, writing commits, or creating PRs.
+
+## Branch Naming
+
+```
+agent/issue-{number}     # automated loop branches
+feat/{description}       # feature branches
+fix/{description}        # bug fix branches
+```
+
+## Commit Conventions
+
+Use conventional commits:
+
+```
+feat: add health check endpoint (closes #1)
+fix: resolve test failures for #3
+test: add unit tests for runner module
+refactor: simplify prompt building
+docs: update CLAUDE.md with new skills
+chore: update dependencies
+```
+
+Rules:
+- Lowercase, no period at end
+- Reference issue number when applicable
+- One logical change per commit
+- Commit message explains WHY, diff shows WHAT
+
+## PR Workflow
+
+1. Branch from the target branch (master or session branch)
+2. Implement + test + commit
+3. Push branch
+4. Create PR with: summary, test results, review report
+5. Link PR to issue with `closes #N`
+
+## Never Do
+
+- Force push to master/main
+- Commit directly to master/main
+- Commit .env files or secrets
+- Create merge commits (use squash merge)

package/templates/skills/implementation-planning/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: implementation-planning
+description: Two-layer feature planning (business + technical). Use when planning any feature before implementation starts.
+auto_load: true
+priority: high
+---
+
+# Implementation Planning Skill
+
+## Trigger
+When planning a feature before implementation starts.
+
+## Rules
+
+### Two-Layer Approach
+
+Every feature plan has two layers:
+
+**Layer A: Non-Technical Summary**
+- What are we building?
+- Who benefits?
+- What's the impact?
+
+**Layer B: Technical Detail**
+- What components/modules?
+- What database changes?
+- What API endpoints?
+- What will be tested?
+
+### Acceptance Criteria
+
+Make them specific and testable:
+
+Good:
+```
+- [ ] User can select a coach from a list
+- [ ] System prevents booking overlapping sessions
+- [ ] All tests pass
+```
+
+Bad:
+```
+- [ ] Booking system works
+- [ ] It's fast
+```
+
+### Feature Breakdown
+
+Break large features into smaller issues:
+- One feature per issue (small, scoped)
+- XS (< 4h), S (4-8h), M (8-16h), L (16-32h)
+- Identify dependencies between issues
+
+### Red Flags
+
+**Blocker:**
+- Acceptance criteria vague or untestable
+- Technical approach missing
+- Feature too large for one sprint
+
+**Warning:**
+- Dependencies not identified
+- No test plan
+- High-risk approach without discussion