{"id":"6162b3ae-58ab-4e81-aa62-51795dc811a9","entityType":"agent","slug":"clawhub-robbiwu-blossom-jobs","name":"Find and Offer New Work and Tasks","canonicalUrl":"https://www.xpersona.co/agent/clawhub-robbiwu-blossom-jobs","canonicalPath":"/agent/clawhub-robbiwu-blossom-jobs","generatedAt":"2026-10-10T06:48:01.037Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":null},"description":"Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language. Skill: Find and Offer New Work and Tasks Owner: robbiwu Summary: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language. Tags: latest:2.0.2 Version history: v2.0.2 | 2026-07-31T06:51:39.300Z | user - Removed the sample file skill-card.md. - Updated protocol documentation to clarify that image upload is not supported via the protocol AP","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.2K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17029ksnmv6bz19ztqqs711vd83gv5h:blossom-jobs","sourceUrl":"https://clawhub.ai/robbiwu/blossom-jobs","homepage":"https://clawhub.ai/robbiwu/skills/blossom-jobs","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/robbiwu/blossom-jobs","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/robbiwu/skills/blossom-jobs","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":48,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language. Skill: Find and Offer"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":null},"stars":null,"forks":null,"downloads":2202,"packageName":null,"latestVersion":"2.0.2","tractionLabel":"2.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T17:35:23.744Z","lastCrawledAt":"2026-10-09T17:35:23.744Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T17:35:23.744Z","lastVerifiedAt":null,"highlights":[{"version":"2.0.2","createdAt":"2026-07-31T06:51:39.300Z","changelog":"- Removed the sample file skill-card.md. - Updated protocol documentation to clarify that image upload is not supported via the protocol API and must use DeskChat instead. - Adjusted API documentation and guidance for address management and image handling. - No breaking changes to API surfaces or user flows; documentation improvements only.","fileCount":3,"zipByteSize":6248},{"version":"2.0.0","createdAt":"2026-07-30T15:04:54.594Z","changelog":"blossom-jobs 1.0.23 - Major rewrite of protocol, security, and flow documentation in SKILL.md. - Expanded registration, authentication, and confirmation requirements. - Clarified data boundaries and reinforced security/credential handling rules. - Simplified description of marketplace endpoints and activation triggers. - Removed the skill-card.md file.","fileCount":3,"zipByteSize":5844},{"version":"1.0.23","createdAt":"2026-07-30T15:01:15.072Z","changelog":"Version 1.0.23 - Removed the file skill-card.md. - No functional or API changes in this release.","fileCount":3,"zipByteSize":5817},{"version":"1.0.22","createdAt":"2026-05-30T05:02:06.883Z","changelog":"- Enforced name validation: When registering, the first name and surname must not contain numbers—only letters, spaces, hyphens, and apostrophes are allowed. Users will be prompted to correct their names if digits are present. - Minor documentation updates and clarifications to the registration and data handling flows. - Removed the “skill-card.md” file.","fileCount":3,"zipByteSize":10826},{"version":"1.0.21","createdAt":"2026-05-24T05:08:51.308Z","changelog":"**Blossom Jobs 1.0.21 Changelog** - SKILL.md: Major update to setup and onboarding instructions. - Added tailored first-run welcome and registration guidance; treat users as existing assistants connecting Blossom, not anonymous newcomers. - Clarified collection and confirmation of user identity details before registration (full name, email, passKey). - Updated onboarding dialogue to avoid generic feature lists and maintain the assistant's current voice and relationship. - Reorganized workflow to ensure account and address setup are completed before starting Blossom job actions. - No functional changes to API or business logic. Documentation and user experience improvements only.","fileCount":3,"zipByteSize":10655},{"version":"1.0.20","createdAt":"2026-05-13T16:44:03.827Z","changelog":"blossom-jobs 1.0.20 - Skill documentation updated to clarify that, when managing addresses, the agent should use the existing address if available (`GET /getAddresses`), rather than always creating a new one. - The flow description now directs use of the smallest suitable endpoint depending on the action (e.g., `/ask` for conversational tasks, structured endpoints when the action and payload are clear). - Added guidance on using `/ask` for employer job ingestion from URLs or pasted adverts, and on using `/role` only after full user confirmation and structured payload collection. - These changes improve accuracy and reduce unnecessary address duplication during user interactions.","fileCount":2,"zipByteSize":8463},{"version":"1.0.19","createdAt":"2026-05-06T05:33:26.248Z","changelog":"Blossom Jobs 1.0.19 Changelog - Updated metadata fields for operator, homepage, support, privacy, and API host. - Added guidance for choosing unique passKeys (do not reuse email or banking passwords). - Clarified handling and workflow for employer job import requests (add/ingest/import from job URL or advert now routes through employer path). - Increased detail on API key security: keys have no expiry or self-service revocation; contact Blossom support if exposed. - Added explicit instruction to relay registration rejections for employer accounts instead of switching user type automatically. - General improvements to API usage and user guidance for job import, confirmation, and data privacy.","fileCount":2,"zipByteSize":7906},{"version":"1.0.18","createdAt":"2026-05-02T02:48:14.342Z","changelog":"- Added a contact/help section highlighting Blossom support email and main website. - No changes to features or functionality—informational content only. - Version number and descriptive metadata remain unchanged.","fileCount":2,"zipByteSize":6989}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17029ksnmv6bz19ztqqs711vd83gv5h:blossom-jobs","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T06:48:01.032Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-robbiwu-blossom-jobs/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":null},"readme":"Skill: Find and Offer New Work and Tasks\n\nOwner: robbiwu\n\nSummary: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\n\nTags: latest:2.0.2\n\nVersion history:\n\nv2.0.2 | 2026-07-31T06:51:39.300Z | user\n\n- Removed the sample file skill-card.md.\n- Updated protocol documentation to clarify that image upload is not supported via the protocol API and must use DeskChat instead.\n- Adjusted API documentation and guidance for address management and image handling.\n- No breaking changes to API surfaces or user flows; documentation improvements only.\n\nv2.0.0 | 2026-07-30T15:04:54.594Z | user\n\nblossom-jobs 1.0.23\n\n- Major rewrite of protocol, security, and flow documentation in SKILL.md.\n- Expanded registration, authentication, and confirmation requirements.\n- Clarified data boundaries and reinforced security/credential handling rules.\n- Simplified description of marketplace endpoints and activation triggers.\n- Removed the skill-card.md file.\n\nv1.0.23 | 2026-07-30T15:01:15.072Z | user\n\nVersion 1.0.23\n\n- Removed the file skill-card.md.\n- No functional or API changes in this release.\n\nv1.0.22 | 2026-05-30T05:02:06.883Z | user\n\n- Enforced name validation: When registering, the first name and surname must not contain numbers—only letters, spaces, hyphens, and apostrophes are allowed. Users will be prompted to correct their names if digits are present.\n- Minor documentation updates and clarifications to the registration and data handling flows.\n- Removed the “skill-card.md” file.\n\nv1.0.21 | 2026-05-24T05:08:51.308Z | auto\n\n**Blossom Jobs 1.0.21 Changelog**\n\n- SKILL.md: Major update to setup and onboarding instructions.\n- Added tailored first-run welcome and registration guidance; treat users as existing assistants connecting Blossom, not anonymous newcomers.\n- Clarified collection and confirmation of user identity details before registration (full name, email, passKey).\n- Updated onboarding dialogue to avoid generic feature lists and maintain the assistant's current voice and relationship.\n- Reorganized workflow to ensure account and address setup are completed before starting Blossom job actions.\n- No functional changes to API or business logic. Documentation and user experience improvements only.\n\nv1.0.20 | 2026-05-13T16:44:03.827Z | auto\n\nblossom-jobs 1.0.20\n\n- Skill documentation updated to clarify that, when managing addresses, the agent should use the existing address if available (`GET /getAddresses`), rather than always creating a new one.\n- The flow description now directs use of the smallest suitable endpoint depending on the action (e.g., `/ask` for conversational tasks, structured endpoints when the action and payload are clear).\n- Added guidance on using `/ask` for employer job ingestion from URLs or pasted adverts, and on using `/role` only after full user confirmation and structured payload collection.\n- These changes improve accuracy and reduce unnecessary address duplication during user interactions.\n\nv1.0.19 | 2026-05-06T05:33:26.248Z | user\n\nBlossom Jobs 1.0.19 Changelog\n\n- Updated metadata fields for operator, homepage, support, privacy, and API host.\n- Added guidance for choosing unique passKeys (do not reuse email or banking passwords).\n- Clarified handling and workflow for employer job import requests (add/ingest/import from job URL or advert now routes through employer path).\n- Increased detail on API key security: keys have no expiry or self-service revocation; contact Blossom support if exposed.\n- Added explicit instruction to relay registration rejections for employer accounts instead of switching user type automatically.\n- General improvements to API usage and user guidance for job import, confirmation, and data privacy.\n\nv1.0.18 | 2026-05-02T02:48:14.342Z | user\n\n- Added a contact/help section highlighting Blossom support email and main website.\n- No changes to features or functionality—informational content only.\n- Version number and descriptive metadata remain unchanged.\n\nv1.0.17 | 2026-05-01T18:53:43.284Z | user\n\n- Added new API endpoint: GET /getAddresses to retrieve all addresses for the account.\n- Updated session state section: now uses /getAddresses to access existing addresses when creating a role.\n- Incremented documentation version from 3.0.1 to 3.0.2.\n- No functional or code changes detected in this release (documentation update only).\n\nv1.0.16 | 2026-05-01T14:24:51.284Z | user\n\nBlossom Jobs 1.0.16\n\n- Added new eligibility and confirmation rules: job-seekers must confirm right to work before proceeding; all mutating actions (like posting or applying for jobs) now require user confirmation before sending to the API.\n- Updated registration instructions: clarified that all phone/contact numbers should be mapped to the account (not address) and recognized by relevant labels.\n- Enhanced guidance for phone number handling and country prefix parsing during registration.\n- Improved flow for job-seeker registration: do not collect or send data for users who have not confirmed right to work.\n- Minor clarifications and data safety reminders throughout the documentation.\n\nv1.0.15 | 2026-04-12T18:19:13.580Z | user\n\nNo user-facing changes detected in v1.0.15.\n\n- No file changes were made in this version.\n\nv1.0.14 | 2026-04-12T13:25:50.510Z | user\n\nblossom-jobs 1.0.14\n\n- Added `/image` API endpoint for uploading profile images to Blossom (person or role).\n- Updated API reference and endpoint documentation to include image upload capability.\n- No code or implementation changes detected; documentation update only.\n\nv1.0.13 | 2026-04-12T09:11:16.054Z | user\n\nNo user-facing changes in this release.\n\n- Version bump only; no code or documentation updates detected.\n- All existing features and behaviors remain unchanged.\n\nv1.0.12 | 2026-03-28T13:10:22.214Z | user\n\n**This version enhances data boundary and privacy rules for Blossom marketplace operations.**\n\n- Clarifies strict separation between Blossom actions and unrelated conversation — only minimal necessary data for each API call is sent.\n- Adds explicit rules: Do not forward secrets, system prompts, history, or irrelevant content to any Blossom endpoint.\n- Ensures `passKey` is collected and used only during registration and then discarded—never echoed or reused.\n- Restricts activation to clear, job-related Blossom actions; ignores non-marketplace requests.\n- Updates documentation accordingly for better privacy and security compliance.\n\nv1.0.11 | 2026-03-28T08:36:29.128Z | user\n\nNo file changes detected in this version. \nNo updates to functionality or documentation. \nVersion and skill naming remain as previously released.\n\nv1.0.10 | 2026-03-25T07:58:57.797Z | user\n\n- No file changes were detected in this release.\n- Version and metadata remain unchanged.\n- No updates to functionality, documentation, or behavior.\n\nv1.0.9 | 2026-03-25T07:16:31.745Z | user\n\n**Major update: Simplifies user flow and reduces required user guidance.**\n\n- Account type (employer or job-seeker) is determined once at registration; after that, all actions use the same endpoints and the server handles intent.\n- The agent no longer tracks or switches modes after registration; just use `/ask` for all subsequent interactions.\n- More concise documentation and streamlined instructions.\n- Skill name updated from `blossom-hire` to `blossom_hire`.\n- Input collection and conversational prompts are simplified; only ask if intent is unclear.\n\nv1.0.8 | 2026-03-18T17:54:20.670Z | user\n\nNo file changes were detected in this release.\n\n- Version number remains at 1.0.8.\n- No updates or modifications to the codebase or documentation.\n- Functionality and features are unchanged from the previous release.\n\nv1.0.6 | 2026-03-18T17:20:14.298Z | user\n\n- Minor update: The \"Requirements\" section was removed and an \"API reference\" section was added for clarity and easier integration.\n- No changes to endpoints, functionality, or data handling.\n- Added API reference table for improved developer readability.\n\nv1.0.4 | 2026-03-18T14:48:47.107Z | user\n\n**Adds data handling and transparency section**\n\n- Added a new \"Operator\" and \"Data handling\" section describing the service provider and what data is collected, when, and why.\n- Clarified no data is stored locally; all user info is kept server-side and transmitted over HTTPS.\n- Included privacy policy, website, and contact links for user transparency.\n- No changes to code or conversation flow logic.\n\nv1.0.2 | 2026-03-18T14:46:03.641Z | user\n\nBlossom Hire 2.2.0 — Expanded, clearer documentation and triggers\n\n- Improved and expanded the skill overview and description for better clarity.\n- Updated activation triggers and example use cases to be more inclusive and easier to understand.\n- Reworded conversation flows, job posting, and job search guidance to be more user-friendly.\n- Clarified tool requirements and session handling instructions.\n- No functional changes or file modifications — documentation improvements only.\n\nv1.0.1 | 2026-03-18T14:35:51.640Z | user\n\nBlossom-hire 2.1.0 is a major update expanding from employer-only to dual-sided job marketplace:\n\n- Adds full support for job-seekers: search and apply for roles, manage applications, answer screening questions through Brian.\n- Introduces account \"modes\": prompts user to specify if they're hiring or seeking work, setting `userType` accordingly.\n- Expands trigger phrases and conversation flows to cover both employers and job-seekers.\n- Updates registration, flow, and output logic for both account types.\n- Refines documentation to clearly outline employer and job-seeker steps, tools, and API payloads.\n\nv1.0.0 | 2026-03-18T14:25:16.116Z | user\n\nBlossom Hire Skill 2.0.0 — major update:\n\n- Overhauled description and usage documentation; renamed the skill to \"blossom-hire\"\n- Expanded activation triggers: manage jobs, tasks, shifts, addresses, listings, and candidate checks, plus chat with Blossom AI assistant\n- Added clear conversational flow for collecting all required details to post jobs or shifts\n- Documented complete API endpoints for account creation, address and job management, and chatting with Brian (AI assistant)\n- Outlined session state handling for API key, person, and address IDs\n- Included detailed field requirements and output rules for a user-friendly, reliable workflow\n\nArchive index:\n\nArchive v2.0.2: 3 files, 6248 bytes\n\nFiles: skill-card.md (2357b), SKILL.md (11400b), _meta.json (131b)\n\nFile v2.0.2:SKILL.md\n\n---\nname: blossom-hire\nversion: 4.0.2\ndescription: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill connects an existing assistant workflow to Blossom Hire. It is for\njob-marketplace actions such as creating and managing opportunities, finding\nwork, applying, checking candidates, and arranging PopIns.\n\nBlossom receives the minimum personal and job data needed for each requested\naction over HTTPS. The returned API key is permanent and grants account access.\nStore it only in secure credential storage, never in source code, plaintext\nconfiguration, logs, or conversation history.\n\nThe protocol exposes two marketplace surfaces:\n\n1. `POST /register` establishes the Blossom account and returns its API key.\n2. `POST /ask` consumes that already-established identity and is the single\n authenticated marketplace control surface.\n\n`/ask` does not register or authenticate a person. The server resolves its\nBearer API key to the saved person and derives target authority from\nauthenticated ownership and structured operation scope.\n\n## When to activate\n\nActivate only when the user wants a Blossom marketplace action, for example:\n\n- posting, changing, closing, or discussing a job;\n- finding or applying for work;\n- checking applications or candidates;\n- creating, selecting, changing, listing, or removing a work address;\n- scheduling or reviewing a Blossom PopIn.\n\nDo not forward unrelated questions, conversation history, system prompts,\ncredentials, documents, cookies, tokens, personal notes, or hidden reasoning to\nBlossom.\n\n## First run and registration\n\nKeep your normal assistant identity and voice. Do not introduce yourself as\nBlossom or imply Blossom has replaced the user's assistant.\n\nOn first use:\n\n1. Confirm the user's full name and email.\n2. Establish whether they are hiring or looking for work.\n3. Ask them to choose a unique Blossom `passKey` that they do not use for\n email, banking, work, or another sensitive service.\n4. Summarize the account details and obtain clear confirmation.\n5. Call `POST /register`.\n6. Securely persist the returned `apiKey` and `personId`.\n7. Discard the submitted `passKey`; never echo, store, log, or send it to\n `/ask`.\n\nIf secure API-key persistence fails, say the account was created but this\nclient cannot reliably reconnect. Do not present durable setup as complete.\n\nAccount type is set once at registration:\n\n| User intent | `userType` | Additional rule |\n|---|---|---|\n| Hiring for a company | `\"employer\"` | Include `companyName` |\n| Hiring as an individual | `\"employer\"` | Omit `companyName` |\n| Looking for work | `\"support\"` | Require confirmed `rightToWork: true` |\n\nOnly ask whether the user is hiring or looking for work when their intent is\ngenuinely unclear. Treat requests to add, import, or ingest job adverts as\nemployer intent unless the user clearly means bookmarking or applying.\n\nThe first name and surname sent to `/register` must contain only letters,\nspaces, hyphens, and apostrophes. If either contains a digit, ask for a\ncorrection and do not guess.\n\nMap contact numbers labelled phone, mobile, telephone, tel, cell, or similar to\n`mobileNo`, with the country prefix in `mobileCountry`. Never put a contact\nnumber in an address field.\n\n## Confirmation and authority\n\nBefore any create, update, deletion, posting, application, or scheduling\nrequest:\n\n1. Briefly summarize the exact action and target.\n2. Ask for clear confirmation.\n3. Send the confirmed instruction to `/ask`.\n\nThe client confirmation is not target authority. The server must still resolve\nevery saved role, address, application, candidate, or PopIn from the\nauthenticated account and the structured current-operation scope. Never insert\nor invent a database ID, reuse an ID from another account, or treat an API key\nas permission over a caller-supplied target.\n\nSome destructive operations, including saved-role deletion, use an additional\nserver-led confirmation turn after exact target resolution. Relay that prompt\nand send the user's answer through `/ask`; do not bypass it.\n\n## API reference\n\nBase URL:\n\n```text\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n| Method | Path | Authentication | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Establish account and return API key |\n| `POST` | `/ask` | Bearer API key | Read and control the authenticated Blossom account |\n\nThis table is the complete public protocol surface. There are no separate\npublic role, address, address-list, or image-upload protocol routes. Express\nmarketplace reads and mutations in plain language through `/ask`. Image upload\nremains a DeskChat capability and is not part of the protocol API.\n\n### Register\n\n`POST /register`\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"\",\n \"mobileNo\": \"\"\n}\n```\n\nFor a job-seeker:\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"support\",\n \"rightToWork\": true,\n \"passKey\": \"\"\n}\n```\n\nSuccessful response:\n\n```json\n{\n \"success\": true,\n \"apiKey\": \"\",\n \"personId\": 803\n}\n```\n\nPersist `apiKey` securely and reuse it as the Bearer token. Persist `personId`\nonly as the account identifier. Do not persist `passKey`.\n\nIf registration or validation fails, relay the returned error and ask the user\nfor the missing or corrected detail. Never silently change their account type,\nright-to-work answer, name, or company.\n\n### Ask\n\n`POST /ask`\n\n```http\nAuthorization: Bearer \nContent-Type: application/json\n```\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\nSend only the current Blossom instruction. The API key already establishes the\nperson and account type; do not place identity claims, credentials, a\n`passKey`, client-selected authority, or raw conversation history in\n`instructions`.\n\nDo not prefetch, construct, or submit address inventories. Blossom hydrates a\njobseeker's singular owned address at the common chat boundary. Employer\naddress mutations enter `hotAddress`, which loads the complete\nserver-authoritative address scope before deciding, targeting, or saving the\nmutation.\n\nUse `/ask` for all authenticated marketplace work, including:\n\n- listing, selecting, creating, updating, or removing saved addresses;\n- creating, importing, reading, updating, activating, deactivating, or deleting\n roles;\n- candidate and application questions;\n- finding jobs and applying;\n- PopIn reads and scheduling;\n- follow-up questions needed to complete a pending action.\n\nIf required details are missing or a target is ambiguous, relay the server's\nquestion. Do not manufacture values or switch to a hidden direct endpoint.\n\nProtocol `/ask` accepts text instructions only. For image input, use an\nauthenticated DeskChat session: upload the image with\n`POST /api/v1/fileupload`, then send the returned attachment metadata with\n`POST /api/v1/desk-chat`. If no authenticated DeskChat session is available,\nexplain that image upload is unavailable through the protocol API; never invent\nan image-upload protocol endpoint.\n\n## Mutation receipts\n\nConversational `response` text is not proof of a write. Claim that something\nwas saved, created, changed, deleted, posted, applied for, or scheduled only\nwhen `/ask` returns the canonical structured action showing successful\nexecution.\n\nFor role operations, inspect the applicable structured result:\n\n- `actions.hotRole` or the relevant entry in `actions.hotRoles`;\n- `actions.protocolJob`;\n- `actions.jobMutationStatus`;\n- `actions.roleDeletionConfirmation` when another confirmation is required.\n\nRequire the result to identify the actual operation and report successful saved\nexecution. Use returned `roleId`, `roleIdentifier`, `headline`, `addressId`,\n`roleUrl`, `saveStatus`, `saved`, `toolExecuted`, and `message` fields when\npresent. A proposal, pending draft, confirmation request, `saved: false`,\n`toolExecuted: false`, missing action, or prose-only response is not a durable\nrole mutation receipt.\n\nFor address operations, inspect:\n\n- `actions.hotAddress` or the relevant entry in `actions.hotAddresses`;\n- `actions.protocolAddress`.\n\nRequire successful saved execution and use returned `addressId`, `label`,\n`roleId`, `roleHeadline`, `saved`, `success`, and `message` fields when present.\nA read-only result, blocked linked-address deletion, missing action, or\nprose-only response is not a durable address mutation receipt.\n\nFor applications, scheduling, and other actions, use the corresponding\nstructured action in `actions`. When no authoritative action is returned,\nrelay the response without inventing a state change.\n\n## Examples\n\n### Create a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Confirm the known job details and ask for any missing location detail.\n2. If the account is not established, complete `/register` and securely save\n the API key.\n3. Ask: *\"Create café cover for Saturday 11–5 in Sherwood at £12/hour, using\n [confirmed address].\"*\n4. If `/ask` requests another detail or address selection, relay the question.\n5. Say the job was created only from the successful role mutation receipt.\n\n### Update or remove a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\nConfirm the exact change, then send it to `/ask`. Use the returned exact role\ntarget and durable mutation result before saying it changed.\n\n> **User:** Take down the café role.\n\nSend the confirmed request to `/ask`, relay any server-led exact-target\nconfirmation, then claim deletion only when the structured deletion result says\nthe tool executed and saved the deletion.\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Establish a support account through `/register` only after right-to-work\n confirmation.\n2. Confirm the user's location before asking `/ask` to save or use it.\n3. Ask `/ask` to find the work.\n4. When the user chooses a role, confirm the exact application and send it\n through `/ask`.\n5. Relay screening questions and answers through `/ask`.\n6. Claim an application only from its structured successful action.\n\n## Credential failure\n\nThe protocol currently exposes no scoped keys, expiry, password-based protocol\nlogin, or self-service revocation. If the API key is unavailable, do not ask\n`/ask` to authenticate or recreate identity. Re-register only if the user\nintends to create a distinct new account. If a key may have been exposed, stop\nusing it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate\nor revoke access.\n\nFile v2.0.2:_meta.json\n\n{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"2.0.2\",\n \"publishedAt\": 1785480699300\n}\n\nFile v2.0.2:skill-card.md\n\n## Description:\n\nSet up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[robbiwu](https://clawhub.ai/user/robbiwu)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal employers and jobseekers use this skill to set up Blossom Hire accounts, post or manage local work opportunities, search and apply for jobs, review candidates, and schedule PopIns through confirmed Blossom marketplace requests.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: A permanent unscoped Blossom account API key grants durable account access if exposed.\n\nMitigation: Persist the key only in secure credential storage, never paste or log it, and contact Blossom support to rotate or revoke access if exposure is suspected.\n\nRisk: Marketplace actions can create, update, delete, post, apply for, or schedule work-related records.\n\nMitigation: Summarize the exact action and target, obtain clear user confirmation, and claim completion only from the structured successful action returned by Blossom.\n\nRisk: Unrelated personal data, credentials, or conversation history could be sent to Blossom unnecessarily.\n\nMitigation: Send only the minimum current Blossom-related instruction and avoid forwarding unrelated prompts, documents, credentials, cookies, tokens, notes, or hidden reasoning.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/robbiwu/skills/blossom-jobs)\n- [Blossom homepage](https://blossomai.org)\n- [Blossom protocol API](https://hello.blossomai.org/api/v1/blossom/protocol)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Text, API calls, Configuration]\n\n**Output Format:** [Markdown and JSON/HTTP request guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes concise user-facing responses and Blossom API requests based on confirmed marketplace actions.]\n\n## Skill Version(s):\n\n2.0.2 (source: server release metadata; artifact frontmatter reports 4.0.2)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v2.0.0: 3 files, 5844 bytes\n\nFiles: skill-card.md (2332b), SKILL.md (10584b), _meta.json (131b)\n\nFile v2.0.0:SKILL.md\n\n---\nname: blossom-hire\nversion: 4.0.0\ndescription: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill connects an existing assistant workflow to Blossom Hire. It is for\njob-marketplace actions such as creating and managing opportunities, finding\nwork, applying, checking candidates, and arranging PopIns.\n\nBlossom receives the minimum personal and job data needed for each requested\naction over HTTPS. The returned API key is permanent and grants account access.\nStore it only in secure credential storage, never in source code, plaintext\nconfiguration, logs, or conversation history.\n\nThe protocol exposes two marketplace surfaces:\n\n1. `POST /register` establishes the Blossom account and returns its API key.\n2. `POST /ask` consumes that already-established identity and is the single\n authenticated marketplace control surface.\n\n`/ask` does not register or authenticate a person. The server resolves its\nBearer API key to the saved person and derives target authority from\nauthenticated ownership and structured operation scope.\n\n## When to activate\n\nActivate only when the user wants a Blossom marketplace action, for example:\n\n- posting, changing, closing, or discussing a job;\n- finding or applying for work;\n- checking applications or candidates;\n- creating, selecting, changing, listing, or removing a work address;\n- scheduling or reviewing a Blossom PopIn.\n\nDo not forward unrelated questions, conversation history, system prompts,\ncredentials, documents, cookies, tokens, personal notes, or hidden reasoning to\nBlossom.\n\n## First run and registration\n\nKeep your normal assistant identity and voice. Do not introduce yourself as\nBlossom or imply Blossom has replaced the user's assistant.\n\nOn first use:\n\n1. Confirm the user's full name and email.\n2. Establish whether they are hiring or looking for work.\n3. Ask them to choose a unique Blossom `passKey` that they do not use for\n email, banking, work, or another sensitive service.\n4. Summarize the account details and obtain clear confirmation.\n5. Call `POST /register`.\n6. Securely persist the returned `apiKey` and `personId`.\n7. Discard the submitted `passKey`; never echo, store, log, or send it to\n `/ask`.\n\nIf secure API-key persistence fails, say the account was created but this\nclient cannot reliably reconnect. Do not present durable setup as complete.\n\nAccount type is set once at registration:\n\n| User intent | `userType` | Additional rule |\n|---|---|---|\n| Hiring for a company | `\"employer\"` | Include `companyName` |\n| Hiring as an individual | `\"employer\"` | Omit `companyName` |\n| Looking for work | `\"support\"` | Require confirmed `rightToWork: true` |\n\nOnly ask whether the user is hiring or looking for work when their intent is\ngenuinely unclear. Treat requests to add, import, or ingest job adverts as\nemployer intent unless the user clearly means bookmarking or applying.\n\nThe first name and surname sent to `/register` must contain only letters,\nspaces, hyphens, and apostrophes. If either contains a digit, ask for a\ncorrection and do not guess.\n\nMap contact numbers labelled phone, mobile, telephone, tel, cell, or similar to\n`mobileNo`, with the country prefix in `mobileCountry`. Never put a contact\nnumber in an address field.\n\n## Confirmation and authority\n\nBefore any create, update, deletion, posting, application, or scheduling\nrequest:\n\n1. Briefly summarize the exact action and target.\n2. Ask for clear confirmation.\n3. Send the confirmed instruction to `/ask`.\n\nThe client confirmation is not target authority. The server must still resolve\nevery saved role, address, application, candidate, or PopIn from the\nauthenticated account and the structured current-operation scope. Never insert\nor invent a database ID, reuse an ID from another account, or treat an API key\nas permission over a caller-supplied target.\n\nSome destructive operations, including saved-role deletion, use an additional\nserver-led confirmation turn after exact target resolution. Relay that prompt\nand send the user's answer through `/ask`; do not bypass it.\n\n## API reference\n\nBase URL:\n\n```text\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n| Method | Path | Authentication | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Establish account and return API key |\n| `POST` | `/ask` | Bearer API key | Read and control the authenticated Blossom account |\n\nThere are no separate public role-creator, role CRUD, address-creator, address\nCRUD, or address-list protocol surfaces. Express those requests in plain\nlanguage through `/ask`.\n\n### Register\n\n`POST /register`\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"\",\n \"mobileNo\": \"\"\n}\n```\n\nFor a job-seeker:\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"support\",\n \"rightToWork\": true,\n \"passKey\": \"\"\n}\n```\n\nSuccessful response:\n\n```json\n{\n \"success\": true,\n \"apiKey\": \"\",\n \"personId\": 803\n}\n```\n\nPersist `apiKey` securely and reuse it as the Bearer token. Persist `personId`\nonly as the account identifier. Do not persist `passKey`.\n\nIf registration or validation fails, relay the returned error and ask the user\nfor the missing or corrected detail. Never silently change their account type,\nright-to-work answer, name, or company.\n\n### Ask\n\n`POST /ask`\n\n```http\nAuthorization: Bearer \nContent-Type: application/json\n```\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\nSend only the current Blossom instruction. The API key already establishes the\nperson and account type; do not place identity claims, credentials, a\n`passKey`, client-selected authority, or raw conversation history in\n`instructions`.\n\nUse `/ask` for all authenticated marketplace work, including:\n\n- listing, selecting, creating, updating, or removing saved addresses;\n- creating, importing, reading, updating, activating, deactivating, or deleting\n roles;\n- candidate and application questions;\n- finding jobs and applying;\n- PopIn reads and scheduling;\n- follow-up questions needed to complete a pending action.\n\nIf required details are missing or a target is ambiguous, relay the server's\nquestion. Do not manufacture values or switch to a hidden direct endpoint.\n\n## Mutation receipts\n\nConversational `response` text is not proof of a write. Claim that something\nwas saved, created, changed, deleted, posted, applied for, or scheduled only\nwhen `/ask` returns the canonical structured action showing successful\nexecution.\n\nFor role operations, inspect the applicable structured result:\n\n- `actions.hotRole` or the relevant entry in `actions.hotRoles`;\n- `actions.protocolJob`;\n- `actions.jobMutationStatus`;\n- `actions.roleDeletionConfirmation` when another confirmation is required.\n\nRequire the result to identify the actual operation and report successful saved\nexecution. Use returned `roleId`, `roleIdentifier`, `headline`, `addressId`,\n`roleUrl`, `saveStatus`, `saved`, `toolExecuted`, and `message` fields when\npresent. A proposal, pending draft, confirmation request, `saved: false`,\n`toolExecuted: false`, missing action, or prose-only response is not a durable\nrole mutation receipt.\n\nFor address operations, inspect:\n\n- `actions.hotAddress` or the relevant entry in `actions.hotAddresses`;\n- `actions.protocolAddress`.\n\nRequire successful saved execution and use returned `addressId`, `label`,\n`roleId`, `roleHeadline`, `saved`, `success`, and `message` fields when present.\nA read-only result, blocked linked-address deletion, missing action, or\nprose-only response is not a durable address mutation receipt.\n\nFor applications, scheduling, and other actions, use the corresponding\nstructured action in `actions`. When no authoritative action is returned,\nrelay the response without inventing a state change.\n\n## Examples\n\n### Create a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Confirm the known job details and ask for any missing location detail.\n2. If the account is not established, complete `/register` and securely save\n the API key.\n3. Ask: *\"Create café cover for Saturday 11–5 in Sherwood at £12/hour, using\n [confirmed address].\"*\n4. If `/ask` requests another detail or address selection, relay the question.\n5. Say the job was created only from the successful role mutation receipt.\n\n### Update or remove a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\nConfirm the exact change, then send it to `/ask`. Use the returned exact role\ntarget and durable mutation result before saying it changed.\n\n> **User:** Take down the café role.\n\nSend the confirmed request to `/ask`, relay any server-led exact-target\nconfirmation, then claim deletion only when the structured deletion result says\nthe tool executed and saved the deletion.\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Establish a support account through `/register` only after right-to-work\n confirmation.\n2. Confirm the user's location before asking `/ask` to save or use it.\n3. Ask `/ask` to find the work.\n4. When the user chooses a role, confirm the exact application and send it\n through `/ask`.\n5. Relay screening questions and answers through `/ask`.\n6. Claim an application only from its structured successful action.\n\n## Credential failure\n\nThe protocol currently exposes no scoped keys, expiry, password-based protocol\nlogin, or self-service revocation. If the API key is unavailable, do not ask\n`/ask` to authenticate or recreate identity. Re-register only if the user\nintends to create a distinct new account. If a key may have been exposed, stop\nusing it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate\nor revoke access.\n\nFile v2.0.0:_meta.json\n\n{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"2.0.0\",\n \"publishedAt\": 1785423894594\n}\n\nFile v2.0.0:skill-card.md\n\n## Description:
\nSet up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[robbiwu](https://clawhub.ai/user/robbiwu)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal employers and jobseekers use this skill to set up Blossom Hire accounts, post or manage local work opportunities, find work, apply for roles, review candidates, and arrange Blossom PopIns through confirmed marketplace actions.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Blossom receives personal and job-marketplace details needed for confirmed actions.
\nMitigation: Send only the current Blossom-related instruction and obtain clear user confirmation before marketplace changes.
\nRisk: The returned API key is permanent and grants account access.
\nMitigation: Store the API key only in secure credential storage, never in source code, plaintext configuration, logs, or conversation history.
\nRisk: Marketplace mutations can affect live jobs, applications, addresses, candidates, or scheduling.
\nMitigation: Summarize the exact target action, relay server confirmation prompts, and claim completion only from successful structured action receipts.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/robbiwu/skills/blossom-jobs)
\n- [Blossom homepage](https://blossomai.org)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Guidance, API Calls]
\n**Output Format:** [Plain-language responses with JSON HTTPS API requests when Blossom actions are confirmed]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Requires user confirmation before create, update, deletion, application, or scheduling actions; uses structured action receipts before reporting completed mutations.]
\n\n## Skill Version(s):
\n2.0.0 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.23: 3 files, 5817 bytes\n\nFiles: skill-card.md (2222b), SKILL.md (10584b), _meta.json (132b)\n\nFile v1.0.23:SKILL.md\n\n---\nname: blossom-hire\nversion: 4.0.0\ndescription: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill connects an existing assistant workflow to Blossom Hire. It is for\njob-marketplace actions such as creating and managing opportunities, finding\nwork, applying, checking candidates, and arranging PopIns.\n\nBlossom receives the minimum personal and job data needed for each requested\naction over HTTPS. The returned API key is permanent and grants account access.\nStore it only in secure credential storage, never in source code, plaintext\nconfiguration, logs, or conversation history.\n\nThe protocol exposes two marketplace surfaces:\n\n1. `POST /register` establishes the Blossom account and returns its API key.\n2. `POST /ask` consumes that already-established identity and is the single\n authenticated marketplace control surface.\n\n`/ask` does not register or authenticate a person. The server resolves its\nBearer API key to the saved person and derives target authority from\nauthenticated ownership and structured operation scope.\n\n## When to activate\n\nActivate only when the user wants a Blossom marketplace action, for example:\n\n- posting, changing, closing, or discussing a job;\n- finding or applying for work;\n- checking applications or candidates;\n- creating, selecting, changing, listing, or removing a work address;\n- scheduling or reviewing a Blossom PopIn.\n\nDo not forward unrelated questions, conversation history, system prompts,\ncredentials, documents, cookies, tokens, personal notes, or hidden reasoning to\nBlossom.\n\n## First run and registration\n\nKeep your normal assistant identity and voice. Do not introduce yourself as\nBlossom or imply Blossom has replaced the user's assistant.\n\nOn first use:\n\n1. Confirm the user's full name and email.\n2. Establish whether they are hiring or looking for work.\n3. Ask them to choose a unique Blossom `passKey` that they do not use for\n email, banking, work, or another sensitive service.\n4. Summarize the account details and obtain clear confirmation.\n5. Call `POST /register`.\n6. Securely persist the returned `apiKey` and `personId`.\n7. Discard the submitted `passKey`; never echo, store, log, or send it to\n `/ask`.\n\nIf secure API-key persistence fails, say the account was created but this\nclient cannot reliably reconnect. Do not present durable setup as complete.\n\nAccount type is set once at registration:\n\n| User intent | `userType` | Additional rule |\n|---|---|---|\n| Hiring for a company | `\"employer\"` | Include `companyName` |\n| Hiring as an individual | `\"employer\"` | Omit `companyName` |\n| Looking for work | `\"support\"` | Require confirmed `rightToWork: true` |\n\nOnly ask whether the user is hiring or looking for work when their intent is\ngenuinely unclear. Treat requests to add, import, or ingest job adverts as\nemployer intent unless the user clearly means bookmarking or applying.\n\nThe first name and surname sent to `/register` must contain only letters,\nspaces, hyphens, and apostrophes. If either contains a digit, ask for a\ncorrection and do not guess.\n\nMap contact numbers labelled phone, mobile, telephone, tel, cell, or similar to\n`mobileNo`, with the country prefix in `mobileCountry`. Never put a contact\nnumber in an address field.\n\n## Confirmation and authority\n\nBefore any create, update, deletion, posting, application, or scheduling\nrequest:\n\n1. Briefly summarize the exact action and target.\n2. Ask for clear confirmation.\n3. Send the confirmed instruction to `/ask`.\n\nThe client confirmation is not target authority. The server must still resolve\nevery saved role, address, application, candidate, or PopIn from the\nauthenticated account and the structured current-operation scope. Never insert\nor invent a database ID, reuse an ID from another account, or treat an API key\nas permission over a caller-supplied target.\n\nSome destructive operations, including saved-role deletion, use an additional\nserver-led confirmation turn after exact target resolution. Relay that prompt\nand send the user's answer through `/ask`; do not bypass it.\n\n## API reference\n\nBase URL:\n\n```text\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n| Method | Path | Authentication | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Establish account and return API key |\n| `POST` | `/ask` | Bearer API key | Read and control the authenticated Blossom account |\n\nThere are no separate public role-creator, role CRUD, address-creator, address\nCRUD, or address-list protocol surfaces. Express those requests in plain\nlanguage through `/ask`.\n\n### Register\n\n`POST /register`\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"\",\n \"mobileNo\": \"\"\n}\n```\n\nFor a job-seeker:\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"support\",\n \"rightToWork\": true,\n \"passKey\": \"\"\n}\n```\n\nSuccessful response:\n\n```json\n{\n \"success\": true,\n \"apiKey\": \"\",\n \"personId\": 803\n}\n```\n\nPersist `apiKey` securely and reuse it as the Bearer token. Persist `personId`\nonly as the account identifier. Do not persist `passKey`.\n\nIf registration or validation fails, relay the returned error and ask the user\nfor the missing or corrected detail. Never silently change their account type,\nright-to-work answer, name, or company.\n\n### Ask\n\n`POST /ask`\n\n```http\nAuthorization: Bearer \nContent-Type: application/json\n```\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\nSend only the current Blossom instruction. The API key already establishes the\nperson and account type; do not place identity claims, credentials, a\n`passKey`, client-selected authority, or raw conversation history in\n`instructions`.\n\nUse `/ask` for all authenticated marketplace work, including:\n\n- listing, selecting, creating, updating, or removing saved addresses;\n- creating, importing, reading, updating, activating, deactivating, or deleting\n roles;\n- candidate and application questions;\n- finding jobs and applying;\n- PopIn reads and scheduling;\n- follow-up questions needed to complete a pending action.\n\nIf required details are missing or a target is ambiguous, relay the server's\nquestion. Do not manufacture values or switch to a hidden direct endpoint.\n\n## Mutation receipts\n\nConversational `response` text is not proof of a write. Claim that something\nwas saved, created, changed, deleted, posted, applied for, or scheduled only\nwhen `/ask` returns the canonical structured action showing successful\nexecution.\n\nFor role operations, inspect the applicable structured result:\n\n- `actions.hotRole` or the relevant entry in `actions.hotRoles`;\n- `actions.protocolJob`;\n- `actions.jobMutationStatus`;\n- `actions.roleDeletionConfirmation` when another confirmation is required.\n\nRequire the result to identify the actual operation and report successful saved\nexecution. Use returned `roleId`, `roleIdentifier`, `headline`, `addressId`,\n`roleUrl`, `saveStatus`, `saved`, `toolExecuted`, and `message` fields when\npresent. A proposal, pending draft, confirmation request, `saved: false`,\n`toolExecuted: false`, missing action, or prose-only response is not a durable\nrole mutation receipt.\n\nFor address operations, inspect:\n\n- `actions.hotAddress` or the relevant entry in `actions.hotAddresses`;\n- `actions.protocolAddress`.\n\nRequire successful saved execution and use returned `addressId`, `label`,\n`roleId`, `roleHeadline`, `saved`, `success`, and `message` fields when present.\nA read-only result, blocked linked-address deletion, missing action, or\nprose-only response is not a durable address mutation receipt.\n\nFor applications, scheduling, and other actions, use the corresponding\nstructured action in `actions`. When no authoritative action is returned,\nrelay the response without inventing a state change.\n\n## Examples\n\n### Create a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Confirm the known job details and ask for any missing location detail.\n2. If the account is not established, complete `/register` and securely save\n the API key.\n3. Ask: *\"Create café cover for Saturday 11–5 in Sherwood at £12/hour, using\n [confirmed address].\"*\n4. If `/ask` requests another detail or address selection, relay the question.\n5. Say the job was created only from the successful role mutation receipt.\n\n### Update or remove a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\nConfirm the exact change, then send it to `/ask`. Use the returned exact role\ntarget and durable mutation result before saying it changed.\n\n> **User:** Take down the café role.\n\nSend the confirmed request to `/ask`, relay any server-led exact-target\nconfirmation, then claim deletion only when the structured deletion result says\nthe tool executed and saved the deletion.\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Establish a support account through `/register` only after right-to-work\n confirmation.\n2. Confirm the user's location before asking `/ask` to save or use it.\n3. Ask `/ask` to find the work.\n4. When the user chooses a role, confirm the exact application and send it\n through `/ask`.\n5. Relay screening questions and answers through `/ask`.\n6. Claim an application only from its structured successful action.\n\n## Credential failure\n\nThe protocol currently exposes no scoped keys, expiry, password-based protocol\nlogin, or self-service revocation. If the API key is unavailable, do not ask\n`/ask` to authenticate or recreate identity. Re-register only if the user\nintends to create a distinct new account. If a key may have been exposed, stop\nusing it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate\nor revoke access.\n\nFile v1.0.23:_meta.json\n\n{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"1.0.23\",\n \"publishedAt\": 1785423675072\n}\n\nFile v1.0.23:skill-card.md\n\n## Description:
\nSet up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[robbiwu](https://clawhub.ai/user/robbiwu)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal employers and jobseekers use this skill to manage Blossom Hire marketplace workflows, including creating roles, finding work, applying for roles, managing addresses, reviewing candidates, and scheduling PopIns.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The Blossom API key is permanent and grants account access if exposed.
\nMitigation: Store it only in secure credential storage and contact Blossom support if it may have been exposed.
\nRisk: The skill can create, edit, delete, post, apply for, and schedule marketplace items.
\nMitigation: Require clear user confirmation before mutations and rely on structured action receipts before claiming a change was completed.
\nRisk: Unrelated prompts, credentials, or conversation history could disclose unnecessary personal or account data.
\nMitigation: Send only the current confirmed Blossom-related instruction and the minimum personal or job data needed for the requested action.
\n\n\n## Reference(s):
\n- [ClawHub skill listing](https://clawhub.ai/robbiwu/skills/blossom-jobs)
\n- [Blossom homepage](https://blossomai.org)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Guidance, API Calls, Configuration]
\n**Output Format:** [Markdown and JSON request guidance]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Requires secure storage for the returned Blossom API key and user confirmation before marketplace mutations.]
\n\n## Skill Version(s):
\n1.0.23 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.22: 3 files, 10826 bytes\n\nFiles: skill-card.md (2220b), SKILL.md (26425b), _meta.json (132b)\n\nFile v1.0.22:SKILL.md\n\n---\nname: blossom-hire\nversion: 3.0.4\ndescription: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill is provided by Blossom at [https://blossomai.org](https://blossomai.org). For help, reach out to [hello@blossomai.org](mailto:hello@blossomai.org).\n\nThis skill is for structured Blossom marketplace actions only — posting jobs, searching for work, applying, and managing listings.\n\nIt collects personal data (name, email, address, job details) and sends it over HTTPS to the Blossom API. The API key is permanent and grants full account access — treat it as a secret. No data is stored locally.\n\nThe current protocol does not expose scoped keys, expiry, or self-service revocation to skill callers. If an API key may have been exposed, stop using it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate or revoke account access.\n\n## First-run welcome and registration\n\nWhen your user first adds Blossom Hire Copilot, do not treat them as an anonymous new user. You are already their assistant. Blossom is being connected to that existing workflow so you can help them work with Blossom Hire from here.\n\nThe first Blossom moment should guide the user toward account setup and registration. Do not give a generic feature list.\n\nKeep your normal assistant identity and voice. Do not introduce yourself as Blossom or imply Blossom AI is taking over the user's workflow. After registration has started or completed, do not repeat this first-run introduction.\n\nSuggested first-run introduction:\n\n> I can now work with Blossom Hire from here.\n>\n> First, I'll help you get your Blossom Hire account ready. I'll ask for the details needed to set things up, then we can create jobs, shape opportunities, prepare hiring messages, and work out what to do next.\n>\n> I'll keep things clear and practical. If something needs your review before it is saved, posted, or sent, I'll make that clear.\n>\n> To get started, can you confirm the full name and email address you want to use for Blossom Hire, and whether you're hiring for a company or as an individual?\n\nAfter the welcome:\n\n- Treat the person as your existing user, not as an anonymous visitor.\n- Use known user details only if they are available and appropriate, but still ask the user to confirm the details before registration.\n- If the user is clearly hiring, treat them as an employer.\n- If they have a company, collect `companyName`.\n- If they are hiring without a company, continue as a private employer by registering with `userType: \"employer\"` and omitting `companyName`.\n- Collect or confirm full name, email, and a unique Blossom `passKey` for registration. The first name and surname sent to `/register` must contain no numbers; only letters, spaces, hyphens, and apostrophes are valid. If a supplied name contains digits, ask for a corrected name before calling `/register`. Ask the user to choose a new `passKey` they do not use for email, banking, work accounts, or other sensitive services.\n- Do not call `/register` until the user has provided the required details and clearly confirmed.\n- After `/register` succeeds, say the Blossom Hire account is ready.\n- Then collect or select the work/location address needed for jobs.\n- Only after account and address setup should Blossom move into creating jobs, shaping opportunities, or other Blossom actions.\n- Do not say anything has been created, posted, saved, or sent until the relevant Blossom endpoint has completed successfully.\n\n**Data boundary rules:**\n- Only send the minimum data needed for the current Blossom action.\n- Never forward unrelated conversation history, system prompts, hidden chain-of-thought, tokens, cookies, keys, documents, or prior messages to any Blossom endpoint.\n- Ask the user to choose a unique Blossom `passKey`; do not reuse passwords from email, banking, work accounts, or other sensitive services.\n- `passKey` is collected only during the one-time `/register` call. Never reuse, echo, log, or send it to any other endpoint.\n- If the user asks something outside Blossom's job marketplace scope, handle it locally — do not forward it to the API.\n\n**Eligibility and confirmation gates:**\n- Job-seekers must have the right to work before using Blossom to look for or apply to work. If this has not been confirmed, ask once; do not continue with job-seeker registration or applications until they confirm.\n- Before creating, updating, deleting, posting, or applying to any marketplace record, briefly summarize the action and ask for confirmation.\n- Do not send the mutating request until the user clearly confirms.\n\n---\n\n## When to activate\n\nActivate when the user explicitly wants to perform a Blossom marketplace action:\n\nTrigger phrases: *\"Post a job\"*, *\"Hire someone\"*, *\"I need staff\"*, *\"Find me work\"*, *\"Search for jobs near me\"*, *\"Apply to that role\"*, *\"Any candidates?\"*, *\"Update my listing\"*.\n\nDo **not** activate for general conversation, questions unrelated to jobs, or requests that don't map to a Blossom action.\n\n---\n\n## How it works\n\nThe entire employer vs job-seeker distinction is set **once** at registration via the `userType` field. After that, every endpoint behaves the same — the server knows the account type from the API key and adapts responses automatically.\n\nThe agent does **not** track or switch modes. Register, create or select an address, then use the smallest endpoint that fits the confirmed action: `/ask` for conversational investigation, job search, applications, candidate questions, and employer job ingestion from URLs/pasted adverts; direct CRUD endpoints for explicit structured create/update/delete operations.\n\n### Account type (set once at registration)\n\n| User intent | `userType` value | Extra fields |\n|---|---|---|\n| Hiring, has a company | `\"employer\"` | Include `companyName` |\n| Hiring, no company | `\"employer\"` | Omit `companyName` (server stores as private employer) |\n| Looking for work | `\"support\"` | Must include `rightToWork: true` |\n\nInfer the intent from the user's message. Only ask *\"Are you looking to hire, or looking for work?\"* if the intent is genuinely unclear. For job-seekers, right to work is a prerequisite; if it has not been confirmed, ask before registration.\n\n**Ambiguous \"add jobs\" rule:** If the user asks to *add a job*, *add jobs*, *add this job*, *ingest this URL*, *import this advert*, or provides a job URL/listing to add, treat that as employer role ingestion unless they clearly say they are looking for work, saving job-seeker library entries, bookmarking roles, or applying as a candidate. Register through the employer path for this intent. The protocol registration payload still uses `\"userType\": \"employer\"` for both company employers and private employers; omit `companyName` when the employer has no company so the server can store the account as a private employer. If the employer account shape is rejected by the API, relay the rejection and ask for the missing account details instead of silently switching to a job-seeker account.\n\n### Flow\n\n1. Collect identity: email, full name, passKey. Split the full name into `name` and `surname` for `/register`; if the surname cannot be inferred, ask for it. `name` and `surname` must not contain numbers; if either part contains a digit, ask for a corrected name and do not call `/register`. Optionally: mobile country code, mobile number, company name. Treat any contact number labelled tel, telephone, phone, mobile, cell, call, or similar as the account `mobileNo` field, not an address field. For job-seekers, confirm they have the right to work before continuing.\n2. **Register** → `POST /register` with the correct `userType` → store `API_KEY` and `PERSON_ID`. Discard `passKey` from memory immediately after this call.\n3. **Create or select address** → use `GET /getAddresses` when the account may already have a suitable address; otherwise `POST /address` with the user's location → store `ADDRESS_ID`. Employers need this to attach a location to roles. Job-seekers need this so the server can find nearby opportunities.\n4. **Talk / investigate** → `POST /ask` with only the minimal job-related instruction needed for the current Blossom action. Do not forward unrelated context, secrets, or raw conversation history. For employer requests to add/import/ingest a job from a URL or pasted advert, use `/ask` so the employer protocol job ingestion path can create the address/role when enough information is available.\n\nFor employers posting a role directly (without `/ask`), use `POST /role` only after the user has confirmed a structured role payload with headline, description, introduction, working hours, pay/currency/frequency, remote status, active status, and a valid saved `ADDRESS_ID`.\n\n---\n\n## API reference\n\n### Base URL\n```\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n### Endpoints\n\n| Method | Path | Auth | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Create account → get API key |\n| `GET` | `/getAddresses` | Bearer | Return all addresses for the account |\n| `POST` | `/address` | Bearer | Create / update address(es) |\n| `DELETE` | `/address` | Bearer | Soft-delete address(es) |\n| `POST` | `/role` | Bearer | Create / update role(s) |\n| `DELETE` | `/role` | Bearer | Delete role(s), retaining server-side backup/history |\n| `POST` | `/ask` | Bearer | Conversational AI endpoint |\n| `POST` | `/image` | Bearer | Upload profile image (person or role) |\n\n### Session state\n\nStore and reuse across calls:\n- **`API_KEY`** — returned from `/register`, used as `Authorization: Bearer ` for all subsequent calls\n- **`PERSON_ID`** — returned from `/register`\n- **`ADDRESS_ID`** — returned from `/address`, or from `/getAddresses` for existing addresses, needed when creating a role\n\nThe API key is permanent. No session expiry or login flow.\n\n> **Important:** Never store the API key in global config. Keep it in runtime memory for the current session only.\n> If the key may have been exposed, stop using it and contact Blossom support for revocation or rotation.\n\n---\n\n## API contract\n\n### 1. Register\n\n`POST /register` — no auth required.\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"<+44>\",\n \"mobileNo\": \"\"\n}\n```\n\nFor job-seekers, set `\"userType\": \"support\"` and include `\"rightToWork\": true`. Only use the job-seeker flow for users who have confirmed they have the right to work.\n\n| Field | Required | Notes |\n|---|---|---|\n| `name` | yes | First name, derived from the user's full name. Must not contain numbers; only letters, spaces, hyphens, and apostrophes are valid. |\n| `surname` | yes | Last name/surname, derived from the user's full name. Must not contain numbers; only letters, spaces, hyphens, and apostrophes are valid. |\n| `email` | yes | Must be unique |\n| `userType` | yes | `\"employer\"` or `\"support\"` |\n| `passKey` | yes | User-chosen password. Collect only for `/register`, use once, then discard — never send to any other endpoint |\n| `rightToWork` | yes (support) | Must be `true` when `userType` is `\"support\"` |\n| `companyName` | no | For employers. Omit or leave empty for private employers |\n| `mobileCountry` | no | e.g. `\"+44\"` |\n| `mobileNo` | no | Account contact number. Use this for tel, telephone, phone, mobile, cell, call, or similar contact labels. Do not place phone numbers on addresses. |\n\n**Phone/contact mapping:** If the user provides a number such as `\"Tel: 0300 456 8174\"`, send it during `/register` as:\n\n```json\n{\n \"mobileCountry\": \"+44\",\n \"mobileNo\": \"0300 456 8174\"\n}\n```\n\nIf the number already includes a country prefix, split that prefix into `mobileCountry` and put the remaining local/national number in `mobileNo`.\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"apiKey\": \"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\",\n \"personId\": 803\n}\n```\n\nIf the email already exists → `400`. If validation fails, including names with numbers, relay the validation message and ask for corrected details. Do not retry by guessing or rewriting the user's name.\n\n---\n\n### 2. Create address\n\n`POST /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [\n {\n \"id\": 0,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"GB\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": false,\n \"isActive\": true\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `street` | yes | Street name |\n| `city` | yes | City / town |\n| `country` | yes | ISO 3166-1 alpha-2 code — e.g. `\"GB\"`, `\"US\"`, `\"AU\"`. Server rejects unrecognised codes. |\n| `postcode` | yes | Postal / ZIP code |\n| `label` | yes | User-facing label, e.g. `\"Work location\"` |\n| `houseNumber` | support yes, employer no | Required for job-seeker (`support`) addresses. Optional for employer/private-employer work or venue addresses when unavailable. |\n| `area` | no | Neighbourhood / district |\n| `isHome` | no | Default `false` |\n| `isActive` | no | Default `true` |\n\n- The response may include a top-level `addressId` and/or returned address objects with assigned `id` values — store the created or selected ID as `ADDRESS_ID`. If the ID is unclear, call `GET /getAddresses` and select the matching saved address.\n- Job-seeker accounts (`support`) must provide a house/building number for their own address. Employer and private-employer work/site addresses may omit it when the street, city/town, country, and postal code identify the location.\n\n---\n\n### 3. Get addresses\n\n`GET /getAddresses` — Bearer auth required.\n\nUse this to fetch the current account's saved addresses before updating, deleting, or attaching an address to a role. Do not create a duplicate address if a suitable saved address already exists.\n\nNo request body.\n\n**Response** `200`:\n```json\n{\n \"success\": true,\n \"messages\": [\"Addresses retrieved\"],\n \"dataList\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ],\n \"addresses\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ]\n}\n```\n\nStore the selected address `id` as `ADDRESS_ID`.\n\n---\n\n### 4. Delete address\n\n`DELETE /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [{ \"id\": }]\n}\n```\n\nCannot delete an address linked to an active role (`409`).\n\n---\n\n### 5. Create role\n\n`POST /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [\n {\n \"id\": 0,\n \"headline\": \"\",\n \"jobDescription\": \"\",\n \"introduction\": \"\",\n \"workingHours\": \"\",\n \"salary\": ,\n \"currencyName\": \"GBP\",\n \"currencySymbol\": \"£\",\n \"paymentFrequency\": { \"choices\": [\"\"], \"selectedIndex\": 0 },\n \"requirements\": [\n { \"requirementName\": \"\", \"mandatory\": false, \"originalRequirement\": true }\n ],\n \"benefits\": [\n { \"benefitName\": \"\", \"mandatory\": false }\n ],\n \"addressId\": ,\n \"isRemote\": false,\n \"isActive\": true,\n \"modified\": ,\n \"roleIdentifier\": \"copilot-\"\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `headline` | yes | Short title |\n| `jobDescription` | yes | Full description |\n| `introduction` | yes | Short intro text, minimum 10 characters |\n| `workingHours` | yes | e.g. `\"Saturday 11am–5pm\"` or `\"Flexible\"` |\n| `salary` | yes | Numeric amount; use `0` when pay is negotiable or not yet discussed |\n| `paymentFrequency` | no | Expected for pay display when salary is known: `choices` array with up to 8 entries; each choice must be a non-empty string up to 20 characters; empty `choices` or omitted `selectedIndex` defaults to standard frequencies |\n| `currencySymbol` | yes | Currency symbol, 1-3 characters |\n| `currencyName` | yes | Currency code/name, e.g. `\"GBP\"` |\n| `addressId` | yes | From the address creation step |\n| `isRemote` | yes | Boolean remote-work flag |\n| `isActive` | yes | Boolean active flag; new roles are often created inactive until server/company clearance allows activation |\n| `modified` | yes | Current epoch millis |\n| `roleIdentifier` | yes | Unique string, e.g. `\"copilot-\" + epochMillis` |\n| `requirements` | no | Screening topics for the application conversation; if present, send an array of up to 8 objects |\n| `benefits` | no | Perks; if present, send an array of up to 8 objects |\n\n**Requirement semantics**\n\nRequirements are not all eligibility gates. The `mandatory` flag controls how the application should be treated:\n\n- `mandatory: true` means the requirement is a hard gate. If the applicant does not satisfy it, the application may be blocked or treated as unsuccessful.\n- `mandatory: false` means the requirement is a discussion point or preference. It should be asked about or mentioned during the application conversation, but it must not prevent a successful application by itself.\n\nWhen adding employer-supplied requirements to a role, default to `mandatory: false` unless the employer clearly says the requirement is essential, legally required, or non-negotiable.\n\n**Benefit state semantics**\n\nFor benefits, `mandatory` is a legacy state selector, not an eligibility or guarantee flag:\n\n- `mandatory: true` means \"Provided\": a concrete company-given benefit or perk. Candidate-facing role cards list this item directly as a provided perk.\n- `mandatory: false` means \"Part of the job\": culture, team makeup, or role context. Candidate-facing role cards hide this item, but Blossom may use it conversationally as context. It must not be described as a guaranteed perk, compensation, entitlement, or company-provided benefit.\n\nWhen adding benefits, use `mandatory: true` for concrete provided perks such as meals, discounts, equipment, transport, or schedule benefits. Use `mandatory: false` for culture/team/context statements that are part of the role rather than something the company provides.\n\n**Validation notes**\n\nThe backend currently enforces these role validation rules:\n\n| Field | Validation |\n|---|---|\n| `headline` | Required, 5-35 characters |\n| `jobDescription` | Required, 1-500 characters |\n| `introduction` | Required, 10-500 characters |\n| `workingHours` | Required, 1-150 characters |\n| `roleIdentifier` | Required, 1-100 characters |\n| `currencySymbol` | Required, 1-3 characters |\n| `currencyName` | Required string with no digits, max 5 characters |\n| `salary` | Optional, but if provided must be a number `>= 0` |\n| `paymentFrequency` | Optional, but if provided must be an object with `choices` array of up to 8 non-empty strings, each max 20 characters, and `selectedIndex` pointing to an existing choice; empty `choices` defaults to standard frequencies and missing `selectedIndex` defaults to `0` |\n| `addressId` | Required for new roles, whole number `> 0` from a saved address |\n| `id` | Required, whole number `>= 0` |\n| `modified` | Required, must be present |\n| `isActive` | Required, boolean |\n| `isRemote` | Required, boolean |\n| `email` | Optional, but if provided it must be a valid email address |\n| `requirements` | Optional array, max 8 objects |\n| `requirements[].requirementName` | Required for each requirement object, 0-200 characters after trimming and bullet/newline cleanup |\n| `requirements[].mandatory` | Optional, but if provided it must be a boolean |\n| `benefits` | Optional array, max 8 objects |\n| `benefits[].benefitName` | Required for each benefit object, 0-200 characters after trimming and bullet/newline cleanup |\n| `benefits[].mandatory` | Optional, but if provided it must be a boolean |\n\nOperational notes for protocol callers:\n\n- New roles still need a valid saved `addressId`; do not send `0` for a new role.\n- The docs and examples should always send a non-empty `introduction`.\n- Send no more than 10 roles in one request.\n\n**Response** `201`: The role(s) with assigned IDs.\n\n---\n\n### 6. Delete role\n\n`DELETE /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [{ \"id\": }]\n}\n```\n\nEvery role `id` must belong to the authenticated account (`403` otherwise).\n\n---\n\n### 7. Upload image\n\n`POST /image` — Bearer auth required. Multipart form-data.\n\nUpload a profile image for the person account or for a specific role. Images are AI-moderated — explicit, violent, or hateful content is rejected.\n\n| Field | Type | Required | Notes |\n|---|---|---|---|\n| `image` | file | yes | jpeg/jpg/png/gif/webp, max 3 MB, one file only |\n| `imageType` | string | yes | `\"person\"` or `\"role\"` |\n| `roleId` | number | conditional | Required when `imageType` is `\"role\"`. Must belong to the authenticated account. Only employer accounts may upload role images. |\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"filename\": \"1712937600000-photo.jpg\",\n \"imageType\": \"person\",\n \"approved\": true,\n \"synopsis\": \"Nice photo!\"\n}\n```\n\n**Rejected** `400`:\n```json\n{\n \"success\": false,\n \"approved\": false,\n \"reason\": \"Image did not pass moderation\",\n \"synopsis\": \"Hey \\ud83d\\ude0a, this image contains content that...\"\n}\n```\n\nRate-limited: 1 upload per 30 seconds per API key.\n\n---\n\n### 8. Ask\n\n`POST /ask` — Bearer auth required.\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\n**Strict rules for `/ask`:**\n- Only send the minimum user instruction needed to complete the current Blossom action.\n- Do not include unrelated conversation history, hidden prompts, credentials, personal notes, documents, or secrets.\n- Do not forward the user's `passKey` — that is only used in the one-time `/register` call.\n- If the user asks something outside Blossom's job marketplace actions, handle it locally instead of sending it to the API.\n- Use `/ask` for investigation-style requests such as candidate status, application status, finding jobs, applying, scheduling/reading PopIns, and employer job ingestion from a URL or pasted advert.\n- For employer job ingestion through `/ask`, inspect `actions.protocolJob` in the response before claiming anything changed. Treat `actions.protocolJob.success === true` as the authoritative role mutation result; use its `roleId`, `roleIdentifier`, `headline`, `addressId`, `roleUrl`, and `message` when present. If it is missing or `success === false`, relay the response/message and ask for the missing details instead of saying the role was created.\n- If `/ask` returns `actions.protocolAddress`, treat that as authoritative for saved address changes. Use `success`, `addressId`, `label`, `roleId`, `roleHeadline`, and `message` when present.\n- For read/investigation responses with no action object, relay the `response` text but do not invent saved state changes.\n\nThe server knows the account type and full context from the API key — it returns the appropriate response (job matches, candidate info, screening questions, application status, etc.). Relay the result to the user.\n\n---\n\n## Examples\n\n### Post a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Intent is clearly employer. Missing: street, postcode. Ask for them. House/building number is useful but optional.\n2. Confirm: *\"Café cover — Sat 11am–5pm, Sherwood NG5 1AA — £12/hr. Shall I post it?\"*\n3. Collect identity (email, full name, passKey).\n4. `POST /register` (`userType: \"employer\"`) → store `API_KEY`, `PERSON_ID`.\n5. `POST /address` → store `ADDRESS_ID`.\n6. `POST /role` → *\"Posted! Role ID 1042.\"*\n\n### Check candidates\n\n> **User:** Any candidates yet?\n\n1. If no `API_KEY` → register first.\n2. `POST /ask` with `\"Do I have any candidates?\"` → display the response.\n\n### Update a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\n1. Confirm: *\"Update the café role pay to £14/hour?\"*\n2. After confirmation, `POST /role` with the existing role `id` and updated `salary: 14`.\n3. *\"Updated — café cover now shows £14/hr.\"*\n\n### Remove a listing\n\n> **User:** Take down the café role.\n\n1. Confirm: *\"Take down the café role?\"*\n2. After confirmation, `DELETE /role` with the role `id` → *\"Removed.\"*\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Intent is clearly job-seeker. Collect identity (email, full name, passKey).\n2. Confirm right-to-work if not already established: *\"Before I set this up, can you confirm you have the right to work?\"*\n3. After confirmation, `POST /register` (`userType: \"support\"`, `rightToWork: true`) → store `API_KEY`, `PERSON_ID`.\n4. `POST /address` (their Nottingham location) → store `ADDRESS_ID`.\n5. `POST /ask` with `\"Find bar work near me this weekend\"` → present matching roles.\n6. User picks one → confirm: *\"Apply to role 1055?\"*\n7. After confirmation, `POST /ask` with `\"Apply to role 1055\"` → relay result.\n8. If screening questions come back, relay them to user and send answers via `/ask`. Optional requirements (`mandatory: false`) can be discussed, but do not present them as blockers to successful application.\n\n### Check application status\n\n> **User:** How are my applications going?\n\n1. `POST /ask` with `\"What's the status of my applications?\"` → display the response.\n\nFile v1.0.22:_meta.json\n\n{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"1.0.22\",\n \"publishedAt\": 1780117326883\n}\n\nFile v1.0.22:skill-card.md\n\n## Description:
\nSet up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[robbiwu](https://clawhub.ai/user/robbiwu)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal users, employers, and jobseekers use this skill through an agent to register with Blossom Hire, create or manage local work opportunities, search for jobs, apply to roles, and review candidate or application status.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill sends hiring, job-search, account, address, and application details to Blossom's hosted API and uses a permanent API key with full account access.
\nMitigation: Install only if that data sharing is acceptable, keep the API key in runtime memory only, use a unique Blossom passKey, and contact Blossom support to rotate or revoke access if the key may be exposed.
\nRisk: Marketplace create, update, delete, post, and apply actions can affect real Blossom records.
\nMitigation: Review the action summary and require clear user confirmation before sending any mutating request.
\n\n\n## Reference(s):
\n- [ClawHub listing](https://clawhub.ai/robbiwu/blossom-jobs)
\n- [Blossom homepage](https://blossomai.org)
\n- [Blossom privacy policy](https://blossomai.org/privacypolicy.html)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, API Calls, Configuration]
\n**Output Format:** [Plain-language guidance with JSON API payloads and confirmation prompts]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Requires runtime-only handling of API keys, person IDs, and address IDs; no local data storage is described.]
\n\n## Skill Version(s):
\n1.0.22 (source: ClawHub release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.21: 3 files, 10655 bytes\n\nFiles: skill-card.md (2455b), SKILL.md (25567b), _meta.json (132b)\n\nFile v1.0.21:SKILL.md\n\n---\nname: blossom-hire\nversion: 3.0.3\ndescription: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill is provided by Blossom at [https://blossomai.org](https://blossomai.org). For help, reach out to [hello@blossomai.org](mailto:hello@blossomai.org).\n\nThis skill is for structured Blossom marketplace actions only — posting jobs, searching for work, applying, and managing listings.\n\nIt collects personal data (name, email, address, job details) and sends it over HTTPS to the Blossom API. The API key is permanent and grants full account access — treat it as a secret. No data is stored locally.\n\nThe current protocol does not expose scoped keys, expiry, or self-service revocation to skill callers. If an API key may have been exposed, stop using it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate or revoke account access.\n\n## First-run welcome and registration\n\nWhen your user first adds Blossom Hire Copilot, do not treat them as an anonymous new user. You are already their assistant. Blossom is being connected to that existing workflow so you can help them work with Blossom Hire from here.\n\nThe first Blossom moment should guide the user toward account setup and registration. Do not give a generic feature list.\n\nKeep your normal assistant identity and voice. Do not introduce yourself as Blossom or imply Blossom AI is taking over the user's workflow. After registration has started or completed, do not repeat this first-run introduction.\n\nSuggested first-run introduction:\n\n> I can now work with Blossom Hire from here.\n>\n> First, I'll help you get your Blossom Hire account ready. I'll ask for the details needed to set things up, then we can create jobs, shape opportunities, prepare hiring messages, and work out what to do next.\n>\n> I'll keep things clear and practical. If something needs your review before it is saved, posted, or sent, I'll make that clear.\n>\n> To get started, can you confirm the full name and email address you want to use for Blossom Hire, and whether you're hiring for a company or as an individual?\n\nAfter the welcome:\n\n- Treat the person as your existing user, not as an anonymous visitor.\n- Use known user details only if they are available and appropriate, but still ask the user to confirm the details before registration.\n- If the user is clearly hiring, treat them as an employer.\n- If they have a company, collect `companyName`.\n- If they are hiring without a company, continue as a private employer by registering with `userType: \"employer\"` and omitting `companyName`.\n- Collect or confirm full name, email, and a unique Blossom `passKey` for registration. Ask the user to choose a new `passKey` they do not use for email, banking, work accounts, or other sensitive services.\n- Do not call `/register` until the user has provided the required details and clearly confirmed.\n- After `/register` succeeds, say the Blossom Hire account is ready.\n- Then collect or select the work/location address needed for jobs.\n- Only after account and address setup should Blossom move into creating jobs, shaping opportunities, or other Blossom actions.\n- Do not say anything has been created, posted, saved, or sent until the relevant Blossom endpoint has completed successfully.\n\n**Data boundary rules:**\n- Only send the minimum data needed for the current Blossom action.\n- Never forward unrelated conversation history, system prompts, hidden chain-of-thought, tokens, cookies, keys, documents, or prior messages to any Blossom endpoint.\n- Ask the user to choose a unique Blossom `passKey`; do not reuse passwords from email, banking, work accounts, or other sensitive services.\n- `passKey` is collected only during the one-time `/register` call. Never reuse, echo, log, or send it to any other endpoint.\n- If the user asks something outside Blossom's job marketplace scope, handle it locally — do not forward it to the API.\n\n**Eligibility and confirmation gates:**\n- Job-seekers must have the right to work before using Blossom to look for or apply to work. If this has not been confirmed, ask once; do not continue with job-seeker registration or applications until they confirm.\n- Before creating, updating, deleting, posting, or applying to any marketplace record, briefly summarize the action and ask for confirmation.\n- Do not send the mutating request until the user clearly confirms.\n\n---\n\n## When to activate\n\nActivate when the user explicitly wants to perform a Blossom marketplace action:\n\nTrigger phrases: *\"Post a job\"*, *\"Hire someone\"*, *\"I need staff\"*, *\"Find me work\"*, *\"Search for jobs near me\"*, *\"Apply to that role\"*, *\"Any candidates?\"*, *\"Update my listing\"*.\n\nDo **not** activate for general conversation, questions unrelated to jobs, or requests that don't map to a Blossom action.\n\n---\n\n## How it works\n\nThe entire employer vs job-seeker distinction is set **once** at registration via the `userType` field. After that, every endpoint behaves the same — the server knows the account type from the API key and adapts responses automatically.\n\nThe agent does **not** track or switch modes. Register, create or select an address, then use the smallest endpoint that fits the confirmed action: `/ask` for conversational investigation, job search, applications, candidate questions, and employer job ingestion from URLs/pasted adverts; direct CRUD endpoints for explicit structured create/update/delete operations.\n\n### Account type (set once at registration)\n\n| User intent | `userType` value | Extra fields |\n|---|---|---|\n| Hiring, has a company | `\"employer\"` | Include `companyName` |\n| Hiring, no company | `\"employer\"` | Omit `companyName` (server stores as private employer) |\n| Looking for work | `\"support\"` | Must include `rightToWork: true` |\n\nInfer the intent from the user's message. Only ask *\"Are you looking to hire, or looking for work?\"* if the intent is genuinely unclear. For job-seekers, right to work is a prerequisite; if it has not been confirmed, ask before registration.\n\n**Ambiguous \"add jobs\" rule:** If the user asks to *add a job*, *add jobs*, *add this job*, *ingest this URL*, *import this advert*, or provides a job URL/listing to add, treat that as employer role ingestion unless they clearly say they are looking for work, saving job-seeker library entries, bookmarking roles, or applying as a candidate. Register through the employer path for this intent. The protocol registration payload still uses `\"userType\": \"employer\"` for both company employers and private employers; omit `companyName` when the employer has no company so the server can store the account as a private employer. If the employer account shape is rejected by the API, relay the rejection and ask for the missing account details instead of silently switching to a job-seeker account.\n\n### Flow\n\n1. Collect identity: email, full name, passKey. Split the full name into `name` and `surname` for `/register`; if the surname cannot be inferred, ask for it. Optionally: mobile country code, mobile number, company name. Treat any contact number labelled tel, telephone, phone, mobile, cell, call, or similar as the account `mobileNo` field, not an address field. For job-seekers, confirm they have the right to work before continuing.\n2. **Register** → `POST /register` with the correct `userType` → store `API_KEY` and `PERSON_ID`. Discard `passKey` from memory immediately after this call.\n3. **Create or select address** → use `GET /getAddresses` when the account may already have a suitable address; otherwise `POST /address` with the user's location → store `ADDRESS_ID`. Employers need this to attach a location to roles. Job-seekers need this so the server can find nearby opportunities.\n4. **Talk / investigate** → `POST /ask` with only the minimal job-related instruction needed for the current Blossom action. Do not forward unrelated context, secrets, or raw conversation history. For employer requests to add/import/ingest a job from a URL or pasted advert, use `/ask` so the employer protocol job ingestion path can create the address/role when enough information is available.\n\nFor employers posting a role directly (without `/ask`), use `POST /role` only after the user has confirmed a structured role payload with headline, description, introduction, working hours, pay/currency/frequency, remote status, active status, and a valid saved `ADDRESS_ID`.\n\n---\n\n## API reference\n\n### Base URL\n```\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n### Endpoints\n\n| Method | Path | Auth | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Create account → get API key |\n| `GET` | `/getAddresses` | Bearer | Return all addresses for the account |\n| `POST` | `/address` | Bearer | Create / update address(es) |\n| `DELETE` | `/address` | Bearer | Soft-delete address(es) |\n| `POST` | `/role` | Bearer | Create / update role(s) |\n| `DELETE` | `/role` | Bearer | Delete role(s), retaining server-side backup/history |\n| `POST` | `/ask` | Bearer | Conversational AI endpoint |\n| `POST` | `/image` | Bearer | Upload profile image (person or role) |\n\n### Session state\n\nStore and reuse across calls:\n- **`API_KEY`** — returned from `/register`, used as `Authorization: Bearer ` for all subsequent calls\n- **`PERSON_ID`** — returned from `/register`\n- **`ADDRESS_ID`** — returned from `/address`, or from `/getAddresses` for existing addresses, needed when creating a role\n\nThe API key is permanent. No session expiry or login flow.\n\n> **Important:** Never store the API key in global config. Keep it in runtime memory for the current session only.\n> If the key may have been exposed, stop using it and contact Blossom support for revocation or rotation.\n\n---\n\n## API contract\n\n### 1. Register\n\n`POST /register` — no auth required.\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"<+44>\",\n \"mobileNo\": \"\"\n}\n```\n\nFor job-seekers, set `\"userType\": \"support\"` and include `\"rightToWork\": true`. Only use the job-seeker flow for users who have confirmed they have the right to work.\n\n| Field | Required | Notes |\n|---|---|---|\n| `name` | yes | First name, derived from the user's full name |\n| `surname` | yes | Last name/surname, derived from the user's full name |\n| `email` | yes | Must be unique |\n| `userType` | yes | `\"employer\"` or `\"support\"` |\n| `passKey` | yes | User-chosen password. Collect only for `/register`, use once, then discard — never send to any other endpoint |\n| `rightToWork` | yes (support) | Must be `true` when `userType` is `\"support\"` |\n| `companyName` | no | For employers. Omit or leave empty for private employers |\n| `mobileCountry` | no | e.g. `\"+44\"` |\n| `mobileNo` | no | Account contact number. Use this for tel, telephone, phone, mobile, cell, call, or similar contact labels. Do not place phone numbers on addresses. |\n\n**Phone/contact mapping:** If the user provides a number such as `\"Tel: 0300 456 8174\"`, send it during `/register` as:\n\n```json\n{\n \"mobileCountry\": \"+44\",\n \"mobileNo\": \"0300 456 8174\"\n}\n```\n\nIf the number already includes a country prefix, split that prefix into `mobileCountry` and put the remaining local/national number in `mobileNo`.\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"apiKey\": \"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\",\n \"personId\": 803\n}\n```\n\nIf the email already exists → `400`. Do not retry — inform the user.\n\n---\n\n### 2. Create address\n\n`POST /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [\n {\n \"id\": 0,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"GB\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": false,\n \"isActive\": true\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `street` | yes | Street name |\n| `city` | yes | City / town |\n| `country` | yes | ISO 3166-1 alpha-2 code — e.g. `\"GB\"`, `\"US\"`, `\"AU\"`. Server rejects unrecognised codes. |\n| `postcode` | yes | Postal / ZIP code |\n| `label` | yes | User-facing label, e.g. `\"Work location\"` |\n| `houseNumber` | support yes, employer no | Required for job-seeker (`support`) addresses. Optional for employer/private-employer work or venue addresses when unavailable. |\n| `area` | no | Neighbourhood / district |\n| `isHome` | no | Default `false` |\n| `isActive` | no | Default `true` |\n\n- The response may include a top-level `addressId` and/or returned address objects with assigned `id` values — store the created or selected ID as `ADDRESS_ID`. If the ID is unclear, call `GET /getAddresses` and select the matching saved address.\n- Job-seeker accounts (`support`) must provide a house/building number for their own address. Employer and private-employer work/site addresses may omit it when the street, city/town, country, and postal code identify the location.\n\n---\n\n### 3. Get addresses\n\n`GET /getAddresses` — Bearer auth required.\n\nUse this to fetch the current account's saved addresses before updating, deleting, or attaching an address to a role. Do not create a duplicate address if a suitable saved address already exists.\n\nNo request body.\n\n**Response** `200`:\n```json\n{\n \"success\": true,\n \"messages\": [\"Addresses retrieved\"],\n \"dataList\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ],\n \"addresses\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ]\n}\n```\n\nStore the selected address `id` as `ADDRESS_ID`.\n\n---\n\n### 4. Delete address\n\n`DELETE /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [{ \"id\": }]\n}\n```\n\nCannot delete an address linked to an active role (`409`).\n\n---\n\n### 5. Create role\n\n`POST /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [\n {\n \"id\": 0,\n \"headline\": \"\",\n \"jobDescription\": \"\",\n \"introduction\": \"\",\n \"workingHours\": \"\",\n \"salary\": ,\n \"currencyName\": \"GBP\",\n \"currencySymbol\": \"£\",\n \"paymentFrequency\": { \"choices\": [\"\"], \"selectedIndex\": 0 },\n \"requirements\": [\n { \"requirementName\": \"\", \"mandatory\": false, \"originalRequirement\": true }\n ],\n \"benefits\": [\n { \"benefitName\": \"\", \"mandatory\": false }\n ],\n \"addressId\": ,\n \"isRemote\": false,\n \"isActive\": true,\n \"modified\": ,\n \"roleIdentifier\": \"copilot-\"\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `headline` | yes | Short title |\n| `jobDescription` | yes | Full description |\n| `introduction` | yes | Short intro text, minimum 10 characters |\n| `workingHours` | yes | e.g. `\"Saturday 11am–5pm\"` or `\"Flexible\"` |\n| `salary` | yes | Numeric amount; use `0` when pay is negotiable or not yet discussed |\n| `paymentFrequency` | no | Expected for pay display when salary is known: `choices` array with up to 8 entries; each choice must be a non-empty string up to 20 characters; empty `choices` or omitted `selectedIndex` defaults to standard frequencies |\n| `currencySymbol` | yes | Currency symbol, 1-3 characters |\n| `currencyName` | yes | Currency code/name, e.g. `\"GBP\"` |\n| `addressId` | yes | From the address creation step |\n| `isRemote` | yes | Boolean remote-work flag |\n| `isActive` | yes | Boolean active flag; new roles are often created inactive until server/company clearance allows activation |\n| `modified` | yes | Current epoch millis |\n| `roleIdentifier` | yes | Unique string, e.g. `\"copilot-\" + epochMillis` |\n| `requirements` | no | Screening topics for the application conversation; if present, send an array of up to 8 objects |\n| `benefits` | no | Perks; if present, send an array of up to 8 objects |\n\n**Requirement semantics**\n\nRequirements are not all eligibility gates. The `mandatory` flag controls how the application should be treated:\n\n- `mandatory: true` means the requirement is a hard gate. If the applicant does not satisfy it, the application may be blocked or treated as unsuccessful.\n- `mandatory: false` means the requirement is a discussion point or preference. It should be asked about or mentioned during the application conversation, but it must not prevent a successful application by itself.\n\nWhen adding employer-supplied requirements to a role, default to `mandatory: false` unless the employer clearly says the requirement is essential, legally required, or non-negotiable.\n\n**Benefit selection gate**\n\nFor benefits, `mandatory` is a highlighting/conversation selector, not an eligibility or guarantee flag:\n\n- `mandatory: true` means \"Feature as benefit\". Candidate-facing role cards hide this benefit so Blossom can weave it into conversation as a highlighted perk.\n- `mandatory: false` means \"Show on job card\". Candidate-facing role cards list this benefit directly.\n\nWhen adding benefits, default to `mandatory: false` for ordinary visible perks. Use `mandatory: true` only when the employer wants Blossom to actively highlight or discuss that benefit rather than simply list it on the role card.\n\n**Validation notes**\n\nThe backend currently enforces these role validation rules:\n\n| Field | Validation |\n|---|---|\n| `headline` | Required, 5-35 characters |\n| `jobDescription` | Required, 1-500 characters |\n| `introduction` | Required, 10-500 characters |\n| `workingHours` | Required, 1-100 characters |\n| `roleIdentifier` | Required, 1-100 characters |\n| `currencySymbol` | Required, 1-3 characters |\n| `currencyName` | Required string with no digits, max 5 characters |\n| `salary` | Optional, but if provided must be a number `>= 0` |\n| `paymentFrequency` | Optional, but if provided must be an object with `choices` array of up to 8 non-empty strings, each max 20 characters, and `selectedIndex` pointing to an existing choice; empty `choices` defaults to standard frequencies and missing `selectedIndex` defaults to `0` |\n| `addressId` | Required for new roles, whole number `> 0` from a saved address |\n| `id` | Required, whole number `>= 0` |\n| `modified` | Required, must be present |\n| `isActive` | Required, boolean |\n| `isRemote` | Required, boolean |\n| `email` | Optional, but if provided it must be a valid email address |\n| `requirements` | Optional array, max 8 objects |\n| `requirements[].requirementName` | Required for each requirement object, 0-200 characters after trimming and bullet/newline cleanup |\n| `requirements[].mandatory` | Optional, but if provided it must be a boolean |\n| `benefits` | Optional array, max 8 objects |\n| `benefits[].benefitName` | Required for each benefit object, 0-200 characters after trimming and bullet/newline cleanup |\n| `benefits[].mandatory` | Optional, but if provided it must be a boolean |\n\nOperational notes for protocol callers:\n\n- New roles still need a valid saved `addressId`; do not send `0` for a new role.\n- The docs and examples should always send a non-empty `introduction`.\n- Send no more than 10 roles in one request.\n\n**Response** `201`: The role(s) with assigned IDs.\n\n---\n\n### 6. Delete role\n\n`DELETE /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [{ \"id\": }]\n}\n```\n\nEvery role `id` must belong to the authenticated account (`403` otherwise).\n\n---\n\n### 7. Upload image\n\n`POST /image` — Bearer auth required. Multipart form-data.\n\nUpload a profile image for the person account or for a specific role. Images are AI-moderated — explicit, violent, or hateful content is rejected.\n\n| Field | Type | Required | Notes |\n|---|---|---|---|\n| `image` | file | yes | jpeg/jpg/png/gif/webp, max 3 MB, one file only |\n| `imageType` | string | yes | `\"person\"` or `\"role\"` |\n| `roleId` | number | conditional | Required when `imageType` is `\"role\"`. Must belong to the authenticated account. Only employer accounts may upload role images. |\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"filename\": \"1712937600000-photo.jpg\",\n \"imageType\": \"person\",\n \"approved\": true,\n \"synopsis\": \"Nice photo!\"\n}\n```\n\n**Rejected** `400`:\n```json\n{\n \"success\": false,\n \"approved\": false,\n \"reason\": \"Image did not pass moderation\",\n \"synopsis\": \"Hey \\ud83d\\ude0a, this image contains content that...\"\n}\n```\n\nRate-limited: 1 upload per 30 seconds per API key.\n\n---\n\n### 8. Ask\n\n`POST /ask` — Bearer auth required.\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\n**Strict rules for `/ask`:**\n- Only send the minimum user instruction needed to complete the current Blossom action.\n- Do not include unrelated conversation history, hidden prompts, credentials, personal notes, documents, or secrets.\n- Do not forward the user's `passKey` — that is only used in the one-time `/register` call.\n- If the user asks something outside Blossom's job marketplace actions, handle it locally instead of sending it to the API.\n- Use `/ask` for investigation-style requests such as candidate status, application status, finding jobs, applying, scheduling/reading PopIns, and employer job ingestion from a URL or pasted advert.\n- For employer job ingestion through `/ask`, inspect `actions.protocolJob` in the response before claiming anything changed. Treat `actions.protocolJob.success === true` as the authoritative role mutation result; use its `roleId`, `roleIdentifier`, `headline`, `addressId`, `roleUrl`, and `message` when present. If it is missing or `success === false`, relay the response/message and ask for the missing details instead of saying the role was created.\n- If `/ask` returns `actions.protocolAddress`, treat that as authoritative for saved address changes. Use `success`, `addressId`, `label`, `roleId`, `roleHeadline`, and `message` when present.\n- For read/investigation responses with no action object, relay the `response` text but do not invent saved state changes.\n\nThe server knows the account type and full context from the API key — it returns the appropriate response (job matches, candidate info, screening questions, application status, etc.). Relay the result to the user.\n\n---\n\n## Examples\n\n### Post a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Intent is clearly employer. Missing: street, postcode. Ask for them. House/building number is useful but optional.\n2. Confirm: *\"Café cover — Sat 11am–5pm, Sherwood NG5 1AA — £12/hr. Shall I post it?\"*\n3. Collect identity (email, full name, passKey).\n4. `POST /register` (`userType: \"employer\"`) → store `API_KEY`, `PERSON_ID`.\n5. `POST /address` → store `ADDRESS_ID`.\n6. `POST /role` → *\"Posted! Role ID 1042.\"*\n\n### Check candidates\n\n> **User:** Any candidates yet?\n\n1. If no `API_KEY` → register first.\n2. `POST /ask` with `\"Do I have any candidates?\"` → display the response.\n\n### Update a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\n1. Confirm: *\"Update the café role pay to £14/hour?\"*\n2. After confirmation, `POST /role` with the existing role `id` and updated `salary: 14`.\n3. *\"Updated — café cover now shows £14/hr.\"*\n\n### Remove a listing\n\n> **User:** Take down the café role.\n\n1. Confirm: *\"Take down the café role?\"*\n2. After confirmation, `DELETE /role` with the role `id` → *\"Removed.\"*\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Intent is clearly job-seeker. Collect identity (email, full name, passKey).\n2. Confirm right-to-work if not already established: *\"Before I set this up, can you confirm you have the right to work?\"*\n3. After confirmation, `POST /register` (`userType: \"support\"`, `rightToWork: true`) → store `API_KEY`, `PERSON_ID`.\n4. `POST /address` (their Nottingham location) → store `ADDRESS_ID`.\n5. `POST /ask` with `\"Find bar work near me this weekend\"` → present matching roles.\n6. User picks one → confirm: *\"Apply to role 1055?\"*\n7. After confirmation, `POST /ask` with `\"Apply to role 1055\"` → relay result.\n8. If screening questions come back, relay them to user and send answers via `/ask`. Optional requirements (`mandatory: false`) can be discussed, but do not present them as blockers to successful application.\n\n### Check application status\n\n> **User:** How are my applications going?\n\n1. `POST /ask` with `\"What's the status of my applications?\"` → display the response.\n\nFile v1.0.21:_meta.json\n\n{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"1.0.21\",\n \"publishedAt\": 1779599331308\n}\n\nFile v1.0.21:skill-card.md\n\n## Description:
\nSet up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[robbiwu](https://clawhub.ai/user/robbiwu)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal users and their assistants use this skill to register with Blossom Hire, create or manage local job listings, search for work, apply to roles, and ask job-marketplace questions through the Blossom API.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill handles personal data such as name, email, address, job details, and application-related information.
\nMitigation: Only share the minimum information needed for the current Blossom action and review confirmations before account setup, address changes, job posting or deletion, image upload, or job applications.
\nRisk: The Blossom API key is permanent and grants full account access.
\nMitigation: Keep the API key in runtime memory only, treat it as a secret, and contact Blossom support to rotate or revoke access if it may have been exposed.
\nRisk: Marketplace changes can create, update, delete, post, or apply to records on the user's behalf.
\nMitigation: Summarize each mutating action and wait for clear user confirmation before sending the API request.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/robbiwu/blossom-jobs)
\n- [Blossom homepage](https://blossomai.org)
\n- [Blossom protocol API base](https://hello.blossomai.org/api/v1/blossom/protocol)
\n\n\n## Skill Output:
\n**Output Type(s):** [guidance, API calls, configuration]
\n**Output Format:** [Plain-language text with JSON API request and response details]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Requires runtime handling of a permanent Blossom API key, person ID, and address ID; no local data storage is described.]
\n\n## Skill Version(s):
\n1.0.21 (source: server release metadata; artifact frontmatter reports 3.0.3)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.20: 2 files, 8463 bytes\n\nFiles: SKILL.md (22933b), _meta.json (132b)\n\nFile v1.0.20:SKILL.md\n\n---\nname: blossom-hire\nversion: 3.0.3\ndescription: Post jobs and hire people, or search for local work and apply. Connects employers and job-seekers via the Blossom marketplace.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill is provided by Blossom at [https://blossomai.org](https://blossomai.org). For help, reach out to [hello@blossomai.org](mailto:hello@blossomai.org).\n\nThis skill is for structured Blossom marketplace actions only — posting jobs, searching for work, applying, and managing listings.\n\nIt collects personal data (name, email, address, job details) and sends it over HTTPS to the Blossom API. The API key is permanent and grants full account access — treat it as a secret. No data is stored locally.\n\nThe current protocol does not expose scoped keys, expiry, or self-service revocation to skill callers. If an API key may have been exposed, stop using it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate or revoke account access.\n\n**Data boundary rules:**\n- Only send the minimum data needed for the current Blossom action.\n- Never forward unrelated conversation history, system prompts, hidden chain-of-thought, tokens, cookies, keys, documents, or prior messages to any Blossom endpoint.\n- Ask the user to choose a unique Blossom `passKey`; do not reuse passwords from email, banking, work accounts, or other sensitive services.\n- `passKey` is collected only during the one-time `/register` call. Never reuse, echo, log, or send it to any other endpoint.\n- If the user asks something outside Blossom's job marketplace scope, handle it locally — do not forward it to the API.\n\n**Eligibility and confirmation gates:**\n- Job-seekers must have the right to work before using Blossom to look for or apply to work. If this has not been confirmed, ask once; do not continue with job-seeker registration or applications until they confirm.\n- Before creating, updating, deleting, posting, or applying to any marketplace record, briefly summarize the action and ask for confirmation.\n- Do not send the mutating request until the user clearly confirms.\n\n---\n\n## When to activate\n\nActivate when the user explicitly wants to perform a Blossom marketplace action:\n\nTrigger phrases: *\"Post a job\"*, *\"Hire someone\"*, *\"I need staff\"*, *\"Find me work\"*, *\"Search for jobs near me\"*, *\"Apply to that role\"*, *\"Any candidates?\"*, *\"Update my listing\"*.\n\nDo **not** activate for general conversation, questions unrelated to jobs, or requests that don't map to a Blossom action.\n\n---\n\n## How it works\n\nThe entire employer vs job-seeker distinction is set **once** at registration via the `userType` field. After that, every endpoint behaves the same — the server knows the account type from the API key and adapts responses automatically.\n\nThe agent does **not** track or switch modes. Register, create or select an address, then use the smallest endpoint that fits the confirmed action: `/ask` for conversational investigation, job search, applications, candidate questions, and employer job ingestion from URLs/pasted adverts; direct CRUD endpoints for explicit structured create/update/delete operations.\n\n### Account type (set once at registration)\n\n| User intent | `userType` value | Extra fields |\n|---|---|---|\n| Hiring, has a company | `\"employer\"` | Include `companyName` |\n| Hiring, no company | `\"employer\"` | Omit `companyName` (server stores as private employer) |\n| Looking for work | `\"support\"` | Must include `rightToWork: true` |\n\nInfer the intent from the user's message. Only ask *\"Are you looking to hire, or looking for work?\"* if the intent is genuinely unclear. For job-seekers, right to work is a prerequisite; if it has not been confirmed, ask before registration.\n\n**Ambiguous \"add jobs\" rule:** If the user asks to *add a job*, *add jobs*, *add this job*, *ingest this URL*, *import this advert*, or provides a job URL/listing to add, treat that as employer role ingestion unless they clearly say they are looking for work, saving job-seeker library entries, bookmarking roles, or applying as a candidate. Register through the employer path for this intent. The protocol registration payload still uses `\"userType\": \"employer\"` for both company employers and private employers; omit `companyName` when the employer has no company so the server can store the account as a private employer. If the employer account shape is rejected by the API, relay the rejection and ask for the missing account details instead of silently switching to a job-seeker account.\n\n### Flow\n\n1. Collect identity: email, first name, surname, passKey. Optionally: mobile country code, mobile number, company name. Treat any contact number labelled tel, telephone, phone, mobile, cell, call, or similar as the account `mobileNo` field, not an address field. For job-seekers, confirm they have the right to work before continuing.\n2. **Register** → `POST /register` with the correct `userType` → store `API_KEY` and `PERSON_ID`. Discard `passKey` from memory immediately after this call.\n3. **Create or select address** → use `GET /getAddresses` when the account may already have a suitable address; otherwise `POST /address` with the user's location → store `ADDRESS_ID`. Employers need this to attach a location to roles. Job-seekers need this so the server can find nearby opportunities.\n4. **Talk / investigate** → `POST /ask` with only the minimal job-related instruction needed for the current Blossom action. Do not forward unrelated context, secrets, or raw conversation history. For employer requests to add/import/ingest a job from a URL or pasted advert, use `/ask` so the employer protocol job ingestion path can create the address/role when enough information is available.\n\nFor employers posting a role directly (without `/ask`), use `POST /role` only after the user has confirmed a structured role payload with headline, description, introduction, working hours, pay/currency/frequency, remote status, active status, and a valid saved `ADDRESS_ID`.\n\n---\n\n## API reference\n\n### Base URL\n```\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n### Endpoints\n\n| Method | Path | Auth | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Create account → get API key |\n| `GET` | `/getAddresses` | Bearer | Return all addresses for the account |\n| `POST` | `/address` | Bearer | Create / update address(es) |\n| `DELETE` | `/address` | Bearer | Soft-delete address(es) |\n| `POST` | `/role` | Bearer | Create / update role(s) |\n| `DELETE` | `/role` | Bearer | Soft-delete role(s) |\n| `POST` | `/ask` | Bearer | Conversational AI endpoint |\n| `POST` | `/image` | Bearer | Upload profile image (person or role) |\n\n### Session state\n\nStore and reuse across calls:\n- **`API_KEY`** — returned from `/register`, used as `Authorization: Bearer ` for all subsequent calls\n- **`PERSON_ID`** — returned from `/register`\n- **`ADDRESS_ID`** — returned from `/address`, or from `/getAddresses` for existing addresses, needed when creating a role\n\nThe API key is permanent. No session expiry or login flow.\n\n> **Important:** Never store the API key in global config. Keep it in runtime memory for the current session only.\n> If the key may have been exposed, stop using it and contact Blossom support for revocation or rotation.\n\n---\n\n## API contract\n\n### 1. Register\n\n`POST /register` — no auth required.\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"<+44>\",\n \"mobileNo\": \"\"\n}\n```\n\nFor job-seekers, set `\"userType\": \"support\"` and include `\"rightToWork\": true`. Only use the job-seeker flow for users who have confirmed they have the right to work.\n\n| Field | Required | Notes |\n|---|---|---|\n| `name` | yes | First name |\n| `surname` | yes | Last name |\n| `email` | yes | Must be unique |\n| `userType` | yes | `\"employer\"` or `\"support\"` |\n| `passKey` | yes | User-chosen password. Collect only for `/register`, use once, then discard — never send to any other endpoint |\n| `rightToWork` | yes (support) | Must be `true` when `userType` is `\"support\"` |\n| `companyName` | no | For employers. Omit or leave empty for private employers |\n| `mobileCountry` | no | e.g. `\"+44\"` |\n| `mobileNo` | no | Account contact number. Use this for tel, telephone, phone, mobile, cell, call, or similar contact labels. Do not place phone numbers on addresses. |\n\n**Phone/contact mapping:** If the user provides a number such as `\"Tel: 0300 456 8174\"`, send it during `/register` as:\n\n```json\n{\n \"mobileCountry\": \"+44\",\n \"mobileNo\": \"0300 456 8174\"\n}\n```\n\nIf the number already includes a country prefix, split that prefix into `mobileCountry` and put the remaining local/national number in `mobileNo`.\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"apiKey\": \"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\",\n \"personId\": 803\n}\n```\n\nIf the email already exists → `400`. Do not retry — inform the user.\n\n---\n\n### 2. Create address\n\n`POST /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [\n {\n \"id\": 0,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"GB\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": false,\n \"isActive\": true\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `street` | yes | Street name |\n| `city` | yes | City / town |\n| `country` | yes | ISO 3166-1 alpha-2 code — e.g. `\"GB\"`, `\"US\"`, `\"AU\"`. Server rejects unrecognised codes. |\n| `postcode` | yes | Postal / ZIP code |\n| `label` | yes | User-facing label, e.g. `\"Work location\"` |\n| `houseNumber` | support yes, employer no | Required for job-seeker (`support`) addresses. Optional for employer/private-employer work or venue addresses when unavailable. |\n| `area` | no | Neighbourhood / district |\n| `isHome` | no | Default `false` |\n| `isActive` | no | Default `true` |\n\n- The response may include a top-level `addressId` and/or returned address objects with assigned `id` values — store the created or selected ID as `ADDRESS_ID`. If the ID is unclear, call `GET /getAddresses` and select the matching saved address.\n- Job-seeker accounts (`support`) must provide a house/building number for their own address. Employer and private-employer work/site addresses may omit it when the street, city/town, country, and postal code identify the location.\n\n---\n\n### 3. Get addresses\n\n`GET /getAddresses` — Bearer auth required.\n\nUse this to fetch the current account's saved addresses before updating, deleting, or attaching an address to a role. Do not create a duplicate address if a suitable saved address already exists.\n\nNo request body.\n\n**Response** `200`:\n```json\n{\n \"success\": true,\n \"messages\": [\"Addresses retrieved\"],\n \"dataList\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ],\n \"addresses\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ]\n}\n```\n\nStore the selected address `id` as `ADDRESS_ID`.\n\n---\n\n### 4. Delete address\n\n`DELETE /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [{ \"id\": }]\n}\n```\n\nCannot delete an address linked to an active role (`409`).\n\n---\n\n### 5. Create role\n\n`POST /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [\n {\n \"id\": 0,\n \"headline\": \"\",\n \"jobDescription\": \"\",\n \"introduction\": \"\",\n \"workingHours\": \"\",\n \"salary\": ,\n \"currencyName\": \"GBP\",\n \"currencySymbol\": \"£\",\n \"paymentFrequency\": { \"choices\": [\"\"], \"selectedIndex\": 0 },\n \"requirements\": [\n { \"requirementName\": \"\", \"mandatory\": false, \"originalRequirement\": true }\n ],\n \"benefits\": [\n { \"benefitName\": \"\", \"mandatory\": false }\n ],\n \"addressId\": ,\n \"isRemote\": false,\n \"isActive\": true,\n \"modified\": ,\n \"roleIdentifier\": \"openclaw-\"\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `headline` | yes | Short title |\n| `jobDescription` | yes | Full description |\n| `introduction` | yes | Short intro text, minimum 10 characters |\n| `workingHours` | yes | e.g. `\"Saturday 11am–5pm\"` or `\"Flexible\"` |\n| `salary` | yes | Numeric amount; use `0` when pay is negotiable or not yet discussed |\n| `paymentFrequency` | no | Expected for pay display when salary is known: `choices` array with up to 8 entries; each choice must be a non-empty string up to 20 characters; empty `choices` or omitted `selectedIndex` defaults to standard frequencies |\n| `currencySymbol` | yes | Currency symbol, 1-3 characters |\n| `currencyName` | yes | Currency code/name, e.g. `\"GBP\"` |\n| `addressId` | yes | From the address creation step |\n| `isRemote` | yes | Boolean remote-work flag |\n| `isActive` | yes | Boolean active flag; new roles are often created inactive until server/company clearance allows activation |\n| `modified` | yes | Current epoch millis |\n| `roleIdentifier` | yes | Unique string, e.g. `\"openclaw-\" + epochMillis` |\n| `requirements` | no | Screening topics for the application conversation; if present, send an array of up to 8 objects |\n| `benefits` | no | Perks; if present, send an array of up to 8 objects |\n\n**Requirement semantics**\n\nRequirements are not all eligibility gates. The `mandatory` flag controls how the application should be treated:\n\n- `mandatory: true` means the requirement is a hard gate. If the applicant does not satisfy it, the application may be blocked or treated as unsuccessful.\n- `mandatory: false` means the requirement is a discussion point or preference. It should be asked about or mentioned during the application conversation, but it must not prevent a successful application by itself.\n\nWhen adding employer-supplied requirements to a role, default to `mandatory: false` unless the employer clearly says the requirement is essential, legally required, or non-negotiable.\n\n**Benefit selection gate**\n\nFor benefits, `mandatory` is a highlighting/conversation selector, not an eligibility or guarantee flag:\n\n- `mandatory: true` means \"Feature as benefit\". Candidate-facing role cards hide this benefit so Blossom can weave it into conversation as a highlighted perk.\n- `mandatory: false` means \"Show on job card\". Candidate-facing role cards list this benefit directly.\n\nWhen adding benefits, default to `mandatory: false` for ordinary visible perks. Use `mandatory: true` only when the employer wants Blossom to actively highlight or discuss that benefit rather than simply list it on the role card.\n\n**Validation notes**\n\nThe backend currently enforces these role validation rules:\n\n| Field | Validation |\n|---|---|\n| `headline` | Required, 5-35 characters |\n| `jobDescription` | Required, 1-500 characters |\n| `introduction` | Required, 10-500 characters |\n| `workingHours` | Required, 1-100 characters |\n| `roleIdentifier` | Required, 1-100 characters |\n| `currencySymbol` | Required, 1-3 characters |\n| `currencyName` | Required string with no digits, max 5 characters |\n| `salary` | Optional, but if provided must be a number `>= 0` |\n| `paymentFrequency` | Optional, but if provided must be an object with `choices` array of up to 8 non-empty strings, each max 20 characters, and `selectedIndex` pointing to an existing choice; empty `choices` defaults to standard frequencies and missing `selectedIndex` defaults to `0` |\n| `addressId` | Required for new roles, whole number `> 0` from a saved address |\n| `id` | Required, whole number `>= 0` |\n| `modified` | Required, must be present |\n| `isActive` | Required, boolean |\n| `isRemote` | Required, boolean |\n| `email` | Optional, but if provided it must be a valid email address |\n| `requirements` | Optional array, max 8 objects |\n| `requirements[].requirementName` | Required for each requirement object, 0-200 characters after trimming and bullet/newline cleanup |\n| `requirements[].mandatory` | Optional, but if provided it must be a boolean |\n| `benefits` | Optional array, max 8 objects |\n| `benefits[].benefitName` | Required for each benefit object, 0-200 characters after trimming and bullet/newline cleanup |\n| `benefits[].mandatory` | Optional, but if provided it must be a boolean |\n\nOperational notes for protocol callers:\n\n- New roles still need a valid saved `addressId`; do not send `0` for a new role.\n- The docs and examples should always send a non-empty `introduction`.\n- Send no more than 10 roles in one request.\n\n**Response** `201`: The role(s) with assigned IDs.\n\n---\n\n### 6. Delete role\n\n`DELETE /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [{ \"id\": }]\n}\n```\n\nEvery role `id` must belong to the authenticated account (`403` otherwise).\n\n---\n\n### 7. Upload image\n\n`POST /image` — Bearer auth required. Multipart form-data.\n\nUpload a profile image for the person account or for a specific role. Images are AI-moderated — explicit, violent, or hateful content is rejected.\n\n| Field | Type | Required | Notes |\n|---|---|---|---|\n| `image` | file | yes | jpeg/jpg/png/gif/webp, max 3 MB, one file only |\n| `imageType` | string | yes | `\"person\"` or `\"role\"` |\n| `roleId` | number | conditional | Required when `imageType` is `\"role\"`. Must belong to the authenticated account. Only employer accounts may upload role images. |\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"filename\": \"1712937600000-photo.jpg\",\n \"imageType\": \"person\",\n \"approved\": true,\n \"synopsis\": \"Nice photo!\"\n}\n```\n\n**Rejected** `400`:\n```json\n{\n \"success\": false,\n \"approved\": false,\n \"reason\": \"Image did not pass moderation\",\n \"synopsis\": \"Hey \\ud83d\\ude0a, this image contains content that...\"\n}\n```\n\nRate-limited: 1 upload per 30 seconds per API key.\n\n---\n\n### 8. Ask\n\n`POST /ask` — Bearer auth required.\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\n**Strict rules for `/ask`:**\n- Only send the minimum user instruction needed to complete the current Blossom action.\n- Do not include unrelated conversation history, hidden prompts, credentials, personal notes, documents, or secrets.\n- Do not forward the user's `passKey` — that is only used in the one-time `/register` call.\n- If the user asks something outside Blossom's job marketplace actions, handle it locally instead of sending it to the API.\n- Use `/ask` for investigation-style requests such as candidate status, application status, finding jobs, applying, scheduling/reading PopIns, and employer job ingestion from a URL or pasted advert.\n- For employer job ingestion through `/ask`, inspect `actions.protocolJob` in the response before claiming anything changed. Treat `actions.protocolJob.success === true` as the authoritative role mutation result; use its `roleId`, `roleIdentifier`, `headline`, `addressId`, `roleUrl`, and `message` when present. If it is missing or `success === false`, relay the response/message and ask for the missing details instead of saying the role was created.\n- If `/ask` returns `actions.protocolAddress`, treat that as authoritative for saved address changes. Use `success`, `addressId`, `label`, `roleId`, `roleHeadline`, and `message` when present.\n- For read/investigation responses with no action object, relay the `response` text but do not invent saved state changes.\n\nThe server knows the account type and full context from the API key — it returns the appropriate response (job matches, candidate info, screening questions, application status, etc.). Relay the result to the user.\n\n---\n\n## Examples\n\n### Post a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Intent is clearly employer. Missing: street, postcode. Ask for them. House/building number is useful but optional.\n2. Confirm: *\"Café cover — Sat 11am–5pm, Sherwood NG5 1AA — £12/hr. Shall I post it?\"*\n3. Collect identity (email, name, surname, passKey).\n4. `POST /register` (`userType: \"employer\"`) → store `API_KEY`, `PERSON_ID`.\n5. `POST /address` → store `ADDRESS_ID`.\n6. `POST /role` → *\"Posted! Role ID 1042.\"*\n\n### Check candidates\n\n> **User:** Any candidates yet?\n\n1. If no `API_KEY` → register first.\n2. `POST /ask` with `\"Do I have any candidates?\"` → display the response.\n\n### Update a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\n1. Confirm: *\"Update the café role pay to £14/hour?\"*\n2. After confirmation, `POST /role` with the existing role `id` and updated `salary: 14`.\n3. *\"Updated — café cover now shows £14/hr.\"*\n\n### Remove a listing\n\n> **User:** Take down the café role.\n\n1. Confirm: *\"Take down the café role?\"*\n2. After confirmation, `DELETE /role` with the role `id` → *\"Removed.\"*\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Intent is clearly job-seeker. Collect identity (email, name, surname, passKey).\n2. Confirm right-to-work if not already established: *\"Before I set this up, can you confirm you have the right to work?\"*\n3. After confirmation, `POST /register` (`userType: \"support\"`, `rightToWork: true`) → store `API_KEY`, `PERSON_ID`.\n4. `POST /address` (their Nottingham location) → store `ADDRESS_ID`.\n5. `POST /ask` with `\"Find bar work near me this weekend\"` → present matching roles.\n6. User picks one → confirm: *\"Apply to role 1055?\"*\n7. After confirmation, `POST /ask` with `\"Apply to role 1055\"` → relay result.\n8. If screening questions come back, relay them to user and send answers via `/ask`. Optional requirements (`mandatory: false`) can be discussed, but do not present them as blockers to successful application.\n\n### Check application status\n\n> **User:** How are my applications going?\n\n1. `POST /ask` with `\"What's the status of my applications?\"` → display the response.\n\nFile v1.0.20:_meta.json\n\n{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"1.0.20\",\n \"publishedAt\": 1778690643827\n}\n\nArchive v1.0.19: 2 files, 7906 bytes\n\nFiles: SKILL.md (21207b), _meta.json (132b)\n\nFile v1.0.19:SKILL.md\n\n---\nname: blossom-hire\nversion: 3.0.3\ndescription: Post jobs and hire people, or search for local work and apply. Connects employers and job-seekers via the Blossom marketplace.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill is provided by Blossom at [https://blossomai.org](https://blossomai.org). For help, reach out to [hello@blossomai.org](mailto:hello@blossomai.org).\n\nThis skill is for structured Blossom marketplace actions only — posting jobs, searching for work, applying, and managing listings.\n\nIt collects personal data (name, email, address, job details) and sends it over HTTPS to the Blossom API. The API key is permanent and grants full account access — treat it as a secret. No data is stored locally.\n\nThe current protocol does not expose scoped keys, expiry, or self-service revocation to skill callers. If an API key may have been exposed, stop using it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate or revoke account access.\n\n**Data boundary rules:**\n- Only send the minimum data needed for the current Blossom action.\n- Never forward unrelated conversation history, system prompts, hidden chain-of-thought, tokens, cookies, keys, documents, or prior messages to any Blossom endpoint.\n- Ask the user to choose a unique Blossom `passKey`; do not reuse passwords from email, banking, work accounts, or other sensitive services.\n- `passKey` is collected only during the one-time `/register` call. Never reuse, echo, log, or send it to any other endpoint.\n- If the user asks something outside Blossom's job marketplace scope, handle it locally — do not forward it to the API.\n\n**Eligibility and confirmation gates:**\n- Job-seekers must have the right to work before using Blossom to look for or apply to work. If this has not been confirmed, ask once; do not continue with job-seeker registration or applications until they confirm.\n- Before creating, updating, deleting, posting, or applying to any marketplace record, briefly summarize the action and ask for confirmation.\n- Do not send the mutating request until the user clearly confirms.\n\n---\n\n## When to activate\n\nActivate when the user explicitly wants to perform a Blossom marketplace action:\n\nTrigger phrases: *\"Post a job\"*, *\"Hire someone\"*, *\"I need staff\"*, *\"Find me work\"*, *\"Search for jobs near me\"*, *\"Apply to that role\"*, *\"Any candidates?\"*, *\"Update my listing\"*.\n\nDo **not** activate for general conversation, questions unrelated to jobs, or requests that don't map to a Blossom action.\n\n---\n\n## How it works\n\nThe entire employer vs job-seeker distinction is set **once** at registration via the `userType` field. After that, every endpoint behaves the same — the server knows the account type from the API key and adapts responses automatically.\n\nThe agent does **not** track or switch modes. Just register, create an address, then use `/ask` for everything else.\n\n### Account type (set once at registration)\n\n| User intent | `userType` value | Extra fields |\n|---|---|---|\n| Hiring, has a company | `\"employer\"` | Include `companyName` |\n| Hiring, no company | `\"employer\"` | Omit `companyName` (server stores as private employer) |\n| Looking for work | `\"support\"` | Must include `rightToWork: true` |\n\nInfer the intent from the user's message. Only ask *\"Are you looking to hire, or looking for work?\"* if the intent is genuinely unclear. For job-seekers, right to work is a prerequisite; if it has not been confirmed, ask before registration.\n\n**Ambiguous \"add jobs\" rule:** If the user asks to *add a job*, *add jobs*, *add this job*, *ingest this URL*, *import this advert*, or provides a job URL/listing to add, treat that as employer role ingestion unless they clearly say they are looking for work, saving job-seeker library entries, bookmarking roles, or applying as a candidate. Register through the employer path for this intent. The protocol registration payload still uses `\"userType\": \"employer\"` for both company employers and private employers; omit `companyName` when the employer has no company so the server can store the account as a private employer. If the employer account shape is rejected by the API, relay the rejection and ask for the missing account details instead of silently switching to a job-seeker account.\n\n### Flow\n\n1. Collect identity: email, first name, surname, passKey. Optionally: mobile country code, mobile number, company name. Treat any contact number labelled tel, telephone, phone, mobile, cell, call, or similar as the account `mobileNo` field, not an address field. For job-seekers, confirm they have the right to work before continuing.\n2. **Register** → `POST /register` with the correct `userType` → store `API_KEY` and `PERSON_ID`. Discard `passKey` from memory immediately after this call.\n3. **Create address** → `POST /address` with the user's location → store `ADDRESS_ID`. Employers need this to attach a location to roles. Job-seekers need this so the server can find nearby opportunities.\n4. **Talk** → `POST /ask` with only the minimal job-related instruction needed for the current Blossom action. Do not forward unrelated context, secrets, or raw conversation history. For employer requests to add/import/ingest a job from a URL or pasted advert, use `/ask` so the employer protocol job ingestion path can create the role.\n\nFor employers posting a role directly (without `/ask`), also collect: headline, description, working hours, pay — then use `POST /role` with the `ADDRESS_ID`.\n\n---\n\n## API reference\n\n### Base URL\n```\nhttps://hello.blossomai.org/api/v1/blossom/protocol\n```\n\n### Endpoints\n\n| Method | Path | Auth | Purpose |\n|---|---|---|---|\n| `POST` | `/register` | None | Create account → get API key |\n| `GET` | `/getAddresses` | Bearer | Return all addresses for the account |\n| `POST` | `/address` | Bearer | Create / update address(es) |\n| `DELETE` | `/address` | Bearer | Soft-delete address(es) |\n| `POST` | `/role` | Bearer | Create / update role(s) |\n| `DELETE` | `/role` | Bearer | Soft-delete role(s) |\n| `POST` | `/ask` | Bearer | Conversational AI endpoint |\n| `POST` | `/image` | Bearer | Upload profile image (person or role) |\n\n### Session state\n\nStore and reuse across calls:\n- **`API_KEY`** — returned from `/register`, used as `Authorization: Bearer ` for all subsequent calls\n- **`PERSON_ID`** — returned from `/register`\n- **`ADDRESS_ID`** — returned from `/address`, or from `/getAddresses` for existing addresses, needed when creating a role\n\nThe API key is permanent. No session expiry or login flow.\n\n> **Important:** Never store the API key in global config. Keep it in runtime memory for the current session only.\n> If the key may have been exposed, stop using it and contact Blossom support for revocation or rotation.\n\n---\n\n## API contract\n\n### 1. Register\n\n`POST /register` — no auth required.\n\n```json\n{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"<+44>\",\n \"mobileNo\": \"\"\n}\n```\n\nFor job-seekers, set `\"userType\": \"support\"` and include `\"rightToWork\": true`. Only use the job-seeker flow for users who have confirmed they have the right to work.\n\n| Field | Required | Notes |\n|---|---|---|\n| `name` | yes | First name |\n| `surname` | yes | Last name |\n| `email` | yes | Must be unique |\n| `userType` | yes | `\"employer\"` or `\"support\"` |\n| `passKey` | yes | User-chosen password. Collect only for `/register`, use once, then discard — never send to any other endpoint |\n| `rightToWork` | yes (support) | Must be `true` when `userType` is `\"support\"` |\n| `companyName` | no | For employers. Omit or leave empty for private employers |\n| `mobileCountry` | no | e.g. `\"+44\"` |\n| `mobileNo` | no | Account contact number. Use this for tel, telephone, phone, mobile, cell, call, or similar contact labels. Do not place phone numbers on addresses. |\n\n**Phone/contact mapping:** If the user provides a number such as `\"Tel: 0300 456 8174\"`, send it during `/register` as:\n\n```json\n{\n \"mobileCountry\": \"+44\",\n \"mobileNo\": \"0300 456 8174\"\n}\n```\n\nIf the number already includes a country prefix, split that prefix into `mobileCountry` and put the remaining local/national number in `mobileNo`.\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"apiKey\": \"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\",\n \"personId\": 803\n}\n```\n\nIf the email already exists → `400`. Do not retry — inform the user.\n\n---\n\n### 2. Create address\n\n`POST /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [\n {\n \"id\": 0,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"GB\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": false,\n \"isActive\": true\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `street` | yes | Street name |\n| `city` | yes | City / town |\n| `country` | yes | ISO 3166-1 alpha-2 code — e.g. `\"GB\"`, `\"US\"`, `\"AU\"`. Server rejects unrecognised codes. |\n| `postcode` | yes | Postal / ZIP code |\n| `label` | yes | User-facing label, e.g. `\"Work location\"` |\n| `houseNumber` | support yes, employer no | Required for job-seeker (`support`) addresses. Optional for employer/private-employer work or venue addresses when unavailable. |\n| `area` | no | Neighbourhood / district |\n| `isHome` | no | Default `false` |\n| `isActive` | no | Default `true` |\n\n- The response includes the address with its assigned `id` — store as `ADDRESS_ID`.\n- Job-seeker accounts (`support`) must provide a house/building number for their own address. Employer and private-employer work/site addresses may omit it when the street, city/town, country, and postal code identify the location.\n\n---\n\n### 3. Get addresses\n\n`GET /getAddresses` — Bearer auth required.\n\nUse this to fetch the current account's saved addresses before updating, deleting, or attaching an address to a role. Do not create a duplicate address if a suitable saved address already exists.\n\nNo request body.\n\n**Response** `200`:\n```json\n{\n \"success\": true,\n \"messages\": [\"Addresses retrieved\"],\n \"dataList\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ],\n \"addresses\": [\n {\n \"id\": 123,\n \"houseNumber\": \"10\",\n \"street\": \"High Street\",\n \"area\": \"Sherwood\",\n \"city\": \"Nottingham\",\n \"country\": \"United Kingdom\",\n \"postcode\": \"NG5 1AA\",\n \"label\": \"Work location\",\n \"isHome\": 0,\n \"isActive\": 1\n }\n ]\n}\n```\n\nStore the selected address `id` as `ADDRESS_ID`.\n\n---\n\n### 4. Delete address\n\n`DELETE /address` — Bearer auth required.\n\n```json\n{\n \"addresses\": [{ \"id\": }]\n}\n```\n\nCannot delete an address linked to an active role (`409`).\n\n---\n\n### 5. Create role\n\n`POST /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [\n {\n \"id\": 0,\n \"headline\": \"\",\n \"jobDescription\": \"\",\n \"introduction\": \"\",\n \"workingHours\": \"\",\n \"salary\": ,\n \"currencyName\": \"GBP\",\n \"currencySymbol\": \"£\",\n \"paymentFrequency\": { \"choices\": [\"\"], \"selectedIndex\": 0 },\n \"requirements\": [\n { \"requirementName\": \"\", \"mandatory\": false, \"originalRequirement\": true }\n ],\n \"benefits\": [\n { \"benefitName\": \"\", \"mandatory\": false }\n ],\n \"addressId\": ,\n \"isRemote\": false,\n \"isActive\": true,\n \"modified\": ,\n \"roleIdentifier\": \"openclaw-\"\n }\n ]\n}\n```\n\n| Field | Required | Notes |\n|---|---|---|\n| `id` | yes | `0` to create, existing ID to update |\n| `headline` | yes | Short title |\n| `jobDescription` | yes | Full description |\n| `introduction` | yes | Short intro text, minimum 10 characters |\n| `workingHours` | yes | e.g. `\"Saturday 11am–5pm\"` or `\"Flexible\"` |\n| `salary` | yes | Numeric amount; use `0` when pay is negotiable or not yet discussed |\n| `paymentFrequency` | no | Expected for pay display when salary is known: `choices` array with up to 8 entries; each choice must be a non-empty string up to 20 characters; empty `choices` or omitted `selectedIndex` defaults to standard frequencies |\n| `currencySymbol` | yes | Currency symbol, 1-3 characters |\n| `currencyName` | yes | Currency code/name, e.g. `\"GBP\"` |\n| `addressId` | yes | From the address creation step |\n| `isRemote` | yes | Boolean remote-work flag |\n| `isActive` | yes | Boolean active flag; new roles are often created inactive until server/company clearance allows activation |\n| `modified` | yes | Current epoch millis |\n| `roleIdentifier` | yes | Unique string, e.g. `\"openclaw-\" + epochMillis` |\n| `requirements` | no | Screening topics for the application conversation; if present, send an array of up to 8 objects |\n| `benefits` | no | Perks; if present, send an array of up to 8 objects |\n\n**Requirement semantics**\n\nRequirements are not all eligibility gates. The `mandatory` flag controls how the application should be treated:\n\n- `mandatory: true` means the requirement is a hard gate. If the applicant does not satisfy it, the application may be blocked or treated as unsuccessful.\n- `mandatory: false` means the requirement is a discussion point or preference. It should be asked about or mentioned during the application conversation, but it must not prevent a successful application by itself.\n\nWhen adding employer-supplied requirements to a role, default to `mandatory: false` unless the employer clearly says the requirement is essential, legally required, or non-negotiable.\n\n**Benefit selection gate**\n\nFor benefits, `mandatory` is a highlighting/conversation selector, not an eligibility or guarantee flag:\n\n- `mandatory: true` means \"Feature as benefit\". Candidate-facing role cards hide this benefit so Blossom can weave it into conversation as a highlighted perk.\n- `mandatory: false` means \"Show on job card\". Candidate-facing role cards list this benefit directly.\n\nWhen adding benefits, default to `mandatory: false` for ordinary visible perks. Use `mandatory: true` only when the employer wants Blossom to actively highlight or discuss that benefit rather than simply list it on the role card.\n\n**Validation notes**\n\nThe backend currently enforces these role validation rules:\n\n| Field | Validation |\n|---|---|\n| `headline` | Required, 5-35 characters |\n| `jobDescription` | Required, 1-500 characters |\n| `introduction` | Required, 10-500 characters |\n| `workingHours` | Required, 1-100 characters |\n| `roleIdentifier` | Required, 1-100 characters |\n| `currencySymbol` | Required, 1-3 characters |\n| `currencyName` | Required string with no digits, max 5 characters |\n| `salary` | Optional, but if provided must be a number `>= 0` |\n| `paymentFrequency` | Optional, but if provided must be an object with `choices` array of up to 8 non-empty strings, each max 20 characters, and `selectedIndex` pointing to an existing choice; empty `choices` defaults to standard frequencies and missing `selectedIndex` defaults to `0` |\n| `addressId` | Required, whole number `>= 0` |\n| `id` | Required, whole number `>= 0` |\n| `modified` | Required, must be present |\n| `isActive` | Required, boolean |\n| `isRemote` | Required, boolean |\n| `email` | Optional, but if provided it must be a valid email address |\n| `requirements` | Optional array, max 8 objects |\n| `requirements[].requirementName` | Required for each requirement object, 0-200 characters after trimming and bullet/newline cleanup |\n| `requirements[].mandatory` | Optional, but if provided it must be a boolean |\n| `benefits` | Optional array, max 8 objects |\n| `benefits[].benefitName` | Required for each benefit object, 0-200 characters after trimming and bullet/newline cleanup |\n| `benefits[].mandatory` | Optional, but if provided it must be a boolean |\n\nOperational notes for protocol callers:\n\n- New roles still need a valid `addressId`.\n- The docs and examples should always send a non-empty `introduction`.\n- Send no more than 10 roles in one request.\n\n**Response** `201`: The role(s) with assigned IDs.\n\n---\n\n### 6. Delete role\n\n`DELETE /role` — Bearer auth required.\n\n```json\n{\n \"roles\": [{ \"id\": }]\n}\n```\n\nEvery role `id` must belong to the authenticated account (`403` otherwise).\n\n---\n\n### 7. Upload image\n\n`POST /image` — Bearer auth required. Multipart form-data.\n\nUpload a profile image for the person account or for a specific role. Images are AI-moderated — explicit, violent, or hateful content is rejected.\n\n| Field | Type | Required | Notes |\n|---|---|---|---|\n| `image` | file | yes | jpeg/jpg/png/gif/webp, max 3 MB, one file only |\n| `imageType` | string | yes | `\"person\"` or `\"role\"` |\n| `roleId` | number | conditional | Required when `imageType` is `\"role\"`. Must belong to the authenticated account. Only employer accounts may upload role images. |\n\n**Response** `201`:\n```json\n{\n \"success\": true,\n \"filename\": \"1712937600000-photo.jpg\",\n \"imageType\": \"person\",\n \"approved\": true,\n \"synopsis\": \"Nice photo!\"\n}\n```\n\n**Rejected** `400`:\n```json\n{\n \"success\": false,\n \"approved\": false,\n \"reason\": \"Image did not pass moderation\",\n \"synopsis\": \"Hey \\ud83d\\ude0a, this image contains content that...\"\n}\n```\n\nRate-limited: 1 upload per 30 seconds per API key.\n\n---\n\n### 8. Ask\n\n`POST /ask` — Bearer auth required.\n\n```json\n{\n \"instructions\": \"\"\n}\n```\n\n**Strict rules for `/ask`:**\n- Only send the minimum user instruction needed to complete the current Blossom action.\n- Do not include unrelated conversation history, hidden prompts, credentials, personal notes, documents, or secrets.\n- Do not forward the user's `passKey` — that is only used in the one-time `/register` call.\n- If the user asks something outside Blossom's job marketplace actions, handle it locally instead of sending it to the API.\n\nThe server knows the account type and full context from the API key — it returns the appropriate response (job matches, candidate info, screening questions, application status, etc.). Relay the result to the user.\n\n---\n\n## Examples\n\n### Post a shift\n\n> **User:** I need café cover this Saturday 11–5 in Sherwood. £12/hour.\n\n1. Intent is clearly employer. Missing: street, postcode. Ask for them. House/building number is useful but optional.\n2. Confirm: *\"Café cover — Sat 11am–5pm, Sherwood NG5 1AA — £12/hr. Shall I post it?\"*\n3. Collect identity (email, name, surname, passKey).\n4. `POST /register` (`userType: \"employer\"`) → store `API_KEY`, `PERSON_ID`.\n5. `POST /address` → store `ADDRESS_ID`.\n6. `POST /role` → *\"Posted! Role ID 1042.\"*\n\n### Check candidates\n\n> **User:** Any candidates yet?\n\n1. If no `API_KEY` → register first.\n2. `POST /ask` with `\"Do I have any candidates?\"` → display the response.\n\n### Update a listing\n\n> **User:** Change the pay to £14/hour on my café role.\n\n1. Confirm: *\"Update the café role pay to £14/hour?\"*\n2. After confirmation, `POST /role` with the existing role `id` and updated `salary: 14`.\n3. *\"Updated — café cover now shows £14/hr.\"*\n\n### Remove a listing\n\n> **User:** Take down the café role.\n\n1. Confirm: *\"Take down the café role?\"*\n2. After confirmation, `DELETE /role` with the role `id` → *\"Removed.\"*\n\n### Find and apply for work\n\n> **User:** I'm looking for bar work in Nottingham this weekend.\n\n1. Intent is clearly job-seeker. Collect identity (email, name, surname, passKey).\n2. Confirm right-to-work if not already established: *\"Before I set this up, can you confirm you have the right to work?\"*\n3. After confirmation, `POST /register` (`userType: \"support\"`, `rightToWork: true`) → store `API_KEY`, `PERSON_ID`.\n4. `POST /address` (their Nottingham location) → store `ADDRESS_ID\n\nArchive v1.0.18: 2 files, 6989 bytes\n\nFiles: SKILL.md (18515b), _meta.json (132b)\n\nArchive v1.0.17: 2 files, 6722 bytes\n\nFiles: SKILL.md (17500b), _meta.json (132b)\n\nArchive v1.0.16: 2 files, 6163 bytes\n\nFiles: SKILL.md (15497b), _meta.json (132b)","readmeExcerpt":"Skill: Find and Offer New Work and Tasks Owner: robbiwu Summary: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language. Tags: latest:2.0.2 Version history: v2.0.2 | 2026-07-31T06:51:39.300Z | user - Removed the sample file skill-card.md. - Updated protocol documentation to clarify that image upload is not supported via the protocol AP","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"https://hello.blossomai.org/api/v1/blossom/protocol"},{"language":"json","snippet":"{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"employer\",\n \"passKey\": \"\",\n \"companyName\": \"\",\n \"mobileCountry\": \"\",\n \"mobileNo\": \"\"\n}"},{"language":"json","snippet":"{\n \"name\": \"\",\n \"surname\": \"\",\n \"email\": \"\",\n \"userType\": \"support\",\n \"rightToWork\": true,\n \"passKey\": \"\"\n}"},{"language":"json","snippet":"{\n \"success\": true,\n \"apiKey\": \"\",\n \"personId\": 803\n}"},{"language":"http","snippet":"Authorization: Bearer \nContent-Type: application/json"},{"language":"json","snippet":"{\n \"instructions\": \"\"\n}"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: blossom-hire\nversion: 4.0.2\ndescription: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\noperator: Blossom AI Ltd\nhomepage: \"https://blossomai.org\"\nsource: \"https://blossomai.org\"\nsupport: \"mailto:hello@blossomai.org\"\nprivacy: \"https://blossomai.org/privacypolicy.html\"\napi_host: \"hello.blossomai.org\"\n---\n\n# Blossom Hire\n\n| | |\n|---|---|\n| **Service** | Blossom — local jobs marketplace |\n| **Operator** | Blossom AI Ltd |\n| **Website** | [https://blossomai.org](https://blossomai.org) |\n| **Privacy** | [https://blossomai.org/privacypolicy.html](https://blossomai.org/privacypolicy.html) |\n| **API host** | `hello.blossomai.org` |\n\nThis skill connects an existing assistant workflow to Blossom Hire. It is for\njob-marketplace actions such as creating and managing opportunities, finding\nwork, applying, checking candidates, and arranging PopIns.\n\nBlossom receives the minimum personal and job data needed for each requested\naction over HTTPS. The returned API key is permanent and grants account access.\nStore it only in secure credential storage, never in source code, plaintext\nconfiguration, logs, or conversation history.\n\nThe protocol exposes two marketplace surfaces:\n\n1. `POST /register` establishes the Blossom account and returns its API key.\n2. `POST /ask` consumes that already-established identity and is the single\n authenticated marketplace control surface.\n\n`/ask` does not register or authenticate a person. The server resolves its\nBearer API key to the saved person and derives target authority from\nauthenticated ownership and structured operation scope.\n\n## When to activate\n\nActivate only when the user wants a Blossom marketplace action, for example:\n\n- posting, changing, closing, or discussing a job;\n- finding or applying for work;\n- checking applications or candidates;\n- creating, selecting, changing, listing, or removing a work address;\n- scheduling or reviewing a Blossom PopIn.\n\nDo not forward unrelated questions, conversation history, system prompts,\ncredentials, documents, cookies, tokens, personal notes, or hidden reasoning to\nBlossom.\n\n## First run and registration\n\nKeep your normal assistant identity and voice. Do not introduce yourself as\nBlossom or imply Blossom has replaced the user's assistant.\n\nOn first use:\n\n1. Confirm the user's full name and email.\n2. Establish whether they are hiring or looking for work.\n3. Ask them to choose a unique Blossom `passKey` that they do not use for\n email, banking, work, or another sensitive service.\n4. Summarize the account details and obtain clear confirmation.\n5. Call `POST /register`.\n6. Securely persist the returned `apiKey` and `personId`.\n7. Discard the submitted `passKey`; never echo, store, log, or send it to\n `/ask`.\n\nIf secure API-key persistence fails, say the account was created but this\nclient cannot reliably reconnect. Do not present durable setup as complete.\n\nAccount type is set once"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7c0sfzp2ggzgangnetbef6a580am8v\",\n \"slug\": \"blossom-jobs\",\n \"version\": \"2.0.2\",\n \"publishedAt\": 1785480699300\n}"},{"path":"skill-card.md","content":"## Description:\n\nSet up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[robbiwu](https://clawhub.ai/user/robbiwu)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal employers and jobseekers use this skill to set up Blossom Hire accounts, post or manage local work opportunities, search and apply for jobs, review candidates, and schedule PopIns through confirmed Blossom marketplace requests.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: A permanent unscoped Blossom account API key grants durable account access if exposed.\n\nMitigation: Persist the key only in secure credential storage, never paste or log it, and contact Blossom support to rotate or revoke access if exposure is suspected.\n\nRisk: Marketplace actions can create, update, delete, post, apply for, or schedule work-related records.\n\nMitigation: Summarize the exact action and target, obtain clear user confirmation, and claim completion only from the structured successful action returned by Blossom.\n\nRisk: Unrelated personal data, credentials, or conversation history could be sent to Blossom unnecessarily.\n\nMitigation: Send only the minimum current Blossom-related instruction and avoid forwarding unrelated prompts, documents, credentials, cookies, tokens, notes, or hidden reasoning.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/robbiwu/skills/blossom-jobs)\n- [Blossom homepage](https://blossomai.org)\n- [Blossom protocol API](https://hello.blossomai.org/api/v1/blossom/protocol)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Text, API calls, Configuration]\n\n**Output Format:** [Markdown and JSON/HTTP request guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes concise user-facing responses and Blossom API requests based on confirmed marketplace actions.]\n\n## Skill Version(s):\n\n2.0.2 (source: server release metadata; artifact frontmatter reports 4.0.2)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language. Skill: Find and Offer New Work and Tasks Owner: robbiwu Summary: Set up Blossom Hire, create local work opportunities, and help employers and jobseekers move through Blossom work flows in plain language. Tags: latest:2.0.2 Version history: v2.0.2 | 2026-07-31T06:51:39.300Z | user - Removed the sample file skill-card.md. - Updated protocol documentation to clarify that image upload is not supported via the protocol AP","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1629,"uniquenessScore":45,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T17:35:23.744Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:48:01.037Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}