Token导航 LogoToken导航TokenDH.com
运维和基础设施只读github未标认证来源可访问许可证需确认审计通过

product-modelingproduct modeling 命令行

Agent Skill

product-modeling 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

216

周安装

9

GitHub Stars

28

下载量

72
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:product-modeling(product modeling 命令行)
来源仓库:https://github.com/saleor/configurator
仓库路径:skills/product-modeling
安装命令:
npx skills add https://github.com/saleor/configurator --skill product-modeling
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/saleor/configurator --skill product-modeling

简介

product-modeling 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中围绕项目结构、代码演进或协作流程进行建模分析。

  • 它支持产品架构与技术选型的决策辅助,可用于微服务拆分、数据流设计与依赖关系梳理等场景。
  • 通过 npx skills add https://github.com/saleor/configurator --skill product-modeling 安装,应确认 Saleor 版本兼容性。
  • 注意该技能可能解析复杂目录结构,避免误读配置文件导致错误推断。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Saleor Domain Modeling

Overview

This skill helps you design your product catalog structure in Saleor -- choosing the right product types, attributes, variants, categories, and collections. The key decisions are what makes a product vs. a variant, and which attribute type to use for each field.

When to Use

  • "How do I model my products?"
  • "What attributes should I use?"
  • "Product vs variant attributes?"
  • "When to use DROPDOWN vs MULTISELECT?"
  • "How to structure my product types?"
  • "Categories vs Collections?"
  • "When to use Models (Pages) vs Attributes?"
  • When NOT looking for YAML syntax -- use configurator-schema instead
  • When NOT looking for CLI commands -- use configurator-cli instead

The Core Flow

This is the most important relationship to understand:

1. ATTRIBUTES (define fields)
   └── Reusable typed fields: Size (DROPDOWN), Color (SWATCH), Brand (DROPDOWN)

2. PRODUCT TYPES (define structure)
   └── Assign attributes:
       ├── productAttributes: Brand, Material (same for all variants)
       └── variantAttributes: Size, Color (create SKU combinations)

3. PRODUCTS (create items)
   └── Instance of a ProductType:
       ├── Set values: Brand="Nike", Material="Cotton"
       └── Define variants with SKU combinations

4. VARIANTS (purchasable SKUs)
   └── Each combination = 1 variant:
       ├── SKU: "TSHIRT-BLK-M" -> Size="M", Color="Black", Price=$29.99
       └── SKU: "TSHIRT-WHT-L" -> Size="L", Color="White", Price=$29.99

Key insight: Attributes are building blocks. ProductTypes assemble them into templates. Products are instances. Variants are what customers buy.

Decision Framework: Product vs Variant Attributes

This is the most critical modeling decision.

Use Product-Level When:

QuestionIf YES, use Product Level
Same value for all sizes/colors?Brand, Material, Manufacturer
Descriptive information?Care Instructions, Specs
For filtering/categorization only?Style, Gender, Season

Use Variant-Level When:

QuestionIf YES, use Variant Level
Creates a separate purchasable item?Size, Color, Storage
Affects price?Size (XL costs more), quality tier
Needs separate inventory tracking?Each size needs its own stock
Customer selects this at checkout?Color picker, size selector

Quick Decision Matrix

AttributeProductVariantWhy
BrandxSame for all variants
SizexCreates separate SKUs
ColorxCreates separate SKUs
MaterialxUsually same for product
Storage (64GB/128GB)xDifferent prices
Care InstructionsxSame for all variants
WeightxMay differ per size

Attribute Type Selection

Saleor supports 12 attribute input types. Use this decision tree:

Is it a CHOICE from predefined options?
├── YES: Can user select MULTIPLE?
│   ├── YES -> MULTISELECT
│   └── NO: Is it a COLOR/PATTERN?
│       ├── YES -> SWATCH
│       └── NO: Is it YES/NO?
│           ├── YES -> BOOLEAN
│           └── NO -> DROPDOWN
└── NO: Is it a NUMBER with units?
    ├── YES -> NUMERIC
    └── NO: Is it a DATE?
        ├── YES -> DATE (or DATE_TIME if time needed)
        └── NO: Is it long formatted text?
            ├── YES -> RICH_TEXT
            └── NO: Is it a file/document?
                ├── YES -> FILE
                └── NO: Link to another entity?
                    ├── YES -> REFERENCE
                    └── NO -> PLAIN_TEXT

For the complete attribute type reference, see references/attribute-types-deep-dive.md.

Variant Matrix Planning

Before creating variants, calculate the SKU explosion:

SKU Count = Value1 x Value2 x Value3 x ...

Example: T-Shirt
- Sizes: XS, S, M, L, XL, XXL (6)
- Colors: Black, White, Navy, Gray, Red (5)
- SKUs: 6 x 5 = 30 variants per product
SKU CountAssessmentRecommendation
1-10ManageableGood for most products
11-50ModerateFine for fashion, needs inventory planning
51-100HighConsider splitting into multiple products
100+Too manySimplify -- move some attributes to product level

Tips for high counts: Split by product line, reduce dimensions, move non-purchasable attributes to product level.

Industry Patterns

Quick reference for common store types:

PatternProduct-Level AttrsVariant-Level AttrsTypical SKUs
ApparelBrand, Material, CareSize, Color30/product
ElectronicsBrand, Screen, Processor, FeaturesStorage, Color20/product
FurnitureBrand, Style, Capacity, DimensionsFabric, Color16/product
Food & BeverageOrigin, Roast, Flavor, CertificationsSize, Grind12/product
Digital ProductsPublisher, Platform, FeaturesLicense Type, Duration9/product

For complete YAML examples of each pattern, see references/industry-patterns.md.

Categories vs Collections

Both organize products, but they serve different purposes:

AspectCategoryCollection
StructureHierarchical (tree)Flat (list)
Assignment1 product = 1 category1 product = many collections
PurposeTaxonomy, navigationMerchandising, promotions
ExamplesElectronics > Phones > Smartphones"Summer Sale", "New Arrivals"

Use Categories for main site navigation, browse/filter structure, SEO URLs. Use Collections for curated groups, promotions, campaigns, temporary groupings.

Keep category trees to 3 levels deep. If you need a 4th level, consider using Collections instead.

Models and Structures

Models (Pages/PageTypes) let you create custom entities beyond products -- like Brands, Ingredients, or Scent Profiles. Use them when data is shared across many products, has its own attributes, and needs its own page.

Structures (Menus) assemble Categories, Collections, Models, and URLs into navigation hierarchies.

For complete guidance and examples, see references/models-and-structures.md.

Workflow: Designing a New Product Type

  1. List all product characteristics -- write down every field/attribute
  2. Categorize each -- apply the decision framework (product vs variant)
  3. Select types -- use the attribute type decision tree
  4. Calculate SKU count -- ensure the variant matrix is manageable
  5. Write the YAML -- create the ProductType configuration
  6. Validate -- deploy with --plan to check structure

Common Mistakes

MistakeFix
Over-dimensioning variants (6 sizes x 10 colors x 4 materials = 240 SKUs)Move non-purchasable attributes to product level. Aim for under 50 SKUs.
Using variant attributes for non-inventory fieldsIf it doesn't create a separate SKU (like Care Instructions), it's a product attribute
Product attributes that should varyIf value differs by size (e.g., Weight), move to variant level
Too many product typesReuse types when products share the same attribute structure
Skipping variant planningAlways calculate SKU count before creating product types

Additional Resources

Reference Files

Related Skills

  • configurator-schema - Complete YAML schema reference
  • saleor-domain - Entity relationships and Saleor concepts
  • configurator-recipes - Complete store templates

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.23%
按下载量换算25

Claude

30.75%
按下载量换算22

Cursor

19.37%
按下载量换算14

Gemini CLI

8.99%
按下载量换算6

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills