cc-codeconductor 0.4.3 → 0.5.0

package/presets/cursor/skills/auth-token-inspector/SKILL.md

@@ -0,0 +1,33 @@
+---
+id: auth-token-inspector
+version: 1.0.0
+name: Auth Token Inspector
+description: >
+  Audits token storage mechanisms to prevent XSS-based JWT theft.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: security
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript, python, kotlin, java, php]
+paths:
+  - "**/*.{ts,tsx,py,kt,php}"
+---
+# Auth Token Inspector
+
+## Core Principles
+
+1. **Secure Storage**: JWTs or session tokens must NOT be stored in `localStorage` or `sessionStorage` due to vulnerability to Cross-Site Scripting (XSS).
+2. **HttpOnly Cookies**: Deliver tokens via `HttpOnly`, `Secure`, and `SameSite=Strict` (or `Lax`) cookies to protect them from client-side JS access.
+3. **Short Expiration**: Ensure access tokens have short expiration times, and implement secure, rotation-enabled refresh tokens stored in cookies.
+
+## Storage Comparison
+
+| Storage Mode | Vulnerable to XSS | Vulnerable to CSRF | Recommended |
+| :--- | :--- | :--- | :--- |
+| **localStorage** | Yes (High Risk) | No | **NO** |
+| **sessionStorage** | Yes (High Risk) | No | **NO** |
+| **HttpOnly Cookie** | No (Secure) | Yes (Mitigated via SameSite/Tokens) | **YES** |

package/presets/cursor/skills/code-review/SKILL.md

@@ -0,0 +1,208 @@
+---
+id: code-review
+version: 1.0.0
+name: Code Review
+description: >
+  Provides a structured framework for conducting thorough code reviews covering correctness, security, architecture alignment, performance, and technical debt.
+
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: review
+
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: []
+    frameworks: []
+
+risk:
+  level: low
+  can_execute_shell: false
+  can_modify_files: true
+  requires_network: false
+
+inputs: []
+
+outputs: []
+
+quality:
+  reviewed_by: codeconductor-core
+  version: 0.1.0
+---
+
+
+
+# Code Review
+
+## Review Axes
+
+Every finding must reference exactly one axis. This prevents vague feedback and
+makes it actionable.
+
+| Axis | What to check |
+|------|--------------|
+| **Correctness** | Does the logic handle all cases in the acceptance criteria? |
+| **Security** | Injection vectors, secret exposure, auth bypasses, insecure defaults |
+| **Architecture** | Does the code follow existing patterns and module boundaries? |
+| **Performance** | N+1 queries, unnecessary allocations, blocking I/O in hot paths |
+| **Error handling** | Are failure cases handled explicitly and safely? |
+| **Test coverage** | Do tests verify the acceptance criteria, not just happy paths? |
+| **Scope** | Are there changes outside the stated task boundary? |
+| **Technical debt** | Does the implementation introduce debt without acknowledging it? |
+
+## Finding Categories
+
+### CRITICAL — must be resolved before merge
+
+- Logic failures that violate acceptance criteria
+- Security vulnerabilities (injection, auth bypass, secret exposure)
+- Data loss or corruption risk
+- Breaking changes to public API or shared contracts
+- Missing error handling that causes silent failures
+
+### WARNING — should be resolved before merge
+
+- Missing edge case coverage in tests
+- Scope creep (changes outside the task boundary)
+- Pattern inconsistency that will confuse future maintainers
+- Performance issue that will degrade under load
+- Missing input validation at system boundaries
+
+### SUGGESTION — optional improvement
+
+- Naming clarity improvements
+- Extracting a reusable abstraction
+- Test readability
+- Documentation gaps on non-obvious behavior
+
+## Review Report Format
+
+```markdown
+## Review Report
+
+**Task**: [objective from task card]
+**Verdict**: [approved | approved with warnings | blocked]
+
+---
+
+### CRITICAL
+
+- [ ] [C1] `path/to/file:line` — [description]
+  Axis: [axis] | Evidence: `[quoted code]` | Required action: [what must change]
+
+_(none)_ if no critical findings
+
+### WARNING
+
+- [ ] [W1] `path/to/file:line` — [description]
+  Axis: [axis] | Recommended action: [what should change]
+
+_(none)_ if no warning findings
+
+### SUGGESTION
+
+- [ ] [S1] — [description] | Rationale: [brief reason]
+
+_(none)_ if no suggestions
+
+### Summary
+
+- Critical: [count] | Warning: [count] | Suggestion: [count]
+- **Verdict justification**: [one sentence]
+```
+
+**Verdict rules:**
+
+- `blocked` — any CRITICAL finding present
+- `approved with warnings` — no CRITICAL, at least one WARNING
+- `approved` — no CRITICAL, no WARNING
+
+## What to Check — by Axis
+
+### Correctness
+
+- Does every acceptance criterion have a corresponding code path?
+- Are null/empty/zero values handled explicitly?
+- Are boundary conditions checked (off-by-one, empty collections, max values)?
+- Do conditional branches cover all cases (exhaustive when/switch)?
+
+### Security
+
+```text
+Injection: SQL, command, LDAP, XML — is input sanitized or parameterized?
+Auth: is the endpoint protected? are role checks correct?
+Secrets: no hardcoded credentials, tokens, or keys in source
+Headers: are security headers set (CSP, HSTS, X-Frame-Options)?
+CORS: is the origin whitelist explicit, not wildcard?
+Dependencies: are new dependencies from trusted sources?
+```
+
+### Performance
+
+```text
+N+1 queries: does a loop call the database per iteration?
+Eager loading: are JOINs or includes used where needed?
+Pagination: are all list endpoints paginated?
+Caching: is expensive computation cached at an appropriate layer?
+Index: do new query filters have corresponding DB indexes?
+```
+
+### Error Handling
+
+```text
+Are exceptions caught at the right layer (not swallowed silently)?
+Is the error response format consistent with the rest of the API?
+Is the original exception logged before translating to a user-facing error?
+Are transient failures retried with backoff, or propagated immediately?
+```
+
+## What NOT to Flag
+
+**Personal style preferences.** If the code follows the project's established
+conventions, do not flag it because you would have written it differently.
+
+**Trivial naming.** Variable names are a SUGGESTION at most, never a WARNING.
+Do not block a PR over naming unless the name is genuinely misleading.
+
+**Tests for trivial code.** Do not demand tests for getters, setters, or data
+class construction. Test behavior, not boilerplate.
+
+**Refactors not in scope.** If you notice an improvement opportunity outside
+the task boundary, log it as a SUGGESTION. Do not block the PR for work that
+was not requested.
+
+**Framework defaults.** Do not second-guess framework conventions (Spring
+dependency injection, Next.js file-based routing). Trust the framework.
+
+## Exact Diff Recommendations
+
+When a finding requires a code change, provide the exact replacement:
+
+```text
+# Current code (path/to/file:42)
+val user = userRepository.findById(id)
+return user.name   // NPE if not found
+
+# Recommended fix
+val user = userRepository.findById(id)
+  ?: throw NotFoundException("User $id not found")
+return user.name
+```
+
+Vague instructions ("handle the null case") force the author to guess your
+intent. Exact diffs remove ambiguity and speed up the review cycle.
+
+## Prioritization Order
+
+When multiple findings exist, address them in this order:
+
+1. Security — security issues can silently compromise users or data
+2. Correctness — broken behavior defeats the purpose of the change
+3. Error handling — silent failures are hard to debug in production
+4. Test coverage — gaps mean regressions will be invisible
+5. Performance — degrade gradually; fix before it causes incidents
+6. Architecture — inconsistency compounds over time
+7. Technical debt — acknowledge and track; do not always block for it
+8. Suggestions — apply at author's discretion

package/presets/cursor/skills/conductor-setup/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: conductor-setup
+description: Configure a Rails project to work with Conductor (parallel coding agents)
+allowed-tools: Bash(chmod *), Bash(bundle *), Bash(npm *), Bash(script/server)
+context: fork
+risk: unknown
+source: community
+metadata:
+  author: Shpigford
+  version: "1.0"
+
+disable-model-invocation: true
+---
+
+Set up this Rails project for Conductor, the Mac app for parallel coding agents.
+
+## When to Use
+- You need to configure a Rails project so it runs correctly inside Conductor workspaces.
+- The project should support parallel coding agents with isolated ports, Redis settings, and shared secrets.
+- You want the standard `conductor.json`, `bin/conductor-setup`, and `script/server` scaffolding for a Rails repo.
+
+# What to Create
+
+## 1. conductor.json (project root)
+
+Create `conductor.json` in the project root if it doesn't already exist:
+
+```json
+{
+  "scripts": {
+    "setup": "bin/conductor-setup",
+    "run": "script/server"
+  }
+}
+```
+
+## 2. bin/conductor-setup (executable)
+
+Create `bin/conductor-setup` if it doesn't already exist:
+
+```bash
+#!/bin/bash
+set -e
+
+# Symlink .env from repo root (where secrets live, outside worktrees)
+[ -f "$CONDUCTOR_ROOT_PATH/.env" ] && ln -sf "$CONDUCTOR_ROOT_PATH/.env" .env
+
+# Symlink Rails master key
+[ -f "$CONDUCTOR_ROOT_PATH/config/master.key" ] && ln -sf "$CONDUCTOR_ROOT_PATH/config/master.key" config/master.key
+
+# Install dependencies
+bundle install
+npm install
+```
+
+Make it executable with `chmod +x bin/conductor-setup`.
+
+## 3. script/server (executable)
+
+Create the `script` directory if needed, then create `script/server` if it doesn't already exist:
+
+```bash
+#!/bin/bash
+
+# === Port Configuration ===
+export PORT=${CONDUCTOR_PORT:-3000}
+export VITE_RUBY_PORT=$((PORT + 1000))
+
+# === Redis Isolation ===
+if [ -n "$CONDUCTOR_WORKSPACE_NAME" ]; then
+  HASH=$(printf '%s' "$CONDUCTOR_WORKSPACE_NAME" | cksum | cut -d' ' -f1)
+  REDIS_DB=$((HASH % 16))
+  export REDIS_URL="redis://localhost:6379/${REDIS_DB}"
+fi
+
+exec bin/dev
+```
+
+Make it executable with `chmod +x script/server`.
+
+## 4. Update Rails Config Files
+
+For each of the following files, if they exist and contain Redis configuration, update them to use `ENV.fetch('REDIS_URL', ...)` or `ENV['REDIS_URL']` with a fallback:
+
+### config/initializers/sidekiq.rb
+If this file exists and configures Redis, update it to use:
+```ruby
+redis_url = ENV.fetch('REDIS_URL', 'redis://localhost:6379/0')
+```
+
+### config/cable.yml
+If this file exists, update the development adapter to use:
+```yaml
+development:
+  adapter: redis
+  url: <%= ENV.fetch('REDIS_URL', 'redis://localhost:6379/1') %>
+```
+
+### config/environments/development.rb
+If this file configures Redis for caching, update to use:
+```ruby
+config.cache_store = :redis_cache_store, { url: ENV.fetch('REDIS_URL', 'redis://localhost:6379/0') }
+```
+
+### config/initializers/rack_attack.rb
+If this file exists and configures a Redis cache store, update to use:
+```ruby
+Rack::Attack.cache.store = ActiveSupport::Cache::RedisCacheStore.new(url: ENV.fetch('REDIS_URL', 'redis://localhost:6379/0'))
+```
+
+# Implementation Notes
+
+- **Don't overwrite existing files**: Check if conductor.json, bin/conductor-setup, and script/server exist before creating them. If they exist, skip creation and inform the user.
+- **Rails config updates**: Only modify Redis-related configuration. If a file doesn't exist or doesn't use Redis, skip it gracefully.
+- **Create directories as needed**: Create `script/` directory if it doesn't exist.
+
+# Verification
+
+After creating the files:
+1. Confirm all Conductor files exist and scripts are executable
+2. Run `script/server` to verify it starts without errors
+3. Check that Rails configs properly reference `ENV['REDIS_URL']` or `ENV.fetch('REDIS_URL', ...)`
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.