@aryaminus/controlkeel-opencode 0.3.31 → 0.3.33

package/.opencode/skills/architect-first/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: architect-first
+description: "Settle types, module shape, and boundaries before implementation. Trigger: 'architect this', 'design module structure', 'settle types first'. For multi-module changes."
+when_to_use: "Activate BEFORE writing code that crosses function/module boundaries or changes public APIs. Do NOT use for single-function fixes or when types are obvious."
+argument-hint: "[feature or change to architect]"
+disable-model-invocation: true
+license: Apache-2.0
+compatibility:
+  - opencode-native
+  - claude-standalone
+  - cursor-native
+  - codex
+metadata:
+  author: controlkeel
+  version: "1.1"
+  category: planning
+  ck_mcp_tools: [ck_memory_record, ck_memory_search, ck_review_submit]
+  related_skills: [align, plan-slice, investigate]
+---
+
+# Architect First
+
+Settle types, module shape, and boundaries before writing code. Cheaper to fix the design now than rewrite callers later.
+
+## Do NOT use when
+- Single-function fix (use `tdd-bugfix`)
+- Types are obvious and scope is narrow
+- The change fits in one module with no boundary changes
+- During implementation (design is already approved)
+
+## Workflow
+
+1. Search `ck_memory_search` for prior decisions about the affected area.
+2. Investigate existing module boundaries (use `investigate` skill if needed).
+3. Define:
+   - **Types/structs** for key data structures
+   - **Module boundaries**: owns / exposes / depends / does-not for each module
+   - **Data flow**: trace primary use case across boundaries
+4. Mark unresolved decisions as `[DECISION NEEDED]`.
+5. Record design via `ck_memory_record` (type: `decision`).
+6. Submit via `ck_review_submit` (review_type: `plan`, plan_phase: `design_options`). **Wait for approval**.
+
+## Design principles
+
+- Boundary discipline — modules own their data and invariants
+- Type-system discipline — structs and typespecs, not bare maps
+- Subtract before you add — can existing module absorb this?
+- Minimize reader load — purpose clear from public API alone
+
+## Output
+
+- Types and structs
+- Module boundary definitions
+- Data flow for primary use case
+- `ck_review_submit` plan awaiting approval
+- `ck_memory_record` with the design

package/.opencode/skills/challenge/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: challenge
+description: "Adversarially challenge the current plan or finding. Assume the direction is wrong and build the strongest case against it. Surfaces blind spots, false assumptions, and unexplored alternatives before execution starts."
+when_to_use: "Activate when the user says 'challenge this', 'push back', 'what could go wrong', 'steelman against', or 'devil's advocate'. Also activate before executing a high-depth or high-scope plan (depth >= 5, scope architectural_scope=true). Use after ck_review_submit to stress-test an approved plan before coding starts."
+argument-hint: "[plan review_id or finding rule_id to challenge — omit to challenge the latest approved plan]"
+license: Apache-2.0
+compatibility:
+  - codex
+  - claude-standalone
+  - claude-plugin
+  - copilot-plugin
+  - opencode-native
+  - cursor-native
+  - windsurf-native
+  - continue-native
+  - cline-native
+  - roo-native
+  - goose-native
+  - gemini-cli-native
+  - kiro-native
+  - amp-native
+  - augment-native
+metadata:
+  author: controlkeel
+  version: "1.0"
+  category: governance
+  ck_mcp_tools:
+    - ck_context
+    - ck_finding
+    - ck_review_status
+---
+
+# Challenge Skill
+
+Adversarially review the current plan or a specific finding. The goal is not to block work — it is to surface the strongest objections *before* execution so they can be addressed, not discovered mid-implementation.
+
+Inspired by Paradigma/Flywheel's adversarial review nodes: every knowledge claim should have an adversarial pass that tries to refute it before it propagates downstream.
+
+## When to Use
+
+- Before executing a plan with `architectural_scope: true` or `depth >= 5`
+- When the user asks "what could go wrong", "push back on this", or "devil's advocate"
+- After `ck_review_submit` on a plan that affects multiple files or core modules
+- When a finding has been open for multiple sessions and no one has questioned it
+- Before delegating long-running autonomous work
+
+## Challenge Flow
+
+### Step 1 — Load context
+
+Call `ck_context` to load:
+- The current session, task, and latest approved plan
+- Open findings (especially `blocked` and `escalated`)
+- Risk tier and compliance constraints
+
+If a specific `review_id` or `rule_id` was passed as an argument, use that as the target. Otherwise challenge the latest approved plan from `planning_context.latest_approved_plan`.
+
+### Step 2 — Extract the hypothesis
+
+Look for `hypothesis` and `expected_signal` in the plan refinement. If absent, infer them:
+- **Hypothesis**: what core assumption does this plan rest on? (e.g. "adding X will fix Y", "this abstraction won't break Z")
+- **Expected signal**: what would confirm the hypothesis is correct?
+
+State both explicitly before challenging. If you cannot reconstruct a hypothesis, that itself is the first challenge: **"This plan has no falsifiable hypothesis."**
+
+### Step 3 — Run the adversarial pass
+
+For each dimension below, generate the strongest objection you can. Do not hedge — argue as if you are trying to kill the plan.
+
+#### A. Assumption inversion
+List the top 3 assumptions the plan makes. For each, ask: "What if this is false?" If any assumption being false would make the plan fail or significantly change the approach, flag it.
+
+#### B. Scope creep signal
+Look at `scope_estimate`. Is `architectural_scope` underreported? Are there more files likely to be touched than `files_touched_estimate` suggests? Flag any evidence that the real diff will be larger than claimed.
+
+#### C. Contradicted findings
+Check existing findings. Does any open finding (status `open` or `blocked`) directly contradict or undermine the plan? List them with their `rule_id`.
+
+#### D. Missing alternatives
+Look at `options_considered` and `rejected_options`. Is there a viable approach that was never considered? Describe it in one sentence and state why it might be better.
+
+#### E. Validation gap
+Look at `validation_plan`. Is there a scenario where all validation steps pass but the plan still fails in production? Describe it.
+
+#### F. Hallucination propagation risk
+If this plan produces outputs that downstream tasks will depend on — identify what those outputs are and whether they are verifiable. Flag any output that downstream work will treat as ground truth but that has not been independently verified.
+
+### Step 4 — Score the challenge
+
+Summarize findings as:
+
+```
+STRONG objections (would change the plan):   N
+MODERATE objections (should be addressed):   N
+WEAK objections (worth noting, not blocking): N
+```
+
+If `STRONG >= 1`: recommend **blocking execution** and re-submitting the plan with the objections addressed.
+If `STRONG == 0, MODERATE >= 2`: recommend **addressing before execution starts**, not blocking.
+If `STRONG == 0, MODERATE <= 1`: recommend **proceeding** with the noted caveats.
+
+### Step 5 — Record findings
+
+For each STRONG or MODERATE objection, call `ck_finding` with:
+- `category`: `"challenge"`
+- `severity`: `"high"` for STRONG, `"medium"` for MODERATE
+- `rule_id`: `"challenge.<dimension>"` (e.g. `"challenge.assumption_inversion"`, `"challenge.validation_gap"`)
+- `plain_message`: the objection in one sentence
+- `decision`: `"warn"` (never block automatically — the human decides)
+- `extends_finding_id`: the finding this challenge responds to, if applicable
+- `contradicts_finding_id`: any existing finding this objection overturns, if applicable
+
+Do NOT record WEAK objections as findings. Include them only in the report.
+
+### Step 6 — Output the report
+
+```markdown
+# Challenge Report
+
+**Target:** [plan title or finding rule_id]
+**Hypothesis:** [stated or inferred]
+**Expected signal:** [stated or inferred, or "not specified"]
+
+## Verdict: [BLOCK | ADDRESS BEFORE EXECUTION | PROCEED WITH CAVEATS]
+
+## Strong objections
+[list, or "None"]
+
+## Moderate objections
+[list, or "None"]
+
+## Weak objections / notes
+[list, or "None"]
+
+## Findings recorded
+[list of ck_finding IDs created, or "None"]
+```
+
+## Integration with ck_review_submit
+
+After a challenge that clears (no STRONG objections), the caller can re-submit the plan with the moderate objections addressed. The new submission should include:
+- `hypothesis`: the hypothesis now made explicit
+- `expected_signal`: the observable confirmation criterion
+- Prior challenge findings referenced in `alignment_context`
+
+This creates a traceable chain: plan → challenge → revised plan → execution.
+
+## What this skill does NOT do
+
+- It does not rewrite or fix the plan. It challenges it.
+- It does not block execution directly. It records findings and gives a recommendation.
+- It does not repeat static policy checks (`ck_validate` covers those). It targets reasoning and assumption errors.

package/.opencode/skills/cli-for-agents/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: cli-for-agents
+description: "Design/review CLIs for agent-friendliness: non-interactive flags, layered help, idempotency, dry-run, actionable errors. Trigger: 'agent CLI', 'automation-friendly CLI', 'headless CLI design'."
+when_to_use: "Activate when building or reviewing a CLI that agents will drive. Do NOT use for general coding or web UI work."
+argument-hint: "[CLI name or command to design/review]"
+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]
+---
+
+# CLI for Agents
+
+CLIs that agents can drive reliably. Most human-oriented CLIs block agents with interactive prompts, missing examples, and ambiguous errors.
+
+## Do NOT use when
+- Building web UIs or non-CLI tools
+- The CLI already follows these patterns and needs no review
+
+## Checklist
+
+Design or review against these rules. Record violations as `ck_finding` (rule `cli.agent_unfriendly`).
+
+- **Non-interactive first**: Every input as a flag. Interactive is fallback, not default.
+- **Layered help**: `--help` per subcommand, not full manual dump.
+- **Examples on every `--help`**: Real copy-pasteable invocations.
+- **stdin/pipelines**: Accept stdin where sensible, support chaining.
+- **Actionable errors**: Missing flag → correct example invocation, not a hang.
+- **Idempotency**: Same command twice = safe (no-op or "already done").
+- **Destructive actions**: `--dry-run` to preview, `--yes`/`--force` to skip confirmations.
+- **Predictable structure**: `resource verb` pattern consistent across all subcommands.
+- **Machine-readable output**: IDs, URLs, durations on success — not just "done".
+
+## Output
+
+- CLI design with flags, examples, error messages
+- Or: review findings for existing CLI
+- `ck_finding` records for agent-unfriendly patterns

package/.opencode/skills/continual-learning/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: continual-learning
+description: "Auto-mine session for durable memory: user preferences and workspace facts. Trigger: 'learn from this', 'update memory', 'save what we learned', or at session end."
+when_to_use: "Activate at session end, when the user asks to save learnings, or periodically in long sessions. Do NOT use during active coding."
+argument-hint: "[optional: specific area to learn from]"
+disable-model-invocation: true
+license: Apache-2.0
+compatibility:
+  - opencode-native
+  - claude-standalone
+  - cursor-native
+  - codex
+metadata:
+  author: controlkeel
+  version: "1.1"
+  category: memory
+  ck_mcp_tools: [ck_memory_search, ck_memory_record, ck_memory_archive]
+  related_skills: [proof-memory]
+---
+
+# Continual Learning
+
+Auto-mine session activity for durable memory updates. CK's `ck_memory_record` is manual — this skill automates extraction.
+
+## Do NOT use when
+- During active coding (distracts from the task)
+- When no meaningful session activity has occurred
+- To record secrets, tokens, or transient debugging state
+
+## What gets learned (only two categories)
+
+1. **User Preferences**: Recurring corrections, preferred patterns, naming, tools, workflows
+2. **Workspace Facts**: Stable codebase facts, architecture decisions, module ownership, constraints
+
+## What does NOT get learned
+
+Secrets, one-off instructions, transient state, process meta-guidance
+
+## Workflow
+
+1. Search `ck_memory_search` for existing memories to avoid duplication.
+2. Scan session recent events (reviews, findings, decisions) for:
+   - User corrections recurring more than once
+   - Architecture decisions approved and not reversed
+   - Workspace facts discovered and not contradicted
+   - Preferences stated explicitly or demonstrated consistently
+3. For each candidate: Is it durable? Reusable? Specific? If no to any, skip.
+4. Record via `ck_memory_record`:
+   - Preferences → type `decision`, tags `["user-preference"]`
+   - Facts → type `brief`, tags `["workspace-fact"]`
+5. Archive superseded items via `ck_memory_archive`.
+6. If no high-signal items found: "No high-signal memory updates."
+
+## Rules
+
+- Plain bullet points only — no metadata blocks, confidence scores
+- Cap at 12 items per section
+- Deduplicate semantically — "prefer Req" and "always use Req" are the same item
+- Update in place, do not create duplicates alongside old items
+- Never record secrets
+
+## Output
+
+- `ck_memory_record` entries for new preferences/facts
+- `ck_memory_archive` for superseded items
+- Summary: "Recorded N preferences, M facts, archived K items."

package/.opencode/skills/continuity/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: continuity
+description: "Learn, record, audit, and apply codebase patterns consistently across a repo by comparing current code to canonical local examples stored in CK memory. Use when asked to preserve continuity, learn a pattern, check drift, fix inconsistent implementations, or enforce local conventions."
+when_to_use: "Activate ONLY for pattern-related work: learning repo conventions, auditing for drift, or fixing inconsistencies. Do NOT use for one-off code changes or general governance."
+argument-hint: "[learn <name> <paths...>|check <name>|fix <name>|ci]"
+disable-model-invocation: true
+license: Apache-2.0
+compatibility:
+  - opencode-native
+  - claude-standalone
+  - cursor-native
+  - codex
+metadata:
+  author: controlkeel
+  version: "1.0"
+  category: governance
+  ck_mcp_tools: [ck_memory_record, ck_memory_search, ck_finding, ck_fs_find, ck_fs_grep, ck_fs_read, ck_git_diff, ck_validate]
+  related_skills: [investigate, controlkeel-governance, deslop]
+---
+
+# Continuity
+
+Learn, record, audit, and apply codebase patterns consistently using CK's existing tools. No external registry files, no new infrastructure — everything lives in CK typed memory and findings.
+
+This skill fills the gap between CK's policy-level validation (`ck_validate`) and unstructured convention hints in `AGENTS.md`. It lets you encode *local coding conventions* — "our screens follow this shape, hooks use this pattern, imports go here" — as searchable, auditable, CI-gatable rules.
+
+## Do NOT use when
+- The work is a one-off code change (governance is handled by `controlkeel-governance`)
+- The question is about security policy (use `security-review`)
+- You need to trace code paths without enforcing conventions (use `investigate`)
+- The repo has no patterns worth recording yet
+
+## How it works
+
+CK typed memory IS the pattern registry. `ck_finding` IS the violation tracker. `ck_fs_*` tools ARE the scanner. This skill just wires them together:
+
+| Need | CK tool |
+|------|---------|
+| Store a pattern | `ck_memory_record(record_type: "decision", tags: ["continuity", "pattern", "active"])` |
+| Find known patterns | `ck_memory_search(query: "...", record_type: "decision")` + filter tags |
+| Find canonical files | `ck_fs_find`, `ck_fs_grep` to locate implementations |
+| Read source-of-truth | `ck_fs_read` |
+| Audit files for drift | `ck_fs_grep` for violation signals, `ck_fs_read` to verify |
+| Record violations | `ck_finding(category: "continuity", severity: "...", rule_id: "continuity.<pattern-name>")` |
+| Scope to changed files | `ck_git_diff` to list changed paths first |
+| CI gate | `ck_validate` against finding-based policy |
+
+## Pattern Registry
+
+Patterns live in CK typed memory. To learn a pattern, record it with a consistent shape:
+
+```elixir
+# Pattern recording convention
+record_type: "decision"
+tags: ["continuity", "pattern", "<status>"]
+# status: active | draft | deprecated
+
+# Body shape (markdown):
+# ## Pattern: <kebab-case-name>
+# - **Source of truth:** <file paths>
+# - **Applies to:** <glob patterns>
+# - **Does not apply to:** <glob exceptions>
+# - **Rule summary:** <one paragraph>
+# - **Required shape:** <observable rules>
+# - **Violation signals:** <searchable patterns>
+# - **Severity:** high | medium | low
+# - **Fix strategy:** <mechanical fix steps>
+```
+
+### Tag conventions
+
+- `["continuity", "pattern", "active"]` — actively enforced
+- `["continuity", "pattern", "draft"]` — being refined
+- `["continuity", "pattern", "deprecated"]` — no longer enforced
+
+## Invocation modes
+
+### learn — Record a new pattern
+
+When the user says "learn this pattern" or shows you canonical example files:
+
+1. Read the provided files with `ck_fs_read`.
+2. Search for similar implementations with `ck_fs_find` + `ck_fs_grep`.
+3. Compare examples. Identify the canonical shape.
+4. **Ask focused questions if ambiguous.** Don't guess. Point to specific files and ask which should be canonical.
+5. Once confirmed, record with `ck_memory_record` using the shape above.
+6. Tell the user what was recorded.
+
+### check — Audit for drift (read-only)
+
+When the user says "check this pattern" or "audit for drift":
+
+1. Search `ck_memory_search(tags: ["continuity", "pattern"])` for matching patterns.
+2. If a specific name given, filter by body content matching that name.
+3. If scope wasn't specified, check `ck_git_diff` for changed files first (changed-files scope).
+4. Or audit the full path scope if user explicitly requests full-repo.
+5. For each pattern, search for violation signals using `ck_fs_grep`.
+6. Read candidate files with `ck_fs_read` to verify.
+7. Report violations concisely. Do NOT edit files.
+8. For each violation, offer to record it with `ck_finding` if the user wants it tracked.
+
+### fix — Audit and apply safe fixes
+
+When the user says "fix this pattern" or "apply the pattern":
+
+1. Run the `check` workflow first.
+2. Apply high-confidence mechanical fixes directly.
+3. **Ask before** fixes that rename public symbols, move files across packages, or require choosing between canonical examples.
+4. Re-run the pattern search to confirm drift is closed.
+5. Run repo-native validation (tests, lint, typecheck) if available.
+6. Summarize what changed.
+
+### ci — Deterministic audit for automation
+
+When run in CI or pre-commit context:
+
+1. Run `ck_git_diff` to get changed files.
+2. Search `ck_memory_search(tags: ["continuity", "pattern", "active"])`.
+3. For patterns with `changed-files` scope, audit only changed files against violation signals.
+4. For patterns with `full-repo` scope, audit the full scope.
+5. Report violations as `ck_finding(category: "continuity", severity: rule_severity)`.
+6. End with a stable summary line matching the pattern:
+
+```
+CONTINUITY_RESULT: pass|fail
+PATTERNS_CHECKED: <n>
+VIOLATIONS: <n>
+```
+
+## Operating principles
+
+1. **Code wins over docs.** Start from actual implementations, not documentation.
+2. **CK memory wins over inference.** Read recorded patterns before making claims. If memory contradicts current code, report the conflict.
+3. **Do not invent canonical patterns.** If unsure which file is canonical, ask the user. Point to files, not abstract preferences.
+4. **Record decisions.** After the user identifies canonical examples, save in CK memory so future sessions inherit it.
+5. **Prefer narrow scope first.** Audit changed files or provided paths before scanning the whole repo.
+6. **Separate detection from fixing.** First report violations. Then fix only what's clearly implied by pattern rules.
+7. **Avoid shallow text matching.** Use `ck_fs_grep` to find candidates, but verify structure by reading relevant files.
+8. **Respect baselines.** If a pattern has known legacy drift, don't report it as a new violation.
+
+## Useful search tactics
+
+```bash
+# Find pattern candidates
+ck_fs_find --query "ComponentName" --path lib/
+
+# Search for violation signals
+ck_fs_grep --query "import { useState }" --path lib/app/
+
+# List changed files for CI scope
+ck_git_diff --base-ref origin/main...HEAD
+
+# Find related implementations
+ck_fs_find --query "*.tsx" --path lib/app/screens
+```
+
+## Output style
+
+Be direct and actionable. Never dump raw search results. Always distinguish:
+
+- **Confirmed canonical:** file paths with evidence
+- **Inferred but unconfirmed:** labeled as such
+- **Violations that should be fixed:** specific files + issue + expected shape
+- **Intentional exceptions:** known drift, not actionable
+- **Open questions:** what needs human input
+
+If no violations found, say:
+
+> Continuity check passed for `<pattern>/<scope>`.

package/.opencode/skills/controlkeel-governance/SKILL.md

@@ -105,6 +105,28 @@ For any new feature, fix, or project — before writing plans or code — use th
 - Do not add abstractions, compatibility shims, or indirection unless they are justified by the current codebase. Prefer the simplest change that solves the actual task.
 - Before saying work is done, re-check proof, findings, and budget state.
 
+## Invariant Enforcement vs. Local Workarounds
+
+**Critical principle**: Prefer enforcing system invariants over adding local workarounds for bad states.
+
+- **Avoid**: "Make the system work with malformed data" (tolerant readers, fallbacks, recovery logic)
+- **Prefer**: "Make malformed data impossible" (validation at write time, strict schemas, invariants)
+
+AI-generated code often sees a local failure and adds local defenses against it. This accumulates complexity and weakens system foundations. Instead:
+
+1. **Identify the invariant**: What should always be true? (e.g., session logs are always valid, user data is always validated)
+2. **Enforce at the boundary**: Prevent invalid states from being written, not handle them after the fact
+3. **Remove workarounds**: Existing code that handles "impossible" states should be removed after invariant enforcement
+4. **Validate patterns**: Use `ck_finding` with category `architecture` and rule `CK-INVARIANT-001` when you see tolerance for bad states
+
+**Examples**:
+- ❌ Add fallback reader for corrupted session logs
+- ✅ Prevent corrupted session logs from being written (strict validation, checksums)
+- ❌ Add migration for malformed user records
+- ✅ Enforce schema constraints so malformed records cannot be created
+- ❌ Add retry logic for undefined API responses
+- ✅ Define strict API contracts and validate responses against them
+
 ## Quick reference
 
 - `ck_context` — mission, task, budget, proof, memory, workspace snapshot, transcript summary, resume context
@@ -125,3 +147,4 @@ For any new feature, fix, or project — before writing plans or code — use th
 ## Additional resources
 
 - For the full governed workflow, see [references/workflow.md](references/workflow.md)
+- For issue and PR validation patterns to combat AI-generated slop, see [docs/issue-pr-validation-guide.md](../../docs/issue-pr-validation-guide.md)

package/.opencode/skills/deep-code-quality-review/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: deep-code-quality-review
+description: "Strict maintainability review: abstraction quality, file size, spaghetti growth, code-judo simplification. Trigger: 'deep quality review', 'thermo-nuclear review', 'harsh maintainability audit'."
+when_to_use: "Activate ONLY when explicitly asked for a harsh code quality review. Do NOT auto-trigger during normal coding or security reviews."
+argument-hint: "[file, PR, branch, or area]"
+disable-model-invocation: true
+license: Apache-2.0
+compatibility:
+  - opencode-native
+  - claude-standalone
+  - cursor-native
+  - codex
+metadata:
+  author: controlkeel
+  version: "1.1"
+  category: quality
+  ck_mcp_tools: [ck_validate, ck_finding, ck_git_diff, ck_review_submit]
+  related_skills: [security-review, parallel-review]
+---
+
+# Deep Code Quality Review
+
+Extremely strict maintainability review. Be **ambitious** about structure — search for "code judo" moves that make the implementation dramatically simpler.
+
+## Do NOT use when
+- Security review needed (use `security-review`)
+- Normal code review or PR feedback
+- Making behavior changes
+
+## Standards (non-negotiable)
+
+1. **File size**: Flag files crossing 1000 lines → `ck_finding` rule `code_quality.file_size` (severity `high`).
+2. **No spaghetti**: Flag ad-hoc conditionals in unrelated flows → rule `code_quality.spaghetti_condition`.
+3. **Design over "it works"**: If structure can be cleaner with same behavior, push for cleaner.
+4. **Direct over magical**: Flag thin wrappers, identity functions, pass-through helpers → rule `code_quality.unnecessary_abstraction`.
+5. **Type boundaries**: Flag unnecessary casts, optionality, ad-hoc shapes → rule `code_quality.type_boundary`.
+6. **Canonical layer**: Flag feature logic in shared paths → rule `code_quality.wrong_layer`.
+7. **Orchestration**: Flag sequential when parallel is simpler → rule `code_quality.orchestration`.
+
+Additional rules: `code_quality.missing_abstraction`, `code_quality.magic_handling`, `code_quality.duplicate_logic`.
+
+## Workflow
+
+1. Run `ck_git_diff` to get changes. Run `ck_validate` for automated patterns.
+2. Walk [quality checklist](references/quality-checklist.md) against every meaningful change.
+3. Record each issue with `ck_finding` using the rule IDs above.
+4. Submit findings via `ck_review_submit` (review_type: `plan`). Wait for approval.
+
+## Approval bar
+
+No approval unless: no structural regression, no missed simplification, no file explosion, no spaghetti growth, no unnecessary abstraction, no layer leak, no missed decomposition.
+
+## Relationship to security-review
+
+- **security-review**: OWASP, injection, auth, secrets, dependencies
+- **this skill**: abstraction quality, file size, spaghetti, layering, simplification
+- Use `parallel-review` to run both concurrently.
+
+## Output
+
+- `ck_finding` records with specific rule IDs
+- `ck_review_submit` plan with prioritized findings
+- No code changes — review only