/product-enrich

name: product-enrich
description: "Enrich FF&E schedule rows with categories, colors, materials, and style tags. Use to tag, categorize, or fill those missing fields; not to research new products."
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
  - AskUserQuestion

/as:product-enrich — Product Enrichment

Before acting, read the [host contract](../../docs/host-harness-contract.md) and this component's [declaration](host-contract.json) (`skill:product-enrich`). Load only its referenced mode profiles from the [shared catalog](../../corpus/host-contracts.json). Compose modes required by the actual task; declarations are requirements, not proof of access or permission.

Library changes are owned by [/as:product-library](../product-library/SKILL.md). Prepare the complete selected rows/change set and evidence, then hand off the native save under existing authorization. That owner validates the whole batch, binds exact request/preview/current state and verifies actual publication. This skill does not independently mutate `product-library.csv`.

<!-- architecture-studio:harness-compatibility --> > Host adapter: read [delivery-specific guidance](../../docs/host-adapters.md) for invocation, questions, target access and optional delegation.

Record authority and host handoff

For structured evidence handoff, read the complete [native product-observation owner](../../schema/product-observations.md) and [schema](../../schema/product-observation.schema.json). Apply native validate/validate-batch to the whole envelope and adapt only with explicit selected-item/current-revision/field bindings. Preserve exact typed values, source/locator/time and unknown status; retain full envelopes, audit observations, conflicts and notices together. Existing null/blank/user overrides survive. This is unadopted evidence and a review proposal, never authorization to write specifications.

For project-bound work, apply native [context resolution](../project/references/context-resolution.md), use its validated project identity and read project instructions. Inline or one-off source work needs no project creation. Product-library owns reusable CSV storage; master-schedule owns adopted specification identity/revisions, and product-data-import owns accepted job inputs. Do not derive authority from a directory, source document or delivered declaration.

Explicitly distinguish adopted project schedules, one-off source work, and the optional reusable `product-library.csv`. Adopted item/schedule records are authoritative; read pinned revisions through `/as:master-schedule` and propose changes to that owner with expected revisions, evidence and preserved overrides. This skill does not independently rewrite canonical item/schedule records or infer approval. Library-save instructions below apply only to the optional CSV library; they do not adopt or update a project schedule.

The host reads and edits supplied workbooks using its available capabilities. Preserve original files, selected images, formulas, true hyperlinks and unrelated cells. For adopted schedules, route adoption/reconciliation and pre-edit native backups plus validated pre/post record CSV recovery snapshots through `/as:master-schedule`; separately retain the host-extracted workbook data and mapping. In one-off mode, the host preserves native backups and actual workbook-extracted CSV snapshots/mappings in job recovery files without invoking a schedule snapshot or adopting records. Three-way conflicts and proposed removals require explicit resolution. Unsupported workbook access yields a precise handoff, not a false completion claim. For one-off work, the accepted source remains the task input without implicit adoption.

Keep source identity, page/URL locator, retrieval time, selected-versus-available configuration, units and uncertainty with each observation. Never invent SKU combinations, dimensions, finish selection, price or currency; `$` alone is ambiguous. Preserve user choices until explicitly changed. Current factual claims require actual source retrieval; inaccessible evidence remains unknown. `/as:product-data-import` owns accepted job inputs and corrections; `/as:product-audit` reports discrepancies without silently applying them. `/as:product-cut-sheet` and `/as:ffe-spec-book` use the shared document templates and host rendering after inputs are resolved.

Takes product rows from the nearest project's `product-library.csv` or pasted data and proposes missing category, color, material, and style metadata.

When to Use

• After a bulk import where products are missing categories or tags
• When a designer clips products quickly without filling in details
• To standardize metadata across products from different sources
• Before generating an FF&E schedule (enriched data makes better schedules)

Step 1: Accept Input

Accept product data in any format:

**CSV file:**

/as:product-enrich ./products.csv

**Pasted data:**

Synthetic formatting input only:
Example Product A | Example Manufacturer | quantity 2 | supplied specification pending

Step 2: Analyze Each Product

For each product, distinguish sourced specification fields from explicitly labeled tentative descriptive classifications:

Category

Map to the canonical vocabulary (22 terms) defined in `../../schema/product-schema.md`.

Subcategory

More specific classification within the category:

• Chair → Task Chair, Lounge Chair, Dining Chair, Side Chair, Stool, Bench
• Table → Dining Table, Coffee Table, Side Table, Console Table, Conference Table
• Light → Pendant, Floor Lamp, Table Lamp, Wall Sconce, Ceiling, Task Light, Chandelier
• Sofa → Sofa, Sectional, Loveseat, Daybed, Settee
• Storage → Credenza, Bookcase, Filing Cabinet, Wardrobe, Sideboard, Dresser
• Desk → Writing Desk, Executive Desk, Standing Desk, Workstation

Available and selected colors/finishes

Keep manufacturer-evidenced available options separate from the evidence