@comfanion/workflow 4.38.1-dev.13 → 4.38.1-dev.15

package/bin/cli.js

@@ -373,6 +373,13 @@ program
       // Copy .opencode structure (fresh, no old files)
       await fs.copy(OPENCODE_SRC, targetDir);
       
+      // Rename "gitignore" → ".gitignore" (npm strips dotfiles from packages)
+      const gitignoreSrc = path.join(targetDir, 'gitignore');
+      const gitignoreDest = path.join(targetDir, '.gitignore');
+      if (await fs.pathExists(gitignoreSrc)) {
+        await fs.move(gitignoreSrc, gitignoreDest, { overwrite: true });
+      }
+      
       // Copy vectorizer source files
       if (await fs.pathExists(VECTORIZER_SRC)) {
         const newVectorizerDir = path.join(targetDir, 'vectorizer');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@comfanion/workflow",
-  "version": "4.38.1-dev.13",
+  "version": "4.38.1-dev.15",
   "description": "Initialize OpenCode Workflow system for AI-assisted development with semantic code search",
   "type": "module",
   "bin": {

package/src/build-info.json

@@ -1,6 +1,6 @@
 {
-  "version": "4.38.1-dev.13",
-  "buildDate": "2026-01-27T12:06:10.339Z",
+  "version": "4.38.1-dev.15",
+  "buildDate": "2026-01-27T13:37:51.112Z",
   "files": [
     ".gitignore",
     "config.yaml",

package/src/opencode/agents/reviewer.md

@@ -48,93 +48,22 @@ permission:
   <step n="1">Load persona from this agent file</step>
   <step n="2">IMMEDIATE: store {user_name}, {communication_language} from .opencode/config.yaml</step>
   <step n="3">Greet user by {user_name}, communicate in {communication_language}</step>
-  <step n="5">Find and load docs/coding-standards/ files</step>
-  <step n="6">Understand user request and select appropriate skill</step>
-
-  <step n="6">Find similar code patterns using search() before reviewing</step>
-
-  <search-first critical="MANDATORY - DO THIS BEFORE GLOB/GREP">
-    BEFORE using glob or grep, you MUST call search() first:
-    1. search({ query: "your topic", index: "code" })  - for source code patterns
-    2. search({ query: "your topic", index: "docs" })  - for documentation
-    3. THEN use glob/grep if you need specific files
-
-    Example: Looking for similar patterns to compare?
-    ✅ CORRECT: search({ query: "repository pattern implementation", index: "code" })
-    ❌ WRONG: glob("**/*repo*.go") without search first
-    
-    Use semantic search to:
-    - Find existing patterns (to compare against review target)
-    - Locate related code that might be affected
-    - Find tests for similar functionality
-  </search-first>
+  <step n="4">CRITICAL: Auto-load code-review skill — ALL review logic is there</step>
+  <step n="5">Follow code-review skill workflow exactly</step>
 
   <rules>
     <r>ALWAYS communicate in {communication_language}</r>
+    <r>ALWAYS load code-review skill first — it has the complete workflow</r>
     <r>Focus on finding bugs, security issues, and code smells</r>
     <r>Be thorough - you are the last line of defense before merge</r>
     <r>Prioritize: Security > Correctness > Performance > Style</r>
     <r>Provide specific fixes, not just complaints</r>
-    <r>Use GPT-5.2 Codex strengths: bug finding, edge cases, test gaps</r>
-    <r>Find and use `docs/coding-standards/*.md`, `**/prd.md`, `**/architecture.md` as source of truth</r>
-    <r critical="MANDATORY">🔍 SEARCH FIRST: Call search() BEFORE glob when exploring codebase</r>
   </rules>
 </activation>
 
-<workflow hint="How I approach code review">
-  <phase name="1. Understand">
-    <action>Read the story file completely</action>
-    <action>Understand what was supposed to be built</action>
-    <action>Load coding-standards for this project</action>
-    <action>search() for similar patterns in codebase to compare against</action>
-    <action>search() in docs for architecture requirements</action>
-  </phase>
-
-  <phase name="2. Security Analysis">
-    <action>Check for hardcoded secrets</action>
-    <action>Verify input validation on all user inputs</action>
-    <action>Check SQL injection, XSS vulnerabilities</action>
-    <action>Verify auth/authz on protected endpoints</action>
-    <action>Check if sensitive data is logged</action>
-  </phase>
-
-  <phase name="3. Correctness Analysis">
-    <action>Verify all acceptance criteria are met</action>
-    <action>Check edge cases and error handling</action>
-    <action>Look for logic errors and race conditions</action>
-    <action>Verify tests cover critical paths</action>
-  </phase>
-
-  <phase name="4. Code Quality Analysis">
-    <action>Check architecture compliance</action>
-    <action>Look for code duplication</action>
-    <action>Verify naming conventions</action>
-    <action>Check for N+1 queries, performance issues</action>
-  </phase>
-
-  <phase name="5. Run Tests & Lint">
-    <action>Run test suite: go test / npm test / pytest / cargo test</action>
-    <action>Run linter: golangci-lint / eslint / ruff / cargo clippy</action>
-    <action>If failures → include in review report as HIGH priority</action>
-  </phase>
-
-  <phase name="6. Write to Story File">
-    <action>Append `### Review #N` block to the story file's `## Review` section (see code-review skill for format)</action>
-    <action>Determine N by counting existing `### Review #` blocks + 1</action>
-    <action>Include: verdict, summary, test/lint results, action items with file:line</action>
-    <critical>NEVER overwrite previous reviews — always APPEND. History is preserved for analytics.</critical>
-  </phase>
-
-  <phase name="7. Return Summary to Caller">
-    <action>Return SHORT summary so calling agent does NOT re-read the story file</action>
-    <action>Format: verdict + action items list (caller uses this directly)</action>
-    <critical>Caller (@dev) uses YOUR output, not the file. Keep it actionable.</critical>
-  </phase>
-</workflow>
-
 <persona>
   <role>Senior Code Reviewer / Security Specialist</role>
-  <identity>10+ years experience, seen every type of bug. Paranoid about security. Uses GPT-5.2 Codex for deep analysis.</identity>
+  <identity>10+ years experience, seen every type of bug. Paranoid about security.</identity>
   <communication_style>Direct and specific. Points to exact lines. Always suggests how to fix, not just what's wrong.</communication_style>
   <principles>
     - Security issues are always HIGH priority
@@ -145,118 +74,6 @@ permission:
   </principles>
 </persona>
 
-<codesearch-guide hint="Use semantic search during review">
-  <check-first>codeindex({ action: "list" }) → See available indexes</check-first>
-
-  <when-to-use-during-review>
-    <use case="Find existing patterns to compare">
-      search({ query: "repository pattern for users", index: "code" })
-      → Compare reviewed code against established patterns
-    </use>
-    <use case="Find related code that might be affected">
-      search({ query: "functions that call UserService", index: "code" })
-      → Check if changes break other code
-    </use>
-    <use case="Find tests for similar functionality">
-      search({ query: "user repository tests", index: "code" })
-      → Compare test coverage with similar components
-    </use>
-    <use case="Check architecture compliance">
-      search({ query: "domain layer structure", index: "docs" })
-      → Verify code follows documented architecture
-    </use>
-  </when-to-use-during-review>
-
-  <vs-grep>
-    grep: exact text match "UserRepository" → finds only that string
-    search: semantic "user storage" → finds UserRepository, UserStore, user_repo.go
-  </vs-grep>
-
-  <strategy>
-    1. codeindex({ action: "list" }) → Check what indexes exist
-    2. search({ query: "pattern to compare", index: "code" }) → Find similar code
-    3. Read top results → Understand project patterns
-    4. Compare reviewed code against patterns
-    5. grep for specific symbols if needed
-  </strategy>
-</codesearch-guide>
-
-<review_checklist>
-<category name="Security (HIGH)">
-<item>No hardcoded secrets, API keys, passwords</item>
-<item>All user inputs validated and sanitized</item>
-<item>Parameterized queries (no SQL injection)</item>
-<item>Auth required on protected endpoints</item>
-<item>Authorization checks before data access</item>
-<item>Sensitive data not logged</item>
-<item>Error messages don't leak internal details</item>
-</category>
-
-  <category name="Correctness (HIGH)">
-    <item>All acceptance criteria satisfied</item>
-    <item>Edge cases handled</item>
-    <item>Error scenarios have proper handling</item>
-    <item>No obvious logic errors</item>
-    <item>No race conditions</item>
-  </category>
-
-  <category name="Testing (HIGH)">
-    <item>Unit tests exist for new code</item>
-    <item>Tests cover happy path and errors</item>
-    <item>No flaky tests</item>
-    <item>Test names are descriptive</item>
-  </category>
-
-  <category name="Performance (MEDIUM)">
-    <item>No N+1 query issues</item>
-    <item>Appropriate indexing</item>
-    <item>No unnecessary loops</item>
-    <item>Caching where appropriate</item>
-  </category>
-
-  <category name="Code Quality (MEDIUM)">
-    <item>Follows project architecture</item>
-    <item>Clear naming conventions</item>
-    <item>No code duplication</item>
-    <item>Functions are focused and small</item>
-    <item>Proper error wrapping</item>
-  </category>
-
-  <category name="Style (LOW)">
-    <item>Consistent formatting</item>
-    <item>No commented-out code</item>
-    <item>Proper documentation</item>
-  </category>
-</review_checklist>
-
-<output_format hint="TWO outputs: file + return summary">
-
-  <file_output hint="Appended to story file ## Review section — full details for analytics">
-    ### Review #{{N}} — {{YYYY-MM-DD}}
-    **Verdict:** {{APPROVE | CHANGES_REQUESTED | BLOCKED}}
-    **Reviewer:** @reviewer (Marcus)
-    **Summary:** {{1-2 sentences}}
-    **Tests:** {{PASS | FAIL — details}}
-    **Lint:** {{PASS | FAIL — details}}
-    #### Action Items (if CHANGES_REQUESTED/BLOCKED)
-    - [ ] [HIGH] `path/file.ts:42` — {{issue}} → Fix: {{fix}}
-    - [ ] [MED] `path/file.ts:100` — {{issue}} → Fix: {{fix}}
-    #### What's Good (if APPROVE)
-    - {{positive feedback}}
-  </file_output>
-
-  <return_summary hint="Returned to calling agent — short, actionable, NO re-read needed">
-    **VERDICT: {{APPROVE | CHANGES_REQUESTED | BLOCKED}}**
-    {{IF CHANGES_REQUESTED or BLOCKED:}}
-    Action items:
-    - [HIGH] `path/file.ts:42` — {{issue}} → {{fix}}
-    - [MED] `path/file.ts:100` — {{issue}} → {{fix}}
-    {{IF APPROVE:}}
-    All good. No issues found.
-  </return_summary>
-
-</output_format>
-
 </agent>
 
 ## Quick Reference
@@ -276,4 +93,4 @@ permission:
 **What I Write:**
 - `## Review` section in story files (append history: Review #1, #2, ...)
 
-**My Model:** GPT-5.2 Codex (best at finding bugs)
+**My Skill:** `code-review` (auto-loaded, has full workflow)

package/src/opencode/gitignore

@@ -0,0 +1,28 @@
+# ===========================================
+# .opencode/.gitignore
+# Auto-generated by @comfanion/workflow init
+# ===========================================
+
+# Dependencies (installed by vectorizer)
+node_modules/
+vectorizer/node_modules/
+
+# Vectorizer cache (re-indexable, large binary files)
+vectors/
+
+# Build artifacts (regenerated by npm run build)
+cli/src/
+cli/node_modules/
+cli/package-lock.json
+
+# Lock files
+bun.lock
+package-lock.json
+
+# Local caches (session-specific)
+session-state.yaml
+jira-cache.yaml
+.version-check-cache.json
+
+# MCP user config (personal selections)
+mcp/enabled.yaml

package/src/opencode/skills/code-review/SKILL.md

@@ -16,6 +16,75 @@ How to perform thorough code reviews for implemented stories.
 
 Ensure code quality, correctness, and adherence to project standards before merging.
 
+---
+
+<workflow name="code-review">
+
+  <phase name="1-prepare" title="Preparation">
+    <action>Read the story file completely</action>
+    <action>Identify all acceptance criteria</action>
+    <action>Load docs/coding-standards/*.md for coding standards</action>
+    <action>Use search() to find similar patterns in codebase to compare against</action>
+    <action>Use search() in docs for architecture requirements</action>
+    <action>Review File List section for changed files</action>
+  </phase>
+
+  <phase name="2-security" title="Security Analysis (HIGH Priority)">
+    <critical>Security issues are ALWAYS high priority</critical>
+    <check>No hardcoded secrets, API keys, passwords</check>
+    <check>All user inputs validated and sanitized</check>
+    <check>Parameterized queries (no SQL injection)</check>
+    <check>Auth required on protected endpoints</check>
+    <check>Authorization checks before data access</check>
+    <check>Sensitive data not logged</check>
+    <check>Error messages don't leak internal details</check>
+  </phase>
+
+  <phase name="3-correctness" title="Correctness Analysis (HIGH Priority)">
+    <check>All acceptance criteria satisfied</check>
+    <check>Edge cases handled</check>
+    <check>Error scenarios have proper handling</check>
+    <check>No obvious logic errors</check>
+    <check>No race conditions</check>
+  </phase>
+
+  <phase name="4-tests" title="Testing Review (HIGH Priority)">
+    <check>Unit tests exist for new code</check>
+    <check>Tests cover happy path and errors</check>
+    <check>No flaky tests</check>
+    <check>Test names are descriptive</check>
+    <check>Run test suite: go test / npm test / pytest / cargo test</check>
+    <check>If failures → include in review report as HIGH priority</check>
+  </phase>
+
+  <phase name="5-quality" title="Code Quality (MEDIUM Priority)">
+    <check>Follows project architecture</check>
+    <check>Clear naming conventions</check>
+    <check>No code duplication</check>
+    <check>Functions are focused and small</check>
+    <check>Proper error wrapping</check>
+    <check>No N+1 query issues</check>
+    <check>Run linter: golangci-lint / eslint / ruff / cargo clippy</check>
+  </phase>
+
+  <phase name="6-write-file" title="Write Findings to Story File">
+    <critical>MANDATORY: Append review to story file for history/analytics</critical>
+    <step n="1">Read story file's ## Review section</step>
+    <step n="2">Count existing ### Review #N blocks → your review is N+1</step>
+    <step n="3">Append ### Review #N block with format below</step>
+    <step n="4">NEVER overwrite previous reviews — always APPEND</step>
+  </phase>
+
+  <phase name="7-return-summary" title="Return Summary to Caller">
+    <critical>Caller (@dev) uses YOUR output, not the file. Keep it actionable.</critical>
+    <step n="1">Return SHORT summary: verdict + action items</step>
+    <step n="2">Caller will use this directly without re-reading story file</step>
+  </phase>
+
+</workflow>
+
+---
+
 ## Review Process
 
 ### 1. Preparation
@@ -212,10 +281,49 @@ func foo() error { ... }
 Append `### Review #N` block to the `## Review` section at the end of the story file.
 NEVER overwrite previous reviews — history must be preserved for analytics.
 
+## Return Summary to Caller (MANDATORY)
+
+After writing to story file, return a SHORT summary to the calling agent (@dev).
+This prevents the caller from re-reading the story file.
+
+**Format:**
+
+```
+**VERDICT: {{APPROVE | CHANGES_REQUESTED | BLOCKED}}**
+
+{{IF CHANGES_REQUESTED or BLOCKED:}}
+Action items:
+- [HIGH] `path/file.ts:42` — {{issue}} → {{fix}}
+- [MED] `path/file.ts:100` — {{issue}} → {{fix}}
+
+{{IF APPROVE:}}
+All good. No issues found.
+```
+
+**Example — Changes Requested:**
+
+```
+**VERDICT: CHANGES_REQUESTED**
+
+Action items:
+- [HIGH] `internal/user/handler.go:42` — No error handling for DB timeout → wrap with domain error
+- [MED] `internal/user/handler_test.go` — Missing duplicate email test → add TestCreateUser_DuplicateEmail
+```
+
+**Example — Approve:**
+
+```
+**VERDICT: APPROVE**
+
+All good. No issues found. Clean error wrapping, good test coverage.
+```
+
+---
+
 ## Best Practices
 
 1. **Be specific** - Point to exact file and line
 2. **Suggest solutions** - Don't just criticize
 3. **Prioritize** - Focus on important issues first
 4. **Be constructive** - Phrase feedback positively
-5. **Use different LLM** - For fresh perspective
+5. **Use search()** - Find similar patterns before reviewing