claudepod 1.2.2 → 1.3.1

package/.devcontainer/plugins/devs-marketplace/plugins/ticket-workflow/.claude-plugin/commands/ticket:review-commit.md

@@ -0,0 +1,290 @@
+---
+description: Thorough code review, verify requirements met, commit with detailed message
+disable-model-invocation: true
+allowed-tools: Bash(gh:*), Bash(git:*), Read, Grep, Glob, AskUserQuestion
+---
+
+# /ticket:review-commit - Review and Commit Changes
+
+Thorough review, verify requirements, commit with detailed message.
+
+## Prerequisites
+
+Must have active ticket context from `/ticket:work`. If not set, prompt for ticket number.
+
+## Process
+
+### Phase 1: Gather Context
+
+```bash
+# Get changes
+git status
+git diff HEAD
+git diff --staged
+
+# Get ticket
+gh issue view $TICKET --json number,title,body
+
+# Discover project rules
+ls -la CLAUDE.md .claude/CLAUDE.md CLAUDE.local.md 2>/dev/null
+ls -la .claude/rules/*.md 2>/dev/null
+```
+
+### Phase 2: Conduct Full Review
+
+Review ALL changes with file:line references.
+
+#### Security Review
+
+| Check | Look For |
+|-------|----------|
+| Secrets | API keys, passwords, tokens, connection strings in code |
+| Injection | SQL injection, command injection, XSS, CSRF |
+| Auth/Authz | Missing auth checks, privilege escalation paths |
+| Data Exposure | PII in logs, sensitive data in error messages |
+| Dependencies | New dependencies with known vulnerabilities |
+| Input Validation | Unvalidated user input, missing sanitization |
+
+#### Project Rules Adherence
+
+Check compliance with project-specific rules:
+
+1. **Discover rules**:
+   - Read `CLAUDE.md` or `.claude/CLAUDE.md` if present
+   - Read all files in `.claude/rules/*.md`
+   - Check `CLAUDE.local.md` for user-specific rules
+
+2. **Review for compliance**:
+   - Check if changes violate any stated rules
+   - Note architectural patterns that should be followed
+   - Flag deviations from documented conventions
+
+| Rule Source | Compliance | Notes |
+|-------------|------------|-------|
+| CLAUDE.md | OK / VIOLATION | [specifics] |
+| rules/[name].md | OK / VIOLATION | [specifics] |
+
+**Common checks**:
+- Code organization matches documented patterns
+- Naming conventions followed
+- Required abstractions used
+- Forbidden patterns avoided
+
+#### Code Quality Review
+
+| Check | Look For |
+|-------|----------|
+| Complexity | Nesting depth > 3, high cyclomatic complexity |
+| Duplication | Copy-paste code, extractable shared logic |
+| Naming | Unclear names, inconsistent conventions |
+| Error Handling | Missing boundaries, generic catches, no recovery |
+| SOLID Violations | God classes, tight coupling, leaky abstractions |
+| Dead Code | Unreachable code, unused imports/variables |
+
+#### Architecture Review
+
+| Check | Look For |
+|-------|----------|
+| Pattern Compliance | Deviations from established patterns |
+| Coupling | Inappropriate dependencies, circular imports |
+| API Contracts | Breaking changes, missing versioning |
+| Cohesion | Mixed responsibilities, scattered logic |
+
+#### Test Review
+
+**Note**: If user opted out of tests during `/ticket:work`, skip this section entirely.
+
+Evaluate against testing standards (not coverage metrics):
+
+| Check | Assess |
+|-------|--------|
+| Behavior Coverage | Are key behaviors tested? (not line count) |
+| Test Quality | Do tests verify outcomes, not implementation? |
+| Brittleness | Any tests that will break on refactor? |
+| Over-testing | Trivial code with unnecessary tests? |
+| Under-testing | Critical paths without tests? |
+
+**AI testing pitfalls to flag**:
+- Tests for trivial getters/setters
+- Excessive edge cases (>5 per function)
+- Tests asserting on implementation details
+- Over-mocked tests that verify nothing
+
+#### Requirements Verification
+
+Cross-reference each EARS requirement from ticket:
+
+```markdown
+| Requirement | Status | Evidence |
+|-------------|--------|----------|
+| [REQ text] | SATISFIED / PARTIAL / NOT ADDRESSED | [file:line or explanation] |
+```
+
+### Phase 3: Present Findings
+
+Present ALL findings organized by category:
+
+```markdown
+## Review Findings
+
+### Security
+**Critical**
+- [Finding with file:line]
+
+**High**
+- [Finding with file:line]
+
+**Medium/Low**
+- [Finding with file:line]
+
+### Project Rules
+- [Rule violation with file:line and rule reference]
+
+### Code Quality
+- [Finding with file:line]
+
+### Architecture
+- [Finding with file:line]
+
+### Test Issues (if applicable)
+- [Finding description]
+
+### Requirements Status
+| Requirement | Status | Evidence |
+|-------------|--------|----------|
+| ... | ... | ... |
+```
+
+### Phase 4: User Decisions
+
+Use AskUserQuestion to batch decisions:
+
+```
+For each category of findings, select handling:
+- FIX: Address before commit
+- ISSUE: Create GitHub issue for later
+- IGNORE: Acknowledge and proceed
+```
+
+Allow multi-select within categories.
+
+### Phase 5: Create Issues (if selected)
+
+For findings marked ISSUE:
+
+1. Group by category
+2. Create single issue per category:
+
+```markdown
+## [Category] Findings from #[TICKET]
+
+**Source**: Branch `[branch]`, commit `[hash]`
+**Related Ticket**: #[TICKET]
+
+### Findings
+
+- [ ] [Finding 1] - `file:line`
+- [ ] [Finding 2] - `file:line`
+
+### Context
+
+[Brief context about what was being implemented]
+```
+
+```bash
+gh issue create --title "[Category] findings from #[TICKET]" --body "..."
+```
+
+Link issues in response.
+
+### Phase 6: Fix Selected Items
+
+Address all items marked FIX.
+
+### Phase 7: Draft Commit Message
+
+```markdown
+<type>(<scope>): <summary>
+
+<Business context>
+- [Requirement addressed]
+- [User-facing change]
+
+<Technical changes>
+- [File/component changed]
+- [Pattern used]
+
+<Review findings>
+- Addressed: [list]
+- Deferred to #[issue]: [list]
+- Acknowledged: [list]
+
+Closes #[TICKET] (if completing all requirements)
+Refs #[TICKET] (if partial)
+```
+
+Types: feat, fix, refactor, test, docs, chore
+
+### Phase 8: User Sign-Off
+
+Present commit message for approval. Allow edits.
+
+### Phase 9: Execute
+
+```bash
+git add [files]
+git commit -m "$(cat <<'EOF'
+[approved message]
+EOF
+)"
+git push
+```
+
+### Phase 10: Post to Issue
+
+Single batched comment:
+
+```markdown
+## Commit Summary
+
+**Commit**: [hash] on branch `[branch]`
+
+### Requirements Status
+| Requirement | Status |
+|-------------|--------|
+| ... | ... |
+
+### Review Findings Addressed
+- [Finding]: [Resolution]
+
+### Project Rules Compliance
+- [Rule source]: [Status]
+
+### Issues Created
+- #[N]: [Category] findings
+
+### Deferred (User Approved)
+- [Item]: Reason
+
+---
+*Reviewed and committed by Claude.*
+```
+
+## Rules
+
+- **NEVER defer** without EXPRESS user approval
+- **All findings** need file:line references
+- **User MUST approve** commit message
+- **Group issues** by category, link to original ticket
+- **Batch** all GitHub operations
+- Present findings FIRST, then get decisions
+- Fix selected items BEFORE drafting commit
+- **Check project rules** (CLAUDE.md, .claude/rules/*.md)
+- **Respect test preferences** from planning phase
+
+## Finding Severity Guide
+
+**Critical**: Security vulnerability, data loss risk, breaking production
+**High**: Significant bug, major pattern violation, auth issue
+**Medium**: Code smell, minor bug, missing validation
+**Low**: Style issue, minor optimization, documentation gap

package/.devcontainer/plugins/devs-marketplace/plugins/ticket-workflow/.claude-plugin/commands/ticket:work.md

@@ -0,0 +1,257 @@
+---
+description: Retrieve ticket, create technical implementation plan, post to GitHub issue
+argument-hint: [ticket-number]
+disable-model-invocation: true
+allowed-tools: Bash(gh:*), Bash(git:*), Read, Grep, Glob, AskUserQuestion
+---
+
+# /ticket:work - Implementation Planning
+
+Retrieve ticket, convert business requirements to technical plan, post to issue.
+
+## Input
+
+`$ARGUMENTS` - Ticket identifier (e.g., `#123`, `123`, or issue URL)
+
+## Process
+
+### Phase 1: Retrieve and Parse Ticket
+
+```bash
+gh issue view $1 --json number,title,body,labels,comments
+```
+
+Parse ticket structure:
+- Original Request (if present)
+- Overview
+- Requirements (by system/component)
+- Technical Questions
+- Acceptance Criteria
+
+Track ticket number in context for subsequent commands.
+
+### Phase 2: Launch Plan Subagent
+
+Use Plan subagent to:
+
+1. **Explore Codebase**
+   - Find related code/patterns
+   - Identify existing abstractions to use
+   - Map dependencies
+   - Discover project structure and conventions
+
+2. **Resolve Technical Questions**
+   - Explore codebase first
+   - Only ask user if ambiguity persists after exploration
+   - Document all decisions
+
+3. **Convert Requirements to Technical Spec**
+
+   For each EARS requirement, specify:
+   - Files to modify/create
+   - Components/classes affected
+   - Dependencies required
+   - Tests to write (if applicable - see Phase 3)
+
+4. **Build Implementation Plan**
+
+   Structure as phases:
+   ```markdown
+   ## Technical Plan
+
+   ### Prerequisites
+   - [ ] [Dependencies, setup, migrations needed]
+
+   ### Phase 1: [Descriptive Name]
+   **Requirements Addressed**: [REQ-1, REQ-2]
+
+   Files:
+   - `path/to/file.ext` - [What changes]
+
+   Implementation:
+   1. [Step with detail]
+   2. [Step with detail]
+
+   Tests: (if applicable)
+   - `test_file.ext::test_name` - [What it verifies]
+
+   ### Phase 2: [Descriptive Name]
+   ...
+
+   ### Verification Checklist
+   - [ ] [Acceptance criteria mapped to verification method]
+   ```
+
+### Phase 3: User Review and Test Preference
+
+1. Present full plan to user
+2. Get explicit approval before proceeding
+
+**Test Preference** - Before finalizing plan, confirm testing approach:
+
+Use AskUserQuestion to ask:
+- What test coverage does the user want? (full, minimal, none)
+- Are there existing test patterns to follow?
+- Any specific scenarios that MUST be tested?
+
+If user says "no tests" or "skip tests":
+- Respect this and exclude test tasks from plan
+- Note in plan: "Tests: Skipped per user preference"
+
+If user wants tests:
+- Follow testing_standards from system prompt
+- Propose specific scenarios, not vague coverage
+- Estimate count: "2-3 unit tests for validation, 1 integration test"
+
+3. Allow modifications to plan
+
+### Phase 4: Post to GitHub Issue
+
+Create single batched comment:
+
+```markdown
+## Implementation Plan
+
+[Technical plan from above]
+
+## Decisions Made
+
+| Decision | Rationale |
+|----------|-----------|
+| [Choice] | [Why] |
+
+## Resolved Questions
+
+- **Q**: [Original question from ticket]
+  **A**: [Resolution and rationale]
+
+## Test Approach
+
+[Full / Minimal / Skipped] - [Brief rationale]
+[If applicable: specific test scenarios planned]
+
+## Assumptions
+
+[NONE without express user approval - list any that were approved]
+
+---
+*Plan generated by Claude. Implementation tracked in subsequent commits.*
+```
+
+Post via:
+```bash
+gh issue comment $TICKET --body "$(cat <<'EOF'
+[plan content]
+EOF
+)"
+```
+
+## Rules
+
+- **Use Plan subagent** for all exploration and plan generation
+- **NEVER defer** without EXPRESS user approval
+- **NEVER mark out-of-scope** without EXPRESS user approval
+- **All decisions** → documented in issue comment
+- **All resolved questions** → documented in issue comment
+- **No assumptions** without user approval
+- **Track ticket** in context for `/ticket:review-commit` and `/ticket:create-pr`
+- **Respect test preferences** - if user says no tests, don't add them
+
+## Context Tracking
+
+After successful planning, maintain in context:
+- Current ticket number
+- Ticket title
+- Key requirements (for commit/PR reference)
+- Test preference (full/minimal/none)
+
+Support multiple tickets per session - each `/ticket:work` adds to tracked tickets.
+
+## Example Plan Comment
+
+```markdown
+## Implementation Plan
+
+### Prerequisites
+- [ ] None required
+
+### Phase 1: Data Layer - Status Field
+**Requirements Addressed**: API REQ-1, REQ-2
+
+Files:
+- `src/models/character.py` - Add `is_enabled` field with default True
+- `src/repositories/character_repo.py` - Update queries to handle enabled filter
+- `src/services/character_service.py` - Add toggle method, publish event
+
+Implementation:
+1. Add `is_enabled: bool = True` to Character model
+2. Generate migration for new column
+3. Update repository with optional enabled filter
+4. Add `toggle_enabled()` service method with event publishing
+
+Tests:
+- `tests/test_character_service.py::test_toggle_enabled_publishes_event`
+- `tests/test_character_service.py::test_toggle_updates_database`
+
+### Phase 2: Bot Integration - Proxy Check
+**Requirements Addressed**: Bot REQ-1, REQ-2
+
+Files:
+- `src/bot/proxy_handler.py` - Check enabled before proxying
+
+Implementation:
+1. Update `should_proxy()` to check `character.is_enabled`
+2. Return early if disabled (no proxy, no error)
+
+Tests:
+- `tests/test_proxy_handler.py::test_disabled_character_not_proxied`
+
+### Phase 3: Dashboard - Toggle UI
+**Requirements Addressed**: Dashboard REQ-1, REQ-2
+
+Files:
+- `src/components/CharacterCard.tsx` - Add toggle switch
+- `src/api/characters.ts` - Add toggle endpoint call
+
+Implementation:
+1. Add Switch component to character card header
+2. Implement optimistic update with error rollback
+
+Tests: Manual verification (UI component)
+
+### Verification Checklist
+- [ ] Migration runs successfully
+- [ ] Disabled character not proxied
+- [ ] Toggle persists after restart
+- [ ] Dashboard shows correct status
+- [ ] Event published on toggle
+
+## Decisions Made
+
+| Decision | Rationale |
+|----------|-----------|
+| Default `is_enabled=True` | Existing characters should continue working |
+| Keep in autocomplete | Disabled ≠ hidden, user may want to re-enable |
+| Optimistic UI update | Better UX, rollback handles errors |
+
+## Resolved Questions
+
+- **Q**: Should disabled characters appear differently in autocomplete?
+  **A**: Yes - show with "(disabled)" suffix, keep selectable for re-enabling.
+
+- **Q**: Default enabled status for new characters?
+  **A**: True - matches user expectation that created characters work immediately.
+
+## Test Approach
+
+Minimal - Unit tests for service logic, manual verification for UI.
+- 3 unit tests for toggle/proxy behavior
+- Manual test for dashboard toggle
+
+## Assumptions
+
+None - all decisions confirmed with user.
+
+---
+*Plan generated by Claude. Implementation tracked in subsequent commits.*
+```

package/.devcontainer/plugins/devs-marketplace/plugins/ticket-workflow/.claude-plugin/plugin.json

@@ -0,0 +1,8 @@
+{
+  "name": "ticket-workflow",
+  "description": "EARS-based ticket workflow: create issues, plan implementation, review commits, create PRs",
+  "author": {
+    "name": "AnExiledDev"
+  },
+  "keywords": ["tickets", "github", "workflow", "ears", "issues", "pr"]
+}