Marketplace Dev

marketplace-dev

Convert a Claude Code skills repository into an official plugin marketplace so users can install skills via claude plugin marketplace add and get auto-updates.

Input: a repo with skills/ directories containing SKILL.md files. Output: .claude-plugin/marketplace.json + validated + installation-tested + PR-ready.

Phase 0: Evidence Intake

Before editing an existing marketplace, collect evidence instead of relying on the default template:

1. Read the current .claude-plugin/marketplace.json. 2. Read this repo's marketplace rules (CLAUDE.md, README install section, changelog). 3. Read official docs for marketplace/plugin path semantics. 4. If refining from prior failures, mine local Claude Code session history.

Each project's sessions live under ~/.claude/projects/<escaped-cwd>/:

• Top-level files: <session-id>.jsonl
• Subagent transcripts: <session-id>/subagents/agent-*.jsonl

Useful search patterns (adjust keywords to the failure you are debugging):

grep -lc "marketplace.json\|claude plugin validate\|claude plugin install" \
  ~/.claude/projects/<escaped-cwd>/*.jsonl
grep -lc "Unrecognized key\|Plugin not found\|No manifest found\|Duplicate plugin" \
  ~/.claude/projects/<escaped-cwd>/*.jsonl \
  ~/.claude/projects/<escaped-cwd>/*/subagents/*.jsonl

Extract lessons as evidence-backed rules: command attempted, observed output, root cause, final working command/config. Do not encode guesses from memory.

Phase 1: Analyze the Target Repo

Step 1: Discover all skills

# Find every SKILL.md
find <repo-path>/skills -name "SKILL.md" -type f 2>/dev/null

For each skill, extract from SKILL.md frontmatter:

• name — the skill identifier
• description — the ORIGINAL text, do NOT rewrite or translate

Step 2: Read the repo metadata

• VERSION file (if exists) — this becomes metadata.version
• README.md — understand the project, author info, categories
• LICENSE — note the license type
• Git remotes — identify upstream vs fork (git remote -v)

Step 3: Determine categories

Group skills by function. Categories are freeform strings. Good patterns:

• business-diagnostics, content-creation, thinking-tools, utilities
• developer-tools, productivity, documentation, security

Ask the user to confirm categories if grouping is ambiguous.

Step 4: Choose plugin boundaries

Claude Code has three separate levels:

marketplace -> plugin -> skill

• Marketplace name is used for install identity: plugin@marketplace.
• Plugin name is the slash namespace: /plugin-name:skill-name.
• Skill name comes from SKILL.md frontmatter when the skill path points to a

directory containing SKILL.md directly.

Choose each plugin boundary by installation/update/cache intent:

• Single-skill plugin: use when the skill should install, update, and roll back

independently with a narrow cache.

• Suite plugin: use when related skills should share one namespace and one

install command, for example /daymade-docs:mermaid-tools.

For detailed source/cache patterns and pitfalls, read references/cache_and_source_patterns.md before changing source or skills.

Phase 2: Create marketplace.json

The official schema (memorize this)

Read references/marketplace_schema.md for the complete field reference. Key rules that are NOT obvious from the docs:

1. `$schema` field is REJECTED by claude plugin validate. Do not include it. 2. `metadata` only has 3 valid fields: description, version, pluginRoot. Nothing else. metadata.homepage does NOT exist — the validator accepts it silently but it's not in the spec. 3. `metadata.version` is the marketplace catalog version, NOT individual plugin versions. It should match the repo's VERSION file (e.g., "2.3.0"). 4. Plugin entry `version` is independent. For first-time marketplace registration, use "1.0.0". 5. `strict: false` is required when there's no plugin.json in the repo. With strict: false, the marketplace entry IS the entire plugin definition. Having BOTH strict: false AND a plugin.json with components causes a load failure. 6. `source` defines the installed plugin root. For single-skill plugins, point source directly at the skill directory (e.g., "./tunnel-doctor") and omit skills entirely — this is the official pattern used by 167/168 plugins in anthropics/claude-plugins-official. For suite plugins, use source: "./<suite>" with explicit skills array listing subdirectories. Avoid source: "./" (installs full repo as cache) and skills: ["./"] (rejected by Claude Code 2.1.x path-escape validator). 7. Reserved marketplace names that CANNOT be used: claude-code-marketplace, claude-code-plugins, claude-plugins-official, anthropic-marketplace, anthropic-plugins, agent-skills, knowledge-work-plugins, life-sciences. 8. `tags` vs `keywords`: Both are optional. In the current Claude Code source, keywords is defined but never consumed in search. tags only has a UI effect for the value "community-managed" (shows a label). Neither affects discovery. The Discover tab searches only name + description + marketplaceName. Include keywords for future-proofing but don't over-invest.

Generate the marketplace.json

Use this template, filling in from the analysis:

{
  "name": "<marketplace-name>",
  "owner": {
    "name": "<github-org-or-username>"
  },
  "metadata": {
    "description": "<one-line description of the marketplace>",
    "version": "<from-VERSION-file-or-1.0.0>"
  },
  "plugins": [
    {
      "name": "<skill-name>",
      "description": "<EXACT text from SKILL.md frontmatter, do NOT rewrite>",
      "source": "./<skill-name>",
      "strict": false,
      "version": "1.0.0",
      "category": "<category>",
      "keywords": ["<relevant>", "<keywords>"]
    }
  ]
}

Naming the marketplace

The name field is what users type after @ in install commands: claude plugin install dbs@<marketplace-name>

Choose a name that is:

• Short and memorable
• kebab-case (lowercase, hyphens only)
• Related to the project identity, not generic

Description rules

• Use the ORIGINAL description from each SKILL.md frontmatter
• Do NOT translate, embellish, or "improve" descriptions
• If the repo's audience is Chinese, keep descriptions in Chinese
• If bilingual, use the first language in the SKILL.md description field
• The metadata.description at marketplace level can be a new summary

Maintaining an existing marketplace

When adding a new plugin to an existing marketplace.json:

1. Bump `metadata.version` — this is the marketplace catalog version. Follow semver: new plugin = minor bump, breaking change = major bump. 2. Update `metadata.description` — append the new skill's summary. 3. Set new plugin `version` to `"1.0.0"` — it's new to the marketplace. 4. Bump existing plugin `version` when its SKILL.md content changes. Claude Code uses version to detect updates — same version = skip update. 5. Bump existing plugin `version` when its source or skills changes. The installed cache path and component resolution changed even if SKILL.md did not. 6. Audit `metadata` for invalid fields — metadata.homepage is a common mistake (not in spec, silently ignored). Remove if found.

Phase 3: Validate

Step 1: One-shot pre-flight check

Run the bundled validator. It runs four checks in sequence and exits non-zero on any required failure:

bash scripts/check_marketplace.sh          # validates current repo
bash scripts/check_marketplace.sh /path    # validates a target repo

What it checks:

Common schema failures and fixes:

• Unrecognized key: "$schema" → remove the $schema field
• Duplicate plugin name → ensure all names are unique
• Path contains ".." → use ./ relative paths only
• No manifest found in directory when validating an installed cache path → validate

the marketplace manifest or plugin source, not a strict: false cache directory.

Step 2: Installation test

# Add as local marketplace
claude plugin marketplace add .

# Install a plugin
claude plugin install <plugin-name>@<marketplace-name>

# Verify it appears
claude plugin list | grep <plugin-name>

# Check for updates (should say "already at latest")
claude plugin update <plugin-name>@<marketplace-name>

# Clean up
claude plugin uninstall <plugin-name>@<marketplace-name>
claude plugin marketplace remove <marketplace-name>

Step 3: Cache footprint test

After installation or update, inspect the actual cache. This is the only way to confirm source produced the intended snapshot:

PLUGIN=<plugin-name>
MARKET=<marketplace-name>
CACHE=$(jq -r --arg id "$PLUGIN@$MARKET" '.plugins[$id][0].installPath' ~/.claude/plugins/installed_plugins.json)
find "$CACHE" -maxdepth 1 -mindepth 1 -exec basename {} \; | sort

Expected results:

• Single-skill plugin cache: SKILL.md plus its own scripts/, references/,

assets/ as applicable.

• Suite plugin cache: only the suite member skill directories and suite-scoped

resources.

• If unrelated skill directories appear, source is too broad.
• If cache entries are symlinks, the plugin is not self-contained; use canonical

source directories instead of symlink farms.

Step 4: GitHub installation test (if pushed)

# Test from GitHub (requires the branch to be pushed)
claude plugin marketplace add <github-user>/<repo>
claude plugin install <plugin-name>@<marketplace-name>

# Verify
claude plugin list | grep <plugin-name>

# Clean up
claude plugin uninstall <plugin-name>@<marketplace-name>
claude plugin marketplace remove <marketplace-name>

Pre-flight Checklist (MUST pass before proceeding to PR)

Run this checklist after every marketplace.json change. Do not skip items.

Automated checks

bash scripts/check_marketplace.sh

All four checks must pass. Treat the reverse-sync WARN as a real signal: an unregistered SKILL.md on disk is almost always either an accidentally-dropped skill you forgot to register, or dead code that should be removed.

Metadata check

Verify these by reading marketplace.json:

• [ ] metadata.version bumped from previous version
• [ ] metadata.description mentions all skill categories
• [ ] No metadata.homepage (not in spec, silently ignored)
• [ ] No $schema field (rejected by validator)

Per-plugin check

For each plugin entry:

• [ ] description matches SKILL.md frontmatter EXACTLY (not rewritten)
• [ ] version is "1.0.0" for new plugins, bumped for changed plugins
• [ ] source points directly at the skill directory (e.g., "./skill-name")
• [ ] Single-skill plugins omit the skills field (auto-discovery from source)
• [ ] Suite plugins list skills paths relative to source
• [ ] strict is false (no plugin.json in repo)
• [ ] name is kebab-case, unique across all entries

Final validation

bash scripts/check_marketplace.sh

Must print RESULT: PASSED before creating a PR. A WARN [4/4] is acceptable only when you have consciously decided to leave a SKILL.md unregistered.

Phase 4: Create PR

Principles

• Pure incremental: do NOT modify any existing files (skills, README, etc.)
• Squash commits: avoid binary bloat in git history from iterative changes
• Only add: .claude-plugin/marketplace.json, optionally scripts/, optionally update README

README update (if appropriate)

Add the marketplace install method above existing install instructions:

## Install

![demo](demo.gif)  <!-- only if demo exists -->

**Claude Code plugin marketplace (one-click install, auto-update):**

\`\`\`bash
claude plugin marketplace add <owner>/<repo>
claude plugin install <skill>@<marketplace-name>
\`\`\`

PR description template

Include:

• What was added (marketplace.json with N skills, M categories)
• Install commands users will use after merge
• Design decisions (pure incremental, original descriptions, etc.)
• Validation evidence (claude plugin validate . passed)
• Test plan (install commands to verify)

Bundled hooks (optional, auto-activated)

This skill ships two PostToolUse hooks under hooks/:

• hooks/post_edit_validate.sh — runs claude plugin validate whenever a

marketplace.json file is written or edited.

• hooks/post_edit_sync_check.sh — warns when a SKILL.md is edited but the

matching plugin entry in marketplace.json does not bump its version.

Both hooks are declared in this plugin's own manifest entry (plugins[].hooks), so they activate automatically when the plugin is enabled in a Claude Code session. No manual settings.json edit is required. To disable them, remove the hooks block from this plugin entry in the user's installed copy or use /plugin disable marketplace-dev (they take effect only when the plugin is enabled).

These hooks are editor-time guardrails. They do NOT replace scripts/check_marketplace.sh — always run the pre-flight check before a PR.

Anti-Patterns (things that went wrong and how to fix them)

Read references/anti_patterns.md for the full list of pitfalls discovered during real marketplace development. These are NOT theoretical — every one was encountered and debugged in production.

Anti-Patterns: Marketplace Development Pitfalls

Every item below was encountered during real marketplace development. Not theoretical — each cost debugging time.

Contents

• Schema Errors — $schema, metadata.homepage, conflicting strict: false + plugin.json
• Version Confusion — marketplace vs plugin version, silent update skips, source/skills changes
• Source and Cache Errors — full-repo cache pollution, namespace surprises, symlink suites, cache-directory validation
• Description Errors — rewriting SKILL.md descriptions, inventing features
• Installation Testing — GitHub push timing, test cleanup
• PR Best Practices — unrelated file diffs, commit squashing
• Discovery Misconceptions — what keywords and tags actually do

Schema Errors

Adding $schema field

• Symptom: claude plugin validate fails with Unrecognized key: "$schema"
• Fix: Do not include $schema. Unlike many JSON schemas, Claude Code rejects it.
• Why it's tempting: Other marketplace examples (like daymade/claude-code-skills) include it,

and it works for JSON Schema-aware editors. But the validator is strict.

Using metadata.homepage

• Symptom: Silently ignored — no error, no effect.
• Fix: metadata only supports description, version, pluginRoot. Put homepage

on individual plugin entries if needed.

• Why it's tricky: homepage IS valid on plugin entries (from plugin.json schema),

so it looks correct but is wrong at the metadata level.

Conflicting strict: false with plugin.json

• Symptom: Plugin fails to load with "conflicting manifests" error.
• Fix: Choose one authority. strict: false means marketplace.json is the SOLE

definition. Remove plugin.json or set strict: true and let plugin.json define components.

Version Confusion

Using marketplace version as plugin version

• Symptom: All plugins show the same version (e.g., "2.3.0") even though each was

introduced at different times.

• Fix: metadata.version = marketplace catalog version (matches repo VERSION file).

Each plugin entry version is independent. First time in marketplace = "1.0.0".

Not bumping version after changes

• Symptom: Users don't receive updates after you push changes.
• Fix: Claude Code uses version to detect updates. Same version = skip.

Bump the plugin version in marketplace.json when you change skill content.

Changing source/skills without bumping plugin version

• Symptom: Marketplace cache updates, but installed users stay on an old cache

layout because claude plugin update sees the same plugin version.

• Fix: Treat source and skills changes as plugin behavior changes. Bump the

plugin version even if SKILL.md content is unchanged.

Source and Cache Errors

Using full repo source for a narrow plugin

• Symptom: Installing a single plugin creates a cache containing many unrelated

skill directories.

• Fix: Point source directly at the skill directory (e.g., "./my-skill")

and omit the skills field. Do not use skills: ["./"] — it is rejected by Claude Code 2.1.x path-escape validator.

Assuming marketplace name controls slash namespace

• Symptom: Expecting /daymade-skills:mermaid-tools after installing

mermaid-tools@daymade-skills.

• Fix: The plugin name controls the slash namespace. Use a suite plugin like

daymade-docs when you want /daymade-docs:mermaid-tools.

Building suite sources with symlinks

• Symptom: Installed cache contains symlinks pointing back to a marketplace

working copy.

• Fix: Use real canonical suite source directories. Do not use symlink farms for

plugin cache boundaries.

Validating a strict:false cache directory as a plugin manifest

• Symptom: claude plugin validate ~/.claude/plugins/cache/... reports

No manifest found in directory.

• Fix: Validate the marketplace manifest or source repo. Then validate installed

cache footprint with find, not claude plugin validate on the cache.

Description Errors

Rewriting or translating SKILL.md descriptions

• Symptom: Descriptions don't match the actual skill behavior. English descriptions

for a Chinese-audience repo feel foreign.

• Fix: Copy the EXACT description field from each SKILL.md frontmatter.

The author wrote it for their audience — preserve it.

Inventing features in descriptions

• Symptom: Description promises "8,000+ consultations" or "auto-backup and rollback"

when the SKILL.md doesn't mention these specifics.

• Fix: Only state what the SKILL.md frontmatter says. If you want to add context,

use the marketplace-level metadata.description, not individual plugin descriptions.

Installation Testing

Not testing after GitHub push

• Symptom: Local validation passes, but claude plugin marketplace add <user>/<repo>

fails because it clones the default branch which doesn't have the marketplace.json.

• Fix: Push marketplace.json to the repo's default branch before testing GitHub install.

Feature branches only work if the user specifies the ref.

Forgetting to clean up test installations

• Symptom: Next test run finds stale marketplace/plugins and produces confusing results.
• Fix: Always uninstall plugins and remove marketplace after testing:

  claude plugin uninstall <plugin>@<marketplace> 2>/dev/null
  claude plugin marketplace remove <marketplace> 2>/dev/null

PR Best Practices

Modifying existing files unnecessarily

• Symptom: PR diff includes unrelated changes (empty lines in .gitignore, whitespace

changes in README), making it harder to review and merge.

• Fix: Only add new files. If modifying README, be surgical — only add the install section.

Verify with git diff upstream/main that no unrelated files are touched.

Not squashing commits

• Symptom: Git history has 15+ commits with iterative demo.gif changes, bloating the

repo by megabytes. Users cloning the marketplace download all this history.

• Fix: Squash all commits into one before creating the PR:

  git reset --soft upstream/main
  git commit -m "feat: add Claude Code plugin marketplace"

Discovery Misconceptions

Over-investing in keywords/tags

• Symptom: Spending time crafting perfect keyword lists.
• Reality: In the current Claude Code source (verified by reading DiscoverPlugins.tsx),

the Discover tab searches ONLY name + description + marketplaceName. keywords is defined in the schema but never consumed. tags only affects UI for the specific value "community-managed". Include keywords for future-proofing but don't obsess over them.

Using tags for search optimization

• Symptom: Adding tags: ["business", "diagnosis"] expecting search improvements.
• Reality: Only tags: ["community-managed"] has any effect (shows a UI label).

The official Anthropic marketplace (123 plugins) uses tags on only 3 plugins, all with the value ["community-managed"].

Cache and Source Patterns

This reference captures marketplace lessons from real Claude Code marketplace work: full-repo cache pollution, suite namespace design, symlink experiments, and version semantics.

Contents

• Mental Model — the three-level marketplace → plugin → skill hierarchy
• Why Plugin Boundaries Matter — toggle granularity, the baoyu-skills failure case, the false-green trap
• Pattern: Single-Skill Narrow Cache — independent install/update for one skill
• Pattern: Suite Plugin — shared namespace for related skills
• Canonical Source for Suite Members — avoiding duplicate skill directories
• Anti-Patterns — full-repo sources, symlink suites, broad text replacement
• Verification Commands — schema, resolution, and cache footprint checks

Mental Model

Claude Code marketplace distribution has three levels:

marketplace -> plugin -> skill

• Marketplace is the catalog and install suffix: plugin@marketplace.
• Plugin is the install/update/cache boundary and slash namespace.
• Skill is the actual SKILL.md capability.

source defines the installed plugin root. skills paths are resolved relative to that root.

Why Plugin Boundaries Matter (Toggle Granularity)

The plugin boundary isn't just a cache/namespace detail — it decides what a user can turn on and off. The smallest unit a user can enable/disable (enabledPlugins) is a plugin, not a skill. Multiple skills bundled in one plugin are all-or-nothing — a user cannot disable just one of them. (Platform behavior: skillOverrides does not apply to plugin-sourced skills, and /skills can't toggle them either. Tracking: anthropics/claude-code#14920, long-open.)

So the single-vs-suite choice below is really a product decision: will users want to toggle these abilities separately? Yes → one plugin per ability. Always used together → a suite is fine, but tell users it's all-or-nothing.

Failure case: baoyu-skills

baoyu-skills (20k+ stars) originally split its skills into 3 plugins (content / ai-generation / utility), all sharing "source": "./". The shared source caused duplicate registration (issue #49 "installing one pulls in unrelated skills"; #79 "slash command list 3x"), forcing PR #106 to merge all 3 into 1 — which bound ~21 skills together, so users can no longer toggle them individually. Two lessons: (1) never share "source": "./" across plugins (see Anti-Patterns); (2) if a repo keeps shared code at its root (baoyu's bun packages/), it can't be split into independent plugins at all — on GitHub install each plugin gets only its own source subtree, so repo-root shared code never reaches any plugin's cache. Keep each plugin self-contained.

Trap: local directory-source installs give a false green

A local directory-source install references the source in place (no copy), so repo-root shared code and cross-subdir references appear to work — but a real GitHub install breaks them. Validate subdirectory isolation / self-containment against a real GitHub install, not just a local directory source.

Pattern: Single-Skill Plugin

Use this when a skill should install and update independently. Point source directly at the skill directory and omit skills (auto-discovery):

{
  "name": "mermaid-tools",
  "source": "./daymade-docs/mermaid-tools",
  "strict": false,
  "version": "1.0.2"
}

Expected cache:

SKILL.md
references/
scripts/

The slash command remains /mermaid-tools:mermaid-tools because the plugin and skill have the same name. This is acceptable when independence matters more than namespace aesthetics.

This is the official pattern used by 167 of 168 plugins in anthropics/claude-plugins-official.

Pattern: Suite Plugin

Use this when related skills should share one namespace:

{
  "name": "daymade-docs",
  "source": "./daymade-docs",
  "strict": false,
  "version": "1.0.1",
  "skills": [
    "./doc-to-markdown",
    "./mermaid-tools",
    "./pdf-creator",
    "./ppt-creator",
    "./docs-cleaner",
    "./meeting-minutes-taker"
  ]
}

Expected slash commands:

/daymade-docs:doc-to-markdown
/daymade-docs:mermaid-tools
/daymade-docs:pdf-creator

Expected cache top level:

doc-to-markdown/
docs-cleaner/
meeting-minutes-taker/
mermaid-tools/
pdf-creator/
ppt-creator/

Canonical Source for Suite Members

If users also need single-skill installs for suite members, point the individual plugin entries at the same canonical subdirectories and omit skills:

{
  "name": "pdf-creator",
  "source": "./daymade-docs/pdf-creator",
  "strict": false,
  "version": "1.3.2"
}

Avoid keeping duplicate root-level skill directories and suite copies. Duplication creates drift and makes version bumps ambiguous.

Anti-Patterns

Full repo source for a single skill

{
  "name": "mermaid-tools",
  "source": "./"
}

This installs a full repository cache for one plugin. The cache will contain unrelated skills and can confuse debugging. Use source: "./mermaid-tools" instead.

Using skills: ["./"]

{
  "name": "pdf-creator",
  "source": "./daymade-docs/pdf-creator",
  "skills": ["./"]
}

Rejected by Claude Code 2.1.x path-escape validator with skills path "./" escapes plugin root. Omit the skills field — auto-discovery finds SKILL.md in the source directory.

Symlink suite directories

Do not build suite sources from symlinks to canonical skill directories. Claude Code preserves the symlink in the cache, and the symlink can point back to the marketplace working copy. That cache is not self-contained or version-immutable.

Text-wide source replacement

Do not patch source fields by broad text replacement. In a real failure, a patch that intended to change only docs plugins also changed unrelated plugins like skill-creator and statusline-generator. Use a structured JSON edit keyed by plugins[].name, then run a source+skills resolution check.

Verification Commands

Schema + resolution + reverse sync in one shot (uses the bundled script):

bash scripts/check_marketplace.sh          # validate current repo
bash scripts/check_marketplace.sh /path    # validate a target repo

check_marketplace.sh runs four checks:

1. JSON syntax of .claude-plugin/marketplace.json 2. claude plugin validate . (skipped if claude CLI is missing) 3. source+skills resolution (every plugin path resolves to a real SKILL.md) 4. Reverse sync (WARN-only when a disk SKILL.md is not registered)

Inspect the installed cache footprint (cannot be done by the pre-flight script because it depends on what claude plugin install actually produced):

PLUGIN=<plugin-name>
MARKET=<marketplace-name>
CACHE=$(jq -r --arg id "$PLUGIN@$MARKET" \
  '.plugins[$id][0].installPath' ~/.claude/plugins/installed_plugins.json)
find "$CACHE" -maxdepth 1 -mindepth 1 -exec basename {} \; | sort
find "$CACHE" -maxdepth 1 -type l -ls

A symlink in the cache almost always means the plugin was built from a symlink suite and is not self-contained. Fix by pointing source at a real canonical directory.

marketplace.json Complete Schema Reference

Source: https://code.claude.com/docs/en/plugin-marketplaces + https://code.claude.com/docs/en/plugins-reference Verified against Claude Code source code and claude plugin validate.

Root Level

metadata fields (ONLY these 3 are valid)

Invalid metadata fields (silently ignored or rejected):

• metadata.homepage — does NOT exist in spec
• metadata.repository — does NOT exist in spec
• $schema — REJECTED by claude plugin validate

Plugin Entry Fields

Each entry in the plugins array. Can include any field from the plugin.json manifest schema, plus marketplace-specific fields.

Required

Standard metadata (from plugin.json schema)

Marketplace-specific

Component paths (from plugin.json schema)

Source Types

All object sources support optional ref (branch/tag) and sha (40-char commit).

Reserved Marketplace Names

Cannot be used: claude-code-marketplace, claude-code-plugins, claude-plugins-official, anthropic-marketplace, anthropic-plugins, agent-skills, knowledge-work-plugins, life-sciences.

Names impersonating official marketplaces are also blocked.