@aryaminus/controlkeel-opencode 0.3.31 → 0.3.33

package/.opencode/skills/reviewable-pr/references/pr-checklist.md

@@ -0,0 +1,42 @@
+# PR Reviewability Checklist
+
+Walk this checklist when diagnosing whether a PR is ready for review. Each item
+lists a concrete check. Use `ck_validate` for automated scanning, then manually
+verify items requiring judgment.
+
+## Commit History
+
+- **Single-intent commits**: Each commit should express one coherent change. If a commit mixes schema changes, UI tweaks, and test updates, flag it for splitting.
+- **Descriptive subjects**: Every commit subject should answer "what does this change?" without opening the diff. Avoid subjects like "fix", "update", or "wip".
+- **Dependency order**: Commits should follow a logical order: schema → service → API → UI → tests. Out-of-order commits make the reviewer reconstruct the timeline.
+- **No dead commits**: Reverted commits, "fix previous commit", or "oops" commits add noise. Squash or reorder before review.
+
+## PR Description
+
+- **TL;DR present**: One sentence describing the diff's purpose, matching the actual changes.
+- **Core files listed**: The 3-7 files a reviewer should read carefully, separated from mechanical changes.
+- **Risk callouts**: Migration order, behavior changes, rollout dependencies, or missing test coverage.
+- **Context links**: Issue tracker, design doc, dashboard, or prior PR that explains the intent.
+- **Testing instructions**: How to verify the change locally (commands, seed data, specific routes).
+
+## Diff Structure
+
+- **Mechanical vs logic separation**: Formatting, generated files, or boilerplate should be in separate commits from logic changes. Reviewers should not hunt for the real change.
+- **Unrelated changes removed**: If the branch contains changes for a different feature or fix, move them to a separate branch.
+- **Test coverage**: Core logic changes must have corresponding test changes. If tests are missing, flag it as a reviewability issue.
+- **File count reasonable**: More than 15 changed files signals the PR may need splitting. More than 30 is a strong signal to split.
+
+## Reviewer Entry Points
+
+- **Main entry file identified**: Which file should the reviewer read first? Add this to the PR description.
+- **Complex sections annotated**: Non-obvious algorithms, workarounds, or trade-offs should have inline comments explaining the "why".
+- **Migration safety**: If the PR includes migrations, note the rollback plan and any data migration concerns.
+
+## Blocking Conditions
+
+Do not proceed with reviewability improvements if:
+
+- `ck_validate` returns blocked findings — fix those first
+- The PR contains behavior changes hidden as cleanup
+- The tree hash changes after history cleanup (content was accidentally modified)
+- The branch depends on unmerged work from another branch

package/.opencode/skills/standup-summary/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: standup-summary
+description: "Summarize work completed over a time period using git commits + CK session data. Trigger: 'what did I get done', 'standup', 'weekly summary', 'status update'."
+when_to_use: "Activate ONLY when the user asks for a work summary over a time range. Do NOT auto-trigger during coding or review tasks."
+argument-hint: "[time period: yesterday, last 3 days, last week]"
+disable-model-invocation: true
+license: Apache-2.0
+compatibility:
+  - opencode-native
+  - claude-standalone
+  - cursor-native
+  - codex
+metadata:
+  author: controlkeel
+  version: "1.1"
+  category: reporting
+  ck_mcp_tools: [ck_session_digest, ck_engineer_mirror, ck_memory_search]
+  related_skills: [proof-memory]
+---
+
+# Standup Summary
+
+Summarize work over a time period. Enriches git log with CK session data for richer context than git alone.
+
+## Do NOT use when
+- During coding, review, or planning tasks
+- The user wants code changes (not a summary)
+
+## Workflow
+
+1. Resolve time window from user input. Default: yesterday.
+2. Read git commits by current user in range:
+   ```
+   git log --author="$(git config user.email)" --since="<start>" --until="<end>" --no-merges --format="%h %s"
+   ```
+3. Enrich with CK data:
+   - `ck_session_digest` (mode: `generate`) for session tasks, findings, budget
+   - `ck_engineer_mirror` for daily reflection and approval patterns
+   - `ck_memory_search` for active decisions in the time window
+4. Synthesize: prioritize substantial changes, omit cosmetic-only.
+5. Output format:
+   ```
+   ## Standup: <start> – <end>
+   <one sentence summary>
+   ### Shipped
+   - <2-5 bullets, major changes only>
+   ### In progress / Blocked
+   - <if any>
+   ```
+
+## Guardrails
+
+- Every bullet traces to a commit or CK record — no fabrication
+- Do not infer intent — describe changes functionally
+- If no activity in range, say so clearly
+
+## Output
+
+- Concise status update with real date range
+- 2-5 major bullets for substantial changes

package/.opencode/skills/tdd-bugfix/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: tdd-bugfix
+description: "Reproduce → root-cause → failing test → minimal fix → verify. Trigger: 'fix this bug', 'reproduce and fix', 'TDD fix'. Requires a local test path."
+when_to_use: "Activate when fixing a bug WITH a cheap local test path. Do NOT use for design tasks, features, or bugs requiring manual browser reproduction."
+argument-hint: "[bug description or failing test path]"
+disable-model-invocation: true
+license: Apache-2.0
+compatibility:
+  - opencode-native
+  - claude-standalone
+  - cursor-native
+  - codex
+metadata:
+  author: controlkeel
+  version: "1.1"
+  category: development
+  ck_mcp_tools: [ck_validate, ck_finding, ck_git_diff, ck_git_commit, ck_memory_record]
+  related_skills: [deep-code-quality-review]
+---
+
+# TDD Bugfix
+
+Test-first bug fix. Failing test proves the bug, fix makes it pass, runtime evidence confirms.
+
+## Do NOT use when
+- No local test path exists (manual browser testing, production-only bugs)
+- Building features (use `architect-first` then `plan-slice`)
+- Refactoring (use `deep-code-quality-review`)
+
+## Workflow
+
+1. **Reproduce**: Trace the code path to the defect. Write a minimal test that fails. Run it to confirm failure.
+2. **Root-cause**: Follow [root-cause checklist](references/root-cause-checklist.md). Record root cause via `ck_memory_record` (type: `finding`).
+3. **Failing test**: Write a test that demonstrates the bug. Must be: minimal, deterministic, clearly named. Confirm it fails.
+4. **Validate test**: Run `ck_validate` on the test code. Fix findings.
+5. **Minimal fix**: Smallest change to make the test pass. No refactoring, no improvements. Record improvement ideas via `ck_memory_record` for later.
+6. **Verify**: Failing test passes. Full suite passes (`mix test`). Zero new failures.
+7. **Validate fix**: Run `ck_validate` on the diff. Record findings.
+8. **Commit**: `ck_git_commit` with message referencing the bug and test.
+
+## Rules
+
+- Test first, fix second — no exceptions
+- Minimal fix only — refactoring is a separate commit
+- No `Process.sleep/1` in tests — use monitors or `:sys.get_state/1`
+- Root-cause, not symptom — fix the cause or record deeper issue as `ck_finding`
+
+## Output
+
+- Failing test proving the bug
+- Minimal fix making test pass
+- Full suite passing
+- Root cause recorded in memory

package/.opencode/skills/tdd-bugfix/references/root-cause-checklist.md

@@ -0,0 +1,28 @@
+# Root-Cause Checklist
+
+Walk this checklist during root-cause analysis. Do not stop at the first
+symptom — trace each layer until the actual cause is identified.
+
+## Symptom → Cause Tracing
+
+- **What is the observed failure?** Describe the exact symptom: error message, wrong output, crash, timing issue.
+- **Where does it manifest?** File, function, line number. The error location is often not the root cause location.
+- **What changed recently?** Check `git log --oneline -10` for the relevant area. Often a recent commit introduced the regression.
+- **What is the data flow?** Trace inputs → processing → outputs. Where does the wrong value first appear?
+
+## Common Root Causes
+
+- **Nil / missing value**: A field was not preloaded, a map key was missing, a function returned `nil` unexpectedly.
+- **Wrong boundary condition**: Off-by-one, empty list, zero value, first/last element not handled.
+- **Race condition**: State read before write completes, async operation not awaited, process not alive.
+- **Type mismatch**: String vs atom, integer vs float, struct vs map. Check function heads and pattern matches.
+- **Schema migration not run**: Column missing, constraint not applied, index not created.
+- **Wrong scope or context**: Function called with the wrong module, variable shadowed, import conflict.
+- **Stale cache or compiled code**: Old bytecode, stale process dictionary, cached value not invalidated.
+- **External dependency change**: API response format changed, dependency version bumped, config drift.
+
+## Verification
+
+- **Can you reproduce it deterministically?** If not, the root cause is not yet understood.
+- **Does the fix address the root cause?** If you fix a symptom without the root cause, the bug will recur in a different form.
+- **Are there other code paths with the same root cause?** Search for the pattern across the codebase. If found, record as a `ck_finding` with `correctness.same_root_cause`.

package/package.json

@@ -35,5 +35,5 @@
     "url": "git+https://github.com/aryaminus/controlkeel.git"
   },
   "type": "module",
-  "version": "0.3.31"
+  "version": "0.3.33"
 }