new-product-domain

星标1

分支1

更新时间2026年7月31日 18:47

Author a complete, balanced, realistic product domain from scratch under _config/product-domains/<domain>/ — framing, customers, strategy, products/deployment, product bricks, streams, data assets, teams, competition, and evidence — in the right dependency order, with cross-file references kept consistent and docs regenerated. Use when creating a brand-new domain end-to-end, not editing one artifact. Orchestrates the edit-* skills and the validate/audit gates.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

zeljkoobrenovic

zeljkoobrenovic/spec-driven-product-architecture

打开 GitHub 仓库查看创作者相关仓库

下载

New Product Domain (orchestrator)

End-to-end workflow for building a whole domain. It composes the per-artifact edit-* skills in dependency order so cross-file references resolve as you go, and gates the result with validate-domain and audit-domain-balance. Read .claude/skills/_references/domain-model.md first.

This is a large, multi-step task — track it with a task list and build incrementally, validating after each artifact rather than at the end.

Before starting

Inspect two comparable existing domains and the reference ride-sharing-marketplace for shape and density. Copy its structure, not its content.
Targets for a mature domain: ~4 customer groups with real personas, 20+ bricks across 3 group levels, 15+ data assets, 8+ teams, 8+ competitors, 8+ sourced insights. A smaller domain is fine if intentional — say so.
The new-domain prompt scaffold lives next to this skill: .claude/skills/new-product-domain/NEW-DOMAIN-PROMPT.md.

Build order (dependencies flow downward)

Author top-to-bottom; later artifacts reference earlier IDs, so this order keeps references resolvable.

Frame & register → set-domain-strategy
- _domain/DOMAIN.md, start/config.json (creating start/config.json registers the domain — run.sh discovers domains from the config tree). Decide scope, value exchange, vision, 1/3/5-year horizons.
Customers → edit-customers
- Groups, personas, JTBD, journeys, KPI pyramids, per-customer productStrategy, insights.json. Establishes customer ids + KPI names everything else reuses.
Product bricks → edit-product-bricks
- Root groups → subgroups → 20+ bricks with layered modules and dependencies. Establishes brick ids.
Streams → edit-streams
- Outcome streams + flows over the bricks; reconcile with JTBD streamsNeeded.
Data assets → edit-data-assets
- Assets + stores + governance; wire dataDependencies from bricks (back-edit bricks if needed).
Products & deployment → edit-products
- Portfolio, interfaces, neededBricks, and deployment.json channels/environments; reference customer ids and brick ids.
Teams → edit-teams
- Org groups + teams; assign every brick to exactly one owning team; wire primary customers and data-asset ownerTeamId back-references.
Competition → edit-competition
- Sourced landscape with official URLs.
- Attach evidence to key bricks/streams.

Reference-integrity pass (do this before declaring done)

Walk the spine and confirm it's unbroken (this is exactly what audit-domain-balance checks): customer → JTBD → stream/brick → product.neededBricks → deployment → team.ownedBricks, plus insight → linkedCustomers, brick.dataDependencies → asset, asset.ownerTeamId → team. No orphan bricks, no unowned bricks, no dangling customer/asset/channel refs, KPI names consistent everywhere.

Validate & generate

python3 .claude/skills/scripts/validate-domain-model.py <domain-id> --strict-ids — fix every error.
python3 .claude/skills/scripts/validate-skills.py is for the skill library itself, not domains — skip unless editing skills.
Regenerate all docs for the domain: from _wiring/product-domains/, set run ./run-one.sh <domain-id> (start → customers → products → product-bricks → teams → competition, in fixed order).
Run audit-domain-balance <domain-id> and resolve P1 findings before calling the domain done.

Report

Summarize: scope/boundary, counts per artifact vs the mature targets, the integrity result, the audit verdict (skeletal/partial/mature), and any intentional gaps.

同仓库更多 Skills

同仓库

edit-product-bricks

zeljkoobrenovic/spec-driven-product-architecture

Create or edit product bricks for a product domain: root groups, subgroups, bricks, their layered modules (ui/interfaces/worker/stateless-service/service/integration), brick-to-brick dependencies, data dependencies, and external-system dependencies in _config/product-domains/<domain>/product-bricks/product-bricks.json. Use when adding a brick, restructuring brick groups, adding/moving modules across layers, wiring module or brick dependencies, or linking bricks to data assets. Keeps brick and module IDs consistent across products, deployment, streams, teams, evidence, and data assets.

2026-07-311

edit-streams

zeljkoobrenovic/spec-driven-product-architecture

Create or edit product streams for a product domain: outcome-based streams, their outcomes, brick dependencies, and end-to-end flows with steps, key facts, pain points, and step-level dependencies in _config/product-domains/<domain>/product-bricks/product-stream.json. Use when adding a stream, modeling a customer/operator journey as a flow, or wiring stream and step dependencies to product bricks. Keeps stream IDs consistent with JTBD streamsNeeded.

2026-07-311

edit-competition

zeljkoobrenovic/spec-driven-product-architecture

Create or edit the competitive landscape for a product domain: competitor players, their category, HQ, regions, descriptions, sourced business stats with official URLs, and official links in _config/product-domains/<domain>/business/competition.json. Use when adding a competitor, updating market positioning, or refreshing business metrics. Every business stat must carry an official source URL and reported scope — no invented metrics.

2026-07-311

edit-customers

zeljkoobrenovic/spec-driven-product-architecture

Create or edit customer data for a product domain: customer groups, personas, jobs-to-be-done (JTBD), customer journey stories, KPI pyramids, per-customer product strategy, customer insights, and external reference links. Use when adding a customer segment, refining a persona, writing JTBD/journeys, building KPI pyramids, adding sourced insights, or curating external links in _config/product-domains/<domain>/customers/customers.json, insights.json, and links.json. Keeps customer IDs consistent across products, teams, and insights.

2026-07-311

validate-domain

zeljkoobrenovic/spec-driven-product-architecture

Validate a product domain's JSON and cross-file references, then regenerate its static docs. Use after any edit under _config/product-domains/** — adding/changing customers, bricks, products, teams, streams, data assets, competition, or evidence — to confirm JSON parses, IDs are consistent, product-brick/team/module references resolve, and docs rebuild cleanly. The gate every edit-* skill calls before reporting done.

2026-07-311

product-domain

zeljkoobrenovic/spec-driven-product-architecture

Router and index for creating and maintaining Spec-Driven Product Architecture domain data (customers, strategy, jobs-to-be-done, product vision, insights, competition, teams, product bricks, streams, data assets, product deployments). Use when the user wants to work on a product domain but the specific artifact isn't named, when they ask what's possible, or to understand the model, ID conventions, and the validate/regenerate loop before editing _config/product-domains/**.

2026-07-311

name

new-product-domain

description

New Product Domain (orchestrator)

This is a large, multi-step task — track it with a task list and build incrementally, validating after each artifact rather than at the end.

Before starting

Inspect two comparable existing domains and the reference ride-sharing-marketplace for shape and density. Copy its structure, not its content.
Targets for a mature domain: ~4 customer groups with real personas, 20+ bricks across 3 group levels, 15+ data assets, 8+ teams, 8+ competitors, 8+ sourced insights. A smaller domain is fine if intentional — say so.
The new-domain prompt scaffold lives next to this skill: .claude/skills/new-product-domain/NEW-DOMAIN-PROMPT.md.

Build order (dependencies flow downward)

Author top-to-bottom; later artifacts reference earlier IDs, so this order keeps references resolvable.

Frame & register → set-domain-strategy
- _domain/DOMAIN.md, start/config.json (creating start/config.json registers the domain — run.sh discovers domains from the config tree). Decide scope, value exchange, vision, 1/3/5-year horizons.
Customers → edit-customers
- Groups, personas, JTBD, journeys, KPI pyramids, per-customer productStrategy, insights.json. Establishes customer ids + KPI names everything else reuses.
Product bricks → edit-product-bricks
- Root groups → subgroups → 20+ bricks with layered modules and dependencies. Establishes brick ids.
Streams → edit-streams
- Outcome streams + flows over the bricks; reconcile with JTBD streamsNeeded.
Data assets → edit-data-assets
- Assets + stores + governance; wire dataDependencies from bricks (back-edit bricks if needed).
Products & deployment → edit-products
- Portfolio, interfaces, neededBricks, and deployment.json channels/environments; reference customer ids and brick ids.
Teams → edit-teams
- Org groups + teams; assign every brick to exactly one owning team; wire primary customers and data-asset ownerTeamId back-references.
Competition → edit-competition
- Sourced landscape with official URLs.
- Attach evidence to key bricks/streams.

Reference-integrity pass (do this before declaring done)

Validate & generate

python3 .claude/skills/scripts/validate-domain-model.py <domain-id> --strict-ids — fix every error.
python3 .claude/skills/scripts/validate-skills.py is for the skill library itself, not domains — skip unless editing skills.
Regenerate all docs for the domain: from _wiring/product-domains/, set run ./run-one.sh <domain-id> (start → customers → products → product-bricks → teams → competition, in fixed order).
Run audit-domain-balance <domain-id> and resolve P1 findings before calling the domain done.

Report

Summarize: scope/boundary, counts per artifact vs the mature targets, the integrity result, the audit verdict (skeletal/partial/mature), and any intentional gaps.