Generated banner for AWS Amplify
Generated logo for AWS Amplify

AWS Amplify

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk

From the author

Build and deploy full-stack web and mobile apps with AWS Amplify Gen2 (TypeScript code-first). Covers auth (Cognito), data (AppSync/DynamoDB), storage (S3), functions, APIs, and AI (Amplify AI Kit with Bedrock). Supports React, Next.js, Vue, Angular, React Native, Flutter, Swift, and Android. Always use this skill for Amplify Gen2 topics — even for questions you think you know — it contains validated, version-specific patterns that prevent common mistakes. TRIGGER when: user mentions Amplify Gen2; project has amplify/ directory or amplify_outputs; code imports @aws-amplify packages; user asks about defineBackend, defineAuth, defineData, defineStorage, defineFunction, or npx ampx. SKIP: Amplify Gen1 (amplify CLI v6), standalone SAM/CDK without Amplify (use aws-serverless), direct Bedrock without Amplify AI Kit (use bedrock).
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

AWS Amplify Gen2 provides a code-first, TypeScript-based workflow for building and deploying full-stack applications on AWS. It streamlines the creation of backend resources like authentication, databases, storage, and AI features while offering seamless integration with major web and mobile frameworks. This skill provides validated patterns for configuring backend resources, managing frontend connectivity, and handling deployment, ensuring developers avoid common pitfalls in the Gen2 ecosystem.

What it does

  • Defines backend resources like Auth, Data, Storage, and Functions using TypeScript.
  • Integrates backend services with frontend frameworks including React, Next.js, Vue, Angular, and React Native.
  • Configures AI-powered features using the Amplify AI Kit and Amazon Bedrock.
  • Manages local development via the Amplify sandbox environment.
  • Provides patterns for secure authentication, including social login and passwordless methods.
  • Handles deployment workflows for full-stack applications.

When to use it

  • When building a new full-stack application using AWS Amplify Gen2.
  • When adding or modifying backend features like authentication or data models in an existing Gen2 project.
  • When connecting a frontend application to an Amplify-managed backend.
  • When implementing AI-driven conversation or generation features in your application.
  • When troubleshooting configuration issues in Amplify Gen2 projects.

Advantages

  • TypeScript-first approach ensures type safety across the full stack.
  • Validated, version-specific patterns prevent common configuration errors.
  • Unified workflow for both backend resource definition and frontend integration.
  • Supports a wide range of popular web and mobile frameworks.
  • Simplifies complex AWS service orchestration into manageable code-first definitions.

Usage examples

“How do I set up a new Amplify Gen2 project with React?”
The agent will guide you through initializing the project, setting up the amplify/ directory, and configuring the frontend entry point with Amplify.configure().
“Add email-based authentication to my existing Amplify Gen2 backend.”
The agent will provide the code to update amplify/auth/resource.ts using defineAuth and explain how to import it into your backend definition.
“How do I connect my Next.js App Router project to Amplify?”
The agent will provide the code for a client-side component to configure Amplify with { ssr: true } and show how to import it into your root layout.
“How can I add an AI conversation route to my data schema?”
The agent will show you how to use a.conversation() within your data schema definition, including model selection and authorization rules.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/aws/aws-amplify/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip aws-amplify.zip -d .agents/skills

Documentation by AWS

AWS Amplify Gen2

Build and deploy full-stack applications using AWS Amplify Gen2's TypeScript code-first approach. This skill covers backend resource creation, frontend integration across 8 frameworks, and deployment workflows.

Prerequisites

  • Node.js ^18.19.0 || ^20.6.0 || >=22 and npm

  • AWS credentials configured (aws sts get-caller-identity succeeds)

  • For sandbox: npx ampx --version returns a valid version

  • For mobile: Platform-specific tooling (Xcode, Android Studio, Flutter SDK)

Defaults & Assumptions

When the user does not specify a framework:

  • Web: Default to React (Vite) and explain the choice.

  • Mobile: Ask which platform (Flutter, Swift, Android, or React Native) — there is no universal mobile default, so guessing leads to wasted effort.

  • Neither specified: If the user says "build an app" without clarifying web vs. mobile, ask before proceeding — the framework choice affects every subsequent step.

  • Backend only: If only backend changes are requested and no frontend framework is mentioned, skip the frontend integration step entirely.

When the user does not specify tooling or strategy:

  • Package manager: Default to npm unless the user specifies yarn or pnpm.

  • Language: Default to TypeScript. Gen2 backends are TypeScript-only; frontends should follow the project's existing language.

  • Next.js: Default to App Router unless the user specifies Pages Router.

  • React Native: Ask whether the user uses Expo or bare React Native CLI.

  • Auth: You MUST ask which login method the user wants (email/password, social login, SAML, passwordless, etc.). Do not assume a default.

  • Data authorization: default to publicApiKey (allow.publicApiKey()) — this is the starter template default. When auth is added, switch to owner-based (allow.owner()) with defaultAuthorizationMode: 'userPool'.

Quick Start — Route to the Right Reference

Step 1: Identify the Task Type
TaskGo To
Create a new project→ scaffolding.md, then Step 2 and/or Step 3
Add or modify a backend feature→ Step 2 (Backend Features)
Connect frontend to existing backend→ Step 3 (Frontend Integration)
Deploy the application→ deployment.md
Step 2: Backend Features

Read the corresponding reference for each backend feature you need:

FeatureReferenceWhen to Use
Authenticationauth-backend.mdEmail/password, social login, MFA, SAML/OIDC
Data Modelsdata-backend.mdGraphQL schema, DynamoDB, relationships, auth rules
File Storagestorage-backend.mdS3 uploads/downloads, access rules
Functions & APIfunctions-and-api.mdLambda, custom resolvers, REST/HTTP APIs, calling from client
AI Featuresai.mdConversation, generation, AI tools via Bedrock (backend config + React/Next.js frontend)
Geo, PubSub, CDKgeo-pubsub-cdk.mdBackend-only: custom CDK stacks, overrides, custom outputs. Backend + frontend: Geo, PubSub, Face Liveness

Each backend feature file is self-contained. Load only what you need.

Routing note: These files apply for both adding and modifying features. Route to the same file whether the user says "add auth" or "change auth config" — each reference covers the full define surface.

Step 3: Frontend Integration

After configuring backend resources, connect the frontend. Choose by platform and feature:

Web (React, Next.js, Vue, Angular, React Native):

FeatureReference
Auth UI & flowsauth-web.md
Data CRUD & subscriptionsdata-web.md
Storage upload/downloadstorage-web.md

Mobile (Flutter, Swift, Android):

FeatureReference
Auth UI & flowsauth-mobile.md
Data CRUD & subscriptionsdata-mobile.md
Storage upload/downloadstorage-mobile.md

Note: AI and Functions frontend patterns are included in ai.md and functions-and-api.md respectively — they are not split into separate web/mobile files.

Core Concepts

Amplify Gen2 Architecture
  • Code-first: All backend resources defined in TypeScript under amplify/

  • Main config: amplify/backend.ts imports and combines all resources via defineBackend()

  • Resource files: amplify/auth/resource.ts, amplify/data/resource.ts, amplify/storage/resource.ts, amplify/functions/<name>/resource.ts

  • Generated output: amplify_outputs.json — consumed by frontend Amplify.configure(). Gitignored — generated by npx ampx sandbox (local dev) or npx ampx pipeline-deploy (CI/CD), never committed.

Directory Structure

amplify/ and src/ must be siblings under the project root — placing them at different directory levels breaks sandbox detection. (Exception: in monorepos, amplify/ may be in a packages/ subdirectory — the key is that amplify_outputs.json must be accessible from the frontend entry point.)

project-root/
├── amplify/
│   ├── backend.ts            # defineBackend({ auth, data, ... })
│   ├── auth/resource.ts      # defineAuth({ ... })
│   ├── data/resource.ts      # defineData({ schema })
│   ├── storage/resource.ts   # defineStorage({ ... })
│   └── functions/
│       └── my-func/
│           ├── resource.ts   # defineFunction({ ... })
│           └── handler.ts    # export const handler = ...
├── src/                      # Frontend code
├── amplify_outputs.json      # Generated, gitignored — never edit or commit
└── package.json
Key APIs
PackagePurpose
@aws-amplify/backenddefineAuth, defineData, defineStorage, defineFunction, defineBackend
aws-amplifyFrontend: Amplify.configure(), generateClient(), auth/data/storage APIs
@aws-amplify/ui-reactPre-built UI: <Authenticator>, <StorageBrowser>
@aws-amplify/ui-react-aiAI UI: <AIConversation>, useAIConversation

Framework Setup

These patterns apply to every web task — not just new projects. Verify each one before implementing any feature.

Gen2 Detection

Before modifying any code, check if the project is already Gen2:

  1. amplify/ directory exists with backend.ts

  2. @aws-amplify/backend in package.json devDependencies

If both are true, the project is already Gen2 — skip to feature implementation. If amplify/.config/ exists instead, this is a Gen1 project — do not proceed (requires separate migration skill).

Frontend Configuration

Import the generated outputs and configure Amplify in the correct entry point for your framework. Placing this in the wrong file causes silent failures — Amplify API calls return undefined or empty responses with no error.

WARNING: amplify_outputs.json must exist before the app can compile — without it, the build fails with a module-not-found error. Run npx ampx sandbox (or npx ampx sandbox --once) first to generate it. See scaffolding.md for the correct sequence.

React (Vite) — src/main.tsx:

import { Amplify } from 'aws-amplify';
import outputs from '../amplify_outputs.json';
Amplify.configure(outputs);

Next.js (App Router) — app/layout.tsx:

Important: layout.tsx is a server component in App Router. Use the ConfigureAmplifyClientSide client component pattern below instead.

{ ssr: true } is a Next.js-only option (not needed by Vue, Angular, or React SPA). Both App Router and Pages Router use it, but apply it differently:

  • App Router — set globally in ConfigureAmplifyClientSide client component

  • Pages Router — set per-file where server-side access is needed

Next.js App Router: Client-Side Configuration

Next.js App Router requires a dedicated client component to configure Amplify for browser-side operations:

// components/ConfigureAmplifyClientSide.tsx
"use client";
import { Amplify } from "aws-amplify";
import outputs from "@/amplify_outputs.json";

Amplify.configure(outputs, { ssr: true });

export default function ConfigureAmplifyClientSide() {
  return null;
}

Import in your root layout:

// app/layout.tsx
import ConfigureAmplifyClientSide from "@/components/ConfigureAmplifyClientSide";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <ConfigureAmplifyClientSide />
        {children}
      </body>
    </html>
  );
}

Why? In App Router, layout.tsx is a server component. Client components need Amplify.configure() to run in the browser. Without this, you get "Auth UserPool not configured" errors.

Vue — src/main.js:

import { Amplify } from 'aws-amplify';
import outputs from '../amplify_outputs.json';
Amplify.configure(outputs);

Angular — src/main.ts:

import { Amplify } from 'aws-amplify';
import outputs from '../amplify_outputs.json';
Amplify.configure(outputs);
Next.js Pages Router

Pages Router does NOT need { ssr: true } in _app.tsx. Instead, configure per-file where you need server-side access:

// pages/api/protected.ts or getServerSideProps
import { Amplify } from 'aws-amplify';
import outputs from '@/amplify_outputs.json';
Amplify.configure(outputs, { ssr: true });

Key difference: App Router uses a global client component. Pages Router configures per-file.

<Authenticator.Provider> is required in layout.tsx for auth context.

React Native

React Native uses the same aws-amplify JS package as web frameworks (it is part of amplify-js, not the native mobile SDKs). All web APIs apply to RN with the additions below.

Required Packages
npm install aws-amplify @aws-amplify/react-native \
  @react-native-async-storage/async-storage \
  react-native-get-random-values

@react-native-async-storage/async-storage is required — the Amplify SDK uses it for token persistence and will fail at runtime without it.

Configure Entry Points

No plugin registration needed — configure only.

React Native (Expo) — App.tsx:

import 'react-native-get-random-values';  // MUST be first
import { Amplify } from 'aws-amplify';
import outputs from './amplify_outputs.json';
Amplify.configure(outputs);

React Native (Bare CLI) — index.js (before AppRegistry.registerComponent):

import 'react-native-get-random-values';  // MUST be first
import { Amplify } from 'aws-amplify';
import outputs from './amplify_outputs.json';
Amplify.configure(outputs);
React Native Pitfalls
  • Import order: react-native-get-random-values must be the FIRST import in the entry file, before aws-amplify. Reversing the order causes cryptographic failures at runtime.

  • Missing AsyncStorage: Without @react-native-async-storage/async-storage, auth tokens are not persisted and users must re-authenticate on every app restart.

SvelteKit

Configure Amplify in the client hooks file:

// src/hooks.client.ts
import { Amplify } from 'aws-amplify';
import outputs from '../amplify_outputs.json';

Amplify.configure(outputs);

Note: No @aws-amplify/ui-* components exist for Svelte. Use core APIs directly.

Unsupported Frameworks (Astro, Solid, etc.)

For frameworks without official Amplify support:

  1. Use npm create amplify@latest -y to scaffold the backend (works in any project)

  2. Configure Amplify inside a client-side component (not at build time)

Astro

Amplify is client-side only in Astro. Create a React component (no Astro syntax):

// src/components/AuthenticatedApp.tsx
import { Amplify } from 'aws-amplify';
import { Authenticator } from '@aws-amplify/ui-react';
import outputs from '../amplify_outputs.json';

Amplify.configure(outputs);

export default function AuthenticatedApp() {
  return (
    <Authenticator>
      {({ signOut, user }) => <main>Hello {user?.username}</main>}
    </Authenticator>
  );
}

Use in an Astro page with client:only:

---
// src/pages/index.astro — no Amplify imports here
---
<html>
  <body>
    <AuthenticatedApp client:only="react" />
  </body>
</html>

Must use client:only="react" (NOT client:load) to avoid SSR hydration errors.

All documentation links use react as the default platform slug. Replace /react/ in any URL with your target framework:

FrameworkSlug
Reactreact
Next.jsnextjs
Vuevue
Angularangular
React Nativereact-native
Flutterflutter
Swiftswift
Androidandroid

Files

references/data-backend.md

Data — Backend

Prerequisites: Backend defined in amplify/backend.ts with defineBackend({ auth, data }).

Schema Definition

Define your data models in amplify/data/resource.ts:

import { type ClientSchema, a, defineData } from '@aws-amplify/backend';

const schema = a.schema({
  Todo: a.model({
    content: a.string().required(),
    priority: a.enum(['low', 'medium', 'high']),
    done: a.boolean().default(false),
    dueDate: a.date(),
    owner: a.string(),
  }).authorization(allow => [allow.owner()]),
});

export type Schema = ClientSchema<typeof schema>;
export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: 'userPool',
  },
});

Import into amplify/backend.ts:

import { defineBackend } from '@aws-amplify/backend';
import { auth } from './auth/resource';
import { data } from './data/resource';
defineBackend({ auth, data });

Export Schema as ClientSchema<typeof schema> — without this export, frontend clients lose all type inference. Field types: a.string(), a.integer(), a.float(), a.boolean(), a.date(), a.datetime(), a.timestamp(), a.time(), a.email(), a.url(), a.phone(), a.ipAddress(), a.json(), a.id(), a.enum([...]). Chain .required() or .array() on any field; .default(value) on scalar fields only (not enums — see Pitfalls).

a.phone(): Only accepts E.164 format (+15551234567). Hyphens (+1-555-0101) and short formats are rejected.

Date/Time Field Formats
Field TypeStorage FormatExample
a.date()ISO date string2024-01-15
a.time()ISO time string14:30:00.000Z
a.datetime()ISO datetime2024-01-15T14:30:00.000Z
a.timestamp()Epoch seconds (not ms!)1705325400

Pitfall: a.timestamp() is seconds, not milliseconds. Use Math.floor(Date.now() / 1000) when setting values from JavaScript.

Custom Identifiers

.identifier(['sku']) replaces the auto-generated id field entirely:

Product: a.model({
  sku: a.string().required(),
  name: a.string(),
}).identifier(['sku'])
  • All queries must use the custom identifier ({ sku: 'ABC123' })

  • Duplicate values cause DynamoDB conditional check error

  • The id field no longer exists on this model

Authorization Rules

Six strategies, applied per-model or per-field:

WARNING: In data authorization rules, allow.guest() is a method call (with parentheses). In storage access rules, allow.guest is a property (no parentheses). Mixing these up causes TypeScript errors.

a.model({ /* fields */ }).authorization(allow => [
  allow.publicApiKey().to(['read']), // API key: public read
  allow.guest().to(['read']), // Requires defaultAuthorizationMode: 'iam'
  allow.owner(), // Creator has full CRUD
  allow.authenticated().to(['read']), // Any signed-in user can read
  allow.group('Admins'), // Named Cognito group
  allow.custom(), // Lambda authorizer
])

Security note: allow.guest() and allow.publicApiKey() both permit unauthenticated access. Only use for intentionally public, non-sensitive data. Prefer allow.authenticated() or allow.owner() for sensitive resources. See Amplify authorization best practices and Amazon Cognito Identity Pool security for guidance on choosing the right authorization strategy.

Per-field authorization overrides model-level rules:

Post: a.model({
  title: a.string(),
  secret: a.string().authorization(allow => [allow.owner()]),
}).authorization(allow => [allow.authenticated().to(['read'])])

Multi-owner: Use allow.ownersDefinedIn('editors') with an editors: a.string().array() field to grant multiple users ownership. Dynamic groups: Use allow.groupsDefinedIn('teamGroups') with a string field to control access via group names stored on each record.

Authorization Rule Combining

When multiple rules are applied, the most permissive wins. You cannot use deny rules — if allow.authenticated() grants full CRUD, you cannot selectively deny delete for non-owners. Structure rules from most restrictive:

.authorization(allow => [
  allow.owner(),           // Owner: full CRUD
  allow.authenticated().to(['read', 'create']),  // Others: read + create only
])

Pitfall: groupsDefinedIn('fieldName') automatically creates an implicit field on the model. Do NOT also declare that field explicitly — this causes: "Implicit field conflicts with explicit field definition."

Type system gap: The implicit field from groupsDefinedIn('fieldName') is NOT exposed in generated TypeScript client types. To set the field programmatically, use an untyped approach:

await client.graphql({
  query: mutations.updateProject,
  variables: { id: projectId, teamGroups: ['Admins', 'Editors'] },
});
PatternUse CaseField TypeWho Gets Access
allow.ownersDefinedIn('editors')Multiple named users own the resourcea.string().array() — declare explicitlySpecific users listed in the array
allow.groupsDefinedIn('teamGroups')Access by Cognito group membershipImplicit — do NOT declareAny user in the named Cognito group

Relationships

Three types — reference field types must match the related model's identifier type.

Foreign key fields must use a.id(), not a.string(). Using a.string() causes silent relationship resolution failures.

const schema = a.schema({
  Team: a.model({
    name: a.string().required(),
    members: a.hasMany('Member', 'teamId'),
  }).authorization(allow => [allow.owner()]),

  Member: a.model({
    name: a.string().required(),
    teamId: a.id().required(),
    team: a.belongsTo('Team', 'teamId'),
    profile: a.hasOne('Profile', 'memberId'),
  }).authorization(allow => [allow.owner()]),

  Profile: a.model({
    bio: a.string(),
    memberId: a.id().required(),
    member: a.belongsTo('Member', 'memberId'),
  }).authorization(allow => [allow.owner()]),
});

The second argument to hasMany/belongsTo/hasOne is the foreign key field name. That field must be declared explicitly on the child model.

Declare both sides of every relationship — the parent model needs a.hasMany('Child', 'fkField') AND the child model needs a.belongsTo('Parent', 'fkField'). Omitting either side causes silent query failures (e.g., lazy-loading the relation returns undefined).

Deletion Behavior — No Referential Integrity

Deleting a parent record does NOT cascade to children and does NOT fail. Child records become orphaned silently — manually delete children first or implement a soft-delete pattern.

// Delete children before parent
const books = await client.models.Book.list({ filter: { authorId: { eq: authorId } } });
await Promise.all(books.data.map(b => client.models.Book.delete({ id: b.id })));
await client.models.Author.delete({ id: authorId });
Self-Referential Models (Tree Structures)
Category: a.model({
  name: a.string().required(),
  parentId: a.id(),
  parent: a.belongsTo('Category', 'parentId'),
  children: a.hasMany('Category', 'parentId'),
})

Requires explicit FK field (parentId: a.id()). Works for trees, org charts, threaded comments.

Secondary Indexes

Todo: a.model({
  content: a.string(),
  status: a.string(),
  createdAt: a.datetime(),
}).secondaryIndexes(index => [
  index('status').sortKeys(['createdAt']).queryField('listByStatus'),
])

Indexes enable client.models.Todo.listByStatus({ status: 'active' }). Composite sort keys allow multi-field sorting within a partition. You SHOULD name the queryField descriptively — it becomes the typed client method name.

Enum Types

Define enums with a.enum() at the top level of a.schema(), then reference them in model fields with a.ref():

const schema = a.schema({
  Priority: a.enum(['low', 'medium', 'high']),

  Task: a.model({
    title: a.string().required(),
    priority: a.ref('Priority'),
  }).authorization(allow => [allow.owner()]),
});

You can also use a.enum() inline on a model field:

Todo: a.model({
  content: a.string().required(),
  priority: a.enum(['low', 'medium', 'high']),
})

⚠️ Pitfall: .default() does not work on a.enum() fields — default values are only supported on scalar types (a.string(), a.integer(), etc.). Applying .default() to an enum field silently fails at deployment.

.required() on enums: a.enum(['A','B']).required() does NOT work — .required() doesn't exist on EnumType. Define the enum separately and use a.ref():

const Priority = a.enum(['low', 'medium', 'high']);
const schema = a.schema({
  Todo: a.model({
    priority: a.ref('Priority').required(), // ✅ Works
    // priority: Priority.required(),       // ❌ Fails
  })
});

Custom Types

Custom types group related fields into a reusable structure:

const schema = a.schema({
  Location: a.customType({ lat: a.float(), lng: a.float() }),

  Task: a.model({
    title: a.string().required(),
    location: a.ref('Location'),
  }).authorization(allow => [allow.owner()]),
});

Use a.ref('TypeName') to reference custom types or enums in model fields.

Custom Queries and Mutations

Expose Lambda-backed operations through the schema:

const schema = a.schema({
  // ... models ...
  echo: a.query()
    .arguments({ message: a.string().required() })
    .returns(a.string())
    .handler(a.handler.function('echoHandler'))
    .authorization(allow => [allow.authenticated()]),

  placeOrder: a.mutation()
    .arguments({ productId: a.id().required(), qty: a.integer() })
    .returns(a.json())
    .handler(a.handler.function('orderHandler'))
    .authorization(allow => [allow.authenticated()]),
});

The handler function name must match a defineFunction name imported into backend.ts.

Authorization Modes

Configure default and additional auth modes in defineData:

Starter template default (public access):

export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: 'apiKey',
    apiKeyAuthorizationMode: { expiresInDays: 30 },
  },
});

With auth (user-scoped access):

export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: 'userPool',
    apiKeyAuthorizationMode: { expiresInDays: 30 },
    // lambdaAuthorizationMode: { function: myAuthFn },
  },
});

The defaultAuthorizationMode must match at least one strategy used in your model authorization() rules (e.g., userPool ↔ owner() / authenticated() / group(); apiKey ↔ publicApiKey(); iam ↔ guest()).

Guest access is enabled by default in Amplify Gen2 — see auth-backend.md for details and how to disable it.

Guest access configuration: see auth-backend.md § Guest Access.

Pitfalls

  • Missing ClientSchema export: Without export type Schema = ClientSchema<typeof schema>, frontend generateClient<Schema>() has no type information and all operations are untyped.

  • Auth mode conflict: Using allow.publicApiKey() in model rules but setting defaultAuthorizationMode: 'userPool' without adding apiKeyAuthorizationMode causes API key requests to be rejected.

  • Per-field auth + .required(): Fields with owner-only authorization (allow.owner()) cannot be .required() — other users can't provide a value on create. Make private fields optional.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/specialized-skills/web-and-mobile-development/aws-amplify · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-amplify.zip