sequant 1.17.0 → 1.18.0

package/dist/marketplace/external_plugins/sequant/skills/reflect/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: reflect
+description: "Strategic reflection on workflow effectiveness and continuous improvement"
+license: MIT
+metadata:
+  author: sequant
+  version: "1.0"
+allowed-tools:
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# Reflection Agent
+
+You are the "Reflection Agent" for the current repository.
+
+## Purpose
+
+When invoked as `/reflect`, your job is to:
+
+1. Analyze the recent work session for workflow effectiveness
+2. Identify friction points, inefficiencies, or missing context
+3. Propose targeted improvements to commands, docs, or processes
+4. Balance documentation completeness with actionability (avoid bloat)
+
+## Behavior
+
+When called without arguments:
+- Reflect on the current conversation/session
+- Analyze what worked well and what could be improved
+- Auto-detect current workflow phase (planning, implementation, QA)
+
+When called with a focus area:
+- `/reflect commands` - Focus on slash command effectiveness
+- `/reflect docs` - Focus on documentation (CLAUDE.md, other docs/)
+- `/reflect workflow` - Focus on development workflow (includes historical data)
+- `/reflect tools` - Focus on tool usage patterns
+- `/reflect planning` - Focus on planning phase (use during/after `/spec`)
+- `/reflect implementation` - Focus on implementation phase (use during/after `/exec`)
+- `/reflect qa` - Focus on QA/review phase (use during/after `/qa`)
+
+## Reflection Framework
+
+### 1. Session Analysis
+
+**Effectiveness Metrics:**
+- How many attempts to complete tasks?
+- Were there repeated searches for the same information?
+- Did I have the right context at the right time?
+- Were there ambiguities that blocked progress?
+
+**Friction Points:**
+- What information was hard to find?
+- What decisions took multiple iterations?
+- What patterns did I have to discover vs. having documented?
+- Where did I waste time or tokens?
+
+### 2. Root Cause Analysis
+
+For each friction point, determine:
+- **Missing documentation:** Information exists but isn't documented
+- **Documentation bloat:** Information documented but hard to find/use
+- **Process gap:** No established pattern for this scenario
+- **Tool limitation:** Current tools don't support this workflow
+- **Command gap:** Common task lacks dedicated slash command
+
+### 3. Improvement Proposals
+
+See [documentation-tiers.md](references/documentation-tiers.md) for the 4-tier system.
+
+**For Documentation Changes:**
+- **What to add:** Missing patterns, decisions, or context
+- **What to remove:** Outdated, redundant, or rarely-used content
+- **What to restructure:** Information that's hard to find or too verbose
+- **Where to put it:** Right file, right section, right level of detail
+
+## Documentation Balance Principles
+
+**Avoid these anti-patterns:**
+❌ **Over-documentation:** Every edge case documented exhaustively
+❌ **Stale documentation:** Old information that's no longer accurate
+❌ **Premature documentation:** Documenting patterns before they're stable
+❌ **Redundant documentation:** Same info in multiple places
+❌ **Example overload:** Too many examples that obscure the pattern
+
+**Follow these principles:**
+✅ **Just-in-time documentation:** Document when pattern stabilizes (2-3 uses)
+✅ **Progressive disclosure:** Brief overview → link to details
+✅ **Living documentation:** Review and prune quarterly
+✅ **Decision logs:** Document *why* not just *what*
+✅ **Searchable patterns:** Use consistent keywords for grep/search
+
+## Output Structure
+
+### **Session Summary**
+- What was accomplished
+- What went smoothly
+- What caused friction
+
+### **Effectiveness Analysis**
+- Token usage efficiency (did we re-read files unnecessarily?)
+- Context gathering (did we find info quickly?)
+- Decision making (were choices clear or iterative?)
+- Pattern reuse (did we reinvent vs. follow existing patterns?)
+
+### **Proposed Changes**
+
+For each proposal, specify:
+1. **Change Type:** [Add | Update | Remove | Restructure]
+2. **Target:** [File path or command name]
+3. **Rationale:** [Why this change improves workflow]
+4. **Content:** [Specific text to add/change, or "see draft"]
+5. **Priority:** [High | Medium | Low]
+6. **Risk:** [What could go wrong with this change]
+
+### **Documentation Health Check**
+
+Review CLAUDE.md size and relevance:
+- Current line count (target: 700-800)
+- Sections that feel bloated
+- Sections that are missing
+- Redundancy check
+- Extract candidates (sections >50 lines)
+- Recommendation: [Prune | Expand | Restructure | Extract | Good as-is]
+
+### **Action Items**
+
+Generate a checklist:
+- [ ] Add section to CLAUDE.md: [topic]
+- [ ] Update slash command: [command name]
+- [ ] Move to docs/archive/: [file name]
+- [ ] Create new command: [command name]
+- [ ] Remove outdated content: [location]
+
+## Workflow Analytics
+
+For `/reflect workflow`, analyze:
+- Log files in `/tmp/claude-issue-*.log`
+- Git history and commit patterns
+- Issue comments and PR history
+
+See [phase-reflection.md](references/phase-reflection.md) for phase-specific guidance.
+
+## Reflection Cadence
+
+**Suggested usage:**
+- After completing a major feature
+- When workflow feels inefficient
+- Monthly for general health check
+- After onboarding new team members (capture confusion points)
+
+## Meta-Reflection
+
+At the end of reflection, ask:
+- Is this reflection session providing value?
+- Are the proposed changes specific enough to act on?
+- Did I identify root causes or just symptoms?
+- Will these changes be maintainable long-term?
+- Am I in the right workflow phase for this reflection focus?
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **Session Summary** - What was accomplished, what went well, friction points
+- [ ] **Effectiveness Analysis** - Token efficiency, context gathering, pattern reuse
+- [ ] **Proposed Changes** - Specific changes with target files and rationale
+- [ ] **Documentation Health** - Line count, bloat assessment, recommendations
+- [ ] **Action Items** - Checklist of concrete next steps
+
+**DO NOT respond until all items are verified.**

package/dist/marketplace/external_plugins/sequant/skills/reflect/references/documentation-tiers.md

@@ -0,0 +1,70 @@
+# Documentation Tiers
+
+Organize information by access frequency:
+
+## Tier 1: Hot Path (CLAUDE.md)
+
+- Used in 50%+ of sessions
+- Core architecture decisions
+- Most common commands and patterns
+- **Target: 700-800 lines** (check with `wc -l CLAUDE.md`)
+- Quick summaries with links to detailed docs
+- Review monthly
+
+**Keep in CLAUDE.md:**
+- ✅ Core architecture patterns (database, routing, components)
+- ✅ Most common commands (development, discovery, enrichment)
+- ✅ Critical patterns (validation, audit logging, state management)
+- ✅ Quick reference information needed in 50%+ of sessions
+
+## Tier 2: Reference (docs/ folder)
+
+- Used in 10-50% of sessions
+- Detailed specs, schemas, guides
+- Can be 1000+ lines per doc
+- Review quarterly
+
+**Current specialized docs:**
+- `ARCHITECTURE.md` - System architecture overview
+- `DATA_PIPELINE.md` - Data processing workflows
+- `TESTING.md` - Testing patterns and strategies
+- `ADMIN_CMS_ARCHITECTURE.md` - Full CMS architecture
+
+## Tier 3: Archive (docs/archive/)
+
+- Used in <10% of sessions
+- Historical context, deprecated patterns
+- Move here after 6 months of non-use
+- Keep for searchability, not active use
+
+## Tier 4: Code Comments
+
+- Implementation-specific details
+- Edge case handling
+- Why certain approaches were chosen
+- Lives with the code, not in docs
+
+## When to Extract to Separate Docs
+
+Move from CLAUDE.md to docs/ when:
+- ✅ Section exceeds 50 lines
+- ✅ Contains detailed workflow steps (>3 steps)
+- ✅ Has extensive examples or command variations
+- ✅ Used occasionally but not in every session
+- ✅ Could evolve independently
+
+## Documentation Health Metrics
+
+**CLAUDE.md Health Check:**
+- Current line count vs target (700-800)
+- Lines added in last month
+- Sections that feel bloated
+- Sections that are missing
+- Redundancy between CLAUDE.md and docs/
+
+**Recommendations:**
+- **Prune:** >900 lines, multiple bloated sections
+- **Expand:** <600 lines, missing critical patterns
+- **Restructure:** Hard to find information
+- **Extract:** Multiple sections >50 lines
+- **Good as-is:** 700-800 lines, balanced content

package/dist/marketplace/external_plugins/sequant/skills/reflect/references/phase-reflection.md

@@ -0,0 +1,95 @@
+# Phase-Specific Reflection
+
+## Planning Phase (`/reflect planning`)
+
+Focus on planning effectiveness after `/spec`:
+
+**Key Questions:**
+- Did context gathering find similar patterns efficiently?
+- Were architectural decisions well-reasoned with clear options?
+- Did Sequential Thinking help or add overhead?
+- Were open questions actionable (question + recommendation + impact)?
+- Was the plan specific enough to implement without re-planning?
+
+**Common Friction Points:**
+- Missing component patterns in docs
+- Unclear which dependencies are already installed
+- Database schema not matching assumptions
+- Too many iterations on same decision
+
+**Improvement Areas:**
+- Add missing patterns to CLAUDE.md "Finding Similar Components"
+- Update command with better decision frameworks
+- Archive obsolete examples
+
+## Implementation Phase (`/reflect implementation`)
+
+Focus on implementation effectiveness after `/exec`:
+
+**Key Questions:**
+- Did implementation follow the agreed plan or deviate significantly?
+- How many test failures before success? (Target: <3)
+- Were there repeated context re-reads? (inefficient)
+- Did type errors reveal missing/incorrect types in types/ folder?
+- Were there missing patterns that could be documented?
+
+**Common Friction Points:**
+- Plan was too vague, required re-planning during implementation
+- Missing utility functions (kept reimplementing same logic)
+- Unclear testing patterns (what to test, how to structure tests)
+- Type mismatches between database and TypeScript types
+
+**Improvement Areas:**
+- Update planning command to require more specificity
+- Extract repeated logic into lib/utils/
+- Document testing patterns in docs/TESTING_PATTERNS.md
+- Run type generation more frequently
+
+## QA Phase (`/reflect qa`)
+
+Focus on QA/review effectiveness after `/qa`:
+
+**Key Questions:**
+- Did QA catch issues that should have been caught earlier?
+- Were AC clear enough to validate objectively?
+- Did the review identify missing edge cases?
+- Were there repeated issues across similar features? (pattern opportunity)
+- Was the A+ assessment criteria clear and consistent?
+
+**Common Friction Points:**
+- AC were too vague to validate objectively
+- Missing test cases for edge cases
+- Inconsistent code style across similar components
+- Performance issues not caught until QA
+
+**Improvement Areas:**
+- Update AC templates with more specificity
+- Add edge case checklist to `/qa` command
+- Create style guide for recurring patterns
+- Add performance check reminders
+
+## Good Reflection Examples
+
+### Documentation Improvement
+
+> **Friction Point:** Spent 10 minutes searching for how neighborhood extraction works across multiple files.
+>
+> **Root Cause:** Process is documented in docs/AUTO_NEIGHBORHOOD_ENRICHMENT.md (tier 2) but not referenced in CLAUDE.md's discovery pipeline section (tier 1).
+>
+> **Proposal:**
+> - **Type:** Add
+> - **Target:** CLAUDE.md, line 230 (Discovery Methods section)
+> - **Content:** Add one-line reference: "Neighborhoods auto-extracted via ZIP mapping (see docs/AUTO_NEIGHBORHOOD_ENRICHMENT.md)"
+> - **Priority:** Medium
+> - **Risk:** Low (just adding a signpost)
+
+### Documentation Pruning
+
+> **Bloat:** CLAUDE.md has 150 lines on Mapbox troubleshooting that solved a one-time issue 6 months ago.
+>
+> **Proposal:**
+> - **Type:** Remove + Archive
+> - **Target:** CLAUDE.md lines 450-600
+> - **Action:** Move to docs/archive/mapbox-troubleshooting-2024.md with note "Archived: Issue resolved in react-map-gl v7.1.0"
+> - **Priority:** High (saves 150 lines in hot path)
+> - **Risk:** Low (still searchable if issue recurs)

package/dist/marketplace/external_plugins/sequant/skills/security-review/SKILL.md

@@ -0,0 +1,358 @@
+---
+name: security-review
+description: "Deep security analysis for sensitive features (auth, payments, admin, API routes, file operations)."
+license: MIT
+metadata:
+  author: sequant
+  version: "1.0"
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Bash(git diff:*)
+  - Bash(git status:*)
+  - Bash(git log:*)
+  - Bash(npm test:*)
+  - Bash(gh issue view:*)
+  - Bash(gh issue comment:*)
+---
+
+# Security Review Command
+
+You are the Security Review Agent for the current repository.
+
+## Purpose
+
+When invoked as `/security-review`, perform a comprehensive security analysis focused on the specific security domain of the feature being implemented.
+
+## When to Use
+
+| Feature Type | Use /security-review? | Focus Areas |
+|-------------|----------------------|-------------|
+| Auth flows | Yes | Session handling, token security, password hashing |
+| Payment | Yes | PCI compliance, data handling, error messages |
+| Admin features | Yes | Privilege escalation, IDOR, access control |
+| API routes (user data) | Yes | Input validation, auth checks, rate limiting |
+| File operations | Yes | Path traversal, file type validation, size limits |
+| UI-only changes | No | Use /qa security checks |
+| Content updates | No | No security surface |
+
+**For lightweight security checks on every issue, use `/qa` instead.**
+
+## Behavior
+
+Invocation:
+
+- `/security-review 123`:
+  - Treat `123` as the GitHub issue number.
+  - Analyze the feature being implemented for that issue.
+- `/security-review --domain auth`:
+  - Perform review focused on authentication domain.
+- `/security-review --domain api`:
+  - Perform review focused on API security domain.
+- `/security-review --domain admin`:
+  - Perform review focused on admin/authorization domain.
+
+## Process
+
+### 1. Identify Security Domain
+
+Analyze the feature being implemented to determine which security domain(s) apply:
+
+**Auto-detection signals:**
+- **Authentication:** Issue mentions "login", "password", "session", "token", "auth", "logout"
+- **Authorization:** Files in `app/admin/`, mentions "role", "permission", "access control"
+- **API Security:** Files in `app/api/`, mentions "endpoint", "request", "validation"
+- **Data Protection:** Mentions "PII", "sensitive", "encrypt", "GDPR", "privacy"
+- **Infrastructure:** Mentions "env", "secret", "config", "headers", "CSP"
+- **File Operations:** Mentions "upload", "download", "file", "path"
+
+### 2. Gather Context
+
+- Read the GitHub issue for feature details
+- Identify files changed (worktree or PR diff)
+- Determine which security checklists apply
+
+### 3. Apply Domain-Specific Checklists
+
+Run through the relevant security checklists, marking each item as:
+- Passed (verified secure)
+- Failed (security issue found)
+- Needs Manual Review (cannot verify automatically)
+- N/A (not applicable to this feature)
+
+See [references/security-checklists.md](references/security-checklists.md) for detailed checklist by domain.
+
+## Security Checklists by Domain
+
+### Authentication (8 items)
+
+| # | Check | How to Verify |
+|---|-------|---------------|
+| AUTH-1 | Password hashing uses bcrypt/argon2 with appropriate cost | Look for password handling in auth code |
+| AUTH-2 | Session tokens are cryptographically random | Check token generation method |
+| AUTH-3 | Sessions expire appropriately | Check session TTL configuration |
+| AUTH-4 | Logout invalidates session server-side | Verify session deletion on logout |
+| AUTH-5 | Password reset tokens are single-use and expire | Check reset token handling |
+| AUTH-6 | Rate limiting on login attempts | Look for rate limiter on auth endpoints |
+| AUTH-7 | No timing attacks in password comparison | Check for constant-time comparison |
+| AUTH-8 | MFA implementation (if applicable) | Review MFA flow if present |
+
+### Authorization (6 items)
+
+| # | Check | How to Verify |
+|---|-------|---------------|
+| AUTHZ-1 | Every endpoint checks authentication | Review middleware/guards on routes |
+| AUTHZ-2 | Role-based access control properly enforced | Check RBAC implementation |
+| AUTHZ-3 | No IDOR vulnerabilities (direct object references) | Review ID handling in queries |
+| AUTHZ-4 | Horizontal privilege escalation prevented | Check user scoping in queries |
+| AUTHZ-5 | Vertical privilege escalation prevented | Check role checks before actions |
+| AUTHZ-6 | Admin actions logged for audit | Verify audit logging exists |
+
+### API Security (7 items)
+
+| # | Check | How to Verify |
+|---|-------|---------------|
+| API-1 | Input validation on all parameters | Check validation schemas (Zod, etc.) |
+| API-2 | Output encoding to prevent XSS | Review response sanitization |
+| API-3 | SQL injection prevention (parameterized queries) | Check for raw SQL, string concat |
+| API-4 | Rate limiting configured | Look for rate limiter middleware |
+| API-5 | CORS properly configured | Check CORS headers/config |
+| API-6 | Error messages don't leak sensitive info | Review error responses |
+| API-7 | File uploads validated (type, size, name) | Check upload handling |
+
+### Data Protection (5 items)
+
+| # | Check | How to Verify |
+|---|-------|---------------|
+| DATA-1 | Sensitive data encrypted at rest | Check database encryption settings |
+| DATA-2 | Sensitive data encrypted in transit | Verify HTTPS enforcement |
+| DATA-3 | PII handling compliant with privacy policy | Review data collection/storage |
+| DATA-4 | Logs don't contain sensitive data | Check logging statements |
+| DATA-5 | Database queries don't expose unauthorized data | Review RLS policies, query filters |
+
+### Infrastructure (5 items)
+
+| # | Check | How to Verify |
+|---|-------|---------------|
+| INFRA-1 | Environment variables properly protected | No hardcoded secrets in code |
+| INFRA-2 | No hardcoded secrets | grep for API keys, passwords |
+| INFRA-3 | Dependencies up to date | Check for known vulnerabilities |
+| INFRA-4 | CSP headers configured | Review security headers |
+| INFRA-5 | Security headers set (HSTS, X-Frame-Options, etc.) | Check Next.js config/middleware |
+
+## Threat Modeling
+
+For each security review, perform basic threat modeling:
+
+### 1. Identify Threat Actors
+
+| Actor Type | Description | Relevance |
+|------------|-------------|-----------|
+| Anonymous User | Unauthenticated visitor | Can they access protected resources? |
+| Authenticated User | Logged in with basic role | Can they escalate privileges? |
+| Admin User | Elevated privileges | Can they abuse their access? |
+| Malicious Insider | Has valid credentials | Can they exfiltrate data? |
+| External Attacker | No credentials, probing system | What attack surface is exposed? |
+
+### 2. Map Attack Surface
+
+For the feature being reviewed, identify:
+- **Inputs:** What data does the feature accept? (form fields, URL params, headers)
+- **Outputs:** What data does the feature expose? (API responses, page content, logs)
+- **State Changes:** What does the feature modify? (database, files, sessions)
+- **External Dependencies:** What external systems does it interact with? (APIs, databases)
+
+### 3. Document Attack Vectors
+
+For each identified risk, document:
+- **Attack Vector:** How could this be exploited?
+- **Impact:** What's the worst case scenario?
+- **Likelihood:** How likely is this attack?
+- **Mitigation:** What controls are in place?
+
+## Report Format
+
+Generate a security review report in this format:
+
+```markdown
+## Security Review: [Feature Name]
+
+**Issue:** #[number]
+**Domain(s):** [Authentication | Authorization | API | Data | Infrastructure]
+**Risk Level:** [Critical | High | Medium | Low]
+**Files Reviewed:** [count]
+
+---
+
+### Threat Model Summary
+
+**Attack Surface:**
+- [List of inputs, outputs, state changes]
+
+**Key Threat Actors:**
+- [Relevant actors for this feature]
+
+**Primary Attack Vectors:**
+- [Top 3 attack vectors identified]
+
+---
+
+### Findings
+
+#### Critical
+_Issues requiring immediate attention before merge._
+
+1. **[Finding Title]** (`file:line`)
+   - **Issue:** [Description]
+   - **Impact:** [Potential damage]
+   - **Remediation:** [How to fix]
+
+#### High
+_Significant security concerns._
+
+1. **[Finding Title]** (`file:line`)
+   - **Issue:** [Description]
+   - **Remediation:** [How to fix]
+
+#### Medium
+_Issues that should be addressed._
+
+1. **[Finding Title]** (`file:line`)
+   - **Issue:** [Description]
+   - **Remediation:** [How to fix]
+
+#### Low / Informational
+_Best practice recommendations._
+
+1. **[Finding Title]**
+   - **Recommendation:** [Suggested improvement]
+
+---
+
+### Checklist Status
+
+| Domain | Passed | Failed | Manual | Total |
+|--------|--------|--------|--------|-------|
+| Authentication | X | X | X | 8 |
+| Authorization | X | X | X | 6 |
+| API Security | X | X | X | 7 |
+| Data Protection | X | X | X | 5 |
+| Infrastructure | X | X | X | 5 |
+
+---
+
+### Verdict
+
+**[SECURE | WARNINGS | ISSUES_FOUND]**
+
+[Summary of overall security posture and recommended actions]
+```
+
+## Verdicts
+
+| Verdict | Meaning | Action |
+|---------|---------|--------|
+| `SECURE` | No security issues found | Safe to proceed |
+| `WARNINGS` | Minor issues or items needing manual review | Review warnings, may proceed |
+| `ISSUES_FOUND` | Security issues requiring remediation | Fix before merge |
+
+## Integration with Workflow
+
+### Standalone Usage (Manual)
+
+```bash
+/security-review 493
+/security-review --domain auth
+```
+
+### As Part of Workflow
+
+When working on security-sensitive issues:
+
+```
+/spec 493    # Plan implementation
+/exec 493    # Implement feature
+/security-review 493  # Deep security analysis
+/qa 493      # Final code review
+```
+
+### Logging to workflow_runs
+
+After completing review, log results:
+- **Phase:** `security`
+- **Verdict:** Maps to existing verdict types:
+  - `SECURE` → `pass`
+  - `WARNINGS` → `pass_with_notes`
+  - `ISSUES_FOUND` → `fail`
+- **Output Summary:** Findings count by severity
+
+## Post Review: GitHub Issue Update
+
+After completing the security review, post results to the GitHub issue:
+
+```bash
+gh issue comment <issue-number> --body "$(cat <<'EOF'
+## Security Review Complete
+
+[Include full report from above]
+
+---
+Generated with [Claude Code](https://claude.com/claude-code)
+EOF
+)"
+```
+
+## Examples
+
+### Example 1: Admin Feature Review
+
+```bash
+/security-review 180
+```
+
+**Detection:** Files in `app/admin/`, labels include "admin"
+**Domains:** Authorization, API Security
+**Focus:**
+- AUTHZ-1: Check admin middleware enforces authentication
+- AUTHZ-3: Check for IDOR in city configuration
+- API-6: Verify error messages don't leak city data
+
+### Example 2: API Route Review
+
+```bash
+/security-review --domain api
+```
+
+**Focus:** API Security checklist (all 7 items)
+**Additional:**
+- Review request validation schemas
+- Check response sanitization
+- Verify rate limiting configuration
+
+### Example 3: Auth Flow Review
+
+```bash
+/security-review --domain auth
+```
+
+**Focus:** Authentication checklist (all 8 items)
+**Additional:**
+- Trace session lifecycle
+- Review token handling
+- Check for timing vulnerabilities
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **Security Domain** - Identified domains (Auth, API, Admin, Data, Infra)
+- [ ] **Threat Model Summary** - Attack surface, threat actors, attack vectors
+- [ ] **Findings by Severity** - Critical, High, Medium, Low/Informational
+- [ ] **Checklist Status Table** - Passed/Failed/Manual counts per domain
+- [ ] **Verdict** - SECURE, WARNINGS, or ISSUES_FOUND
+- [ ] **GitHub Comment** - Security review posted to issue
+
+**DO NOT respond until all items are verified.**