@aryaminus/controlkeel-opencode 0.3.12 → 0.3.13

package/.opencode/skills/plan-slice/SKILL.md

@@ -11,6 +11,27 @@ compatibility:
   - copilot-plugin
   - github-repo
   - open-standard
+  - cline-native
+  - cursor-native
+  - windsurf-native
+  - continue-native
+  - letta-code-native
+  - pi-native
+  - roo-native
+  - goose-native
+  - opencode-native
+  - gemini-cli-native
+  - kiro-native
+  - kilo-native
+  - amp-native
+  - augment-native
+  - hermes-native
+  - multica-native
+  - openclaw-native
+  - devin-terminal-native
+  - warp-native
+  - droid-bundle
+  - forge-acp
 metadata:
   author: controlkeel
   version: "1.0"
@@ -92,17 +113,35 @@ Map each slice to a CK autonomy profile:
 
 Never label a slice AFK if it contains an unresolved unknown from the `align` step.
 
-### 7. Record the plan
-Call `ck_memory_record` (type: `decision`) with the full slice plan: slice titles, layer coverage, blocking relationships, and autonomy labels.
+### 7. Define success criteria for each slice
+
+For every slice, convert vague requirements into concrete, testable conditions:
+
+**Example:**
+```
+VAGUE: "Make the dashboard faster"
+REFRAMED SUCCESS CRITERIA:
+- Dashboard LCP < 2.5s on 4G connection
+- Initial data load completes in < 500ms
+- No layout shift during load (CLS < 0.1)
+```
+
+Each slice must have:
+- Observable success condition (what you can measure or verify)
+- Failure condition (what would indicate the slice is not done)
+- Edge case coverage (what breaks if inputs are invalid)
+
+### 8. Record the plan
+Call `ck_memory_record` (type: `decision`) with the full slice plan: slice titles, layer coverage, blocking relationships, autonomy labels, and success criteria.
 
 Update the `ck_goal` record (mode: `update_status`) with `active` and a progress note pointing to the slice plan.
 
-### 8. Submit for human approval
+### 9. Submit for human approval
 
 Call `ck_review_submit` with:
 - `review_type`: `plan`
 - `plan_phase`: `implementation_plan`
-- `implementation_steps`: the slice list with blocking relationships and autonomy labels
+- `implementation_steps`: the slice list with blocking relationships, autonomy labels, and success criteria
 - `validation_plan`: which tests or observables prove each slice is done
 - `alignment_context`: the accepted goal from the `align` step
 - `scope_estimate`: number of slices, estimated touch points per layer
@@ -121,7 +160,7 @@ Then call `ck_review_status` to check for `grill_questions`. Surface every grill
 
 At the end of this skill:
 - A reviewed and approved slice plan (via `ck_review_submit`).
-- A `ck_memory_record` containing the DAG: slice titles, layers, dependencies, autonomy labels.
+- A `ck_memory_record` containing the DAG: slice titles, layers, dependencies, autonomy labels, and success criteria.
 - A `ck_goal` update marking the plan as active.
 - A clear first slice ready for handoff to implementation (via `ck_delegate` or direct agent work under the governance skill).
 

package/.opencode/skills/policy-training/SKILL.md

@@ -11,6 +11,27 @@ compatibility:
   - copilot-plugin
   - github-repo
   - open-standard
+  - cline-native
+  - cursor-native
+  - windsurf-native
+  - continue-native
+  - letta-code-native
+  - pi-native
+  - roo-native
+  - goose-native
+  - opencode-native
+  - gemini-cli-native
+  - kiro-native
+  - kilo-native
+  - amp-native
+  - augment-native
+  - hermes-native
+  - multica-native
+  - openclaw-native
+  - devin-terminal-native
+  - warp-native
+  - droid-bundle
+  - forge-acp
 disable-model-invocation: true
 metadata:
   author: controlkeel

package/.opencode/skills/proof-memory/SKILL.md

@@ -11,6 +11,27 @@ compatibility:
   - copilot-plugin
   - github-repo
   - open-standard
+  - cline-native
+  - cursor-native
+  - windsurf-native
+  - continue-native
+  - letta-code-native
+  - pi-native
+  - roo-native
+  - goose-native
+  - opencode-native
+  - gemini-cli-native
+  - kiro-native
+  - kilo-native
+  - amp-native
+  - augment-native
+  - hermes-native
+  - multica-native
+  - openclaw-native
+  - devin-terminal-native
+  - warp-native
+  - droid-bundle
+  - forge-acp
 metadata:
   author: controlkeel
   version: "2.0"

package/.opencode/skills/security-review/SKILL.md

@@ -11,26 +11,99 @@ compatibility:
   - copilot-plugin
   - github-repo
   - open-standard
+  - cline-native
+  - cursor-native
+  - windsurf-native
+  - continue-native
+  - letta-code-native
+  - pi-native
+  - roo-native
+  - goose-native
+  - opencode-native
+  - gemini-cli-native
+  - kiro-native
+  - kilo-native
+  - amp-native
+  - augment-native
+  - hermes-native
+  - multica-native
+  - openclaw-native
+  - devin-terminal-native
+  - warp-native
+  - droid-bundle
+  - forge-acp
 metadata:
   author: controlkeel
-  version: "2.0"
+  version: "2.1"
   category: security
   ck_mcp_tools:
     - ck_validate
     - ck_context
     - ck_finding
     - ck_regression_result
+  related_skills:
+    - agent-pattern-verification
 ---
 
 # Security Review Skill
 
 Use this skill before closing a task, approving a proof bundle, or reviewing a risky diff.
 
+## Three-Tier Boundary System
+
+Apply this explicit boundary system during review:
+
+### Always Do (No Exceptions)
+- Validate all external input at system boundaries
+- Parameterize all database queries
+- Encode output to prevent injection
+- Use HTTPS for external communication
+- Hash passwords with strong algorithms
+- Set security headers (CSP, HSTS, X-Frame-Options)
+- Use httpOnly, secure, sameSite cookies for sessions
+- Run dependency audits before releases
+
+### Ask First (Requires Human Approval)
+- Adding or changing authentication flows
+- Storing new categories of sensitive data (PII, payment info)
+- Adding new external service integrations
+- Changing CORS configuration
+- Adding file upload handlers
+- Modifying rate limiting or throttling
+- Granting elevated permissions or roles
+
+### Never Do
+- Never commit secrets to version control
+- Never log sensitive data (passwords, tokens, full card numbers)
+- Never trust client-side validation as a security boundary
+- Never disable security headers for convenience
+- Never use eval() or innerHTML with user-provided data
+- Never store sessions in client-accessible storage
+- Never expose stack traces or internal error details to users
+
 ## Review flow
 
 1. Call `ck_context` to load the domain pack, risk tier, open findings, instruction hierarchy, and design-drift signals.
-2. Run `ck_validate` on the relevant code or config slices, including trust-boundary metadata when the proposed action was influenced by web, tool, skill, or mixed-provenance content.
-3. Walk the review checklist in [references/review-checklist.md](references/review-checklist.md).
-4. Persist any missed issue with `ck_finding`.
-5. If external security or regression systems produce exploit or browser evidence, record that through `ck_regression_result` when it affects release readiness.
-6. Summarize blockers, warnings, and follow-up proof requirements.
+2. Check if agent frameworks are detected in workspace context. If agent frameworks (LangGraph, CrewAI, AutoGen, LangChain) are present, activate the agent-pattern-verification skill for additional agent-specific checks.
+3. Run `ck_validate` on the relevant code or config slices, including trust-boundary metadata when the proposed action was influenced by web, tool, skill, or mixed-provenance content.
+4. Apply the three-tier boundary system to classify each finding: always-do, ask-first, or never-do.
+5. Walk the review checklist in [references/review-checklist.md](references/review-checklist.md).
+6. Persist any missed issue with `ck_finding`, including boundary tier classification in metadata.
+7. If external security or regression systems produce exploit or browser evidence, record that through `ck_regression_result` when it affects release readiness.
+8. Summarize blockers, warnings, and follow-up proof requirements, grouped by boundary tier.
+
+## Agent Pattern Integration
+
+When agent frameworks are detected in the workspace context, this skill automatically includes agent-specific pattern checks:
+
+- **Loop Safety**: Detects `while True` without break, recursive calls without depth limits
+- **Retry Limits**: Validates retry decorators have explicit stop conditions
+- **Tool Registry**: Cross-references tool definitions with prompt references
+- **Context Size**: Monitors system prompt and tool description token counts
+- **Graph Cycles**: Analyzes LangGraph graphs for unreachable END nodes
+
+These checks complement the baseline security review with agent-specific anti-pattern detection.
+
+## Additional resources
+
+- For anti-rationalization patterns to help recognize and reject security shortcuts, see [references/anti-rationalization-patterns.md](references/anti-rationalization-patterns.md).

package/.opencode/skills/security-review/references/anti-rationalization-patterns.md

@@ -0,0 +1,59 @@
+# Anti-Rationalization Patterns
+
+This document catalogs common excuses agents give when taking security shortcuts and why they are invalid. Use these patterns when reviewing findings to help agents recognize and reject their own shortcuts.
+
+## Security Anti-Rationalizations
+
+| Excuse | Why It's Invalid | Correct Response |
+| ------ | ---------------- | ---------------- |
+| "This is an internal tool, security doesn't matter" | Internal tools get compromised. Attackers target the weakest link. Lateral movement starts from trusted internal surfaces. | Apply the same security controls to internal systems as to external ones. |
+| "We'll add security later" | Security retrofitting is 10x harder than building it in. Adding it later means insecure foundations are already load-bearing. | Build security in from the start. Treat every external input as hostile, every secret as sacred. |
+| "No one would try to exploit this" | Automated scanners find everything. Security by obscurity is not security. | Assume hostile probing. Design for adversarial conditions. |
+| "The framework handles security" | Frameworks provide tools, not guarantees. Auto-escaping doesn't help if you bypass it; parameterized queries don't help if you concatenate anyway. | Verify framework security settings. Don't bypass built-in protections. |
+| "It's just a prototype" | Prototypes ship to production. Security habits from day one prevent security debt from day two. | Assume the code will ship. Apply the same standards to prototypes as to production code. |
+| "The data isn't sensitive" | You don't know what future use cases will be. Data becomes sensitive over time and in combination. | Treat all data with appropriate safeguards. Classify and protect accordingly. |
+| "Performance comes first" | Security is a performance requirement, not an optimization. Insecure systems are unusable when breached. | Design security into the architecture. Use security-focused performance patterns. |
+| "It's too much work" | Security debt is more expensive to fix later. Breaches are catastrophic in cost, reputation, and compliance. | Invest in security upfront. It's cheaper than remediation. |
+
+## Planning Anti-Rationalizations
+
+| Excuse | Why It's Invalid | Correct Response |
+| ------ | ---------------- | ---------------- |
+| "I know what to build, let's just start" | Assumptions become expensive misalignments when caught after implementation. | Surface assumptions explicitly. Get alignment on what, why, and done before coding. |
+| "The requirements are clear enough" | Vague requirements lead to rework. "Faster" is not a success criterion. | Reframe vague requirements into concrete, testable conditions with metrics. |
+| "We can figure out the details later" | Unknowns compound into blocked findings or architectural dead ends. | Identify unknowns explicitly. Spike research before implementation. |
+| "This is a small change, no need to plan" | Small changes can have large surface area. Context matters. | Check touched layers. Even small changes may need review if they cross boundaries. |
+
+## Code Quality Anti-Rationalizations
+
+| Excuse | Why It's Invalid | Correct Response |
+| ------ | ---------------- | ---------------- |
+| "It works, that's what matters" | Working code that is unmaintainable becomes technical debt. Future changes become exponentially harder. | Write clean, maintainable code. Clarity over cleverness. |
+| "I'll clean it up later" | Code cleanup rarely happens. Technical debt compounds. | Write clean code the first time. Refactor as you go. |
+| "This is a temporary hack" | Temporary code becomes permanent. Hacks accumulate and rot the codebase. | Write production-quality code from the start. If you need a hack, mark it with TODO and a ticket. |
+| "The tests will catch it" | Tests don't catch design flaws, security issues, or performance problems. Quality is more than test coverage. | Apply multiple quality gates: security review, performance analysis, design review. |
+| "Nobody will read this code" | Future you will read this code. Others will maintain it. Code is read more than written. | Write code for humans, not just machines. Document intent. |
+
+## Testing Anti-Rationalizations
+
+| Excuse | Why It's Invalid | Correct Response |
+| ------ | ---------------- | ---------------- |
+| "I'll test it manually" | Manual testing doesn't scale. Regressions happen. Automation is necessary for confidence. | Write automated tests. Use TDD where appropriate. |
+| "This is too hard to test" | Hard-to-test code is a design smell. It indicates tight coupling and hidden dependencies. | Refactor for testability. Use dependency injection. Isolate side effects. |
+| "The tests are passing, it's fine" | Passing tests don't prove correctness. They only prove the tests pass. | Review test coverage. Test edge cases. Use property-based testing. |
+| "I'll add tests after the feature works" | Tests after the fact are often shallow or skipped. TDD drives better design. | Write tests first or alongside code. Treat tests as part of the feature. |
+
+## Usage in Findings
+
+When persisting findings with `ck_finding`, include anti-rationalization context in the `plain_message` or `metadata`:
+
+```json
+{
+  "category": "security",
+  "severity": "warning",
+  "plain_message": "Input validation missing at API boundary. Common rationalization: 'I'll add security later' — security is a constraint on every line that touches user data, not a phase.",
+  "rule_id": "input-validation-required"
+}
+```
+
+Including the anti-rationalization in the finding text ensures it surfaces at review time and guides the agent that reads the finding back.

package/.opencode/skills/ship-readiness/SKILL.md

@@ -11,6 +11,27 @@ compatibility:
   - copilot-plugin
   - github-repo
   - open-standard
+  - cline-native
+  - cursor-native
+  - windsurf-native
+  - continue-native
+  - letta-code-native
+  - pi-native
+  - roo-native
+  - goose-native
+  - opencode-native
+  - gemini-cli-native
+  - kiro-native
+  - kilo-native
+  - amp-native
+  - augment-native
+  - hermes-native
+  - multica-native
+  - openclaw-native
+  - devin-terminal-native
+  - warp-native
+  - droid-bundle
+  - forge-acp
 metadata:
   author: controlkeel
   version: "2.0"

package/package.json

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