Menu
Decision framework for determining which platform capabilities a feature needs (Quota, Insights, Telemetry, Activity). Use when planning a new feature to assess which capabilities apply.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Covers GitHub conventions for pull requests, issues, and comments including linking, language style, formatting, and callout syntax. Use when creating PRs, writing issues, or posting comments on Datum Cloud repositories.
Turn raw engineering notes, PR/issue links, commit messages, or a one-line feature description into a changelog entry for Datum Cloud's GitHub Discussions Changelog category: a benefit-led title plus a markdown body, drafted for users and ready to hand off for final capture and publish. Use when someone says "write a changelog entry", "announce this in the changelog", or "post this to the changelog discussions" — this is the community-facing changelog POST, not the Keep a Changelog release file (that lives in `gtm-templates`).
Provides templates for go-to-market communications including blog posts, changelogs, social media, and enablement briefs. Use when writing launch announcements or marketing content.
Create a new GitHub release. Verifies CI is green on the release commit and refreshes the third-party NOTICE file before tagging, determines the next version from the latest tag, summarizes merged PRs since the last release, drafts release notes in the established style, and publishes via gh release create. Works for any datum-cloud service repository.
Scan a project repository for strict AGPL-3.0 license compliance across Go, Rust, and JavaScript/React codebases. Use this skill whenever the user asks to check, audit, verify, or enforce AGPL license compliance on a project, repo, or codebase. Triggers on phrases like "check agpl compliance", "audit license headers", "is this project agpl compliant", "scan for license headers", "check my license files", "agpl audit", or any request involving ensuring a project is properly licensed under AGPL. Always use this skill — don't wing AGPL compliance checks from general knowledge.
Covers producing weekly operational reports for the Datum AI Edge. Use when asked for an ops review, traffic report, latency analysis, provisioning report, or edge performance summary. Guides metric queries, anomaly detection, and publishing to datum-cloud/engineering.
| name | capability-index |
| description | Decision framework for determining which platform capabilities a feature needs (Quota, Insights, Telemetry, Activity). Use when planning a new feature to assess which capabilities apply. |
| user-invocable | false |
This skill provides a decision framework for determining which platform capabilities a feature needs.
| Capability | Question to Ask | When to Use |
|---|---|---|
| Quota | What needs limits to prevent abuse? | Resource consumption |
| Insights | What can the platform detect that users can't? | Proactive issue detection |
| Telemetry | What do operators need to observe? | Debugging and SLOs |
| Activity | What actions need to be auditable? | Compliance and security |
| Feature Type | Likely Capabilities |
|---|---|
| New resource type | All four |
| New API operation | Activity, Telemetry |
| UI feature only | Telemetry (maybe) |
| Configuration change | Activity |
| Performance improvement | Telemetry |
Skip quota if: The resource is inherently limited by other means or has no abuse potential.
Skip insights if: Issues are immediately obvious to users or no early warning is possible.
Note: Insights uses a policy-driven model—services define InsightPolicy resources with CEL expressions that detect issues. No code changes are required to emit insights.
Skip telemetry if: The feature has no runtime behavior to observe.
Skip activity if: The action has no security or compliance implications.
Note: Activity uses a policy-driven model—services define ActivityPolicy resources that translate audit logs and Kubernetes events into human-readable summaries. No code changes are required to emit activities.
Read capability-activity/consuming-timelines.md for how to expose activity timelines to users via CLI, UI, or API.
Use this template:
## Platform Capability Assessment
### Quota
- **Applies**: Yes/No
- **Rationale**: Why or why not
- **If yes**: Dimensions to limit, tier defaults
### Insights
- **Applies**: Yes/No
- **Rationale**: Why or why not
- **If yes**: InsightPolicy rules to create, CEL conditions to evaluate
### Telemetry
- **Applies**: Yes/No
- **Rationale**: Why or why not
- **If yes**: Metrics, traces, logs needed
### Activity
- **Applies**: Yes/No
- **Rationale**: Why or why not
- **If yes**:
- Resource kinds needing policies
- Events to emit from controller (reason codes)
- Key operations to surface in timelines
Almost always needs all four:
Usually needs:
Usually skips:
Usually needs:
Usually skips:
capability-quota — Detailed quota integrationcapability-insights — Detailed insights integrationcapability-telemetry — Detailed telemetry integrationcapability-activity — Detailed activity integration