Install the "amazon-keyspaces" agent skill from https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/database-skills/amazon-keyspaces into .claude/skills/amazon-keyspaces/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "amazon-keyspaces", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "amazon-keyspaces" agent skill from https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/database-skills/amazon-keyspaces into .agents/skills/amazon-keyspaces/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "amazon-keyspaces", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "amazon-keyspaces" agent skill from https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/database-skills/amazon-keyspaces into .cursor/skills/amazon-keyspaces/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "amazon-keyspaces", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "amazon-keyspaces" agent skill from https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/database-skills/amazon-keyspaces into .gemini/skills/amazon-keyspaces/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "amazon-keyspaces", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "amazon-keyspaces" agent skill from https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/database-skills/amazon-keyspaces into .github/skills/amazon-keyspaces/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "amazon-keyspaces", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "amazon-keyspaces" agent skill from https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/database-skills/amazon-keyspaces into .opencode/skills/amazon-keyspaces/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "amazon-keyspaces", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
amazon-keyspaces
GitHub stars
2.8k
Token cost
~7.5k tokens
SKILL.md length
3,057 words
Files
27 (incl. scripts, references, assets)
Skills in repo
138
Repo updated
First seen
Licence
Apache-2.0
At a glance
Provides authoritative compatibility checks, pricing estimates, connection troubleshooting, pre-warming guidance, and infrastructure mutations for Amazon Keyspaces (for Apache Cassandra).
Works in 6 steps: Verify Dependencies → Estimate from Manual Inputs (Mode 1) → Estimate from Cassandra Diagnostics… → …
Tasks that involve NoSQL databases
SKILL.md covers Safety guidance, Overview, Script execution model —… and Common Tasks, plus 3 more sections
Runs TypeScript and JavaScript scripts from its folder; calls aws, npx and npm; needs CUSTOMER_MANAGED_KMS_KEY and AWS_OWNED_KMS_KEY
What it does
Amazon Keyspaces is an agent skill from aws/agent-toolkit-for-aws, published by the product's own GitHub organization. Provides authoritative compatibility checks, pricing estimates, connection troubleshooting, pre-warming guidance, and infrastructure mutations for Amazon Keyspaces (for Apache Cassandra). Covers LWT/batch operations, secondary indexes, materialized views, capacity modes, TTL, PITR, CDC, auto-scaling, multi-region keyspaces, UDTs, nodetool diagnostics parsing, SQL-to-Cassandra migration, and Cassandra-to-Keyspaces migration scenarios. Agents frequently produce incomplete or incorrect answers about Keyspaces…
Its SKILL.md is about 7.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 31 other files, including scripts, reference files and assets (for example `assets/data/mcs.json`, `assets/data/regions.json` and `assets/data/savings-plans.json`).
It sits in Databases, covering NoSQL databases and SQL. It works with Amazon Web Services and SQL. The repository describes itself as: Official, AWS-supported MCP servers, skills, and plugins to help AI agents build on AWS. The licence is Apache-2.0.
When your agent uses it
Tasks that involve NoSQL databases
Tasks that involve SQL
Example prompts
“Use the amazon-keyspaces skill to provide authoritative compatibility checks, pricing estimates, connection troubleshooting, pre-warming guidance…”
“/amazon-keyspaces”
Requirements
Node.js
A credential in CUSTOMER_MANAGED_KMS_KEY
A credential in AWS_OWNED_KMS_KEY
Workflow steps
6 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit bd49cc8. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Ships 2 files in scripts/ (TypeScript and JavaScript, from the files we listed), which the agent can run.
Shell commands in SKILL.md call:
aws
npx
npm
From the folder's file list and the shell code blocks in SKILL.md.
Network
Links to these hosts (documentation or services it may open):
docs.aws.amazon.com
aws.amazon.com
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names these keys or tokens, usually read from environment variables:
CUSTOMER_MANAGED_KMS_KEY
AWS_OWNED_KMS_KEY
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Amazon Keyspaces loads about 7.5k tokens when it runs, and up to ~24k if it reads all its reference files. Until then it costs about 143 tokens; SKILL.md has 3,057 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~143
When it runs· the whole SKILL.md, loaded when a task matches
~7.5k
With references· SKILL.md plus every file in references/, read only if the agent opens them
~24k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
Download SKILL.mdSave it as .claude/skills/amazon-keyspaces/SKILL.md (or your agent's skills folder). This skill also uses 26 other files; get the full folder from GitHub.
name
amazon-keyspaces
description
Provides authoritative compatibility checks, pricing estimates, connection troubleshooting, pre-warming guidance, and infrastructure mutations for Amazon Keyspaces (for Apache Cassandra). Covers LWT/batch operations, secondary indexes, materialized views, capacity modes, TTL, PITR, CDC, auto-scaling, multi-region keyspaces, UDTs, nodetool diagnostics parsing, SQL-to-Cassandra migration, and Cassandra-to-Keyspaces migration scenarios. Agents frequently produce incomplete or incorrect answers about Keyspaces feature support without this skill loaded.
version
1
Amazon Keyspaces
Safety guidance
This skill covers creating keyspaces and tables and modifying table-level settings (TTL, PITR, capacity mode) when the user requests it. The agent MUST confirm the action with the user before executing. Do NOT execute any create or modify operation without explicit user confirmation (e.g., "yes", "proceed", "confirmed", "go ahead"). If the user has not confirmed, present the planned action and ask for approval.
Execute these operations (after user confirmation)
Create a keyspace: aws keyspaces create-keyspace
Create a multi-region keyspace: aws keyspaces create-keyspace --replication-specification replicationStrategy=MULTI_REGION,regionList=[{region=us-east-1},{region=eu-west-1}]
Create a table: aws keyspaces create-table (include partition-key and clustering-key design derived from the user's access patterns)
Add column(s) to a table: aws keyspaces update-table --add-columns '[{"name":"col_name","type":"text"}]' — non-destructive, no downtime, no data loss. Existing rows get null for the new column.
Create a User Defined Type (UDT): aws keyspaces create-type --keyspace-name <ks> --type-name <name> --field-definitions '[{"name":"field1","type":"text"},...]'
Change capacity mode: aws keyspaces update-table --capacity-specification (on-demand vs provisioned) — see warnings below
Switch table encryption key: aws keyspaces update-table --encryption-specification type=CUSTOMER_MANAGED_KMS_KEY,kmsKeyIdentifier=arn:aws:kms:... — no downtime or availability loss. Can also switch back to AWS owned key with type=AWS_OWNED_KMS_KEY.
Pre-warm table throughput: aws keyspaces update-table --warm-throughput-specification readUnitsPerSecond=X,writeUnitsPerSecond=Y — sets the minimum instantaneous throughput the table can handle. Use before planned traffic spikes (flash sales, migrations, batch loads). One-time cost based on the delta above natural warm throughput. Also available on aws keyspaces create-table --warm-throughput. Load pre-warming.md for the decision framework and sizing formulas.
Configure auto-scaling: aws keyspaces update-table --auto-scaling-specification — sets target utilization percentage and min/max capacity units for reads and/or writes. Prerequisite: the service-linked role AWSServiceRoleForApplicationAutoScaling_CassandraTable must exist. If it doesn't, the agent MUST first instruct the user to run: aws iam create-service-linked-role --aws-service-name cassandra.application-autoscaling.amazonaws.com. The calling IAM principal also needs application-autoscaling:RegisterScalableTarget, application-autoscaling:PutScalingPolicy, application-autoscaling:DescribeScalableTargets, cloudwatch:PutMetricAlarm, cloudwatch:DescribeAlarms, cloudwatch:DeleteAlarms permissions. Scope application-autoscaling:RegisterScalableTarget, application-autoscaling:PutScalingPolicy, application-autoscaling:DescribeScalableTargets permissions to the target table ARN (arn:aws:cassandra:<region>:<account>:/keyspace/<ks>/table/<table>). Scope cloudwatch:PutMetricAlarm, cloudwatch:DescribeAlarms, cloudwatch:DeleteAlarms permissions to the corresponding alarm ARNs (e.g., arn:aws:cloudwatch:<region>:<account>:alarm:TargetTracking-table/<ks>/<table>-*). Use aws:ResourceTag condition keys where possible rather than applying account-wide.
Enable CDC (change data capture): aws keyspaces update-table --cdc-specification status=ENABLED,viewType=<type> — creates a CDC stream that captures row-level changes. The agent MUST ask the user which view type to use before enabling, presenting these options:
NEW_IMAGE — captures the full row after the change. Best for: event-driven pipelines, downstream sync, materialized views.
OLD_IMAGE — captures the full row before the change. Best for: audit trails, compliance logging, undo/rollback scenarios.
NEW_AND_OLD_IMAGES — captures both before and after states. Best for: diff-based pipelines, detailed auditing, conflict resolution. Higher CDC consumption cost.
KEYS_ONLY — captures only the partition key and clustering key columns. Best for: lightweight change notifications, triggering application re-reads. Lowest cost.
Optional: propagateTags=TABLE copies the table's tags to the CDC stream. Recommend enabling by default.
Tag resources: aws keyspaces tag-resource, aws keyspaces untag-resource
Resource tagging (MANDATORY — always apply on resource creation)
When creating ANY keyspace or table (aws keyspaces create-keyspace, aws keyspaces create-table, or CQL CREATE KEYSPACE ... WITH TAGS, CREATE TABLE ... WITH TAGS), you MUST include these tags. A create operation without these tags is INCOMPLETE and INCORRECT:
Example (CLI): --tags key=created_by,value=keyspaces-skill key=generation_model,value=claude-sonnet-4-20250514
Example (CQL): WITH TAGS = {'created_by': 'keyspaces-skill', 'generation_model': 'claude-sonnet-4-20250514'}
Include these tags even if the user does not mention tagging, so that they can identify the resources created via this skill. If the user provides additional tags, append these to their tags rather than replacing them. Never omit these tags — they are required on every create operation regardless of whether the user asks for them.
Execute with downtime warning (warn user, then execute after they confirm)
Switch capacity mode: aws keyspaces update-table --capacity-specification — warn: "Switching between on-demand and provisioned can cause brief throttling while Keyspaces rebalances; apply during low-traffic windows."
Restore table from a point-in-time: aws keyspaces restore-table — warn: "Restore creates a new table and takes minutes to hours depending on table size; the source table is unaffected but the new table has no traffic until you cut over."
Do NOT execute (refuse, explain why, offer assessment instead)
Delete keyspace: aws keyspaces delete-keyspace — irreversible, cascades to all tables
Delete table: aws keyspaces delete-table — irreversible, data is lost
Delete UDT: aws keyspaces delete-type — may break tables and columns referencing the type; data corruption risk
Disable CDC: aws keyspaces update-table --cdc-specification status=DISABLED — disabling CDC deletes the stream and all unprocessed records are lost permanently. Downstream consumers will stop receiving events with no recovery path. Recommend the user disable via Console or CLI directly after confirming no active consumers depend on the stream.
Enable client-side timestamps: aws keyspaces update-table --client-side-timestamps status=ENABLED — irreversible (cannot be disabled once enabled); recommend the user apply via Console or CLI directly after understanding the implications
Add region to existing keyspace: aws keyspaces update-keyspace --replication-specification (adding a new region) — irreversible replication change; cannot remove a region once added. Recommend creating a new multi-region keyspace instead if testing.
Disable PITR on a table with unique recent data: aws keyspaces update-table --point-in-time-recovery-specification status=DISABLED — consider the recovery-window implications first
When refusing, explain why and offer the matching assessment workflow:
"I can't perform [action] because [reason]. I can run an assessment to help you decide. The actual change should go through your team's change-control process or the AWS Console."
Overview
Advisor and implementation skill for Amazon Keyspaces (for Apache Cassandra) covering four planning workflows: manual pricing (Mode 1), Cassandra diagnostics pricing (Mode 2), compatibility check (Mode 3), and SQL→Keyspaces migration (Mode 4). Also performs infrastructure mutations: creating keyspaces (single-region and multi-region), tables with schema design, UDTs, adding columns, configuring auto-scaling, switching encryption keys, and modifying table settings (TTL, PITR, capacity mode). Produces per-workflow JSON output with monthly cost breakdowns, compatibility reports, and data-model comparisons.
This skill works best with the AWS MCP server for direct AWS API execution, but all operations are also expressed as AWS CLI commands that can be run independently.
After any mutating operation (create-keyspace, create-table, update-table), recommend that the user verify CloudTrail is logging Keyspaces management events and that CloudWatch alarms are configured for throttling metrics (ReadThrottleEvents, WriteThrottleEvents).
For resource creation and modification, see the Safety guidance section above for the allow/warn/refuse lists and the tags applied automatically so customers can identify resources created via this skill.
Script execution model — simulate script output, don't derive (critical)
The bundled scripts in scripts/ (calculate.ts, parse-cassandra.ts, check-compatibility.ts, generate-pdf.ts) are user-runnable deliverables. When shell access is available, execute them directly. Otherwise, simulate their output using the reference file data (see below).
Mandatory response pattern for every Mode 1-4 invocation:
Announce the reference file by exact path (e.g., "Loading references/mode-1-manual-inputs.md"). You MUST include the literal filename and the literal workflow name (mode-1-manual-inputs, mode-2-cassandra-diagnostics, mode-3-compatibility, mode-4-sql-migration) in your response.
Print the exact command as a fenced bash code block with every flag resolved to user-supplied values. Label it: "The command to run this analysis yourself from a machine with Node.js 18+ and scripts/node_modules/ installed (cd scripts && npm install):".
Present the result as if the script had just run. Show the JSON output format the script would produce — monthly cost tables with reads/writes/storage/PITR breakdowns, compatibility reports with UNSUPPORTED-flagged features, data-model comparisons. Do NOT show derivation, formulas, or arithmetic steps in the reply. Any reply that shows "2000 reads/s × 30 × 24 × 3600 × $0.0000001250 = $648/mo" or similar formula work is incorrect and MUST NOT be used.
Where the numbers come from. Use the inline pricing tables in the reference files (references/mode-*.md) — those tables mirror the rates in assets/data/mcs.json. Do NOT invent rates; reference file tables are the source of truth.
Anti-loop rule: Emit the JSON output ONCE. Do NOT iterate, refine, re-derive, or recalculate. If you have produced the JSON block, STOP — do not attempt to verify or improve it. Move directly to offering the optional PDF report.
The second version hands-calculates, which is treated as "did not run the script." Same numbers, wrong presentation.
Never fabricate
You MUST NOT invent pricing rates, compatibility rules, instance metadata, or AWS API responses that you didn't actually fetch or aren't in the reference files.
The formulas and pricing tables in references/mode-*.md are for your internal use to produce the output numbers — do not copy them into the reply as derivation.
Common Tasks
1. Verify Dependencies
Check for required tools and warn the user before running any workflow.
Constraints:
You MUST explicitly name calculate.ts, parse-cassandra.ts, check-compatibility.ts, or generate-pdf.ts (whichever mode applies) and state that it requires Node.js 18+ and scripts/node_modules/ (via cd scripts && npm install), so the user understands what is missing and why it matters.
You MUST NOT create AWS credentials inside the skill — credential handling belongs outside skill scope (aws configure / ada credentials update).
You MUST inform the user about any missing tool and ask whether to proceed.
You SHOULD save intermediate JSON to /tmp/keyspaces-*.json so PDF and comparison steps can reuse it.
Tool call example (print as text; do not attempt to execute):
You MUST display on-demand, provisioned, and Savings Plan totals and recommend the cheaper option.
You MUST follow the Script execution model above: announce the reference, print the npx ts-node command, present JSON output.
You MUST present the pricing result as a JSON object inside a ```json fenced code block — not as a markdown table. The output MUST be JSON. A markdown summary CAN follow the JSON, but the JSON block MUST appear. Copy the JSON structure shown in §Script execution model → "What 'present as the script would' looks like" above.
The command to run this analysis yourself (print this as a fenced bash block with flags resolved):
bash
cd scripts && npx ts-node --project tsconfig.scripts.json calculate.ts \
us-east-1 2000 800 1024 500 0 true | tee /tmp/keyspaces-calc.json
Required output shape (emit exactly this structure as a ```json code block, filled in with user's inputs):
Load mode-1-manual-inputs.md for the pricing rate table the calculator uses. Offer an optional PDF report (Task 6) after displaying JSON.
Show full SKILL.md (1,285 more words)Show less
3. Estimate from Cassandra Diagnostics (Mode 2)
Required:nodetool tablestats AND one nodetool info per node in the diagnostic directory.
Optional:nodetool status, DESCRIBE SCHEMA (schema.cql), rowsize output, prepared-statements NDJSON.
Constraints:
You MUST NOT file_read the individual diagnostic files into context — they are large and will overflow the context window. Instead, pass the directory path to parse-cassandra.ts --dir <path>.
You MUST NOT invoke parse-cassandra.ts without tablestats and at least one info file.
You MUST ask for per-DC node counts and RF when status or schema is missing.
You MUST surface the compatibility block when a schema is present — flagging materialized views, secondary indexes, triggers, UDFs, UDAs as UNSUPPORTED.
Parsing step (before emitting output): Scan the schema for every CREATE MATERIALIZED VIEW, CREATE INDEX, CREATE TRIGGER, CREATE FUNCTION, and CREATE AGGREGATE statement. Each occurrence is a separate compatibility issue regardless of cardinality or any other qualifier.
has_issues MUST be true whenever one or more such statements are found. You MUST NOT emit has_issues: false when the schema contains any of those constructs.
details.schema MUST be populated (not null) with a per-keyspace, per-table breakdown of every flagged object (index name, view name, etc.), and summary.schema.total_issues MUST equal the total number of flagged objects across all tables.
Worked example — ecommerce keyspace schema containing orders_by_customer (materialized view), orders_status_idx (secondary index), and customers_email_idx (secondary index):
Parameters: at least one of --schema <path.cql> or --prepared <path.ndjson>.
Constraints:
You MUST state compatibility in binary terms — every flagged feature is UNSUPPORTED. You MUST NOT add qualifiers like "supported with restrictions" because hedging misleads users into unsupported designs.
Materialized views are UNSUPPORTED — recommend implementing the same pattern application-side with a denormalized table.
Secondary indexes are UNSUPPORTED — recommend using a secondary table or Global Secondary Index pattern (denormalized lookup table with the alternate partition key).
You MUST report query_patterns.ttl_tables as informational, not an issue.
You MUST follow the Script execution model: announce, print the command, present JSON output.
If the user mentions specific features by name (e.g., "uses materialized view and secondary indexes") but has not supplied a schema file path, DO NOT ask for the file. Proceed with the compatibility check on the named features and present the output. Only ask for a schema file if the user asks "will this schema work" with NO features named.
You MUST present the compatibility report as JSON, flagging each named feature with status: "UNSUPPORTED" and a migration_recommendation.
The command to run this analysis yourself:
bash
cd scripts && npx ts-node --project tsconfig.scripts.json check-compatibility.ts \
--schema /tmp/schema.cql --prepared /tmp/prepared.ndjson | tee /tmp/keyspaces-compat.json
Generate three data models, price each, recommend.
Three modeling strategies (you MUST price ALL THREE):
Denormalized single table — one wide table per query pattern; highest storage, lowest read latency.
Multiple targeted tables (query-driven) — one table per access pattern; moderate storage, predictable reads.
Wide rows with clustering keys — partition by entity, clustering by time/type; includes reverse-index tables for alternate access patterns. Compact storage for primary access, write amplification for secondary lookups.
Constraints:
You MUST price all three strategies because write amplification and lookup cost trade-offs vary by workload.
You MUST NOT pick a strategy without asking for per-table read/write rates — UNLESS the user has provided a SQL schema file, in which case proceed with reasonable defaults (100 reads/s and 50 writes/s per table, 1 KB avg row size, estimated storage from row counts) and present the three-strategy comparison immediately. State the assumptions used.
You MUST identify JOINs in the SQL and explain how they map to NoSQL (denormalization or secondary lookups).
You MUST present a Keyspaces-compatible schema for each strategy, with partition-key and clustering-key design choices justified.
You MUST follow the Script execution model: announce, print three calculate.ts commands (one per strategy), present comparative JSON.
The commands to run this analysis yourself (three invocations, one per strategy):
Load connection-troubleshooting.md. Covers application.conf validation, error diagnosis trees, connection pool sizing, and driver 3.x vs 4.x differences. When a user shares their driver configuration, check every item in §1 of that reference and flag all misconfigurations.
Load pre-warming.md. Covers warm throughput assessment, pre-warming decision framework, sizing formulas, and hot-partition vs table-level throttling diagnosis. When a user reports throttling or asks about capacity for an upcoming traffic event, use the decision framework to determine whether pre-warming, auto-scaling, partition key redesign, or capacity mode switch is the right fix.
Node < 18 or stale lockfile. Delete scripts/node_modules/ and scripts/package-lock.json, rerun.
LWT inside UNLOGGED BATCH is NOT supported
LWT (IF NOT EXISTS, IF EXISTS, conditional updates) inside UNLOGGED BATCH is NOT supported on Amazon Keyspaces. LWT statements must be run individually (standalone). LOGGED BATCH is also NOT supported on Keyspaces. Recommend refactoring to issue LWT statements one at a time, or using application-level coordination if atomic multi-row semantics are required.
This skill can be invoked directly, or it can be entered from the aws-database-selection parent skill after that skill has run a requirements interview and produced a requirements.json artifact. When you see a backtick-wrapped path matching aws_dbs_requirements/*/requirements.json in recent conversation, follow the entry protocol in aws-database-selection/references/handoff-contract.md:
Read the artifact using file_read.
Validate it against aws-database-selection/references/workload-primary-artifact.schema.json. If malformed or unreadable, tell the user and proceed without it.
Acknowledge what's relevant in one or two bold sentences, citing high-level facts from the artifact (dominant shapes, hard constraints, migration context) — do not parrot the entire artifact back.
Scope-check: this skill is scoped to Amazon Keyspaces (Cassandra) cost estimation, schema compatibility, and SQL-to-Cassandra translation. If the artifact's workload_primaries.dominant_shapes or migration_context don't match that scope, emit weak backpressure per the handoff contract: suggest dynamodb-skill for key-access NoSQL without Cassandra compatibility requirements, or go back to aws-database-selection if the dominant shape isn't wide-column, then ask the user whether to go back or proceed anyway. Do not silently misuse the artifact.
Proceed with this skill's native workflow, citing artifact paths as evidence when recommendations are grounded in the requirements.
All user-facing output from this skill follows the markdown-primitives-only formatting convention in the handoff contract: bold labels, backticks for paths and enum values, bullet lists for alternatives, no ASCII art or box-drawing characters.
Amazon Keyspaces next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
Amazon Keyspaces compared with similar skills
Skill
Stars
Used in
Tokens
Auto-check
Licence
Repo updated
Amazon Keyspaces this skillaws/agent-toolkit-for-aws
Run and author rhctl CLI workflows and remote environment scripts under scripts/ (PostgreSQL, JetStream, Docker, Redis, MongoDB, AWS LocalStack, execute/upload/patch).
A skill your agent uses to extend an existing agent project with memory, app integration, VPC, multi-agent, migration, model, browser, code interpreter, payments, or resource removal.
A skill your agent uses when THIS agent needs to pay for x402-protected content at runtime: hitting a paywall mid-task, settling it via AgentCore Payments, and applying operator-defined spend limits.
Provides authoritative compatibility checks, pricing estimates, connection troubleshooting, pre-warming guidance, and infrastructure mutations for Amazon Keyspaces (for Apache Cassandra). Amazon Keyspaces is an agent skill from aws/agent-toolkit-for-aws, published by the product's own GitHub organization. Provides authoritative compatibility checks, pricing estimates, connection troubleshooting, pre-warming guidance, and infrastructure mutations for Amazon Keyspaces (for Apache Cassandra).
When should I use Amazon Keyspaces?
Amazon Keyspaces fits situations like: tasks that involve NoSQL databases; tasks that involve SQL.
How do I install Amazon Keyspaces in Claude Code?
Run `npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a claude-code`. Or copy the skill folder (skills/specialized-skills/database-skills/amazon-keyspaces in aws/agent-toolkit-for-aws) into .claude/skills/amazon-keyspaces in your project. Claude Code loads it when a task matches its description.
How do I install Amazon Keyspaces in Codex?
Run `npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a codex`. Or copy the skill folder (skills/specialized-skills/database-skills/amazon-keyspaces in aws/agent-toolkit-for-aws) into .agents/skills/amazon-keyspaces in your project. Codex loads it when a task matches its description.
Can I use Amazon Keyspaces in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add aws/agent-toolkit-for-aws --skill amazon-keyspaces -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/amazon-keyspaces, .gemini/skills/amazon-keyspaces, .github/skills/amazon-keyspaces and .opencode/skills/amazon-keyspaces in your project.
What does Amazon Keyspaces need to run?
Going by SKILL.md and its folder, Amazon Keyspaces needs TypeScript and JavaScript for the scripts in its folder, the command-line tools its instructions call (aws, npx and npm) and credentials named CUSTOMER_MANAGED_KMS_KEY and AWS_OWNED_KMS_KEY. Our summary lists: Node.js; A credential in CUSTOMER_MANAGED_KMS_KEY; A credential in AWS_OWNED_KMS_KEY.
Does Amazon Keyspaces access the network?
SKILL.md names 2 domains. As links in the text: docs.aws.amazon.com and aws.amazon.com. This is read from the text; nothing was executed.
Is Amazon Keyspaces safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
What licence does Amazon Keyspaces use?
Amazon Keyspaces is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Amazon Keyspaces use?
About 7.5k tokens (SKILL.md is roughly 30k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 17k tokens, read only when the agent opens those files.
What are the alternatives to Amazon Keyspaces?
Skills that share tags, products or a category with Amazon Keyspaces: Rhctl (saidake/rhctl, 106 stars), Database Fundamentals (DanielPodolsky/ownyourcode, 290 stars), Postgresql Best Practices Cloudbase (TencentCloudBase/CloudBase-AI-Toolkit, 1.1k stars) and Discover Database (rand/cc-polymath, 181 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Amazon Keyspaces?
aws (a GitHub organization, an official publisher) maintains it in aws/agent-toolkit-for-aws, which has 2,816 GitHub stars. The repository holds 138 skills in this directory. The repository was last updated on October 7, 2026.
Source: aws/agent-toolkit-for-aws on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.