l-add-takazudo-product

Add a new Takazudo Modular brand product end-to-end. Sets mercariStatus: 'incoming' by default so the page goes live without a Mercari listing. Use when: (1) adding a new SKU under the Takazudo Modula...

Add Takazudo Product (Stage 1: incoming-default)

End-to-end workflow for adding a new product under the Takazudo Modular brand. The page goes live immediately with mercariStatus: 'incoming' so visitors see the Coming-Soon UI (<IncomingItem> + notify-me dialog + JSON-LD availability: PreOrder) without requiring a Mercari listing.

This skill orchestrates existing skills. It does not duplicate their content — read the linked skills when you reach each step.

When to use / when not to use

• Use when the new product’s brand is takazudo (Takazudo Modular). This skill is Takazudo-brand-scoped: it knows about brand-page-takazudo.tsx sections, the orange-fabric photo pipeline, the two-stage release model, and Takazudo-specific defaults (tags, brand value).
• Do not use for non-Takazudo brands (e.g., ADDAC, OXI Instruments, Make Noise). For those, use /l-add-product-page (the generic product-addition skill).
• Do not use for Mercari listing transitions on existing Takazudo products. For incoming → on-sale, use /l-takazudo-product-on-sale {slug} (Stage 2).

Two-stage release model

Takazudo products ship in two stages so the product page can go live before the Mercari listing is ready (orders typically aggregate over a few days before shipping the listing):

After completing Stage 1, this skill prints the hand-off line — see “Hand-off” below.

Information gathering (one question at a time)

Ask the user one question at a time and wait for the answer before moving on. Collect:

1. Slug — kebab-case, must be unique across src/data/product-master-data.mjs. Never change after creation. Example: zudo-3u-to-1u.
2. JA display name — Japanese product name shown on the brand page and detail page (e.g., zudo-3u-to-1u). Often identical to the slug for Takazudo products.
3. EN display name — English equivalent for nameEn. Often identical to the slug for Takazudo products.
4. JA description — short Japanese description (1–2 sentences) for description. Used in product cards and master data.
5. EN description — English equivalent for descriptionEn.
6. brandBasedCategory — which section of /brands/takazudo/ this product appears in. Default: accessories. Common alternatives: etc, iromihon-acr, iromihon-3dp, simpleBlankPanel, designedBlankPanel, modules, zudo-block-60, zudo-block-40, zudo-block-40-lite, zudo-rail. See components/brand/variants/brand-page-takazudo.tsx for the canonical list.
7. Tags — default: ['takazudo-modular', 'accessory']. Only registered tags allowed; check /l-tagging for rules and the registered tag list. Do not invent niche tags.
8. Price — integer yen, tax and shipping included (e.g., 1980).
9. spec — width / HP / depth as appropriate. Examples: { width: '26HP' }, { width: '40HP用' }. Match the convention used by similar existing Takazudo products in product-master-data.mjs.
10. Source photos path — directory or list of HEIC/JPEG/PNG files to be processed. Confirm the photo type (this decides whether /l-make-product-photo runs at all):
    • Already-taken final photo — top-down studio shot already on the Takazudo orange fabric, panels properly framed. The photo is already “taken” — only color normalization is needed. Skip /l-make-product-photo entirely.
    • Needs synthesis — panel-on-non-orange-backdrop (needs ML bg-removal + composite onto orange fabric) OR an incoming/stock manufacturer photo. Run /l-make-product-photo to synthesize the studio shot.

Step-by-step procedure

Step 1 — Photos

Process source photos through the standard Takazudo orange-fabric pipeline. Use the linked skills; do not re-implement their logic here.

1. Run /l-orange-tweak on the source directory (or pass the file list) to normalize the orange background tone across all photos. For already-taken final photos this is the only image-edit step needed — the photo is already framed and lit; only orange-tone normalization is required.

2. Only when synthesis is needed (see step 1.10 above): run /l-make-product-photo to bg-remove + composite onto orange fabric + add programmatic shadows. Decide flags per image (read the skill’s “Deciding flags per image” section):

   • Modular synth panels on a non-orange backdrop (visible panel edges, jacks, knobs, ML can isolate) → --shadow --float
   • Desktop / standalone product on a backdrop → --shadow (no --float; grounded shadow)

   Skip this step entirely when the source is an already-taken top-down photo on the orange fabric. Synthesizing shadow on a flat top-down photo darkens the corners with a fake vignette instead of producing depth — the image looks worse, not better. (--shadow exists for the “incoming photo / bg-removed composite” path, not for finished studio photos.)

3. Move processed images into /imgs/ (the Dropbox symlink) using the slug-based naming convention {slug}-view{N}.heic (or .jpg). Mark the image you want as the OGP source with the __og suffix — typically {slug}-view5__og.heic. See /l-img-convert-workflow for the OGP suffix rules (__og, __ogonly).

4. Run /l-metadata-update to:

   • convimgs + R2 upload
   • regenerate metadata-db.json
   • merge the metadata update to main via a metadata-update-* skip-CI branch
   • return to the original branch

   🚨 MANDATORY — DO NOT SKIP. 🚨

   /l-metadata-update (or, at minimum, pnpm build:metadata + a committed metadata-db.json change reaching main) is non-negotiable when new image slugs are added. The most common silent-failure mode for this skill is: convimgs runs, the WebP / blurhash / mercari.png / ogp.jpg files all upload to R2 successfully, but metadata-db.json is never regenerated or never committed. The site then deploys with the new product page wired to slugs the build-time DB has no record of, so the home-page card renders a black-square blurhash placeholder and the product detail page renders an empty <ImgsGrid>. This is what hit zudo-3u-to-1u on 2026-05-02.

   Verification before declaring Step 1 done:

   # Every slug you just added must appear in metadata-db.json (count must match new slug count)
   for s in <slug>-view1__og <slug>-view2 <slug>-view3 ...; do
     grep -q "\"$s\"" metadata-db.json || echo "MISSING: $s"
   done

   If any slug is missing, Step 1 is not done — re-run /l-metadata-update (or finish the manual pnpm build:metadata + commit + merge to main path).

After /l-metadata-update finishes, pull main into your working branch so the new metadata is visible locally:

git fetch origin main && git merge origin/main --no-edit

Never put files directly into static/images/p/ — always go through /imgs/ → convimgs → R2.

Step 2 — Master data

Edit src/data/product-master-data.mjs. Insert the new entry at the top of the allProducts array (newest products go first).

Required fields for a Takazudo Stage-1 product:

{
  slug: '<slug>',                              // kebab-case, unique
  name: '<JA display name>',                   // step 1.2
  nameEn: '<EN display name>',                 // step 1.3
  brand: 'takazudo',                           // always for this skill
  brandBasedCategory: '<category>',            // step 1.6 (default 'accessories')
  imgSrc: '/images/p/<slug>-view5__og',        // OGP-suffixed thumbnail slug
  description: '<JA description>',             // step 1.4
  descriptionEn: '<EN description>',           // step 1.5
  detailHref: '/products/<slug>-intro/',       // matches MDX file name
  price: 1980,                                 // integer yen, tax + shipping
  mercariProductId: '',                        // Stage 1: always empty
  mercariStatus: 'incoming',                   // Stage 1: explicit 'incoming'
  spec: { width: '26HP' },                     // step 1.9
  tags: ['takazudo-modular', 'accessory'],     // step 1.7
},

Notes:

• mercariStatus: 'incoming' is the inaugural explicit use of this field in master data. The type ('sold' | 'incoming' | 'discontinued' | 'askToBuy') lives in lib/utils/types.ts and the UI has been wired up since earlier work — Stage 1 makes the field actually appear in master data.
• imgSrc references a slug, not a file path. The trailing __og suffix matches the source filename in /imgs/ (e.g., <slug>-view5__og.heic). See the OGP convention in /l-img-convert-workflow.
• mercariProductId must be empty string '' in Stage 1. Stage 2 (l-takazudo-product-on-sale) fills it in once the Mercari listing exists.
• For multi-variant Takazudo products that share a single detail page (like zudo-stand-*), see /l-add-product-page Pattern B — the same multi-entry/shared-detailHref rules apply, but each variant entry still carries mercariStatus: 'incoming' until its individual Mercari listing lands.

Step 3 — JA MDX

Create src/mdx/products/<slug>-intro.mdx. Mirror the structure of existing Takazudo product MDX files, e.g. src/mdx/products/zudo-bus-intro.mdx or src/mdx/products/zudo-stand-intro.mdx.

Frontmatter shape (consult /l-tagging before choosing tags/categories):

---
title: "Takazudo Modular: <name>"
description: "Takazudo Modular: <name>の紹介です。<short description>"
imgThumb: <slug>-view5__og
avoidListing: false
product: <slug>
tags:
  - takazudo-modular
  - accessory
categories:
  - products-intro
contentType: products
createdAt: YYYY-MM-DD
updatedAt: null
---

Body section outline (Japanese-text rules apply — see the Notes section):

1. Intro paragraph — what the product is in 1–3 sentences.
2. <MercariNav ids={['<slug>']} /> — because mercariStatus: 'incoming', this auto-renders <IncomingItem> (Coming-Soon badge + notify-me dialog) for the slug. No special component needed.
3. ## TOC
4. ## 商品写真 — use <ImgsGrid> / <ExImg> to display the processed view-N images.
5. ## 機能 (or ## 概要) — overview of how the product works.
6. ## セット内容 — what ships in the box (panels, hardware, screws, etc.).
7. ## 取り付け — installation/mounting notes if applicable (skip if not).
8. ## 価格 — price line in **¥1,980** format with tax/shipping note.
9. ## 開発について — short development background, mirroring the tone of zudo-bus-intro.mdx / zudo-stand-intro.mdx.
10. <Outro> — closing paragraph, repeat <MercariNav ids={['<slug>']} />, sign off.

For multi-variant products, pass all variant slugs to <MercariNav> and use a series-scoped MercariNav component as documented in /l-add-product-page (Step 3 there).

Step 4 — EN MDX

Create the English translation at src/mdx/products/<slug>-intro.en.mdx. Use one of:

• /l-create-en-implementation — preferred when the JA branch already has a PR; this auto-detects the PR, scaffolds, translates, and creates an EN PR targeting the JA branch.
• en-translator agent (via the Task tool) — for one-off translation when there is no JA PR yet.

Both use the same translation conventions and write .en.mdx next to the JA file.

Step 5 — Brand-page check

Open components/brand/variants/brand-page-takazudo.tsx and confirm there is already a <BrandProductSection> consuming the brandBasedCategory you chose. The current sections are:

zudo-block-60, zudo-block-40, zudo-block-40-lite, accessories, modules, designedBlankPanel, iromihon-acr, iromihon-3dp, simpleBlankPanel, zudo-rail, etc.

If the category is missing, add a new <BrandProductSection> at an appropriate position with both JA and EN titleSub strings (the file is server-rendered Astro/Preact; it accepts a locale prop and gates strings via isEn).

For most new accessory-style Takazudo products you will land in the existing accessories section and no edit is needed.

Verification

Run the standard checks before reporting Stage 1 complete:

pnpm check          # typecheck + lint + format + MDX validation
pnpm test:unit      # unit tests
pnpm dev            # smoke test (zmod.localhost:34434)

Manually confirm in the dev server:

• /products/<slug>-intro/ renders. The MercariNav block renders <IncomingItem> (Coming-Soon badge
  • notify-me dialog), not the Mercari purchase button.
• View-source on the page shows JSON-LD with "availability": "https://schema.org/PreOrder".
• /brands/takazudo/ shows the new product card under the chosen brandBasedCategory section.
• /en/products/<slug>-intro/ renders the EN translation correctly (when EN MDX exists).

Hand-off

Once Stage 1 is verified and committed, print the hand-off line so the user knows what to run when the Mercari listing is ready (typically a few days later):

Stage 2 — when Mercari listing is ready, run /l-takazudo-product-on-sale {slug}.

That partner skill flips mercariStatus off and sets mercariProductId so the page transitions from Coming-Soon to live-purchase.

Notes

• Japanese text rules: use 商品詳細 (product details), not 商品紹介 (product introduction), when referring to the detail page. See src/CLAUDE.md.
• Slugs: kebab-case only, unique across master data, never changed after creation. The slug is also the source-image stem in /imgs/ (e.g., zudo-3u-to-1u-view5__og.heic).
• Tags: only registered tags from lib/data/taxonomy-products.ts. Blacklisted tags fail the build. See /l-tagging for the full rules.
• OGP convention: the OGP source image carries the __og suffix in its filename (e.g., <slug>-view5__og.heic). The slug is the filename without extension — there is no slug stripping. __ogonly is for OGP-only images with no display variants. See /l-img-convert-workflow for the full convention.
• Image safety: never put files directly into static/images/p/. The pipeline is /imgs/ → convimgs → R2, always. /l-metadata-update handles steps 2–4 of that pipeline.
• mercariStatus: 'incoming' is explicit in Stage 1 — do not omit it. Pages without mercariStatus fall back to the regular Mercari purchase UI, which would render a broken state when mercariProductId is empty.

Related skills

• /l-orange-tweak — orange-fabric background normalization (Step 1.1).
• /l-make-product-photo — bg removal + 1600×1600 standard product photo (Step 1.2).
• /l-img-convert-workflow — /imgs/ → R2 pipeline, OGP suffix conventions, MDX image fields.
• /l-metadata-update — convimgs + R2 upload + metadata-db.json regeneration on main (Step 1.4).
• /l-create-en-implementation — EN translation workflow targeting the JA PR (Step 4).
• /l-tagging — tag rules, blacklist, registered taxonomy.
• /l-takazudo-product-on-sale — Stage 2 partner skill (incoming → on-sale).
• /l-add-product-page — generic fallback for non-Takazudo brands and for the multi-variant pattern reference (Pattern B).