edit-competition

Estrelas1

Forks1

Atualizado31 de julho de 2026 às 19:13

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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

zeljkoobrenovic

zeljkoobrenovic/spec-driven-product-architecture

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de pesquisa de mercado e especialistas em marketingNegócios e Operações Financeiras·SOC 13-1161

SKILL.md

readonly

name

edit-competition

description

Edit Competition

Authoring skill for business/competition.json — the sourced competitive landscape. Combines competition/market-research methodology with this repo's exact schema. Read .claude/skills/_references/domain-model.md first, and read the existing file plus the reference domain ride-sharing-marketplace (11 players) before editing.

Method (what good looks like)

Include players that genuinely compete for the same customers/jobs; state the inclusion logic in scope. Categorize (global_leader, regional, challenger, niche).
Every business stat is sourced. Use official sources (investor relations, annual reports, regulator filings) with a real sourceUrl and the reported period and scope. Preserve reported scope — don't normalize away caveats. Never invent metrics or precision. Omit a stat rather than fabricate it.
Logos go in business/logos/; reference by relative path.

Exact schema

{
  "generatedOn": "YYYY-MM-DD",
  "domain": "<domain-id>",
  "title": "… Competitive Landscape",
  "scope": { "description": "…", "inclusionLogic": "…", "notes": "…" },
  "players": [
    {
      "id": "uber",                              // lowercase slug, stable
      "logo": "logos/uber.png",
      "name": "Uber",
      "hq": "San Francisco, United States",
      "category": "global_leader",
      "primaryRegions": ["north_america", "europe"],
      "description": "…",
      "businessStats": [
        {
          "metric": "gross_bookings", "value": "$162.8bn",
          "period": "FY2024", "scope": "platform",
          "sourceTitle": "Uber Announces Results for Fourth Quarter and Full Year 2024",
          "sourceUrl": "https://investor.uber.com/…"
        }
      ],
      "links": {
        "website": "https://…", "investor_relations": "https://…",
        "newsroom": "https://…", "blog": "https://…",
        "engineering_blog": "https://…", "linkedin": "https://…"
      }
    }
  ]
}

Cross-file rules

This artifact is reference intelligence — it has no incoming ID dependencies from other files. The discipline is sourcing, not cross-references. Keep domain equal to the domain id, and keep category/region vocabularies consistent with existing players in the file.

After editing

python3 .claude/skills/scripts/validate-domain-model.py <domain-id> (JSON validity; competition has no brick/team integrity checks).
Regenerate: from _wiring/product-domains/, python3 generate-competition-docs.py <domain-id> "<Domain Name>" "<Domain description>".
Report players added/changed and confirm every new stat has an official source URL.

Avoid

Any business stat without a sourceUrl and reported period/scope.
Invented or suspiciously precise numbers; normalizing away reported scope caveats.
Including non-competitors to pad the list.
Inconsistent category/region vocabularies vs existing players.

Mais deste repositório

mesmo repositório

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-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

new-product-domain

zeljkoobrenovic/spec-driven-product-architecture

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.

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

edit-competition

description

Edit Competition

Method (what good looks like)

Include players that genuinely compete for the same customers/jobs; state the inclusion logic in scope. Categorize (global_leader, regional, challenger, niche).
Every business stat is sourced. Use official sources (investor relations, annual reports, regulator filings) with a real sourceUrl and the reported period and scope. Preserve reported scope — don't normalize away caveats. Never invent metrics or precision. Omit a stat rather than fabricate it.
Logos go in business/logos/; reference by relative path.

Exact schema

{
  "generatedOn": "YYYY-MM-DD",
  "domain": "<domain-id>",
  "title": "… Competitive Landscape",
  "scope": { "description": "…", "inclusionLogic": "…", "notes": "…" },
  "players": [
    {
      "id": "uber",                              // lowercase slug, stable
      "logo": "logos/uber.png",
      "name": "Uber",
      "hq": "San Francisco, United States",
      "category": "global_leader",
      "primaryRegions": ["north_america", "europe"],
      "description": "…",
      "businessStats": [
        {
          "metric": "gross_bookings", "value": "$162.8bn",
          "period": "FY2024", "scope": "platform",
          "sourceTitle": "Uber Announces Results for Fourth Quarter and Full Year 2024",
          "sourceUrl": "https://investor.uber.com/…"
        }
      ],
      "links": {
        "website": "https://…", "investor_relations": "https://…",
        "newsroom": "https://…", "blog": "https://…",
        "engineering_blog": "https://…", "linkedin": "https://…"
      }
    }
  ]
}

Cross-file rules

After editing

python3 .claude/skills/scripts/validate-domain-model.py <domain-id> (JSON validity; competition has no brick/team integrity checks).
Regenerate: from _wiring/product-domains/, python3 generate-competition-docs.py <domain-id> "<Domain Name>" "<Domain description>".
Report players added/changed and confirm every new stat has an official source URL.

Avoid

Any business stat without a sourceUrl and reported period/scope.
Invented or suspiciously precise numbers; normalizing away reported scope caveats.
Including non-competitors to pad the list.
Inconsistent category/region vocabularies vs existing players.