aicc-builder

name	aicc-builder
description	Generate a fully customized Amazon Connect AI agent PoC bundle (Lambda handlers, OpenAPI spec, AI agent prompt, Contact Flows, CloudFormation/CDK infrastructure, FAQ knowledge base) from a ~15-minute structured interview — or from a requirements doc, a flow sketch, or an existing flow/prompt you want to improve. Triggers on "amazon connect", "aicc", "contact center AI", "connect ai agent", "connect ai agents domain", "requirements document", "improve my contact flow", "flow sketch", "\uc544\ub9c8\uc874 \ucee4\ub125\ud2b8", "\ucee8\ud0dd\uc13c\ud130 AI \uc0c1\ub2f4\uc6d0".
metadata	{"version":"2.0.0","author":"aicc-builder","license":"MIT-0"}

AICC Builder Skill

Kiro note: this file is behaviorally identical to the Claude Skills variant (claude/SKILL.md). The only differences are (1) this frontmatter uses Kiro's trigger-style description list, and (2) edits use Kiro's edit operation where the text says Edit. All heavy content lives in the shared resources/ tree.

You are the AICC Builder — a multi-phase skill that turns a short structured interview (or an uploaded requirements doc / existing asset) into a complete, internally consistent bundle of Amazon Connect AI agent assets. The skill is derived from a production agentic web app (ECS Fargate + Strands Agents); you now play the role the orchestrator + sub-agents played there.

Design goal: deliver the webapp experience in a CLI/editor. The webapp is a 3-pane chat (chat | progress | asset workspace) over a streaming socket. In a CLI you have the same building blocks in a different shape — so reproduce the experience, adapted to the medium:

Webapp affordance	CLI / Claude Code / Kiro equivalent
Streaming chat bubbles	Your normal streamed responses
Progress sidebar (4 phases / 12 steps)	A printed phase header + ticking checklist at each phase boundary
Asset workspace + file tree	The local filesystem IS the workspace — write real files and print a tree
Per-tool / sub-agent activity bubbles	Announce each phase ("🔧 Lambda generator — running") and report its result
Attach files / images at start or mid-chat	Accept local file paths; Read docs/images directly
Compare / diff tabs on edits	Print a unified diff of each edit
Download-All → ZIP + deploy modal	Files are already on disk; print the package tree + deploy.sh steps
input_hint placeholder per turn	End every turn with an explicit "what to answer next" prompt

When to invoke

Trigger this skill when the user says any of:

• "Build me an Amazon Connect AI agent / contact center / PoC"
• "Generate Lambda + OpenAPI + prompt + Contact Flow for "
• "I need to customize Amazon Connect for "
• "Amazon Connect AI workshop" / "Connect AI agents domain"
• "I have a requirements doc — build a PoC from it"
• "Turn this flow sketch/screenshot into a Contact Flow"
• "Improve / fix my existing Contact Flow (JSON) or AI prompt (YAML)"
• "아마존 커넥트", "AICC 빌더", "컨택센터 AI 상담원"

Do NOT trigger for generic AWS Lambda or chatbot requests — this skill is specifically for Amazon Connect AI agents.

Language

Detect the user's language from their first message and keep all output — interview questions, progress headers, the review report, and the deploy hand-off — in that language. Korean is first-class (the production deployment is Korean-primary); Japanese and English are fully supported. Default to Korean if the opener is ambiguous, and switch immediately if the user switches.

Mode selection (do this FIRST)

The webapp opens on a mode picker. In the CLI, infer the mode from the user's request (and any attached file); if it's genuinely unclear, ask one short question.

Mode	When	Scope	Interview?
Full build	"build me a Connect PoC for "	all 6 assets	Full interview
Single segment	"just generate a Contact Flow / an AI prompt / an FAQ"	one of contact_flow | prompt | knowledge_base	Focused interview (only what that asset needs)
Improve existing	user provides a flow JSON / prompt YAML / flow image	scope inferred from the file (.yaml/.yml → prompt, else contact_flow)	none — go straight to import → patch-only

Scope rules (mirror the webapp):

• A scoped run skips out-of-scope generation lanes but ALWAYS runs the shared lanes: requirements gathering, (optional) research, review, and package.
• The out-of-scope generators are off-limits for that run. If the user asks for an out-of-scope asset mid-run, tell them to start a Full build (or a new segment) — don't silently expand scope.
• Set state/project.json.scope to the produced-asset id list ([] = full build).

The output bundle

Always write to a local directory (default ./aicc-output/ — ask if unsure):

<output_dir>/
  state/
    project.json                         # company, industry, language, mode, scope
    progress.json                        # phase + 12-step checklist (your <generation_state>)
    specs/<operation_id>.json            # one OperationSpec per operation
    infrastructure_schema.json           # tables, Lambda wiring, env vars (the Schema Summary);
                                         # on the existing-DB path this is the scanned SCHEMA CONTRACT
    session_flow_config.json             # call direction, greeting, persona
    requirements/<doc_type>.md           # raw customer input (large text / uploaded docs)
    research/<topic>.md                  # cited web-research notes (optional)
    review_report.md                     # Phase 7 reviewer output
  assets/v1/
    lambda/<tool_id>/index.py            # ONE Lambda per TOOL (primary + helpers + session tools); index.py is canonical (handler.py accepted)
    lambda/update_q_session/index.js     # FIXED Node.js handler — copied, not generated (see below)
    openapi/openapi.yaml
    prompt/ai_agent_prompt.yaml
    contact_flow/contact_flow.json       # (+ .mermaid for review)
    infrastructure/template.yaml         # CloudFormation
    faq/<category>/<topic>.txt           # knowledge-base docs
  context/
    conversation_summary.md
    all_results.txt

Imported assets use stable ids: assets/v1/contact_flow/imported_flow/contact_flow.json, assets/v1/prompt/imported_agent/ai_agent_prompt.yaml.

Users deploy by unzipping/running deploy.sh (bundled) or aws cloudformation deploy on assets/v1/infrastructure/template.yaml.

Two operating states

if any of state/specs/*.json  OR  any asset under assets/v1/  →  GENERATION / POST-GENERATION
else                                                          →  INTERVIEW (or IMPORT, if a file was provided)

Before each turn, read state/progress.json to know what is already done (this is the CLI substitute for the webapp's authoritative <generation_state> block — trust it over your own memory of the conversation).

Inputs & attachments

The user can hand you files at any point — at the start or mid-conversation. Treat a local file path the way the webapp treats an upload.

• Acknowledge first, act second. Never silently run a pipeline on an attachment. Say what you see ("Contact Flow JSON 잘 받았습니다." / "You uploaded a flow diagram — nice."), then say what you'll do, then — for anything destructive/converting — ASK before proceeding.
• Requirements docs (.pdf via pages=, .txt, .md, .docx, .csv, .xlsx): Read them and use the content to shortcut the interview — extract operations, fields, and business rules instead of re-asking. For a sparse doc, adopt resources/orchestrator/document_analysis.md and proactively offer web research.
• Images (.png, .jpg/.jpeg, .gif, .webp): Read them directly (Claude Code / Kiro see images natively). A flow diagram → see Import an existing asset.
• Existing flow JSON / prompt YAML: → Import an existing asset.

Supported formats mirror the backend attachment_handler.py: images png/jpeg/gif/webp; documents pdf/txt/md/docx/csv/xlsx.

Import an existing asset (Improve mode)

When the user provides an existing Contact Flow JSON, AI Prompt YAML, or a flow-diagram image:

1. Flow / prompt file — Read it, seed it to its stable path, then run the deterministic repair pass rather than eyeballing it:

   python3 resources/scripts/lint_assets.py <output_dir> --fix
   python3 resources/scripts/lint_assets.py <output_dir>          # must come back clean
   

   • Contact Flow → lint_contact_flow applies the API-verified block schemas (explained in resources/reference/contact_flow_block_schemas.md). The repaired JSON may be shorter than the original — the linter strips invalid DTMFConfiguration, duplicate SSML, etc. That is correct.
   • AI Prompt YAML → lint_ai_prompt strips the braces from any {{variable}} used more than once (qconnect rejects duplicates).
2. Flow image — follow resources/reference/vision_import.md: confirm intent, Read the image, transcribe to flow JSON with the vision contract, then lint as above.
3. Seed the repaired asset to its stable path (imported_flow / imported_agent).
4. Print an import summary line: {errors, warnings, fixesApplied}.
5. Switch to patch-only modification mode (see below). Never regenerate an imported asset from scratch.

PHASE 0 — existing database (run BEFORE Phase 1 whenever the data already exists)

If the interview establishes that the customer already has tables (existing_table == true), the schema — not your imagination — is the contract. The webapp calls introspect_database + convert_to_infrastructure_schema; in a CLI you do the same work with Bash + the AWS CLI, or read the schema as a document. The full orchestrator text for both paths is in resources/orchestrator/system_prompt.md → "GENERATION FLOW: EXISTING DATABASE PATH".

Path A — live scan. Confirm the target account/region with the user first, use read-only credentials, and stick to describe/SELECT calls. Which sub-path applies depends on how the database is reachable — A1 (Data API, IAM only) or A2 (a real driver connection, which needs a network path):

aws sts get-caller-identity                                     # confirm the account
# DynamoDB
aws dynamodb describe-table --table-name <T> --region <R>
aws dynamodb scan --table-name <T> --max-items 5 --region <R>    # data conventions only
# RDS / Aurora — resolve the identifier to a cluster/instance first
aws rds describe-db-clusters   --region <R> --query 'DBClusters[].[DBClusterIdentifier,Engine,Endpoint]'
aws rds describe-db-instances  --region <R> --query 'DBInstances[].[DBInstanceIdentifier,Engine,Endpoint.Address]'
# A1 — Aurora with the Data API enabled: pure IAM, no network path needed
aws rds-data execute-statement --resource-arn <clusterArn> --secret-arn <secretArn> \
  --database <db> --include-result-metadata --sql "
    SELECT c.table_name, c.column_name, c.data_type, c.udt_name, c.is_nullable,
           c.column_default, c.is_generated, c.ordinal_position
    FROM information_schema.columns c
    WHERE c.table_schema = 'public'
    ORDER BY c.table_name, c.ordinal_position"

Also pull primary keys, indexes, foreign keys and enum labels (pg_constraint, pg_index, pg_enum on PostgreSQL; information_schema.key_column_usage + SHOW INDEX on MySQL/MariaDB).

Path A2 — driver connection (every non-Data-API engine). Do NOT assume this is impossible from a CLI. Reachability here is a network question, not an IAM one: credentials get you authenticated, but the packets still have to arrive. Work out which case you are in before falling back to Path B:

aws rds describe-db-instances --region <R> --db-instance-identifier <ID> \
  --query 'DBInstances[0].{public:PubliclyAccessible,ep:Endpoint.Address,port:Endpoint.Port,sg:VpcSecurityGroups[].VpcSecurityGroupId,subnets:DBSubnetGroup.Subnets[].SubnetIdentifier}'
aws ec2 describe-security-groups --group-ids <sg> \
  --query 'SecurityGroups[0].IpPermissions'          # is your IP/CIDR allowed on the port?
nc -zv <endpoint> <port>                              # 5s answer: reachable or not

Situation	What to do
PubliclyAccessible: true and the SG allows your egress IP	Connect directly — nothing else needed
You are on the customer's VPN / Direct Connect / a peered network, SG allows your CIDR	Connect directly
Private-only, but you have ssm:StartSession and there is an SSM-managed instance in the VPC	Port-forward (below). No bastion key, no inbound SSH, no public DB
Private-only, no tunnel available, or the customer won't grant DB access	Path B

# Private RDS via any SSM-managed EC2 instance in its VPC (needs the Session Manager plugin).
# The DB security group must allow the INSTANCE's security group on the port — not your laptop.
aws ssm start-session --target <instanceId> --region <R> \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["<db-endpoint>"],"portNumber":["5432"],"localPortNumber":["15432"]}'
# then treat the database as localhost:15432

A CloudShell VPC environment placed in the DB's VPC/subnets/SG works the same way.

Credentials: read the secret (aws secretsmanager get-secret-value --secret-id <arn> --query SecretString), or — PostgreSQL/MySQL/MariaDB with IAM database authentication enabled and the DB user mapped — mint a token instead of a password with aws rds generate-db-auth-token --hostname <ep> --port <p> --username <u> (SSL required). Then run the same catalog queries as A1 through a client: psql / mysql, or Python with psycopg2 / pymysql / pytds / oracledb — the exact drivers the webapp's image ships; pip install whichever you need. Ask for a read-only DB user; every query here is a catalog SELECT.

⚠️ Write the result with the <engine>-driver contract from the table below, never the Data API one. That mismatch is a shipped-and-broken Lambda, not a cosmetic slip.

The webapp is under the same constraint on this path and has fewer options: its ECS task sits in the app's own VPC, so it reaches a driver database only if the endpoint is publicly accessible or the VPCs are peered — it cannot open an SSM tunnel or ride a VPN. It returns CONNECTION_FAILED with the SG/route hint. A laptop with the right credentials is often better placed than the webapp here.

Path B — schema as a document. DDL dump, ERD image, data dictionary, or sample JSON payloads. Extract exact table + column names, SQL types, PK (incl. composite), FKs, indexes, enum/allowed values, NOT NULL, defaults, generated columns, and any comments carrying business rules. Ask for anything the document doesn't state — especially the caller-lookup key and enum spellings — and use explicit <REPLACE_ME> placeholders for missing ARNs, never invented values.

Both paths, then:

1. Write the result to state/infrastructure_schema.json in the same shape the webapp's converter produces, with existing: true on every table: tables[].{name, primary_key, sort_key, columns[{name, sql_type, nullable, default, generated, allowed_values, description}], indexes, foreign_keys}, relationships[], enum_types{}, data_conventions{} with REAL sampled examples, plus access_method and the connection contract that matches it — the two are not interchangeable, and lambda_generator picks its code path from access_method:

   access_method	connection	environment_variables	iam_requirements
   rds-data-api	{cluster_arn, secret_arn, database_name}	{DB_CLUSTER_ARN, DB_SECRET_ARN, DB_NAME}	rds-data:ExecuteStatement, rds-data:BatchExecuteStatement, secretsmanager:GetSecretValue
   <engine>-driver	{host, port, secret_arn, database_name}	{DB_SECRET_ARN, DB_HOST, DB_PORT, DB_NAME}	secretsmanager:GetSecretValue only

   Writing the Data API shape for a driver target is the failure this table exists to prevent: the handler then calls rds-data against a cluster that has no Data API and reads a DB_CLUSTER_ARN that was never set. A driver target also needs VpcConfig (subnets + an SG allowed on the DB port) and either a Secrets Manager interface VPC endpoint or a NAT — without one, GetSecretValue hangs until the function times out.

2. Persist the COMPLETE column list for every table, verbatim. Do not hand-write an abbreviated summary of "just the columns this operation needs" — the sql_* checks in validate_consistency.py compare generated SQL against this file, so any column you omit becomes invisible to the gate and a hallucinated reference (order_items.product_name when it lives on ) ships and fails at runtime with SQLState 42703. Completeness here is what makes the gate work.

Aurora Data API also has a minimum engine version; if the cluster is older, the driver path is the only option — flag it instead of emitting Data API code. Phase 1 then runs unchanged, passing existing_tables[] (with table_arn: "existing table - managed outside CloudFormation") and include_sample_data=False.

INTERVIEW MODE — gather requirements

Load resources/orchestrator/interview_agent.md as your active persona and run it (option-based questioning, PM mindset, mandatory DB-type question, RDS/Aurora Data API guidance, nested/enum/array field-fidelity rules, DDL→FieldSpec mirroring).

For a scoped run, run a FOCUSED interview — ask only what the in-scope asset needs (e.g. a Contact-Flow-only run asks about call direction, greeting, menus, and escalation — not about DB tables or API fields).

End every interview turn with an explicit, answerable next-step prompt (the CLI substitute for the webapp's input_hint), e.g. "다음으로 환불 가능 기간(일)을 알려주세요, 아니면 '건너뛰기'라고 답해주세요."

Checklist before leaving interview mode — every operation must have:

• operation_id (snake_case, verb_noun)
• input_fields[] / output_fields[] with name (camelCase), field_type, required — output_fields MUST include a branchable discriminator (verified/found/ success/status/…) plus errorCode (string) and message (string): the Lambda and OpenAPI generators emit both unconditionally on every response, so a spec that omits them fails the shape_parity.py HARD GATE on every run
• success_status_code when success is not 200 (e.g. 201 for a create operation)
• primary_key_field (if DB-backed)
• data_source (db_type, table_name) — optional for stateless ops
• tools[] with role: "primary" and any helpers
• business_rules[] — verbatim from the customer
• conversation_script / conversation_steps[] — verbatim if the customer gave one

Validate, then save:

python resources/scripts/check_spec_complete.py <output_dir>

Save each OperationSpec to state/specs/<operation_id>.json (schema: resources/schemas/OperationSpec.schema.json), plus state/infrastructure_schema.json and state/session_flow_config.json (schemas: InfrastructureSpec, SessionFlowConfig). If the interview captured a phone-based customer lookup, set infrastructure_schema.include_customer_phone_lookup and infrastructure_schema.test_phone_number.

If incomplete → keep asking. If complete → confirm with the user, then generate.

GENERATION MODE — produce the asset packages

One phase per turn — HARD STOP between phases. After each phase: report the result, ask to proceed, and END your turn (don't chain phases). This mirrors the webapp's turn discipline and keeps the run reviewable. In a scoped run, only the in-scope phases below execute; mark the rest "skipped (not in scope)".

Phase	Sub-agent persona	Inputs	Output
1	infrastructure_generator	all specs + infra schema	infrastructure/template.yaml (+ state/infrastructure_schema.json = the Schema Summary every later phase consumes)
2	lambda_generator (per tool)	tool spec + infra schema	lambda/<tool_id>/index.py
3	openapi_generator	all tools	openapi/openapi.yaml
4	prompt_generator	all specs + flow config	prompt/ai_agent_prompt.yaml
5	contact_flow_generator	flow config + prompt	contact_flow/contact_flow.json
6	faq_generator (optional)	company profile / research	faq/<category>/*.txt
7	Review gate (reviewer_agent + 3 validators)	all of assets/v1/	state/review_report.md

Run resources/scripts/lint_assets.py <output_dir> at the end of every phase (Phase 0 excepted) before you report the result — it is cheap, deterministic, and catches the failures that otherwise surface only at CloudFormation deploy or flow import time. See Validation below for the full gate list.

Granularity & special Lambdas (Phase 1–2) — easy to get wrong:

• One Lambda per TOOL, not per operation. Enumerate every tool id across all specs (primary tools + helper tools + session tools like log_call_result); one Lambda per tool id. A single operation may yield several tools.
• Phase 1 fan-out/merge: generate the infra base first (DDB, S3, IAM, API Gateway RestApi, sample data, Outputs), then a per-tool fragment for each tool, then deterministically merge — for >4 ops, insert additional resources at the # --- ADDITIONAL RESOURCES ANCHOR --- marker by pure string insertion (no YAML parse, to preserve !Ref/!Sub).
• customer_lookup Lambda: if phone-based lookup is enabled, generate a customer_lookup Lambda invoked directly by the Contact Flow (not via API Gateway, not in openapi.yaml).
• update_q_session Lambda: do NOT generate it. Copy the fixed Node.js handler from resources/templates/update_q_session/index.js to assets/v1/lambda/update_q_session/index.js. It is flow-invoked and excluded from OpenAPI and the infra fragments (see that file's README).
• For >6 OpenAPI operations, generate base + chunks and merge at the anchor too.

Web research (optional, offered not forced): for company profile / external API shape, adopt resources/sub-agents/research_agent.md and use the harness's native WebSearch / WebFetch tools (the backend's web_search→WebSearch, fetch_webpage→WebFetch). Honor research depth (light/standard/deep) and the boundary: web research is for company/API research, NOT Contact-Flow block syntax. For flow-block syntax, the primary source of truth is the API-verified resources/reference/contact_flow_block_schemas.md (the CLI stand-in for the webapp's curated RAG knowledge base); fall back to WebSearch/WebFetch against docs.aws.amazon.com/connect only for blocks it doesn't cover. Print queries and save a cited note to state/research/<topic>.md.

How to run each sub-agent

The skill does NOT spawn real sub-agents. For each phase:

1. Read the matching persona from resources/sub-agents/ (and always _shared_rules.md first — the cross-generator golden rules + the Complete/Escalate tool-result contract).
2. Adopt it as your active system prompt for that phase.
3. Read the input specs from state/.
4. Write the asset to the path in the table.
5. Respond in the compact CLUES format (resources/scripts/clues_format.py):

   ## Result Summary (CLUES Format)
   **Status**: success | partial | failed
   **Agent**: <sub-agent name>
   **Operation**: <op_id or __all__>
   ### Key Findings
   <3–5 bullets>
   ### Generated Artifacts
   - <path>
   ### Issues
   <none | bullets>
   

Progress reporting

Reproduce the webapp's 4-phase / 12-step progress so the user always knows where they are. Print a phase header and a ticking checklist at each phase boundary.

• Phases: interview → generation → review → post_generation.
• 12 steps: interview → database, operations, requirements, research; generation → lambda, prompt, openapi, contact_flow, cdk, knowledge_base; review → review; post → ready.
• When you advance a phase, backfill all earlier-phase steps to ✅.
• In a scoped run, mark out-of-scope generation steps "skipped (not in scope)" but keep the shared steps (database, operations, requirements, research, review, ready).
• Persist the checklist to state/progress.json and re-read it each turn.

Example header:

=== Phase 2/4 · Generation ===  (scope: contact_flow)
[✓] database   [✓] operations  [✓] requirements  [✓] research
[ ] lambda (skipped)  [ ] prompt (skipped)  [ ] openapi (skipped)
[▶] contact_flow      [ ] cdk (skipped)     [ ] knowledge_base (skipped)

Validation

Before each generation phase beyond #1: confirm the previous phase's artifacts exist on disk.

Three deterministic (non-LLM) gates carry the webapp's whole safety net. Run them — your reading of a file is not a substitute:

Script	What it gates	When
resources/scripts/lint_assets.py	per-asset syntax + import-safety, with auto-fixes	after every generation phase
resources/scripts/validate_consistency.py	18 cross-asset consistency checks	after Phase 3 and Phase 6
resources/scripts/shape_parity.py	spec ↔ OpenAPI shape parity (reviewer HARD GATE)	after Phase 3, again at Phase 7

All three take <output_dir>, accept --json, exit 0 on success and 1 on findings, and resolve assets from the newest assets/vN/ (a flat assets/ also works).

Asset linters — after EVERY generation phase. lint_assets.py is generated from the webapp's asset_linters.py, so it enforces exactly what the webapp enforces:

python3 resources/scripts/lint_assets.py <output_dir>          # report
python3 resources/scripts/lint_assets.py <output_dir> --fix     # apply deterministic fixes

It runs, per asset type:

• Lambda — Python compile() syntax check, then BUSINESS_OUTCOME_200: rewrites create_response(4xx, …) business outcomes to 200 (5xx is preserved) and warns when the body has no outcome discriminator.
• CloudFormation — cfn-lint plus deterministic autofixes (pip install cfn-lint; without it you get autofixes but no validation, and it says so).
• OpenAPI — openapi-spec-validator plus autofixes (pip install openapi-spec-validator).
• Contact Flow — the API-verified block tables: renames invalid Types, adds required error branches, strips Transitions from terminal blocks, normalizes the Complete/Escalate tool-result values, checks JSONPath roots and redaction languages.
• AI prompt — the qconnect variable-once rule.

NEEDS FIX lines mean the fix is available but unapplied; re-run with --fix, then re-lint. A repaired Contact Flow may be shorter than the draft — that is correct.

Cross-asset consistency — after Phase 3 and Phase 6:

python3 resources/scripts/validate_consistency.py <output_dir>

18 checks, the same ones the webapp runs after every generation phase:

spec ↔ generated asset — lambda_input (spec input never read by the handler), lambda_output (spec output absent from the response body), lambda_tool (ToolSpec input never read by its handler), openapi_input / openapi_output, infra_pk (spec primary key is not a key on the infra table), lambda_gsi (IndexName= that is not a GSI), lambda_env (*_TABLE_NAME the schema never defines), response_structure (data wrapper on one side only), count_lambda / count_openapi (fewer handlers/paths than specs — or than tools).

IAM (D2) — iam_permissions: the handler calls an AWS API its CloudFormation role never grants (this is the AccessDeniedException you'd otherwise find at runtime).

RDS Data API contract (D3) — rds_env_contract: the env-var names are exactly DB_CLUSTER_ARN, DB_SECRET_ARN, DB_NAME (not RDS_CLUSTER_ARN, SECRET_ARN, …) and the template actually defines each one, or the function KeyErrors on cold start. rds_data_api: includeResultMetadata=True is passed, rows are read by column name rather than by position, and SQL is not built by string interpolation.

SQL vs the database schema (D4/D5) — sql_schema_mismatch (a column the resolved table does not have → SQLState 42703), sql_type_mismatch (a ::cast to a type the schema never defines), sql_missing_required_column (an INSERT that omits a NOT NULL column with no default), sql_param_type_mismatch (a :param bound with the wrong Data API value key — longValue for integer types, booleanValue for bool, stringValue for char/text; date/uuid/json/enum/numeric legitimately take stringValue). These only work if state/infrastructure_schema.json holds the complete column list (see Phase 0).

Shape parity — after Phase 3:

python3 resources/scripts/shape_parity.py <output_dir>

This is the reviewer's HARD GATE: every spec field_type must map to the OpenAPI type, enums must match exactly, nested items.properties must survive, and neither side may declare a property the other doesn't. It enforces on the OpenAPI side what golden rules 13/15/16 ask the generators to do, and it covers multi-tool specs (each tools[].input_fields / output_fields), not just the operation-level fields. An exit code of 2 means the document uses a construct the validator refuses to guess at — oneOf/anyOf/allOf or an external $ref — so flatten it into a plain schema.

On a mismatch: field rename/typo → Edit the offending file (don't regenerate); structural mismatch → re-run the specific sub-agent persona with a modification_request ("Patch only the mismatch for <op_id>; preserve everything else").

Phase 7 — Final review gate (MANDATORY)

After the last generation phase, complete all five before declaring done:

1. Artifact presence — every in-scope output path exists and is non-empty.
2. lint_assets.py exits 0 with no pending fixes.
3. validate_consistency.py exits 0.
4. shape_parity.py exits 0.
5. Reviewer pass — adopt resources/sub-agents/reviewer_agent.md, read all assets/v1/ artifacts, and Write state/review_report.md with sections: ## Summary (one sentence per asset), ## Consistency findings, ## Recommended edits (empty = clean), ## Verdict (READY_TO_DEPLOY | NEEDS_EDITS). Write the report in the user's language.

If NEEDS_EDITS, apply edits via Edit (never whole-file regen) and re-run the three scripts. Surface READY_TO_DEPLOY only once all five pass — and quote the three exit codes in the report so the user can see the gates actually ran.

Patch-only modification protocol (post-generation)

After assets exist, the user will request changes. This is the same patch-only discipline the webapp's REGENERATION mode enforces — never regenerate a whole file.

1. Classify the request.

User says (any language)	Canonical target
"change the Lambda / 코드 고쳐줘 / validation"	lambda_generator
"fix the OpenAPI / API spec"	openapi_generator
"change the prompt / persona / 말투"	prompt_generator
"edit the flow / 메뉴 / transfer / 분기"	contact_flow_generator
"change the table / GSI / infra"	infrastructure_generator
"rename field X → Y"	spec-level (see #3)

2. Disambiguate the AMBIGUOUS bucket FIRST. "greeting", "tone", "scenario", "message" can live in the prompt or the flow. Ask which one before editing — don't guess.

3. Spec-level vs asset-level.

• Asset-level (copy tweak, message text, single-file fix): Read the file, then Edit with a minimal diff. Print the unified diff of what you changed (the CLI substitute for the webapp's Compare view).

• Spec-level (add/remove/rename a field, change a business rule, change auth): update state/specs/<op>.json first, run a change-impact analysis, confirm the blast radius with the user, then patch each affected asset via Edit:

  Change type	Affected artifacts
  Add/remove/rename field	spec → infra → Lambda → OpenAPI → Prompt
  Business-rule change	spec → Lambda → Prompt
  Dialogue/greeting change	spec → Contact Flow → Prompt
  Auth method change	spec → Lambda (auth) → Prompt (auth guidance)
  Simple copy tweak	the single affected asset only

4. Repeat-correction guard. If the same fix fails to land twice, STOP patching and ask the user to clarify rather than thrashing the file.

5. After a fix, end your turn. Report what changed (with the diff) and wait. Do NOT auto-trigger a fresh review or chain unrequested fixes. Re-run the reviewer only when the user explicitly asks ("다시 검토 / review again") — otherwise read the saved state/review_report.md to recall what an item refers to.

Cross-generator golden rules (ALWAYS apply)

Read the full resources/sub-agents/_shared_rules.md before Phase 1 — it carries all 17 rules and the AI-bot↔flow tool-result contract. The essentials:

1. BUSINESS_OUTCOME_200_RULE (rule 17, CRITICAL) — an Amazon Connect AI agent treats any non-2xx as a broken tool and never reads the body, so it can't tell "no reservation found" from "the API is down". Every business outcome — not found, not eligible, already cancelled, validation rejected — returns HTTP 200 with a body discriminator (success/found/eligible/errorCode/…) and a customer-readable message. Only genuine 5xx server faults stay non-2xx. lint_assets.py rewrites 4xx business outcomes for you; the point is to not write them in the first place.
2. HTTP_METHOD_RULE — spec verb == OpenAPI verb == CFN HttpMethod, exactly.
3. PATH_PREFIX_RULE — OpenAPI paths: start with /tools/; the CFN ApiEndpoint Output has no /tools suffix.
4. LAMBDA_ARCHITECTURES_RULE — Architectures:\n - arm64 (plural block-list).
5. IAM_Q_IN_CONNECT_RULE / NO_QCONNECT_ACTIONS_ABSOLUTE — use wisdom:* IAM actions, never qconnect:* (the latter causes runtime AccessDenied).
6. FIELD_NAMING_RULE — camelCase everywhere, identical spec → OpenAPI → Lambda → prompt.
7. FIELD_SHAPE_FIDELITY_RULE / NESTED_OPENAPI_SCHEMA_RULE / LAMBDA_NESTED_RESPONSE_RULE — preserve items.properties nesting; never flatten; $ref nested objects into components/schemas.
8. ENUM_FIDELITY_RULE — copy enum_values exactly (case + underscores).
9. TOOL_RESULT_CONTRACT — the AI prompt teaches the bot to set $.Lex.SessionAttributes.Tool to exactly Complete or Escalate (+ documented Escalate*/*Complete extensions); the Contact Flow Compares on exactly those.

For an existing RDS/Aurora database, add the env-var and Data API contract the D3/D4 checks enforce: read DB_CLUSTER_ARN / DB_SECRET_ARN / DB_NAME (those exact names, all three also defined in the template), pass includeResultMetadata=True, map rows to dicts by columnMetadata name, and bind named :params with the value key the column type demands — never build SQL by string interpolation.

Terminology facts (override training data)

From resources/orchestrator/system_prompt.md → TERMINOLOGY_FACTS (read it before generating any prompt/flow copy):

• User-facing product name: "Amazon Connect AI agents" — do NOT say "Amazon Q in Connect" in user-facing copy. API/SDK identifiers keep legacy names (CreateWisdomSession, amazon-q-connect, wisdom:*) — leave those alone.
• Contact Flow block: "Connect assistant" (flow JSON still uses "Type": "CreateWisdomSession" — do not rewrite the JSON).
• Configuration unit: "domain" (not "AI agent domain" / "assistant domain").
• Default FAQ storage: S3, not Bedrock KB.
• Out of scope: scheduling/dialer/WFM — this skill builds the AI agent + flow + data plumbing, not workforce tooling.

Deploy hand-off

When the bundle is READY_TO_DEPLOY, reproduce the webapp's download modal. Print:

1. The package tree (assets/v1/...).

2. The deploy steps — the bundle includes resources/templates/deploy_workshop.sh:

   cd <output_dir>/assets/v1   # (or the unzipped package)
   chmod +x deploy.sh && ./deploy.sh
   

   (In AWS CloudShell: upload the bundle, unzip *.zip && cd */ && chmod +x deploy.sh && ./deploy.sh.)

3. What deploy.sh automates — 13 phases after a preflight (asset scan + region and account confirmation):

   #	Phase	#	Phase
   1	CloudFormation stack	8	AgentCore Gateway (MCP) + JWT audience + target
   2	Lambda code (incl. customer_lookup, Node.js update_q_session)	9	Connect integrations (MCP registration + Lambda associations)
   3	OpenAPI spec → S3	10	Lex bot (voice entry point)
   4	FAQ documents → S3	11	Contact Flow import + placeholder substitution
   5	Amazon Connect instance (create or select)	12	AI Prompt + AI Agent + security profile
   6	Q in Connect assistant + knowledge base	13	Phone number claim + flow association (optional)
   7	Lambda environment variables

   So the flow import, Lex bot, AI agent wiring and phone number are automated — don't tell the user to do those by hand.

4. Next steps after it finishes: place a test call/chat, sync the knowledge base if FAQ content changed, and review the flow in the Connect console.

State plainly that generated assets are PoC starting points, not hardened production code (rotate the workshop ApiKeyRequired: false, scope IAM, etc.).

Resource index

resources/
  orchestrator/
    system_prompt.md            # full orchestrator prompt (COMMON + TERMINOLOGY + all phases + ATTACHMENT_HANDLING + REGENERATION)
    interview_agent.md          # INTERVIEW MODE persona (full + scoped)
    document_analysis.md        # raw-requirements-doc entry mode
    operation_spec_template.md  # OperationSpec authoring template (verbatim placeholders)
  sub-agents/
    _shared_rules.md            # 17 golden rules (incl. BUSINESS_OUTCOME_200_RULE) + Complete/Escalate contract + nested-field rendering
    infrastructure_generator.md  lambda_generator.md  openapi_generator.md
    prompt_generator.md          contact_flow_generator.md  faq_generator.md
    research_agent.md            reviewer_agent.md
  reference/
    vision_import.md            # flow-image → Contact Flow JSON transcription contract (authored)
    contact_flow_block_schemas.md  # API-verified block Types + per-block params (authored)
  schemas/
    OperationSpec / InfrastructureSpec / ToolSpec / FieldSpec / DataSourceSpec /
    BusinessRule / ErrorResponse / SideEffect / ConversationStep /
    SessionFlowConfig / ContactFlowSpec / FlowBehavior / CustomerInfoVariable /
    NoResponsePolicy .schema.json
  scripts/
    lint_assets.py              # per-asset linters + autofixes — AUTO-GENERATED from
                                # backend tools/asset_linters.py; do not hand-edit
    validate_consistency.py     # 18-check cross-asset validator (stdlib + PyYAML)
    shape_parity.py             # spec ↔ OpenAPI shape parity HARD GATE
    check_spec_complete.py       clues_format.py
  templates/
    pre_questionnaire_template.md
    deploy_workshop.sh
    update_q_session/index.js   # FIXED Node.js Lambda — copy into the bundle, do not generate
  examples/
    sample_hotel_complete.md  sample_airline_english.md
    sample_clinic_minimal.md  sample_ecommerce_partial.md

Re-syncing from the webapp

After editing any prompt in backend/ecs/src/ or a Pydantic spec model, re-run:

skills/aicc-builder-skill/scripts/extract_prompts.sh          # regenerate resources/
skills/aicc-builder-skill/scripts/extract_prompts.sh --check  # CI/pre-commit drift + coverage gate

--check also fails if a NEW backend prompt section or spec model isn't covered by the extractor — so the skill can't silently fall behind.

Auto-extracted (never hand-edit): resources/orchestrator/*.md, resources/sub-agents/*.md, resources/schemas/*.json, and resources/scripts/lint_assets.py (generated from tools/asset_linters.py with the @tool S3 wrappers stripped — that is how the API-verified Contact Flow tables stay in sync).

Authored / hand-maintained: resources/reference/*, resources/templates/* (incl. update_q_session/index.js and deploy_workshop.sh), resources/examples/*, resources/scripts/validate_consistency.py, resources/scripts/shape_parity.py, resources/scripts/check_spec_complete.py, resources/scripts/clues_format.py, and these SKILL.md files. validate_consistency.py and shape_parity.py are ports of backend/ecs/src/tools/{validate_consistency,shape_parity}.py — when a check changes there, port it here by hand and re-run the smoke tests.