Update to MatchMyCrew.com

{
  "name": "matchmycrew",
  "description": "Build, change, review, and operate MatchMyCrew.com product work using its marketplace domain model, editorial design system, self-hosted architecture, and safety boundaries.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 270
    },
    {
      "relative_path": "references/design.md",
      "size_in_bytes": 1679
    },
    {
      "relative_path": "references/engineering.md",
      "size_in_bytes": 1758
    },
    {
      "relative_path": "references/product.md",
      "size_in_bytes": 1986
    }
  ],
  "skill_md_contents": "---\nname: matchmycrew\ndescription: Build, change, review, and operate MatchMyCrew.com product work using its marketplace domain model, editorial design system, self-hosted architecture, and safety boundaries.\n---\n\n# MatchMyCrew\n\nUse this skill for work on the MatchMyCrew.com application, repository, public content,\nMCP integration, or product-facing technical decisions. Treat the repository and its\ncanonical docs as the source of truth; inspect the relevant existing implementation\nbefore changing it.\n\n## Product stance\n\n- MatchMyCrew is an international, English-first marketplace for discovering and\n  connecting creative-production professionals. Clients and providers may be the same\n  account.\n- The core flow is: search by craft/service and location, evaluate a public provider\n  profile, then start a private inquiry. Provider profiles are the primary product\n  object; provider is the stable term for a listed professional.\n- Trust matters: published profiles, verified accounts, reviews, reporting, and\n  moderation must be represented honestly. Do not imply booking, payment, identity\n  document handling, or real-time messaging exists unless the implementation supports it.\n- Keep future booking, availability management, payments, and localization in mind, but\n  do not pull deferred features into the current release without an explicit request.\n\n## Working rules\n\n1. Read the relevant reference below before making a material product, UI, or\n   infrastructure decision.\n2. Reuse existing schemas, helpers, tokens, components, auth/session checks, rate\n   limits, and public-visibility predicates. Do not create a parallel convention.\n3. Preserve privacy and authorization boundaries server-side. Public discovery may only\n   expose published, non-suspended profiles; authenticated MCP access is read-only for\n   provider discovery unless the user explicitly requests a separately supported flow.\n4. Keep UI copy concise, concrete, and English-first. Design for future localization:\n   avoid embedding meaning in text concatenation, layout assumptions, or unexplained\n   abbreviations.\n5. Verify proportionately. For code changes use the narrowest relevant tests first,\n   then run formatting, type checking, linting, and build when the change warrants it.\n   For UI changes, check responsive behavior, keyboard focus, reduced motion, dark mode,\n   and accessible names. Run Prettier on edited source.\n\n## References\n\n- Read [product.md](references/product.md) for domain language, scope, trust rules,\n  and feature boundaries.\n- Read [design.md](references/design.md) for the implemented visual and interaction\n  system before changing public UI.\n- Read [engineering.md](references/engineering.md) for architecture, security,\n  deployment, and validation conventions before changing backend or operations.\n\nWhen repository documentation conflicts with this skill, follow the repository's\ncurrent canonical documentation and update the skill only if the rule is stable and\nreusable.\n"
}