@aryaminus/controlkeel-opencode 0.2.18 → 0.2.20
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.
- package/.opencode/skills/agent-integration/SKILL.md +49 -0
- package/.opencode/skills/agent-integration/agents/openai.yaml +11 -0
- package/.opencode/skills/agent-integration/references/target-matrix.md +21 -0
- package/.opencode/skills/benchmark-operator/SKILL.md +33 -0
- package/.opencode/skills/benchmark-operator/agents/openai.yaml +12 -0
- package/.opencode/skills/benchmark-operator/references/benchmark-playbook.md +6 -0
- package/.opencode/skills/cloudflare-agent/SKILL.md +366 -0
- package/.opencode/skills/cloudflare-agent/references/cloudflare-integration.md +226 -0
- package/.opencode/skills/compliance-audit/SKILL.md +34 -0
- package/.opencode/skills/compliance-audit/agents/openai.yaml +12 -0
- package/.opencode/skills/compliance-audit/references/control-matrix.md +51 -0
- package/.opencode/skills/controlkeel-governance/SKILL.md +89 -0
- package/.opencode/skills/controlkeel-governance/agents/openai.yaml +12 -0
- package/.opencode/skills/controlkeel-governance/references/workflow.md +28 -0
- package/.opencode/skills/cost-optimization/SKILL.md +36 -0
- package/.opencode/skills/cost-optimization/agents/openai.yaml +12 -0
- package/.opencode/skills/cost-optimization/references/budget-playbook.md +18 -0
- package/.opencode/skills/domain-audit/SKILL.md +41 -0
- package/.opencode/skills/domain-audit/agents/openai.yaml +12 -0
- package/.opencode/skills/domain-audit/references/domain-review-matrix.md +71 -0
- package/.opencode/skills/policy-training/SKILL.md +35 -0
- package/.opencode/skills/policy-training/agents/openai.yaml +12 -0
- package/.opencode/skills/policy-training/references/promotion-rules.md +6 -0
- package/.opencode/skills/proof-memory/SKILL.md +39 -0
- package/.opencode/skills/proof-memory/agents/openai.yaml +11 -0
- package/.opencode/skills/proof-memory/references/proof-workflow.md +6 -0
- package/.opencode/skills/security-review/SKILL.md +34 -0
- package/.opencode/skills/security-review/agents/openai.yaml +12 -0
- package/.opencode/skills/security-review/references/review-checklist.md +69 -0
- package/.opencode/skills/ship-readiness/SKILL.md +35 -0
- package/.opencode/skills/ship-readiness/agents/openai.yaml +12 -0
- package/.opencode/skills/ship-readiness/references/release-checklist.md +8 -0
- package/package.json +1 -1
|
@@ -0,0 +1,226 @@
|
|
|
1
|
+
# Cloudflare Agent Governance Configuration
|
|
2
|
+
|
|
3
|
+
## Quick Start
|
|
4
|
+
|
|
5
|
+
### 1. Create Cloudflare Worker with Agents SDK
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
npx create-cloudflare@latest --template cloudflare/agents-starter my-governed-agent
|
|
9
|
+
cd my-governed-agent
|
|
10
|
+
npm install
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
### 2. Add CK Governance Tools
|
|
14
|
+
|
|
15
|
+
Create `src/governance.ts`:
|
|
16
|
+
|
|
17
|
+
```typescript
|
|
18
|
+
import type { Env } from "./env";
|
|
19
|
+
|
|
20
|
+
export async function validateWithCK(env: Env, action: string, payload: any) {
|
|
21
|
+
const response = await env.CK_GOVERNANCE.fetch("https://your-ck-instance/validate", {
|
|
22
|
+
method: "POST",
|
|
23
|
+
headers: { "Content-Type": "application/json" },
|
|
24
|
+
body: JSON.stringify({
|
|
25
|
+
action,
|
|
26
|
+
payload,
|
|
27
|
+
agent: "cloudflare-agent",
|
|
28
|
+
version: "1.0.0"
|
|
29
|
+
})
|
|
30
|
+
});
|
|
31
|
+
return response.json();
|
|
32
|
+
}
|
|
33
|
+
|
|
34
|
+
export async function checkBudget(env: Env, scope: string = "task") {
|
|
35
|
+
const response = await env.CK_GOVERNANCE.fetch(`https://your-ck-instance/budget/${scope}`);
|
|
36
|
+
return response.json();
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
### 3. Configure wrangler.toml
|
|
41
|
+
|
|
42
|
+
```toml
|
|
43
|
+
name = "governed-agent"
|
|
44
|
+
main = "src/index.ts"
|
|
45
|
+
compatibility_date = "2025-03-02"
|
|
46
|
+
|
|
47
|
+
[[d1_databases]]
|
|
48
|
+
binding = "DB"
|
|
49
|
+
database_name = "agent-db"
|
|
50
|
+
database_id = "your-d1-id"
|
|
51
|
+
|
|
52
|
+
[[r2_buckets]]
|
|
53
|
+
binding = "AGENT_BUCKET"
|
|
54
|
+
bucket_name = "agent-workspace"
|
|
55
|
+
|
|
56
|
+
[[unsafe.bindings]]
|
|
57
|
+
name = "CK_GOVERNANCE"
|
|
58
|
+
type = "durable_object_namespace"
|
|
59
|
+
class_name = "GovernanceDO"
|
|
60
|
+
|
|
61
|
+
[env.production.vars]
|
|
62
|
+
CK_INSTANCE = "https://controlkeel.yourdomain.com"
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### 4. Create D1 Database
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
wrangler d1 create agent-db
|
|
69
|
+
wrangler d1 execute agent-db --local --command="
|
|
70
|
+
CREATE TABLE IF NOT EXISTS agent_logs (
|
|
71
|
+
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
|
72
|
+
timestamp INTEGER NOT NULL,
|
|
73
|
+
action TEXT NOT NULL,
|
|
74
|
+
payload TEXT,
|
|
75
|
+
decision TEXT,
|
|
76
|
+
budget_before INTEGER,
|
|
77
|
+
budget_after INTEGER
|
|
78
|
+
);
|
|
79
|
+
|
|
80
|
+
CREATE TABLE IF NOT EXISTS agent_state (
|
|
81
|
+
key TEXT PRIMARY KEY,
|
|
82
|
+
value TEXT,
|
|
83
|
+
updated_at INTEGER
|
|
84
|
+
);
|
|
85
|
+
"
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
## R2 Bucket Setup
|
|
89
|
+
|
|
90
|
+
```bash
|
|
91
|
+
# Create R2 bucket for agent workspace
|
|
92
|
+
wrangler r2 bucket create agent-workspace
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
## Governance Rules Example
|
|
96
|
+
|
|
97
|
+
Configure in CK:
|
|
98
|
+
|
|
99
|
+
```json
|
|
100
|
+
{
|
|
101
|
+
"policy": {
|
|
102
|
+
"shell": {
|
|
103
|
+
"allowed_commands": ["git", "npm", "node", "python", "cargo"],
|
|
104
|
+
"blocked_patterns": ["rm -rf /", "sudo", "chmod 777"],
|
|
105
|
+
"max_duration_ms": 60000
|
|
106
|
+
},
|
|
107
|
+
"file_access": {
|
|
108
|
+
"allowed_paths": ["/workspace/*"],
|
|
109
|
+
"max_file_size_mb": 10
|
|
110
|
+
},
|
|
111
|
+
"budget": {
|
|
112
|
+
"task": { "max_tokens": 100000, "max_calls": 50 },
|
|
113
|
+
"daily": { "max_tokens": 1000000, "max_calls": 500 }
|
|
114
|
+
}
|
|
115
|
+
}
|
|
116
|
+
}
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
## MCP Server Setup
|
|
120
|
+
|
|
121
|
+
```typescript
|
|
122
|
+
// src/mcp/governance.ts
|
|
123
|
+
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
|
|
124
|
+
import { z } from "zod";
|
|
125
|
+
|
|
126
|
+
export function createGovernanceMCP(env: Env) {
|
|
127
|
+
const server = new McpServer({
|
|
128
|
+
name: "controlkeel-governance",
|
|
129
|
+
version: "1.0.0"
|
|
130
|
+
});
|
|
131
|
+
|
|
132
|
+
server.tool(
|
|
133
|
+
"ck_validate",
|
|
134
|
+
"Validate an action against governance policies",
|
|
135
|
+
{
|
|
136
|
+
action: z.string(),
|
|
137
|
+
payload: z.record(z.any())
|
|
138
|
+
},
|
|
139
|
+
async ({ action, payload }) => {
|
|
140
|
+
return await validateWithCK(env, action, payload);
|
|
141
|
+
}
|
|
142
|
+
);
|
|
143
|
+
|
|
144
|
+
server.tool(
|
|
145
|
+
"ck_budget_check",
|
|
146
|
+
"Check remaining budget",
|
|
147
|
+
{
|
|
148
|
+
scope: z.enum(["task", "session", "daily"]).optional()
|
|
149
|
+
},
|
|
150
|
+
async ({ scope }) => {
|
|
151
|
+
return await checkBudget(env, scope || "task");
|
|
152
|
+
}
|
|
153
|
+
);
|
|
154
|
+
|
|
155
|
+
return server;
|
|
156
|
+
}
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
## Testing Governance
|
|
160
|
+
|
|
161
|
+
```typescript
|
|
162
|
+
// test/governance.test.ts
|
|
163
|
+
import { describe, it, expect } from "vitest";
|
|
164
|
+
|
|
165
|
+
describe("Cloudflare Agent Governance", () => {
|
|
166
|
+
it("should validate shell commands", async () => {
|
|
167
|
+
const result = await validateWithCK(env, "shell_execute", {
|
|
168
|
+
command: "npm install"
|
|
169
|
+
});
|
|
170
|
+
expect(result.decision).toBe("approved");
|
|
171
|
+
});
|
|
172
|
+
|
|
173
|
+
it("should block dangerous commands", async () => {
|
|
174
|
+
const result = await validateWithCK(env, "shell_execute", {
|
|
175
|
+
command: "rm -rf /"
|
|
176
|
+
});
|
|
177
|
+
expect(result.decision).toBe("denied");
|
|
178
|
+
});
|
|
179
|
+
|
|
180
|
+
it("should track budget", async () => {
|
|
181
|
+
const before = await checkBudget(env, "task");
|
|
182
|
+
// make API call...
|
|
183
|
+
const after = await checkBudget(env, "task");
|
|
184
|
+
expect(after.remaining).toBeLessThan(before.remaining);
|
|
185
|
+
});
|
|
186
|
+
});
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
## Monitoring
|
|
190
|
+
|
|
191
|
+
### Log Queries
|
|
192
|
+
|
|
193
|
+
```sql
|
|
194
|
+
-- Recent governance decisions
|
|
195
|
+
SELECT * FROM agent_logs
|
|
196
|
+
ORDER BY timestamp DESC
|
|
197
|
+
LIMIT 20;
|
|
198
|
+
|
|
199
|
+
-- Blocked actions
|
|
200
|
+
SELECT * FROM agent_logs
|
|
201
|
+
WHERE decision = 'denied'
|
|
202
|
+
ORDER BY timestamp DESC;
|
|
203
|
+
|
|
204
|
+
-- Budget usage
|
|
205
|
+
SELECT
|
|
206
|
+
DATE(timestamp, 'unixepoch') as day,
|
|
207
|
+
COUNT(*) as total_actions,
|
|
208
|
+
SUM(json_extract(payload, '$.tokens')) as tokens_used
|
|
209
|
+
FROM agent_logs
|
|
210
|
+
GROUP BY day;
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
### Prometheus Metrics
|
|
214
|
+
|
|
215
|
+
Configure in `wrangler.toml`:
|
|
216
|
+
|
|
217
|
+
```toml
|
|
218
|
+
[observability]
|
|
219
|
+
enabled = true
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
Track:
|
|
223
|
+
- `governance_decisions_total{decision="approved|denied"}`
|
|
224
|
+
- `budget_consumed_tokens`
|
|
225
|
+
- `shell_execution_duration_ms`
|
|
226
|
+
- `file_operations_total`
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: compliance-audit
|
|
3
|
+
description: "Run a structured compliance audit against active ControlKeel policy packs and domain controls. Use this before shipping regulated data flows, external integrations, or document exports."
|
|
4
|
+
license: Apache-2.0
|
|
5
|
+
compatibility:
|
|
6
|
+
- codex
|
|
7
|
+
- claude-standalone
|
|
8
|
+
- claude-plugin
|
|
9
|
+
- copilot-plugin
|
|
10
|
+
- github-repo
|
|
11
|
+
- open-standard
|
|
12
|
+
metadata:
|
|
13
|
+
author: controlkeel
|
|
14
|
+
version: "2.0"
|
|
15
|
+
category: compliance
|
|
16
|
+
ck_mcp_tools:
|
|
17
|
+
- ck_context
|
|
18
|
+
- ck_validate
|
|
19
|
+
- ck_finding
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
# Compliance Audit Skill
|
|
23
|
+
|
|
24
|
+
## Audit flow
|
|
25
|
+
|
|
26
|
+
1. Call `ck_context` and confirm the active compliance profile for the session.
|
|
27
|
+
2. Review only the pack sections that match the active domain pack and data flows.
|
|
28
|
+
3. Use `ck_validate` for concrete snippets and configs when the checklist points to code.
|
|
29
|
+
4. Persist each failing control with `ck_finding`.
|
|
30
|
+
5. End with packs checked, controls reviewed, blockers, and required approvals.
|
|
31
|
+
|
|
32
|
+
## Additional resources
|
|
33
|
+
|
|
34
|
+
- For the full domain-by-domain checklist, see [references/control-matrix.md](references/control-matrix.md)
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Compliance Audit"
|
|
3
|
+
short_description: "CK compliance control review aligned to active policy packs and domain packs."
|
|
4
|
+
brand_color: "#1d4ed8"
|
|
5
|
+
policy:
|
|
6
|
+
allow_implicit_invocation: true
|
|
7
|
+
dependencies:
|
|
8
|
+
tools:
|
|
9
|
+
- type: "mcp"
|
|
10
|
+
value: "controlkeel"
|
|
11
|
+
description: "ControlKeel MCP server"
|
|
12
|
+
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Control Matrix
|
|
2
|
+
|
|
3
|
+
Use the session's active compliance profile to select the relevant section.
|
|
4
|
+
Each control lists a concrete check. Run `ck_validate` to scan for known patterns,
|
|
5
|
+
then manually verify items that require human judgment.
|
|
6
|
+
|
|
7
|
+
## Baseline
|
|
8
|
+
|
|
9
|
+
- **Secrets**: Verify no hardcoded API keys, tokens, passwords, or private keys exist in source code, config files, or logs. Run `ck_validate` and confirm zero `security.hardcoded_secret` findings.
|
|
10
|
+
- **Injection**: Verify SQL queries use parameterized statements or Ecto-style bindings. Verify shell commands avoid string interpolation of user input. Verify HTML templates escape dynamic content. Run `ck_validate` and confirm zero `security.sql_injection`, `security.shell_injection`, and `security.xss` findings.
|
|
11
|
+
- **XSS**: Verify no `innerHTML` assignments from untrusted input. Verify React/Phoenix templates escape by default. Check any dangerously-set HTML APIs.
|
|
12
|
+
|
|
13
|
+
## Healthcare
|
|
14
|
+
|
|
15
|
+
- **PHI encryption**: Confirm all stored PHI uses AES-256 or equivalent encryption at rest. Confirm all PHI in transit uses TLS 1.2+. Check database column-level encryption for diagnosis, treatment, and identifier fields.
|
|
16
|
+
- **Role-based access**: Verify every route or API endpoint that touches PHI checks the caller's role. Verify admin-only endpoints are not reachable by non-admin tokens. Check that audit logs record which role accessed which record.
|
|
17
|
+
- **Audit logging**: Confirm all PHI read/write operations produce an immutable log entry with timestamp, user/service identity, record ID, and action type. Verify logs are append-only and retained per HIPAA requirements (minimum 6 years).
|
|
18
|
+
- **Breach process**: Confirm a documented incident response plan exists for PHI breaches. Verify the plan includes notification timelines (60 days for covered entities). Check that breach detection triggers alerts to the compliance officer.
|
|
19
|
+
- **Minimum necessary**: Verify each access scope exposes only the minimum PHI fields required for the task. Confirm bulk export endpoints strip fields not needed by the consumer.
|
|
20
|
+
|
|
21
|
+
## Finance
|
|
22
|
+
|
|
23
|
+
- **No raw card data**: Verify no credit card numbers appear in logs, databases, error reports, or debug output. Confirm all card data flows through a PCI-DSS-compliant payment processor. Run `ck_validate` and check for `security.hardcoded_secret` patterns matching card-number formats.
|
|
24
|
+
- **Tokenization**: Verify stored payment references are processor tokens, not raw card numbers. Confirm token-to-card resolution only happens at the payment processor boundary.
|
|
25
|
+
- **Immutable financial records**: Confirm financial transaction rows use insert-only semantics. Verify no UPDATE or DELETE paths exist on transaction tables. Check that correction entries create new rows with reversal references rather than modifying existing records.
|
|
26
|
+
- **Segregation of duties**: Verify the same identity cannot both create and approve a financial transaction. Confirm approval workflows require a different user or service account than the initiator.
|
|
27
|
+
- **Audit trail**: Confirm every financial state change produces a signed, timestamped audit entry. Verify audit entries include before/after state for reconciliation.
|
|
28
|
+
|
|
29
|
+
## Education
|
|
30
|
+
|
|
31
|
+
- **Student-record disclosure**: Verify FERPA-compliant consent checks before any student data export. Confirm directory information opt-out is respected in all listing endpoints. Check that student IDs are not exposed in URLs or logs.
|
|
32
|
+
- **Age and consent checks**: Verify age-gating logic for accounts under 13 (COPPA). Confirm parental consent workflow is triggered before data collection for minors. Check that consent records are retained and auditable.
|
|
33
|
+
- **Access logging**: Confirm all student record access produces an audit log entry. Verify bulk access (e.g., instructor roster views) logs the scope of records accessed.
|
|
34
|
+
|
|
35
|
+
## HR
|
|
36
|
+
|
|
37
|
+
- **Candidate data segregation**: Verify candidate PII is stored separately from interview scoring data. Confirm hiring decision records reference scored rubrics, not raw candidate attributes. Check that rejected candidate data is retained per required retention periods and then purged.
|
|
38
|
+
- **No protected-attribute scoring**: Verify no model or scoring logic uses race, gender, age, religion, disability, or other protected attributes as input features. Confirm compensation algorithms use only role, level, geography, and experience. Run `ck_validate` on any scoring or ranking code.
|
|
39
|
+
- **Salary data access controls**: Verify compensation data is accessible only to roles with explicit need (HR ops, finance payroll). Confirm manager visibility is limited to direct reports. Check that salary fields are excluded from bulk export unless the caller has explicit compensation scope.
|
|
40
|
+
|
|
41
|
+
## Legal
|
|
42
|
+
|
|
43
|
+
- **Privilege isolation**: Verify attorney-client privileged documents are tagged and access-controlled to legal team only. Confirm privilege tags propagate to search indexes and export endpoints. Check that AI-generated summaries of privileged content do not leak into non-privileged contexts.
|
|
44
|
+
- **Encrypted documents**: Confirm legal documents are encrypted at rest with key management tied to legal team roles. Verify document sharing links expire and require authentication. Check that deleted documents are purged from backups within retention policy.
|
|
45
|
+
- **Retention schedule**: Verify document retention periods are configured per document type and jurisdiction. Confirm automated purge or archive runs respect legal-hold flags. Check that retention policy changes do not retroactively shorten holds on active matters.
|
|
46
|
+
|
|
47
|
+
## Marketing / Sales / Real Estate
|
|
48
|
+
|
|
49
|
+
- **Consent and unsubscribe**: Verify CAN-SPAM-compliant unsubscribe links in all marketing emails. Confirm unsubscribe requests take effect within 10 business days. Check that purchased lead lists include consent provenance metadata.
|
|
50
|
+
- **CRM or lead PII protection**: Verify CRM export endpoints strip or mask PII for non-authorized scopes. Confirm contact deletion requests propagate across all CRM integrations within the required timeframe (typically 30 days for GDPR). Check that lead scoring does not use sensitive attributes.
|
|
51
|
+
- **Fair-housing and tenant-data controls**: Verify property listing algorithms do not filter by protected neighborhood characteristics. Confirm tenant screening uses only legally permissible criteria. Check that tenant PII retention respects state-specific data destruction requirements.
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: controlkeel-governance
|
|
3
|
+
description: "Operate inside a ControlKeel-governed session. Use this before code edits, shell execution, delegation, deploy work, or any task that needs CK validation, findings, budget, proof, or routing context."
|
|
4
|
+
license: Apache-2.0
|
|
5
|
+
compatibility:
|
|
6
|
+
- codex
|
|
7
|
+
- claude-standalone
|
|
8
|
+
- claude-plugin
|
|
9
|
+
- copilot-plugin
|
|
10
|
+
- github-repo
|
|
11
|
+
- open-standard
|
|
12
|
+
allowed-tools:
|
|
13
|
+
- ck_validate
|
|
14
|
+
- ck_context
|
|
15
|
+
- ck_finding
|
|
16
|
+
- ck_memory_search
|
|
17
|
+
- ck_memory_record
|
|
18
|
+
- ck_memory_archive
|
|
19
|
+
- ck_regression_result
|
|
20
|
+
- ck_budget
|
|
21
|
+
- ck_route
|
|
22
|
+
- ck_skill_list
|
|
23
|
+
- ck_skill_load
|
|
24
|
+
- ck_cost_optimizer
|
|
25
|
+
- ck_deployment_advisor
|
|
26
|
+
- ck_outcome_tracker
|
|
27
|
+
metadata:
|
|
28
|
+
author: controlkeel
|
|
29
|
+
version: "2.0"
|
|
30
|
+
category: governance
|
|
31
|
+
ck_mcp_tools:
|
|
32
|
+
- ck_validate
|
|
33
|
+
- ck_context
|
|
34
|
+
- ck_finding
|
|
35
|
+
- ck_memory_search
|
|
36
|
+
- ck_memory_record
|
|
37
|
+
- ck_memory_archive
|
|
38
|
+
- ck_regression_result
|
|
39
|
+
- ck_budget
|
|
40
|
+
- ck_route
|
|
41
|
+
- ck_cost_optimizer
|
|
42
|
+
- ck_deployment_advisor
|
|
43
|
+
- ck_outcome_tracker
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
# ControlKeel Governance Skill
|
|
47
|
+
|
|
48
|
+
You are operating inside a **ControlKeel-governed session**. Start here whenever you need the base CK operating protocol.
|
|
49
|
+
|
|
50
|
+
## Core loop
|
|
51
|
+
|
|
52
|
+
1. Call `ck_context` at task start to load mission, risk, budget, proof, active findings, workspace context, context reacquisition, instruction hierarchy, and recent transcript state.
|
|
53
|
+
2. Call `ck_validate` before writing code, config, shell, or deploy text, and pass trust-boundary metadata when the source content came from the web, tools, skills, or mixed provenance.
|
|
54
|
+
3. If you discover a problem the scanner did not raise, call `ck_finding`.
|
|
55
|
+
4. Use `ck_memory_search` when you need explicit recall of prior decisions, checkpoints, or findings rather than relying only on the default context packet.
|
|
56
|
+
5. Use `ck_memory_record` to persist important decisions, assumptions, and operator guidance that future agents should recover.
|
|
57
|
+
6. Use `ck_memory_archive` to retire stale or superseded guidance before it keeps contaminating retrieval.
|
|
58
|
+
7. Call `ck_budget` and `ck_cost_optimizer` before expensive model or bulk operations.
|
|
59
|
+
8. Call `ck_route` before delegating sub-work to another agent.
|
|
60
|
+
9. Use `ck_deployment_advisor` to analyze stack and generate deployment templates when checking ship readiness.
|
|
61
|
+
10. Use `ck_regression_result` to record external browser or QA evidence before claiming deploy readiness.
|
|
62
|
+
11. Use `ck_outcome_tracker` to track success/failure outcomes for continuous learning.
|
|
63
|
+
12. Use `ck_skill_list` and `ck_skill_load` to activate more specific CK workflows.
|
|
64
|
+
|
|
65
|
+
## Non-negotiable rules
|
|
66
|
+
|
|
67
|
+
- Never skip `ck_validate` before repo mutations or shell execution.
|
|
68
|
+
- A blocked ruling means stop and surface the finding.
|
|
69
|
+
- A warned ruling means continue carefully and mention it to the operator.
|
|
70
|
+
- On high or critical risk, prefer smaller changes and explicit checkpoints.
|
|
71
|
+
- Before saying work is done, re-check proof, findings, and budget state.
|
|
72
|
+
|
|
73
|
+
## Quick reference
|
|
74
|
+
|
|
75
|
+
- `ck_context` — mission, task, budget, proof, memory, workspace snapshot, transcript summary, resume context
|
|
76
|
+
- `ck_validate` — governed preflight scan with trust-boundary checks
|
|
77
|
+
- `ck_finding` — persist manual findings
|
|
78
|
+
- `ck_memory_search`, `ck_memory_record`, `ck_memory_archive` — explicit typed-memory retrieval and hygiene
|
|
79
|
+
- `ck_regression_result` — import external regression evidence into proof state
|
|
80
|
+
- `ck_budget` — cost estimate / commit
|
|
81
|
+
- `ck_route` — best agent recommendation
|
|
82
|
+
- `ck_cost_optimizer` — cost optimization strategies and model comparison
|
|
83
|
+
- `ck_deployment_advisor` — repo stack detection, CI/Docker generation, DNS/SSL guide
|
|
84
|
+
- `ck_outcome_tracker` — record and review session outcomes/agent scores
|
|
85
|
+
- `ck_skill_list`, `ck_skill_load` — specialized workflow activation
|
|
86
|
+
|
|
87
|
+
## Additional resources
|
|
88
|
+
|
|
89
|
+
- For the full governed workflow, see [references/workflow.md](references/workflow.md)
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "ControlKeel Governance"
|
|
3
|
+
short_description: "Base governed workflow for CK validation, context, findings, budget, and routing."
|
|
4
|
+
brand_color: "#0f766e"
|
|
5
|
+
policy:
|
|
6
|
+
allow_implicit_invocation: true
|
|
7
|
+
dependencies:
|
|
8
|
+
tools:
|
|
9
|
+
- type: "mcp"
|
|
10
|
+
value: "controlkeel"
|
|
11
|
+
description: "ControlKeel MCP server"
|
|
12
|
+
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Governed Workflow
|
|
2
|
+
|
|
3
|
+
Use this reference with `controlkeel-governance`.
|
|
4
|
+
|
|
5
|
+
## Start
|
|
6
|
+
|
|
7
|
+
1. `ck_context` to load mission, task, risk, budget, proof summary, memory hits, workspace snapshot, and recent transcript events.
|
|
8
|
+
2. Identify whether the task is implementation, review, compliance, benchmark, or policy work.
|
|
9
|
+
3. Load a more specific CK skill if the task has a narrower workflow.
|
|
10
|
+
|
|
11
|
+
## Before mutations
|
|
12
|
+
|
|
13
|
+
1. Validate the exact code, config, shell, or text with `ck_validate`.
|
|
14
|
+
2. Respect `block` immediately.
|
|
15
|
+
3. Note `warn` in your reply and continue carefully.
|
|
16
|
+
|
|
17
|
+
## During work
|
|
18
|
+
|
|
19
|
+
1. Keep changes small.
|
|
20
|
+
2. Call `ck_budget` before expensive multi-agent or long-context work.
|
|
21
|
+
3. Use `ck_route` when another agent would be materially better.
|
|
22
|
+
4. Create a `ck_finding` entry for any issue not automatically detected.
|
|
23
|
+
|
|
24
|
+
## Before completion
|
|
25
|
+
|
|
26
|
+
1. Re-check active findings.
|
|
27
|
+
2. Re-check budget and proof state.
|
|
28
|
+
3. If the session is high or critical risk, summarize decisions and unresolved items explicitly.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: cost-optimization
|
|
3
|
+
description: "Keep a governed session within budget. Use this before long-running agent work, bulk processing, or any task where spend pressure could change the plan."
|
|
4
|
+
license: Apache-2.0
|
|
5
|
+
compatibility:
|
|
6
|
+
- codex
|
|
7
|
+
- claude-standalone
|
|
8
|
+
- claude-plugin
|
|
9
|
+
- copilot-plugin
|
|
10
|
+
- github-repo
|
|
11
|
+
- open-standard
|
|
12
|
+
metadata:
|
|
13
|
+
author: controlkeel
|
|
14
|
+
version: "2.0"
|
|
15
|
+
category: budget
|
|
16
|
+
ck_mcp_tools:
|
|
17
|
+
- ck_budget
|
|
18
|
+
- ck_context
|
|
19
|
+
- ck_route
|
|
20
|
+
- ck_cost_optimizer
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
# Cost Optimization Skill
|
|
24
|
+
|
|
25
|
+
## Budget protocol
|
|
26
|
+
|
|
27
|
+
1. Estimate before expensive work with `ck_budget`.
|
|
28
|
+
2. Prefer smaller checkpoints over one large call when spend is uncertain.
|
|
29
|
+
3. Use `ck_route` to prefer cheaper valid agents when quality permits.
|
|
30
|
+
4. When the budget is low, reduce scope and escalate to the human early.
|
|
31
|
+
5. Commit actual usage after completion if your harness is responsible for spend recording.
|
|
32
|
+
6. Use `ck_cost_optimizer` to discover savings models, caching strategies, and local model alternatives.
|
|
33
|
+
|
|
34
|
+
## Additional resources
|
|
35
|
+
|
|
36
|
+
- For estimation, warning thresholds, and split strategies, see [references/budget-playbook.md](references/budget-playbook.md)
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Cost Optimization"
|
|
3
|
+
short_description: "Budget-aware CK workflow for estimates, commits, and cheaper routing."
|
|
4
|
+
brand_color: "#7c3aed"
|
|
5
|
+
policy:
|
|
6
|
+
allow_implicit_invocation: true
|
|
7
|
+
dependencies:
|
|
8
|
+
tools:
|
|
9
|
+
- type: "mcp"
|
|
10
|
+
value: "controlkeel"
|
|
11
|
+
description: "ControlKeel MCP server"
|
|
12
|
+
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Budget Playbook
|
|
2
|
+
|
|
3
|
+
## Estimate first
|
|
4
|
+
|
|
5
|
+
- Use `ck_budget` estimate mode before expensive operations.
|
|
6
|
+
- Prefer model-based pricing inputs when you know tokens and model.
|
|
7
|
+
- Use explicit `estimated_cost_cents` when the model is unknown.
|
|
8
|
+
|
|
9
|
+
## Split and checkpoint
|
|
10
|
+
|
|
11
|
+
- Break long tasks into smaller runs.
|
|
12
|
+
- Stop after each step and reassess remaining session and rolling-24h budget.
|
|
13
|
+
|
|
14
|
+
## Escalation guidance
|
|
15
|
+
|
|
16
|
+
- If remaining daily budget is tight, pause and ask for approval before the next expensive step.
|
|
17
|
+
- If the operation is optional, defer it instead of spending the last budget headroom.
|
|
18
|
+
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: domain-audit
|
|
3
|
+
description: "Audit a session against its domain pack, especially the regulated and operations-heavy packs such as HR, legal, marketing, sales, real-estate, government, insurance, logistics, manufacturing, e-commerce, and nonprofit. Use this when domain-specific policy needs a manual pass."
|
|
4
|
+
license: Apache-2.0
|
|
5
|
+
compatibility:
|
|
6
|
+
- codex
|
|
7
|
+
- claude-standalone
|
|
8
|
+
- claude-plugin
|
|
9
|
+
- copilot-plugin
|
|
10
|
+
- github-repo
|
|
11
|
+
- open-standard
|
|
12
|
+
metadata:
|
|
13
|
+
author: controlkeel
|
|
14
|
+
version: "2.0"
|
|
15
|
+
category: domain
|
|
16
|
+
ck_mcp_tools:
|
|
17
|
+
- ck_context
|
|
18
|
+
- ck_finding
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
# Domain Audit Skill
|
|
22
|
+
|
|
23
|
+
Use this skill when the session’s domain pack drives the real risk more than generic software checks.
|
|
24
|
+
|
|
25
|
+
## Focus areas
|
|
26
|
+
|
|
27
|
+
- HR: bias, candidate data, compensation visibility
|
|
28
|
+
- Legal: privilege, retention, document handling
|
|
29
|
+
- Marketing: consent, unsubscribe, analytics PII
|
|
30
|
+
- Sales: CRM data, contact deletion, revenue visibility
|
|
31
|
+
- Real estate: fair-housing logic, tenant PII, retention
|
|
32
|
+
- Government: records retention, constituent data, approval chains
|
|
33
|
+
- Insurance: claims fairness, medical-adjacent privacy, denial review
|
|
34
|
+
- E-commerce: card scope, refunds, fraud controls
|
|
35
|
+
- Logistics: shipment custody, dispatch safety, carrier data
|
|
36
|
+
- Manufacturing: QA holds, traceability, plant safety
|
|
37
|
+
- Nonprofit: donor privacy, grant restrictions, beneficiary exports
|
|
38
|
+
|
|
39
|
+
## Additional resources
|
|
40
|
+
|
|
41
|
+
- [Domain review matrix](references/domain-review-matrix.md)
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Domain Audit"
|
|
3
|
+
short_description: "Manual domain-pack review for HR, legal, marketing, sales, and real estate."
|
|
4
|
+
brand_color: "#9333ea"
|
|
5
|
+
policy:
|
|
6
|
+
allow_implicit_invocation: true
|
|
7
|
+
dependencies:
|
|
8
|
+
tools:
|
|
9
|
+
- type: "mcp"
|
|
10
|
+
value: "controlkeel"
|
|
11
|
+
description: "ControlKeel MCP server"
|
|
12
|
+
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# Domain Review Matrix
|
|
2
|
+
|
|
3
|
+
Use this matrix when the session's domain pack drives real risk more than generic software checks.
|
|
4
|
+
For each domain, verify the listed items. Use `ck_validate` for automated pattern checks, then
|
|
5
|
+
manually verify items that require business-logic or process judgment.
|
|
6
|
+
|
|
7
|
+
## HR
|
|
8
|
+
|
|
9
|
+
- **Protected classes in scoring**: Scan job descriptions, screening logic, and ranking algorithms for protected attributes (race, gender, age, religion, disability, national origin). Use `ck_validate` on scoring code. Verify no training data features encode proxies for protected attributes.
|
|
10
|
+
- **Candidate data segregation**: Confirm candidate PII (name, email, address, phone) is stored separately from evaluation data. Verify interviewer notes reference candidate IDs, not names, in analytics. Check that rejected candidate data retention respects local regulations (typically 1-2 years, then purge).
|
|
11
|
+
- **Compensation visibility**: Verify salary bands are visible only to HR ops and authorized managers. Confirm individual compensation data requires explicit role-scoped access. Check that compensation reports aggregate to levels where individual identification is not possible.
|
|
12
|
+
- **Employment verification**: Confirm I-9 document data is stored separately from performance records. Verify work-authorization status is checked at hire and on expiration, but not used in performance or promotion logic.
|
|
13
|
+
|
|
14
|
+
## Legal
|
|
15
|
+
|
|
16
|
+
- **Privileged materials isolation**: Verify privileged documents are tagged at creation time. Confirm privilege tags propagate through search, export, and AI-summarization pipelines. Check that privilege review logs record who accessed what and when.
|
|
17
|
+
- **Retention and eDiscovery**: Confirm retention schedules are configured per document type and jurisdiction. Verify automated retention enforcement skips documents on legal hold. Check that expired document purge produces a destruction certificate.
|
|
18
|
+
- **Conflict checking**: Verify new matter intake runs conflict-of-interest checks against existing clients. Confirm conflict check results are logged and require affirmative clearance before work begins.
|
|
19
|
+
|
|
20
|
+
## Marketing
|
|
21
|
+
|
|
22
|
+
- **Opt-in and unsubscribe controls**: Verify email and messaging consent is captured with timestamp, source, and scope. Confirm consent records are immutable once created. Check that opt-out requests propagate to all downstream systems within 72 hours.
|
|
23
|
+
- **Analytics PII**: Verify analytics pipelines do not store raw email addresses, phone numbers, or device IDs in user-facing dashboards. Confirm PII used for attribution is hashed or tokenized before storage. Check that audience segment exports exclude individual-level PII unless the consumer has explicit consent scope.
|
|
24
|
+
- **Advertising targeting**: Verify ad targeting does not use sensitive categories (health condition, financial status, sexual orientation, religion). Confirm lookalike audiences exclude protected-attribute proxies.
|
|
25
|
+
|
|
26
|
+
## Sales
|
|
27
|
+
|
|
28
|
+
- **CRM contact handling**: Verify CRM export endpoints mask or strip PII for non-authorized scopes. Confirm contact deletion requests propagate to all integrated systems within 30 days. Check that lead enrichment data sources comply with data-minimization principles.
|
|
29
|
+
- **Revenue and quota auditability**: Verify pipeline and forecast data is accessible only to roles with explicit need. Confirm individual deal values are not exposed in team-level dashboards without aggregation. Check that commission calculations are auditable and traceable to signed terms.
|
|
30
|
+
- **Contract handling**: Verify contract documents are encrypted at rest with access restricted to deal team and legal. Confirm contract metadata is stored separately from contract text in analytics. Check that expired contracts are archived per retention policy.
|
|
31
|
+
|
|
32
|
+
## Real Estate
|
|
33
|
+
|
|
34
|
+
- **Fair-housing violations blocked**: Verify property listing algorithms do not filter or sort by neighborhood demographic composition. Confirm advertising copy does not contain discriminatory language. Check that recommendation engines do not use protected-class data.
|
|
35
|
+
- **Tenant data protection**: Verify tenant application data (SSN, income, criminal history) is encrypted at rest and purged after the decision period. Confirm screening results are shared only with authorized leasing agents. Check that tenant payment history is accessible only to property management roles.
|
|
36
|
+
- **Retention controls**: Verify lease documents are retained per state-specific requirements (typically 7 years after lease termination). Confirm tenant dispute records are retained for the statute of limitations period.
|
|
37
|
+
|
|
38
|
+
## Government / Public Sector
|
|
39
|
+
|
|
40
|
+
- **Records retention and holds**: Verify all official records follow the jurisdiction's retention schedule. Confirm record deletion requires documented authorization. Check that records requests (FOIA, public records) are processable within statutory deadlines.
|
|
41
|
+
- **Benefits and licensing fairness**: Verify benefits eligibility logic does not use citizenship-adjacent shortcuts as proxies for protected attributes. Confirm licensing decisions follow published criteria and are auditable. Check that automated scoring in case management is explainable and reviewable.
|
|
42
|
+
- **Approval chains**: Verify procurement and policy decisions follow required approval chains. Confirm approval delegation is documented and auditable.
|
|
43
|
+
|
|
44
|
+
## Insurance / Claims
|
|
45
|
+
|
|
46
|
+
- **Claims fairness**: Verify claim adjudication logic does not use protected attributes as rating or denial factors. Confirm model-based pricing or underwriting decisions are explainable. Check that denial letters include specific reason codes and appeal instructions.
|
|
47
|
+
- **Medical-adjacent privacy**: Verify health-related claims data is treated with HIPAA-equivalent protections even when not technically PHI. Confirm medical records access is limited to claims adjusters with active case assignment.
|
|
48
|
+
- **Denial review**: Verify denied claims undergo secondary review before finalization. Confirm appeal timelines are tracked and enforced. Check that appeal outcomes are logged with reason and reviewer identity.
|
|
49
|
+
|
|
50
|
+
## E-commerce / Retail
|
|
51
|
+
|
|
52
|
+
- **Card and checkout data**: Verify cardholder data environment is segmented from general application infrastructure. Confirm no raw PANs are stored in logs, databases, or error tracking. Check that PCI-DSS self-assessment is completed annually.
|
|
53
|
+
- **Refund and chargeback controls**: Verify refund authorization requires role-appropriate approval for amounts exceeding defined thresholds. Confirm refund processing produces immutable audit entries. Check that refund fraud detection is active and calibrated.
|
|
54
|
+
- **Fraud scoring**: Verify order fraud scoring runs before payment capture. Confirm fraud review queues are staffed to meet response-time SLAs. Check that false-positive rates are monitored.
|
|
55
|
+
|
|
56
|
+
## Logistics / Supply Chain
|
|
57
|
+
|
|
58
|
+
- **Chain-of-custody integrity**: Verify chain-of-custody records are immutable once created. Confirm custody transfers produce signed, timestamped audit entries. Check that custody gaps trigger alerts for investigation.
|
|
59
|
+
- **Dispatch and hazmat safety**: Verify dispatch routing does not assign drivers to routes exceeding hours-of-service limits. Confirm hazardous-material routing follows DOT restrictions. Check that safety interlock bypasses require explicit review and are logged.
|
|
60
|
+
- **Carrier data**: Verify carrier insurance and safety ratings are current before load assignment. Confirm carrier PII is not exposed in shipper-facing dashboards.
|
|
61
|
+
|
|
62
|
+
## Manufacturing / Quality
|
|
63
|
+
|
|
64
|
+
- **QA holds and recall traces**: Verify quality-hold decisions are immutable and require documented justification. Confirm held inventory is physically and logically segregated from shippable stock. Check that hold releases require authorized sign-off with documented corrective action. Verify lot and serial traceability from raw material through finished goods shipment.
|
|
65
|
+
- **Safety interlocks**: Verify safety-critical system changes go through management-of-change review. Confirm incident reports are retained per OSHA requirements (5 years for records, 30 years for exposure records). Check that safety interlock bypasses cannot occur silently in automation.
|
|
66
|
+
|
|
67
|
+
## Nonprofit / Grants
|
|
68
|
+
|
|
69
|
+
- **Donor payment isolation**: Verify donor records are not sold or shared outside the organization's stated privacy policy. Confirm anonymous donation options preserve donor identity from all internal reporting except compliance-required access. Check that donor communication preferences are respected across all channels.
|
|
70
|
+
- **Grant restrictions**: Verify restricted funds are tracked separately from general operating funds. Confirm grant spending reports match restricted-purpose documentation. Check that restricted fund balances are visible to finance and grant management roles only.
|
|
71
|
+
- **Beneficiary data**: Verify beneficiary data exports strip or mask PII unless the consumer has explicit authorization. Confirm bulk beneficiary data transfers use encrypted channels. Check that beneficiary consent for data sharing is documented and current.
|