Stoory Hire Specialist

Previous value: -"The minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub), or — if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. The server scans every file for secrets, then uploads the rest to the task's file storage on Stoory; contents never enter the model context. Max 5MB per file. Entries that are unreadable or filtered as secrets come back in blocked_files — the task is still created without them."New value: +"The minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub) — the server rewrites common Google Drive and Dropbox share links to their direct-download form, and rejects a URL that returns a web page instead of a file — or, if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. The server scans every file for secrets, then uploads the rest to the task's file storage on Stoory; contents never enter the model context. Max 5MB per file. Entries that are unreadable or filtered as secrets come back in blocked_files — the task is still created without them."

Previous value: -"The minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub), or — if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. For a large binary with no URL and no way to upload it yourself, don't inline it — tell the user to add it to the task repo manually instead. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The GitHub username used to invite the client into the task repo comes from their Stoory account, not from you — you never see or pass it. If create_task fails because it's missing or invalid, tell the user to check/set their GitHub username in their Stoory account settings, then retry create_task."New value: +"The minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub), or — if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. The server scans every file for secrets, then uploads the rest to the task's file storage on Stoory; contents never enter the model context. Max 5MB per file. Entries that are unreadable or filtered as secrets come back in blocked_files — the task is still created without them."

Previous value: -"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."New value: +"The minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub), or — if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. For a large binary with no URL and no way to upload it yourself, don't inline it — tell the user to add it to the task repo manually instead. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The GitHub username used to invite the client into the task repo comes from their Stoory account, not from you — you never see or pass it. If create_task fails because it's missing or invalid, tell the user to check/set their GitHub username in their Stoory account settings, then retry create_task."

Previous value: -"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."New value: +"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."

Previous value: -"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."New value: +"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."

Previous value: -"Minimalny zestaw plików potrzebny specjaliście — tylko ścieżki lokalne, NIE wklejaj treści plików. Serwer sam czyta plik z dysku i wrzuca go do prywatnego repo GitHub utworzonego dla tego taska — treść nigdy nie trafia do kontekstu modelu. Nigdy całe repo, max 1 plik = ~900KB. Przy niepustej liście user musi mieć ustawiony github_username — jeśli create_task to zgłosi, dopytaj usera o jego login GitHub i spróbuj ponownie."New value: +"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."

Added value: +{
+  "type": "string"
+}

Added value: +{
+  "type": "string"
+}

Removed value: -{
-  "type": "string"
-}

Added value: +{
+  "format": "uri",
+  "type": "string"
+}

Previous value: -[
-  "path"
-]New value: +[
+  "name"
+]

Previous value: -"Język taska — musi odpowiadać językowi, w jakim user sformułował title/description (nie ma automatycznego wykrywania, ustaw zgodnie z danymi usera)."New value: +"The task's language — must match the language the user phrased title/description in (there is no auto-detection, set it according to the user's input)."

Previous value: -"Id jednego lub kilku specjalistów do zaproszenia."New value: +"Id of one or more specialists to invite."

Previous value: -"Jak pilny jest projekt z perspektywy klienta — pytaj usera wprost, nie zgaduj."New value: +"How urgent the project is from the client's perspective — ask the user directly, do not guess."

Previous value: -"Musi być true — ustaw wyłącznie po jawnym potwierdzeniu przez usera w rozmowie"New value: +"Must be true — set it only after the user's explicit confirmation in the conversation."

Previous value: -"Tylko gdy user jawnie prosi o kraj specjalisty (np. 'grafik z Polski'). Pełna angielska nazwa kraju, np. \"Poland\", \"Germany\" — nie kod ISO. Ignorowane, jeśli podano też geo_location. Pomiń pole, gdy user nie wspomniał o kraju."New value: +"Only when the user explicitly asks for the specialist's country (e.g. 'a designer from Poland'). Full English country name, e.g. \"Poland\", \"Germany\" — not an ISO code. Ignored if geo_location is also given. Omit the field when the user did not mention a country."

Previous value: -"Tylko gdy user podaje konkretne miasto/lokalizację i chce szukać w okolicy (np. 'w okolicy Warszawy', 'designer w Warszawie'). Obiekt { lat, lon, radius_meters } — ustal lat/lon wskazanego miasta samodzielnie. Domyślny radius_meters to 50000 (50km); przy zbyt małej liczbie wyników zwiększaj do 100000, potem 200000 zamiast poszerzać query. Ma priorytet nad `country`, jeśli oba podane. Pomiń pole, gdy user nie wspomniał o lokalizacji."New value: +"Only when the user gives a specific city/location and wants to search nearby (e.g. 'near Warsaw', 'a designer in Warsaw'). An object { lat, lon, radius_meters } — determine the lat/lon of the named city yourself. Default radius_meters is 50000 (50km); when there are too few results, raise it to 100000, then 200000 instead of broadening the query. Takes priority over `country` if both are given. Omit the field when the user did not mention a location."

Previous value: -"Tylko gdy user jawnie prosi o konkretny język specjalisty (np. 'polskojęzyczny grafik'). Dozwolone wartości: English, Polish, German, French, Spanish, Italian — inna wartość zostanie odrzucona przez API. Pomiń pole (lub []), gdy user nie wspomniał o języku."New value: +"Only when the user explicitly asks for a specific specialist language (e.g. 'a Polish-speaking designer'). Allowed values: English, Polish, German, French, Spanish, Italian — any other value is rejected by the API. Omit the field (or []) when the user did not mention a language."

Previous value: -"Domyślnie 10, zwiększ do 20 przy słabych wynikach lub gdy user prosi o więcej opcji (max 20)."New value: +"Default 10, raise to 20 for weak results or when the user asks for more options (max 20)."

Previous value: -"Rola i umiejętności specjalisty, MAKS. 12 słów, naturalny język — nie pełne zdanie opisujące problem usera. Po angielsku, jeśli to możliwe (szybsza odpowiedź i lepsze trafienia niż w innych językach). Dobrze: 'Senior Stripe developer', 'Professional logo designer', 'Experienced UX designer for mobile apps'. Źle: 'I need someone who can help me with branding and visual identity design' (pełne zdanie zamiast roli), 'Full-stack developer with microservices architecture experience' (za dużo naraz sklejonej specyfiki). Gdy wynik słaby (<3 trafień lub same 'Alternative fit'), ponawiaj ze stopniowo prostszym/szerszym query zamiast dopytywać usera, np. 'Senior mobile app developer for fintech startup' → 'Mobile app developer' → 'App developer' → 'Mobile development'; albo 'GDPR compliance lawyer for healthcare startup' → 'GDPR lawyer' → 'Data protection lawyer' → 'Lawyer'."New value: +"The specialist's role and skills, MAX 12 words, natural language — not a full sentence describing the user's problem. In English if possible (faster response and better hits than other languages). Good: 'Senior Stripe developer', 'Professional logo designer', 'Experienced UX designer for mobile apps'. Bad: 'I need someone who can help me with branding and visual identity design' (full sentence instead of a role), 'Full-stack developer with microservices architecture experience' (too much glued-together specificity at once). When results are weak (<3 hits or only 'Alternative fit'), retry with a progressively simpler/broader query instead of asking the user, e.g. 'Senior mobile app developer for fintech startup' → 'Mobile app developer' → 'App developer' → 'Mobile development'; or 'GDPR compliance lawyer for healthcare startup' → 'GDPR lawyer' → 'Data protection lawyer' → 'Lawyer'."