CtrlK
BlogDocsLog inGet started
Tessl Logo

authoring-mwaa-workflow

Authors and deploys MWAA workflow artifacts: Python Airflow DAGs for provisioned environments or YAML workflow files for Serverless. Covers operator selection, timeout design, retry strategy, scheduling, failure notifications, idempotency, and MWAA Serverless schema compliance. Deploys the artifact (S3 DAG upload or Serverless CreateWorkflow/UpdateWorkflow), creates an environment inline when approved, and redeploys fixes, then optionally hands off to testing-mwaa-workflow. Triggers on: create a DAG, write a pipeline, build a workflow, orchestrate tasks, Airflow DAG, data pipeline, schedule a job, deploy a DAG, deploy a workflow, YAML workflow. Not applicable to converting or migrating existing DAGs between provisioned and serverless (conversion is out of scope), running or smoke-testing a deployed workflow (handled by testing-mwaa-workflow) or diagnosing a failed run (handled by debugging-mwaa-workflow).

72

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

85%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.

A well-structured orchestration skill: routing logic, deploy/test gates, security considerations, and troubleshooting are all concrete and correctly split across six real reference files at one level of depth. The only imperfections are mild verbosity in the loading-mode and execution-note sections and the reliance on references for the actual authoring code.

Suggestions

Trim the 'Guardrail — where this skill's own files live' section to its two routing bullets and cut the repetition about retrieve_skill vs local paths; the MCP note at the top plus these bullets convey the same rule in half the tokens (conciseness).

Inline one minimal DAG skeleton (or link directly to the relevant template anchor in dag-patterns.md) at the Path A entry point so the body gives a copy-paste starting point instead of only routing to the reference (actionability).

Condense the schedule/no-schedule option matrices in the Ask step to a single compact table or one line per option, since the phrasing detail is repeated between the two cases (conciseness).

DimensionReasoningScore

Conciseness

The body is dense operational guidance with no filler explaining Airflow or AWS concepts Claude already knows — routing rules, ARN patterns, and deployment gates are all non-obvious content. Minor trimming possible: the MCP-vs-local-install guardrail and the poll-in-discrete-steps note each run longer than strictly needed. Not a 5 because a few sections (the loading-mode guardrail, the schedule/no-schedule option lists) could be tightened without losing information.

4 / 5

Actionability

Mostly executable guidance: concrete ARN regexes, specific commands ("aws mwaa get-environment", "CreateWorkflow (new) or UpdateWorkflow (redeploy)"), exact packaging constraints ("manylinux2014_x86_64 / Py3.12 wheel", "≤250 MB", "no __pycache__"), and exact option phrasings for the user prompt. Not a 5 because the actual authoring code/steps live in the path references, so the body alone is not copy-paste ready for the core writing task — though the delegation is explicit and each reference file exists.

4 / 5

Workflow Clarity

Clear sequenced workflow with explicit validation and feedback loops: Step 0 routing decision tree → path reference → Write → "Run post-deploy verification... to confirm the scheduler parsed the new file without import errors or dag_id conflicts", a "Redeploy (fix loop)", a HARD GATE on test requests, and confirmation requirements for state-mutating operations with a troubleshooting table for recovery. This matches the 5 anchor (explicit validation steps, feedback loops, error recovery).

5 / 5

Progressive Disclosure

Textbook structure: the body is a routing/orchestration overview, with per-path authoring detail split into one-level-deep references (authoring-provisioned-dag.md, authoring-serverless-workflow.md), deploy detail in deploying-mwaa.md, and supporting material (dag-patterns.md, yaml-schema.md, serverless-code-packaging.md) — all six files exist on disk and are annotated in the References section. Navigation is easy and the split is appropriate.

5 / 5

Total

18

/

20

Passed

Description

92%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.

An excellent description: it states what and when concretely, covers both deployment paths, and explicitly fences off sibling skills. Trigger coverage is strong, with only minor natural terms (e.g., "MWAA" itself, "write a DAG") absent.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with comprehensive coverage: "Authors and deploys MWAA workflow artifacts: Python Airflow DAGs... or YAML workflow files for Serverless", "Deploys the artifact (S3 DAG upload or Serverless CreateWorkflow/UpdateWorkflow), creates an environment inline when approved, and redeploys fixes, then optionally hands off to testing-mwaa-workflow". It also enumerates covered concerns (operator selection, timeout design, retry strategy, scheduling, failure notifications, idempotency, schema compliance). Not a 4 because coverage spans authoring, deploying, environment creation, redeployment, and hand-off with no gaps.

5 / 5

Completeness

It explicitly answers both questions: what ("Authors and deploys MWAA workflow artifacts... Covers operator selection, timeout design, retry strategy, scheduling, failure notifications, idempotency, and MWAA Serverless schema compliance") and when ("Triggers on: create a DAG, write a pipeline, build a workflow...") with concrete trigger phrases. It goes further by stating explicit non-applicability (conversion, smoke-testing, diagnosing failed runs). Clearly the 5 anchor.

5 / 5

Trigger Term Quality

Explicit trigger list includes natural phrases users would say: "create a DAG, write a pipeline, build a workflow, orchestrate tasks, Airflow DAG, data pipeline, schedule a job, deploy a DAG, deploy a workflow, YAML workflow". Not a 5 because a few natural terms are missing — the product name "MWAA" itself, "Airflow pipeline", "provisioned environment", and common variants like "write a DAG"; not a 3 because coverage already includes synonyms across both deployment models.

4 / 5

Distinctiveness Conflict Risk

The niche is clear and sibling skills are explicitly disambiguated: "running or smoke-testing a deployed workflow (handled by testing-mwaa-workflow) or diagnosing a failed run (handled by debugging-mwaa-workflow)" and "converting or migrating existing DAGs between provisioned and serverless (conversion is out of scope)". Trigger terms are domain-specific (MWAA, Airflow DAG, Serverless YAML), so minimal conflict risk with other skills.

5 / 5

Total

19

/

20

Passed

Validation

100%

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
Reviewed

Table of Contents

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.