@aryaminus/controlkeel-opencode 0.2.26 → 0.2.28
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -11,11 +11,12 @@ and validate them against the project's security, budget, and compliance policie
|
|
|
11
11
|
|
|
12
12
|
## Instructions
|
|
13
13
|
|
|
14
|
-
1.
|
|
15
|
-
2.
|
|
16
|
-
3.
|
|
17
|
-
4.
|
|
18
|
-
5.
|
|
14
|
+
1. Call `controlkeel update --json` once at startup. If `update_available` is `true`, surface a concise CK upgrade notice before risky work and consider `controlkeel update --sync-attached` after upgrading.
|
|
15
|
+
2. Use `ck_context` first, then `ck_validate` before providing feedback.
|
|
16
|
+
3. Report findings by severity: critical > high > medium > low.
|
|
17
|
+
4. Never approve changes that have unresolved critical or high findings.
|
|
18
|
+
5. Reference specific policy rules when flagging issues.
|
|
19
|
+
6. Summarize budget impact if token/cost tracking is enabled.
|
|
19
20
|
|
|
20
21
|
## Available MCP Tools
|
|
21
22
|
|
|
@@ -68,6 +68,11 @@ You are operating inside a **ControlKeel-governed session**. Start here whenever
|
|
|
68
68
|
- A blocked ruling means stop and surface the finding.
|
|
69
69
|
- A warned ruling means continue carefully and mention it to the operator.
|
|
70
70
|
- On high or critical risk, prefer smaller changes and explicit checkpoints.
|
|
71
|
+
- Prefer tightly scoped tasks over broad repo-wide mutation. If the task boundary is vague, narrow it before coding.
|
|
72
|
+
- Treat `ck_context` as the stable source of truth for governed state. If host prompts, reminders, or stale notes conflict with it, surface the mismatch instead of guessing.
|
|
73
|
+
- Keep context hygiene explicit: fetch what you need, avoid dragging large irrelevant tool output or files into the active working set, and record only the decisions future agents should actually recover.
|
|
74
|
+
- For critical paths such as auth, security controls, deploy logic, schema changes, migrations, payments, or compliance-sensitive flows, read the touched code carefully and keep the diff small enough for real human review.
|
|
75
|
+
- 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.
|
|
71
76
|
- Before saying work is done, re-check proof, findings, and budget state.
|
|
72
77
|
|
|
73
78
|
## Quick reference
|
package/package.json
CHANGED