Aeko fix technical

AEKO Fix Technical

Executor for one Technical-tab item, end-to-end: fetch Plan.md → parse frontmatter + prose → validate contract → produce artifact using embedded spec rules → write locally → mark complete. No separate backend "prepare" tools — the skill is self-contained.

Contract reference: docs/contracts/action-item-contract.md §4 (guide.md / Plan.md format for technical items), §6 (completion).

Marketer-facing output contract

Open with: what AEKO will generate, why it matters, and that this skill creates files/checklists only — it does not deploy changes or touch the live store. For robots.txt, explain "AI search/shopping tools can read public pages" separately from "training crawlers may collect content." End with Before / After / Risk / Undo and one recommended next step.

Language: mirror the user's chat language for user-facing steps, summaries, questions, and risk/undo copy. Keep slash commands, IDs, file paths, channel slugs, schema keys, JSON-LD terms, and tool names in English/ASCII. When a Plan includes target_language, treat it as the artifact/content language, not necessarily the assistant UI language.

Input

• item-id (required) — $1. If missing, stop and point user to /aeko-action-center <domain_id> technical.

Step 1 — Fetch and parse the Plan.md

Call aeko_get_action_plan(item_id). The response is a single markdown string: YAML frontmatter between --- fences + prose body. Parse both.

• frontmatter = YAML block between the opening --- and the first following --- alone on a line.
• prose = everything after the closing --- (with leading blank line trimmed).

Dispatch is driven by frontmatter. Prose is narrative guidance only.

Validate frontmatter:

• contract_version starts with 2026-04-17.action.v1. (technical items share the Plan.md contract in v0.5.0) — else stop.
• This skill is pinned to contract minor v1.2. Greater minor → print advisory (see §Copy) then proceed.
• tab == "technical" — else stop; redirect to /aeko-update-pdp or /aeko-create-content based on execution_class.
• execution_class == "technical_artifact" — else stop.
• artifact_type ∈ {llms_txt, robots_txt_patch, json_ld, technical_bundle} — else stop.
• status ∈ {pending, ready} — else stop with appropriate message.
• tier_required is enforced by backend completion/deploy surfaces when applicable; do not resolve legacy identity metadata here.

Print a plain-language header in the user's chat language, then the prose body verbatim. Translate artifact_type before showing it; for languages beyond Korean/English, use a natural plain-language label:

artifact_type	EN label	KO label
llms_txt	AI content index	AI 콘텐츠 인덱스
robots_txt_patch	AI crawler access	AI 크롤러 접근
json_ld	brand/site schema	브랜드/사이트 스키마
technical_bundle	technical health bundle	기술 상태 패키지

Header format:

1. Action label — mirror the user's chat language; KO: "기술 상태 개선: <KO label>" / EN: "Technical health fix: <EN label>"
2. Context: domain_id, target_url if present.
3. Sections: comma-joined sections_required if non-empty.

Never echo the raw frontmatter to the user.

Copy templates (user's chat language)

• Tier gate — same template as /aeko-update-pdp.
• Minor-version advisory — KO: "이 가이드는 계약 v<plan_minor> 기준입니다. 현재 스킬은 v1.2 — /plugin update aeko." / EN: "This plan uses contract v<plan_minor>; this skill is on v1.2 — run /plugin update aeko."

Step 2 — Resolve domain/context

Call aeko_get_domain_info(domain_id) for base URL, names, keywords, markets, and any site/entity context needed by the technical artifact. Ignore legacy brand_kit_id / requires_brand_kit fields if present in older Plan.md files; legacy identity metadata must not block technical artifacts.

Step 3 — Dispatch by artifact_type

Each branch uses embedded spec rules loaded from references/recipes/ instead of backend prepare-tools. Use domain info + Plan/context for site/entity context.

3.0 Load references (per-artifact, on-demand)

Anthropic progressive-disclosure pattern — recipe detail loads only when its branch runs.

For the dispatched frontmatter.artifact_type:

artifact_type	Recipe(s) to load
llms_txt	references/recipes/llms-txt.md
robots_txt_patch	references/recipes/robots-txt-patch.md
json_ld	references/recipes/json-ld.md
technical_bundle	All three of the above (per the prose's sub-artifact selection)

Always load references/recipes/deploy-checklist.md before Step 4 — it's the source for the per-platform DEPLOY.md.

Conditional loads (silent skip if absent):

• references/examples/<artifact_type>-*example*.{txt,json,md} — brand-specific exemplar; mimic its conventions on top of recipe rules.
• references/style/voice-overrides.md — domain-scoped overrides (Korean section headings, glossary, deploy notes); filter to blocks where domain: <frontmatter.domain_id> matches.

Precedence: voice-overrides > examples/* > recipes/*. Recipe spec rules (llms.txt H1 line, robots.txt syntax, JSON-LD JSON validity) cannot be relaxed by examples — the skill fails the run if violated.

3a–3d. Apply

Apply the recipe loaded for the dispatched artifact_type:

• llms_txt → see references/recipes/llms-txt.md. Output: llms.txt in the item directory.
• robots_txt_patch → see references/recipes/robots-txt-patch.md. Output: robots.txt.diff + robots.txt in the item directory.
• json_ld → see references/recipes/json-ld.md. Output: schema.json in the item directory. Note: site-level / brand-level JSON-LD only; product-level lives in /aeko-update-pdp.
• technical_bundle → run the three branches above as the prose specifies. Each sub-artifact lands in the same item directory. Compose ./aeko-artifacts/<frontmatter.domain_id>/<frontmatter.item_id>/README.md listing the sub-artifacts with deployment order. Acceptance gate for sections_required: each entry names a sub-artifact file. Missing file → iterate or fail.

Honor frontmatter must_include / forbidden / sections_required per each recipe's specifics.

Step 4 — Deploy checklist (never auto-deploy)

For all technical artifact types, write a DEPLOY.md alongside the artifact. Source: references/recipes/deploy-checklist.md (loaded in §3.0). If references/examples/deploy-notes-example.md exists, append its contents after the recipe's per-platform section.

No deploy path is wired into the MCP for v0.5.0. Always instruct manual deploy.

Step 5 — Mark complete

aeko_complete_action_item(
    item_id=frontmatter.item_id,
    artifact_summary="<one-line: artifact_type + path(s) + deploy guidance included>",
    artifact_paths=[<absolute paths of every file written>],
    write_result=None,  # technical items don't do store writes
)

Only call complete if every acceptance-gate check passed AND all artifacts were written. If complete errors, leave item pending and surface the error verbatim.

Step 6 — User-facing summary

✔ Technical fix package ready

What changed
- <plain-language summary: e.g. "AI search/shopping crawlers can read public product pages" or "brand schema file generated">

Risk
- No live site changes were deployed by this skill.
- For robots.txt, search/shopping bot access is separate from training/data crawler access.

Undo
- Do not deploy these files, or restore the previous robots.txt/schema file if already deployed manually.

Files
- <paths>

Recommended next step
- <one command or "Deploy using DEPLOY.md">

Keep refs loaded and self-validation in a short "Technical details" block after the marketer summary.

Error paths

• Plan endpoint unavailable → stop; suggest retry.
• Plan.md parse error → stop; surface exact parse failure + first 20 lines of response.
• Contract mismatch → stop; exact mismatch surfaced.
• Missing domain/context details → continue where possible and surface deployment notes; leave pending only when a required artifact cannot be generated honestly.
• Self-validation fails → do NOT call complete; write artifact anyway and tell user what to fix.
• robots_txt_patch with missing site_base_url → stop; backend data problem.

What this skill never does

• Never writes to a connected store (no PDP, no product changes).
• Never handles Action-tab items (execution_class != technical_artifact).
• Never auto-deploys — always emits a DEPLOY.md checklist.
• Never regenerates the Plan.md; fetch once, follow it.
• Never reads machine values from prose — all machine values come from frontmatter.
• Never echoes the raw frontmatter block to the user.
• Never fabricates sameAs for JSON-LD; use WebSearch + user confirmation or omit.