redshift-guide

Amazon Redshift is NOT PostgreSQL — corrects PostgreSQL-derived LLM mistakes; covers Redshift-specific SQL, DDL, COPY/UNLOAD, system views, metadata discovery, and operational patterns. Applies ONLY when the task is about Redshift itself (cluster, Serverless workgroup, or Redshift SQL). Pushes back on: CREATE INDEX, string_agg, pg_catalog, text type, SERIAL, stl_query, LATERAL, RETURNING. Triggers on: Redshift SQL, Redshift CREATE TABLE, Redshift COPY/UNLOAD, slow Redshift query, Redshift permission denied, Redshift disk full, Redshift system views, QUALIFY, PIVOT, MERGE, Redshift Data API, Redshift WLM, concurrency scaling, Redshift resize, Redshift Spectrum external tables. Does NOT apply to (defer to that service's own skill): Amazon S3 storage/bucket policies, Athena or Glue queries/catalogs, data-lake or Iceberg work outside Redshift, Aurora, RDS, or DynamoDB — but S3/Glue ARE in scope for Redshift COPY, UNLOAD, or data-lake queries (external schemas/tables on S3).

Quality

96%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

93%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a lean, expert-only reference: dense Redshift-specific facts, executable SQL/API specifics, a clear Serverless-vs-Provisioned gate, and well-structured one-level-deep routing to seven real reference files. The only gap is the absence of an explicit validate-retry loop for the destructive operations the guardrails cover.

Suggestions

Add a short validate-then-retry pattern under Safety Guardrails for destructive/batch operations (e.g., after a BLOCK/WARN gate, re-check row counts or run a dry-run query before committing DELETE/DROP) to lift workflow_clarity to 5.

Consider a one-line 'verify after execute' checkpoint for COPY/UNLOAD (e.g., confirm sys_load_error_detail is empty / row count matches) to close the feedback loop on batch loads.

STEP 0's 'ask when not stated' rule could note what to do if the user cannot answer (default assumption + state it), so the workflow has no dead-end branch.

Dimension	Reasoning	Score
Conciseness	The body assumes Claude's competence throughout — it never explains what Redshift or SQL is — and each line is a dense, decision-relevant fact (e.g. the SUBSTR leader-node-only note with the exact error string). Length reflects genuine domain density, not padding, fitting the anchor-5 'every token earns its place' better than the over-explanation of a 4.	5 / 5
Actionability	Concrete, copy-paste-ready specifics throughout: exact SQL (DATEADD(day, -30, GETDATE()), CREATE TABLE ... USING ICEBERG), exact API params (--workgroup-name vs --cluster-identifier, --wait-time-seconds 1-30), and exact CLI calls (aws logs associate-kms-key), covering the common cases.	5 / 5
Workflow Clarity	STEP 0 sequences the Serverless-vs-Provisioned gate before answering, the routing table is marked MANDATORY, and Safety Guardrails use BLOCK/WARN/Confirm; however there is no explicit validate->fix->retry feedback loop for the destructive operations it governs (DROP DATABASE, DELETE without WHERE), which keeps it below a 5.	4 / 5
Progressive Disclosure	The SKILL.md is an overview that routes to seven one-level-deep reference files, all of which exist exactly as named and are clearly signaled with '→ Load references/...'; content is appropriately split with details deferred to the bundle.	5 / 5
	Total	19 / 20 Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is a model of the form: concrete capabilities, an explicit 'Triggers on' list, and boundary-scoping both inclusive and exclusive. It clearly separates Redshift scope from adjacent AWS data services and even handles the COPY/UNLOAD overlap case.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions ('corrects PostgreSQL-derived LLM mistakes; covers Redshift-specific SQL, DDL, COPY/UNLOAD, system views, metadata discovery, and operational patterns') plus a specific pushback list (CREATE INDEX, string_agg, pg_catalog), giving comprehensive coverage rather than the minor gaps of a 4.	5 / 5
Completeness	Explicitly answers both 'what' (corrects mistakes, covers listed topic areas) and 'when' ('Applies ONLY when...', 'Triggers on...', 'Does NOT apply to...') with concrete trigger phrases.	5 / 5
Trigger Term Quality	The 'Triggers on' list spans natural phrases a user would actually say (slow Redshift query, Redshift permission denied, Redshift disk full, Redshift COPY/UNLOAD) plus syntax terms (QUALIFY, PIVOT, MERGE), with broad synonym coverage.	5 / 5
Distinctiveness Conflict Risk	The 'Applies ONLY when the task is about Redshift itself' scoping plus an explicit exclusion list (S3 storage/bucket policies, Athena, Glue, Aurora, RDS, DynamoDB) carves a clear niche with minimal conflict risk against neighboring skills.	5 / 5
	Total	20 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: aws/agent-toolkit-for-aws
Path: plugins/aws-data-analytics/skills/redshift-guide/SKILL.md
Commit: b8171ad

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.