sequant 1.0.0 → 1.1.1

package/templates/skills/solve/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: solve
-description: "Generate the proper execute-issues.ts command for one or more GitHub issues"
+description: "Generate the recommended workflow for one or more GitHub issues"
 license: MIT
 metadata:
   author: sequant
@@ -18,68 +18,33 @@ You are the "Solve Command Generator" for the current repository.
 When invoked as `/solve <issue-numbers>`, your job is to:
 
 1. Analyze the provided issue number(s)
-2. Check if they require UI testing (based on labels: admin, ui, frontend)
-3. Generate the optimal `npx tsx scripts/dev/execute-issues.ts` command
-4. Display the command in a copy-paste ready format
+2. Check labels to determine issue type
+3. Recommend the optimal workflow sequence
+4. Display the recommended commands
 
 ## Behavior
 
 ### Invocation Formats
 
 - `/solve 152` - Single issue
-- `/solve 152 153 154` - Multiple issues (parallel execution)
-- `/solve --batch "152 153" "154 155"` - Sequential batches
+- `/solve 152 153 154` - Multiple issues
 
 ### Detection Logic
 
-For each issue, check GitHub labels to determine if `/test` phase is needed:
+For each issue, check GitHub labels to determine the workflow:
 
 ```bash
 gh issue view <issue-number> --json labels --jq '.labels[].name'
 ```
 
-**UI Testing Required** if labels include:
-- `admin`
-- `ui`
-- `frontend`
+**UI/Frontend Issues** (labels: `ui`, `frontend`, `admin`):
+- Include `/test` phase for browser testing
 
-**Backend Issues** (no UI testing):
-- All other labels
+**Backend/API Issues** (labels: `backend`, `api`, `cli`):
+- Skip browser testing, focus on unit/integration tests
 
-### Command Generation
-
-**Single Issue:**
-```bash
-# UI issue (has admin/ui/frontend label)
-PHASES=spec,exec,test,qa npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152
-
-# Backend issue (no UI label)
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152
-```
-
-**Multiple Issues (Parallel):**
-```bash
-# All backend issues
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152 153 154
-
-# Mixed (some UI, some backend)
-PHASES=spec,exec,test,qa npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152 153 154
-
-# Note: PHASES env var applies to ALL issues
-# If ANY issue needs /test, add it for all
-```
-
-**Sequential Batches (Dependency-Aware):**
-```bash
-# Run issues sequentially (respects dependencies)
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts --sequential 152 153 154
-
-# Run batch 1, then batch 2
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts --batch "152 153" --batch "154 155"
-
-# With custom phases
-PHASES=spec,exec,test,qa npx tsx --env-file=.env.local scripts/dev/execute-issues.ts --batch "152 153" --batch "154 155"
-```
+**Bug Fixes** (labels: `bug`, `fix`):
+- May need simpler workflow, possibly skip `/spec`
 
 ## Output Format
 
@@ -89,154 +54,187 @@ Provide a clear, actionable response with:
    - Issue number
    - Title
    - Labels
-   - Needs /test? (Yes/No)
+   - Recommended workflow
+
+2. **Recommended Commands** in order
 
-2. **Recommended Command** in a code block for easy copying
+3. **CLI Command** - ALWAYS include `sequant run <issue>` for terminal/CI usage
 
-3. **Explanation** of why this command was chosen
+4. **Explanation** of why this workflow was chosen
 
 ### Example Output
 
 ```markdown
-## Solve Command for Issues: 152, 153, 154
+## Solve Workflow for Issues: 152, 153
 
 ### Issue Analysis
 
-| Issue | Title | Labels | Needs /test? |
-|-------|-------|--------|--------------|
-| #152 | Admin Review Queue: Bulk Edit v2 | admin, enhancement | Yes |
-| #153 | Automated content discovery | backend, enhancement | No |
-| #154 | City onboarding UI | admin, ui | Yes |
+| Issue | Title | Labels | Workflow |
+|-------|-------|--------|----------|
+| #152 | Add user dashboard | ui, enhancement | Full (with /test) |
+| #153 | Fix API validation | backend, bug | Standard |
 
-### Recommended Command
+### Recommended Workflow
 
-Since issues #152 and #154 require UI testing, we'll add the `/test` phase for all issues:
+**For #152 (UI feature):**
+```bash
+/spec 152      # Plan the implementation
+/exec 152      # Implement the feature
+/test 152      # Browser-based UI testing
+/qa            # Quality review
+```
 
-\`\`\`bash
-PHASES=spec,exec,test,qa npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152 153 154
-\`\`\`
+**For #153 (Backend fix):**
+```bash
+/spec 153      # Quick plan (bug fix)
+/exec 153      # Implement the fix
+/qa            # Quality review
+```
 
-### Explanation
+### Full Workflow Option
 
-- **Parallel execution**: All 3 issues run simultaneously
-- **Custom phases**: `spec,exec,test,qa` includes browser testing
-- **Logs**: Check `/tmp/claude-issue-{152,153,154}.log` for progress
+For comprehensive quality with automatic fix iterations:
+```bash
+/fullsolve 152
+```
 
-### Quality Loop Option
+### CLI Command
 
-For automatic fix iterations until quality gates pass:
+Run from terminal (useful for automation/CI):
+```bash
+sequant run 152        # Single issue
+sequant run 152 153    # Multiple issues
+```
 
-\`\`\`bash
-QUALITY_LOOP=true PHASES=spec,exec,test,qa npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152 153 154
-\`\`\`
+### Notes
+- Issue #152 requires UI testing due to `ui` label
+- Issue #153 is a bug fix - simpler workflow recommended
+- Run `/qa` after each issue before moving to next
+```
 
-This auto-includes `/testgen` for shift-left testing and runs `/loop` after test/QA failures (max 3 iterations per phase).
+## Workflow Selection Logic
 
-### Speed Option
+### Standard Workflow (Most Issues)
+```
+/spec → /exec → /qa
+```
 
-For faster batch execution without smart tests (disable auto-regression detection):
+### UI Feature Workflow
+```
+/spec → /exec → /test → /qa
+```
 
-\`\`\`bash
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts --no-smart-tests 152 153 154
-\`\`\`
+### Bug Fix Workflow (Simple)
+```
+/exec → /qa
+```
+Skip `/spec` if the bug is well-defined and straightforward.
 
-### Alternative: Sequential Batches
+### Complex Feature Workflow
+```
+/fullsolve <issue>
+```
+Runs complete workflow with automatic fix iterations.
 
-If you want backend issues to run first (faster, no UI testing overhead):
+## Quick Reference
 
-\`\`\`bash
-# Batch 1: Backend issue (faster)
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts --batch "153" --batch "152 154"
-\`\`\`
+| Issue Type | Labels | Workflow |
+|------------|--------|----------|
+| UI Feature | ui, frontend, admin | spec → exec → test → qa |
+| Backend Feature | backend, api | spec → exec → qa |
+| Bug Fix | bug, fix | exec → qa (or full if complex) |
+| Complex Feature | complex, refactor | fullsolve |
+| Documentation | docs | exec → qa |
 
-Or run all in parallel without /test:
+## CLI Alternative
 
-\`\`\`bash
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152 153 154
-\`\`\`
+Use `sequant run` for batch execution from the command line:
 
-**Note:** Skipping /test for admin/UI issues means you'll need to manually verify the UI works correctly.
-```
+```bash
+# Run workflow for single issue
+sequant run 152
 
-## Implementation Steps
+# Multiple issues in parallel
+sequant run 152 153 154
 
-1. **Parse input**: Extract issue numbers from command arguments
-2. **Fetch issue data**: Use `gh issue view <N> --json number,title,labels`
-3. **Analyze labels**: Check for admin/ui/frontend labels
-4. **Determine phases**:
-   - If ANY issue has UI label → use `PHASES=spec,exec,test,qa`
-   - If ALL issues are backend → use default phases (no PHASES env var)
-5. **Generate command**: Format based on number of issues and batch requirements
-6. **Display output**: Show issue table + recommended command + explanation
+# Sequential execution (respects dependencies)
+sequant run 152 153 --sequential
 
-## Edge Cases
+# Custom phases
+sequant run 152 --phases spec,exec,qa
 
-### All Backend Issues
-```bash
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 145 146 147
+# Dry run (shows what would execute)
+sequant run 152 --dry-run
 ```
-No `PHASES` env var needed - default is `spec,exec,qa`
 
-### All UI Issues
-```bash
-PHASES=spec,exec,test,qa npx tsx --env-file=.env.local scripts/dev/execute-issues.ts 152 154 156
+## Edge Cases
+
+### Multiple Issues with Different Types
+
+When solving multiple issues with mixed types, recommend running them separately:
+
+```markdown
+These issues have different requirements. Run separately:
+
+**UI Issues (with browser testing):**
+/fullsolve 152
+
+**Backend Issues:**
+/fullsolve 153
 ```
 
-### Mixed UI + Backend
-**Recommendation**: Use `PHASES=spec,exec,test,qa` for consistency, but warn user:
-> Note: Issue #153 is a backend issue and doesn't need `/test`, but we're including it for consistency. If you want to skip `/test` for #153, run it separately.
+### Issue with Dependencies
 
-### Sequential Batches Requested
-User types: `/solve --batch "152 153" "154"`
+If issues depend on each other:
 
-Generate:
-```bash
-npx tsx --env-file=.env.local scripts/dev/execute-issues.ts --batch "152 153" --batch "154"
+```markdown
+⚠️ Issue #154 depends on #153. Run in order:
+
+1. /fullsolve 153
+2. (Wait for PR merge)
+3. /fullsolve 154
 ```
 
-## Quality Loop Recommendation
+---
 
-Always offer `QUALITY_LOOP=true` as an option in your output. Recommend it especially when:
+## Output Verification
 
-1. **Complex UI issues** - Multiple test cases, likely to have edge case failures
-2. **Issues with many ACs** - More acceptance criteria = more chances for partial implementation
-3. **New feature implementations** - First-time implementations may need iteration
-4. **User requests "best quality"** - Explicit quality preference
+**Before responding, verify your output includes ALL of these:**
 
-**When NOT to recommend quality loop:**
-- Simple bug fixes with clear scope
-- Documentation-only changes
-- User explicitly wants quick execution
+- [ ] **Issue Summary Table** - Table with Issue, Title, Labels, Workflow columns
+- [ ] **Recommended Workflow** - Slash commands in order for each issue
+- [ ] **CLI Command** - `sequant run <issue-numbers>` command (REQUIRED)
+- [ ] **Explanation** - Brief notes explaining workflow choices
 
-## Smart Tests
+**DO NOT respond until all items are verified.**
 
-Smart tests are **enabled by default** in execute-issues.ts. When enabled:
+## Output Template
 
-- Auto-runs related tests after each file edit during implementation
-- Catches regressions immediately (5-10s overhead per edit)
-- Results logged to `/tmp/claude-tests.log`
+You MUST use this exact structure:
 
-**When to disable:**
-- Batch processing many issues (speed priority)
-- Issues with long-running test suites
-- Simple documentation changes
+```markdown
+## Solve Workflow for Issues: <ISSUE_NUMBERS>
 
-**View smart test results:**
-```bash
-npx tsx scripts/dev/analyze-hook-logs.ts --tests
-```
+### Issue Analysis
 
-## Quick Reference
+| Issue | Title | Labels | Workflow |
+|-------|-------|--------|----------|
+<!-- FILL: one row per issue -->
 
-**Script Features:**
-- Default phases: `spec,exec,qa`
-- Auto-detect UI issues: Adds `/test` if issue has admin/ui/frontend label
-- `PHASES` env var: Overrides auto-detection for ALL issues
-- `QUALITY_LOOP=true`: Auto-fix test/QA failures, **auto-includes `/testgen` after `/spec`**
-- `MAX_ITERATIONS`: Max fix attempts per phase (default: 3)
-- **Smart tests: Enabled by default** - auto-runs related tests after file edits
-- `--no-smart-tests`: Disable smart tests (faster but no auto-regression detection)
-- Parallel execution: Multiple issues run simultaneously
-- Batch mode: `--batch "N M"` runs batches sequentially
-- `--env-file=.env.local`: **Required** for database logging (workflow analytics)
-- Logs: `/tmp/claude-issue-<N>.log`, `/tmp/claude-tests.log` (smart test results)
+### Recommended Workflow
+
+**For #<N> (<type>):**
+\`\`\`bash
+<!-- FILL: slash commands in order -->
+\`\`\`
+
+### CLI Command
+
+Run from terminal (useful for automation/CI):
+\`\`\`bash
+sequant run <ISSUE_NUMBERS>
+\`\`\`
+
+### Notes
+<!-- FILL: explanation of workflow choices -->
+```

package/templates/skills/spec/SKILL.md

@@ -60,11 +60,10 @@ Task(subagent_type="schema-inspector", model="haiku",
 
 **Important:** Spawn all agents in a SINGLE message for parallel execution.
 
-### Using MCP Tools
+### Using MCP Tools (Optional)
 
 - **Sequential Thinking:** For complex analysis with multiple dependencies
 - **Context7:** For understanding existing patterns and architecture
-- **Supabase MCP:** For database changes, queries, or data modeling
 
 ## Context Gathering Strategy
 
@@ -83,7 +82,7 @@ Task(subagent_type="schema-inspector", model="haiku",
    - Prefer existing dependencies over new ones
 
 4. **For database-heavy features**
-   - Use Supabase MCP to verify table schemas
+   - Verify table schemas against TypeScript types
    - Check proposed types match database columns
 
 5. **For complex features (>5 AC items)**
@@ -167,3 +166,62 @@ Post the draft comment to GitHub:
 gh issue comment <issue-number> --body "..."
 gh issue edit <issue-number> --add-label "planned"
 ```
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **AC Checklist** - Numbered AC items (AC-1, AC-2, etc.) with descriptions
+- [ ] **Verification Criteria** - Each AC has Verification Method and Test Scenario
+- [ ] **Implementation Plan** - 3-7 concrete steps with codebase references
+- [ ] **Open Questions** - Any ambiguities with recommended defaults
+- [ ] **Issue Comment Draft** - Formatted for GitHub posting
+
+**DO NOT respond until all items are verified.**
+
+## Output Template
+
+You MUST include these sections in order:
+
+```markdown
+## Acceptance Criteria
+
+### AC-1: [Description]
+
+**Verification Method:** [Unit Test | Integration Test | Browser Test | Manual Test]
+
+**Test Scenario:**
+- Given: [Initial state]
+- When: [Action]
+- Then: [Expected outcome]
+
+### AC-2: [Description]
+<!-- Continue for all AC items -->
+
+---
+
+## Implementation Plan
+
+### Phase 1: [Phase Name]
+1. [Step with specific file/component references]
+2. [Step]
+
+### Phase 2: [Phase Name]
+<!-- Continue for all phases -->
+
+---
+
+## Open Questions
+
+1. **[Question]**
+   - Recommendation: [Default choice]
+   - Impact: [What happens if wrong]
+
+---
+
+--- DRAFT GITHUB ISSUE COMMENT (PLAN) ---
+
+[Complete formatted comment for GitHub]
+```

package/templates/skills/spec/references/parallel-groups.md

@@ -51,7 +51,7 @@ Include a `[model: haiku]` or `[model: sonnet]` annotation at the end of each ta
 - [ ] Refactor `lib/hooks/useMetrics.ts` to use new service [model: sonnet]
 
 ### Sequential (depends on Group 2)
-- [ ] Integrate into `app/shops/[slug]/page.tsx`
+- [ ] Integrate into main feature page
 - [ ] Add tests in `__tests__/metrics.test.ts`
 ```
 

package/templates/skills/spec/references/verification-criteria.md

@@ -14,7 +14,7 @@ Verification criteria force you to:
 | Method | Use When | Example |
 |--------|----------|---------|
 | **Unit Test** | Pure logic, utilities, helpers | `formatCurrency()`, `validateEmail()` |
-| **Integration Test** | External APIs, database, file system | Hook scripts, Supabase queries |
+| **Integration Test** | External APIs, database, file system | Hook scripts, database queries |
 | **Browser Test** | UI interactions, forms, modals | Admin dashboard, form validation |
 | **Manual Test** | One-time setup, visual verification | Deployment checks, design review |
 | **N/A - Trivial** | Config changes, simple renames | Env var addition, label change |

package/templates/skills/test/SKILL.md

@@ -91,10 +91,10 @@ find components -name "*<FeatureName>*" -type f
 
 Check for test data requirements:
 
-1. Look for seed script: `scripts/seed-test-*.ts`
+1. Look for seed script or test fixtures in the project
 2. If seed script exists, offer to run it:
    ```bash
-   npx tsx --env-file=.env.local scripts/seed-test-<feature>.ts
+   npx tsx scripts/seed-test-<feature>.ts
    ```
 3. If no seed script exists, check Issue for SQL statements or manual setup steps
 4. Execute setup or provide clear instructions to user
@@ -184,7 +184,7 @@ Use Chrome DevTools MCP for browser-based tests:
 
 ```javascript
 // Navigate to feature
-mcp__chrome-devtools__navigate_page({url: "http://localhost:3000/..."})
+mcp__chrome-devtools__navigate_page({url: "{{DEV_URL}}/..."})
 
 // Get page structure
 mcp__chrome-devtools__take_snapshot()
@@ -446,7 +446,8 @@ After testing completes, ask user if test data should be cleaned up:
 
 **Option 1: Delete test data**
 ```sql
-DELETE FROM pending_shops WHERE name LIKE 'Test Cafe%';
+-- Clean up test records created during testing
+DELETE FROM <table> WHERE name LIKE 'Test %';
 ```
 
 **Option 2: Keep for future testing**
@@ -473,7 +474,7 @@ Testing session is complete when:
 **Expected workflow:**
 1. Fetch Issue #151
 2. Detect 10 test cases in Issue body
-3. Check for seed script: `scripts/seed-test-bulk-edit.ts`
+3. Check for seed script or test fixtures
 4. Start dev server if needed
 5. Execute tests 1-10 using Chrome DevTools MCP
 6. Generate test summary with PASS/FAIL/BLOCKED status
@@ -506,3 +507,17 @@ Testing session is complete when:
 Both can be used together:
 1. `/test` → Verify feature works for users
 2. `/qa` → Verify code quality and completeness
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **Test Summary** - X/Y tests passed
+- [ ] **Test Results Table** - Each test marked PASS, FAIL, or BLOCKED
+- [ ] **Bugs Found** - List of bugs with file:line locations (if any)
+- [ ] **Coverage** - Completed, failed, blocked, remaining counts
+- [ ] **Recommendations** - Next steps for failures or follow-up
+
+**DO NOT respond until all items are verified.**

package/templates/skills/testgen/SKILL.md

@@ -17,7 +17,6 @@ allowed-tools:
   - Bash(git worktree list:*)
   - Bash(ls:*)
   - Bash(mkdir:*)
-  - mcp__supabase__*
 ---
 
 # Test Generation Command
@@ -559,3 +558,18 @@ For Issue #452 (hooks):
 ---
 Generated with [Claude Code](https://claude.com/claude-code)
 ```
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **AC Parsing** - Each AC identified with verification method
+- [ ] **Test Stubs Generated** - Files created for Unit/Integration tests
+- [ ] **Browser/Manual Scenarios** - Written for applicable AC items
+- [ ] **Failure Paths** - Error handling stubs for each AC
+- [ ] **Summary Table** - AC count, happy path count, failure path count
+- [ ] **GitHub Comment** - Summary posted to issue
+
+**DO NOT respond until all items are verified.**

package/templates/skills/verify/SKILL.md

@@ -42,7 +42,7 @@ Use `/verify` for:
 
 ```bash
 # With explicit command
-/verify 559 --command "npx tsx scripts/dev/execute-issues.ts 535 --phases spec"
+/verify 559 --command "npx tsx scripts/migrate.ts --dry-run"
 
 # With issue only (will prompt for command)
 /verify 559
@@ -200,14 +200,14 @@ To prevent oversized GitHub comments (64KB limit):
 ### Example 1: Successful Verification
 
 ```bash
-/verify 558 --command "npx tsx scripts/dev/execute-issues.ts 535 --phases spec --dry-run"
+/verify 558 --command "npx tsx scripts/migrate.ts --dry-run"
 ```
 
 Output:
 ```
-Starting execution for issues: 535
-Phase: spec
-Dry run mode: enabled
+Starting migration (dry run)...
+Checking tables...
+Migration plan: 3 tables, 5 columns
 ...
 Completed successfully
 ```
@@ -264,3 +264,18 @@ If verification fails due to infrastructure issues:
 4. **File not found:** Verify worktree is correct, check file paths
 
 Report infrastructure issues separately from feature issues.
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **Command Executed** - The exact command that was run
+- [ ] **Exit Code** - Success (0) or error code
+- [ ] **Duration** - How long the command took
+- [ ] **Output Sample** - Captured stdout/stderr (truncated if needed)
+- [ ] **Human Confirmation** - User's verification response recorded
+- [ ] **GitHub Comment** - Verification evidence posted to issue
+
+**DO NOT respond until all items are verified.**