feat(AI-012): port Claude skills to OpenCode commands

.github/workflows/ci.yml

@@ -29,6 +29,10 @@ jobs:
         run: |
           shellcheck --severity=error setup-linux.sh
 
+      - name: Verify opencode commands in sync with Claude skills (AI-012)
+        run: |
+          ./scripts/skills-to-opencode.sh --check
+
   lint-powershell:
     runs-on: ubuntu-latest
     steps:

ai/opencode/commands/audit.md

@@ -0,0 +1,41 @@
+---
+description: Use when reviewing code for security vulnerabilities (SQL injection, XSS, hardcoded secrets, CSRF), performance issues (N+1 queries, memory leaks, blocking async), or code quality concerns (complexity, error handling, type safety).
+---
+
+# Security Audit
+
+Analyze code for vulnerabilities, performance issues, and bad practices.
+
+## Checklist
+
+| Category | Issues to Find |
+|----------|----------------|
+| Injection | SQL concatenation, XSS, command injection, path traversal |
+| Secrets | Hardcoded credentials, API keys in code, .env committed |
+| Auth | Missing validation, broken access control, CSRF |
+| Performance | N+1 queries, unbounded loops, blocking in async |
+| Resilience | Unhandled errors, missing timeouts, race conditions |
+| Quality | Magic numbers, deep nesting, missing types, dead code |
+
+## Output Format
+
+```markdown
+## Issues
+
+### HIGH
+- [file:line] Issue description
+- [file:line] Issue description
+
+### MEDIUM
+- [file:line] Issue description
+
+### LOW
+- [file:line] Issue description
+
+## Fixes
+
+### [Issue name]
+[Fixed code - no explanation]
+```
+
+Provide fixes for top 3 HIGH/MEDIUM issues. Code only, no explanations.

ai/opencode/commands/debug-hardware.md

@@ -0,0 +1,39 @@
+---
+description: Use when troubleshooting hardware or firmware issues -- device communication, register configuration, signal processing, camera/sensor behavior, or embedded systems.
+---
+
+# Hardware Debugging
+
+Systematic approach for hardware/firmware issues. Evidence before hypotheses.
+
+## The Iron Rule
+
+```
+NO GUESSING. NO CYCLING THROUGH HYPOTHESES WITHOUT EVIDENCE.
+```
+
+## Process
+
+1. **Read reference code** — Find ALL related source files and working implementations (GUI code, vendor examples, known-good configurations)
+2. **Read documentation** — Check firmware/hardware datasheets, register maps, timing diagrams, protocol specs
+3. **Gather observations** — Ask user to describe observed vs expected behavior. Get concrete data: register values, signal traces, error codes
+4. **Form single hypothesis** — Only AFTER steps 1-3. State clearly: "I think X because evidence Y shows Z"
+5. **Propose minimal fix** — Smallest possible change to test the hypothesis. One variable at a time
+6. **Verify** — Run tests after every change
+
+## When Fix Fails
+
+- Do NOT guess another cause
+- Ask user for more observations
+- Re-read documentation with new context
+- Repeat from step 3
+
+## Common Pitfalls
+
+| Pitfall | Correct Approach |
+|---------|-----------------|
+| Assuming register defaults | Read datasheet for actual reset values |
+| Changing multiple registers at once | One register change per test |
+| Ignoring timing requirements | Check setup/hold times, clock domains |
+| Guessing endianness | Verify byte order from documentation |
+| Skipping reference implementation | Always compare against known-working code |

ai/opencode/commands/docker.md

@@ -0,0 +1,76 @@
+---
+description: Use when containerizing applications, setting up local development environments, or creating multi-service Docker deployments.
+---
+
+# Docker Configuration
+
+Generate `Dockerfile` and `docker-compose.yml`.
+
+## Requirements
+
+| Aspect | Rule |
+|--------|------|
+| Base image | Specific version, never `latest`. Prefer slim/alpine/distroless |
+| User | Non-root (`USER appuser`) |
+| Build | Multi-stage to minimize final image |
+| Layers | Dependencies before code for caching |
+| Secrets | Via environment variables, never in image |
+| Health | `HEALTHCHECK` instruction required |
+
+## Dockerfile Template
+
+```dockerfile
+# Build
+FROM python:3.12-slim-bookworm AS builder
+WORKDIR /build
+COPY requirements.txt .
+RUN pip wheel --no-cache-dir -r requirements.txt -w /wheels
+
+# Production
+FROM python:3.12-slim-bookworm
+WORKDIR /app
+RUN useradd -r -s /bin/false appuser
+COPY --from=builder /wheels /wheels
+RUN pip install --no-cache-dir /wheels/* && rm -rf /wheels
+COPY --chown=appuser:appuser . .
+USER appuser
+EXPOSE 8000
+HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8000/health || exit 1
+CMD ["python", "-m", "app"]
+```
+
+## docker-compose.yml Template
+
+```yaml
+services:
+  app:
+    build: .
+    ports:
+      - "8000:8000"
+    environment:
+      DATABASE_URL: postgresql://user:pass@db:5432/app
+    depends_on:
+      db:
+        condition: service_healthy
+
+  db:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: user
+      POSTGRES_PASSWORD: pass
+      POSTGRES_DB: app
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U user -d app"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+
+volumes:
+  pgdata:
+```
+
+## Output
+
+Both files with comments explaining non-obvious choices.

ai/opencode/commands/prd-to-issues.md

@@ -0,0 +1,226 @@
+---
+description: Use when creating GitHub issues from a PRD, syncing an existing PRD to GitHub, or converting requirements documents into tracked issues.
+---
+
+# PRD to GitHub Issues
+
+Convert a PRD into GitHub issues (epics + stories/tasks) using the `gh` CLI. Supports initial creation and re-sync when the PRD changes.
+
+## Prerequisites
+
+Before starting, verify:
+- `gh` CLI is installed and authenticated (`gh auth status`)
+- A PRD exists in `docs/prd/` (created via the `prd` skill)
+- The project has a GitHub remote (`git remote -v`)
+
+If any prerequisite fails, stop and tell the user what to fix.
+
+## Label Setup
+
+Create these labels before creating issues (idempotent — safe to re-run):
+
+```bash
+gh label create "epic" --color "3B0A8C" --description "Epic: high-level feature group" --force
+gh label create "story" --color "0E8A16" --description "Story: user-facing deliverable" --force
+gh label create "task" --color "1D76DB" --description "Task: technical work item" --force
+gh label create "must-have" --color "B60205" --description "MoSCoW: Must have" --force
+gh label create "should-have" --color "D93F0B" --description "MoSCoW: Should have" --force
+gh label create "could-have" --color "FBCA04" --description "MoSCoW: Could have" --force
+gh label create "wont-have" --color "CCCCCC" --description "MoSCoW: Won't have (this time)" --force
+```
+
+## Initial Create Mode
+
+When no `<!-- GH-ISSUE:` markers exist in the PRD:
+
+### 1. Parse PRD
+
+- Read the PRD from `docs/prd/`
+- Extract Epics, FRs, acceptance criteria, priorities
+- Present a summary table to the user for confirmation before creating anything
+
+### 2. Create Labels
+
+Run the label setup commands above.
+
+### 3. Create Epic Issues
+
+For each Epic:
+
+```bash
+gh issue create \
+  --title "EPIC-001: [Epic Title]" \
+  --label "epic,[priority]-have" \
+  --body "$(cat <<'EOF'
+## Epic: [Title]
+
+[Epic description from PRD]
+
+### Acceptance Criteria
+
+- [ ] [Criterion 1]
+- [ ] [Criterion 2]
+
+### Functional Requirements
+
+- FR-001: [Description]
+- FR-002: [Description]
+
+---
+> Source: docs/prd/<project>-prd.md
+EOF
+)"
+```
+
+### 4. Create Story/Task Sub-Issues
+
+For each FR within an Epic, create a sub-issue:
+
+```bash
+gh issue create \
+  --title "[FR-001] [Short description]" \
+  --label "story,[priority]-have" \
+  --body "$(cat <<'EOF'
+## User Story
+
+As a [persona], I want to [action] so that [benefit].
+
+### Acceptance Criteria
+
+- [ ] [Criterion from PRD]
+
+### Details
+
+- **Priority:** [Must/Should/Could]
+- **Estimate:** [S/M/L]
+- **Epic:** EPIC-001 (#N)
+- **FR:** FR-001
+
+---
+> Source: docs/prd/<project>-prd.md
+EOF
+)"
+```
+
+Then link to the parent epic:
+
+```bash
+gh issue develop <story-number> --issue-parent <epic-number>
+```
+
+If `gh issue develop` is not available, add a comment linking to the parent:
+
+```bash
+gh issue comment <story-number> --body "Parent epic: #<epic-number>"
+```
+
+### 5. Embed Markers in PRD
+
+After creating issues, insert HTML comment markers in the PRD next to each Epic/FR:
+
+```markdown
+### EPIC-001: Authentication <!-- GH-ISSUE: owner/repo#42 -->
+
+| FR-001 | User login | Must | EPIC-001 | <!-- GH-ISSUE: owner/repo#43 --> |
+```
+
+**Marker format:** `<!-- GH-ISSUE: owner/repo#N -->`
+
+Placement rules:
+- Epic markers: end of the Epic heading line
+- FR markers: end of the FR table row or as a new column
+
+## Re-Sync Mode
+
+Triggered when `<!-- GH-ISSUE:` markers already exist in the PRD.
+
+### 1. Parse Existing Markers
+
+Extract all `<!-- GH-ISSUE: owner/repo#N -->` markers from the PRD using:
+
+```
+Pattern: <!-- GH-ISSUE:\s*([^#]+)#(\d+)\s*-->
+```
+
+### 2. Fetch Issue State
+
+For each marker, fetch the current issue state:
+
+```bash
+gh issue view <number> --json title,state,body,labels
+```
+
+### 3. Diff PRD vs Issues
+
+Compare PRD content against issue content. Classify each item:
+
+| Status | Meaning |
+|--------|---------|
+| **UNCHANGED** | PRD and issue match |
+| **NEW** | In PRD but no marker (new requirement) |
+| **MODIFIED** | PRD content differs from issue body |
+| **REMOVED** | Marker exists but FR removed from PRD |
+| **CLOSED** | Issue was closed on GitHub |
+
+### 4. Present Diff Summary
+
+Show the user a summary table before making any changes:
+
+```
+| # | Issue | Status | Action |
+|---|-------|--------|--------|
+| 1 | #42 EPIC-001 | UNCHANGED | — |
+| 2 | #43 FR-001 | MODIFIED | Update issue body |
+| 3 | — FR-004 | NEW | Create issue |
+| 4 | #45 FR-003 | REMOVED | Close issue? |
+```
+
+### 5. User Confirms
+
+Ask: "Which actions should I apply? (all / select by number / none)"
+
+**Never auto-apply re-sync changes.**
+
+### 6. Execute and Update Markers
+
+Apply confirmed actions:
+- **NEW:** `gh issue create` + add marker to PRD
+- **MODIFIED:** `gh issue edit <N> --body "..."`
+- **REMOVED:** `gh issue close <N>` (only if user confirms)
+
+Update markers in the PRD file after execution.
+
+## Issue Body Template
+
+All issues follow this structure:
+
+```markdown
+## [User Story | Epic Description]
+
+[Content from PRD]
+
+### Acceptance Criteria
+
+- [ ] [Criterion]
+
+### Details
+
+- **Priority:** [Must/Should/Could/Won't]
+- **Estimate:** [S/M/L/XL]
+- **Epic:** [EPIC-ID] (#N)
+- **FR:** [FR-ID]
+
+---
+> Source: docs/prd/<project>-prd.md
+```
+
+## Rules
+
+1. **gh CLI only** — never use the GitHub API directly or curl; always use `gh`
+2. **Confirm before creating** — show the summary table, wait for user approval
+3. **Never auto-apply re-sync** — always present the diff and ask for confirmation
+4. **Labels are idempotent** — use `--force` flag so re-runs do not fail
+5. **Markers are sacred** — never delete or modify markers manually; only this skill manages them
+6. **One PR per epic** — suggest (do not enforce) branching strategy: one branch per epic
+7. **Traceability** — update the PRD traceability matrix after creating issues
+8. **Error handling** — if `gh issue create` fails, report the error and continue with remaining issues