← Platform Hire
API
Tokens

Run Platform Hire from your own code

Both metered lanes are available over HTTP and each returns one JSON object. The division of labour: the page scans the posting for who the role serves and for build work stacked with outreach work, ranks the hire, weights the competencies for the track, plans the loop against the interviewer-hour budget, and checks outcomes, the loop, sourcing and compensation, then hands it all to the run as facts. The run writes the scorecard or the loop; the page then holds it to its own facts (phreply.js).

Base URL and the response shape

Every endpoint lives under https://api.skillsafe.ai/v1/app-api, and every response has one shape:

{ "ok": true,  "data":  { ... } }
{ "ok": false, "error": { "code": "...", "message": "..." } }

The token is minted for this app (the guest call takes {"slug":"platform-hire"}), so no slug header is needed afterwards. Send it as Authorization: Bearer YOUR_TOKEN. The run body is the input object, sent bare.

StatusCodeMeaning
400validation_errorThe body is not a JSON object, or a required key (task, role, posting, facts) is missing. The page always sends all five of task, role, posting, carry, facts; carry is an empty string for scorecard.
401unauthorizedNo token, or a stale one. Mint a guest token or sign in again.
402insufficient_creditsThe balance is under min_credits. Price with /estimate first.
403forbiddenA guest token tried to run: both lanes are metered and need a personal sign-in.
404not_foundUnknown job id.
429rate_limitedBack off and retry.
5xxserver_errorTransient. Retry with the same Idempotency-Key so a retry never double-bills.

The task field comes first

Two lanes, chosen by task, in the order the work runs - before the posting goes out, then before the first candidate:

A missing or unknown task is answered as scorecard; an internal-platform hire is refused before it runs. Both lanes send the same five fields. The facts are the page's checks, one row per line, and a line starting "must:" is a rule the reply has to hold. The page's handoff carries the scorecard into carry for the loop lane.

The input

FieldRequiredWhat
taskyesscorecard or loop. If it is missing or neither, do scorecard and set "task": "scorecard".
roleyesthe company and the role, who consumes what it builds, the archetype and track, first hire or addition, what it is measured on, resourcing, the compensation stance, deadline, reuse, the interviewer-hour budget and the recruiter; "not given" means not given.
postingyesthe draft posting, the outcomes drafted, the loop drafted and the sourcing channels drafted.
carrysend it (empty for scorecard)loop task only: the scorecard decisions, when the scorecard task ran first; may be empty.
factsyesthe page's checks, one line each as area | id | status | evidence, the verdict and the rankings. A line starting "must:" applies to your reply.
retry_notenooptional; if present, your previous reply was unusable - follow it.

The rules the model applies

From the source skill, @samber/developer-platform-hiring - the only standard the run applies:

House rules

The replies

scorecard

Write the role scorecard and the posting fixes the hiring manager will use.

  1. summary - one sentence, at most 40 words: the shape of the hire, and the first thing that must change.
  2. calibration - one sentence: that the role serves developers outside the company, the archetype and the track - the veto-able calibration.
  3. mission - one sentence naming the archetype and the metric the role is measured on.
  4. outcomes - three to eight objects: outcome (what changes, in this company's terms), measure (the number and by when - labelled proposed when the input gives none).
  5. competencies - one object per competency the facts weight, in the same order: competency (as the facts name it), weight (the number the facts give).
  6. shape - shape (dedicated, split or fold, exactly as the facts rank first), fix (one sentence: what that means for this hire - for a split, which work this hire keeps and which the next hire takes).
  7. posting_fixes - short strings: the edits the posting needs before it goes out (who the role serves, outcomes with numbers, the scope split or the headcount plan); [] when none.
  8. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "scorecard",
  "summary": "one sentence",
  "calibration": "one sentence",
  "mission": "one sentence",
  "outcomes": [ { "outcome": "what changes", "measure": "a number and a date" } ],
  "competencies": [ { "competency": "as the facts name it", "weight": 35 } ],
  "shape": { "shape": "dedicated", "fix": "one sentence" },
  "posting_fixes": [ "an edit" ],
  "caveats": [ ]
}

The page holds it to its own facts (check() in phreply.js; any warning makes the reply flagged): the reply answers the task it was sent; no web link; no backticks; a summary of at most 40 words; a calibration naming developers outside the company; a mission; three to eight outcomes, each with a number; the page's competencies with exactly its weights, in order; the ranked hire shape; for a collapsed posting, a split or a headcount plan; posting fixes when a posting was pasted.

loop

Write the interview loop, the sourcing plan and the compensation stance.

  1. summary - one sentence, at most 40 words.
  2. stages - one object per stage of the page's loop, in its order, no others: stage (the page's stage id), name (its name for this company), interviewer (the role who runs it - as the input names one, or proposed), minutes (a number - the page's), judges (one sentence: what this stage decides for this hire).
  3. sourcing - at least two objects: channel, why (one sentence tied to this track).
  4. avoid - short strings: the channels to avoid and why, PlatformCon among them.
  5. comp - anchor (one sentence: the general engineering or product-management ladder and the equivalent level), source (the named source with its date, as the input gives it, or proposed and said so).
  6. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "loop",
  "summary": "one sentence",
  "stages": [ { "stage": "recruiter", "name": "Recruiter screen", "interviewer": "a role", "minutes": 30, "judges": "one sentence" } ],
  "sourcing": [ { "channel": "a channel", "why": "one sentence" } ],
  "avoid": [ "a channel and why" ],
  "comp": { "anchor": "one sentence", "source": "a named, dated source" },
  "caveats": [ ]
}

The page requires: the reply answers the task it was sent; the same text rules; the page's loop stages in order, each with an interviewer, minutes and what it judges, inside the interviewer-hour budget; no coding round for the PM track; apidays for the platform and PM tracks; at least two channels and never PlatformCon among them; PlatformCon named among the channels to avoid; compensation anchored to the general engineering or PM ladder, not a bespoke-title search, with a dated source or one proposed.

Worked examples

Three runs from the page's free samples (invented companies): the scorecard for a first public API with three jobs in one seat, the loop for the same hire carrying that scorecard, and the scorecard for an API-first company hiring a senior engineer. Each input is exactly what the page sends; each reply is the saved reply the sample replays, shipped unedited - but the facts and long strings are shortened in this display only, and every cut is listed under the example. The last line is the page's own check of the full reply.

scorecard - A first public API with three jobs in one seat

The page read it as: three jobs in one seat - split the scope first; track platform; hire split, fold, dedicated; 1 of 6 gates; failing checks: scope, outcomes, loop, sourcing, comp.

Input (facts is 2859 characters; the first 1395 are shown):

{
 "task": "scorecard",
 "role": "Company: Relaywise\nThe company and the role: A scheduling app for clinics that is adding its first public API so practice-management vendors can book appointments into it.\nWho consumes what the role builds: developers outside the company; archetype: A company bolting a public API onto its product; track: Platform Engineer / Architect\nFirst dedicated hire: yes; measured on: API design quality and contract stability; resourcing: solo ownership\nCompensation: from a bespoke platform-title search; range: $185k-$210k; source: salary-site search for platform engineer\nDeadline: this quarter; a one-off hire; interviewer-hours per candidate: 6; recruiter: no; effort ceiling: medium; as-of: 2026-11-01",
 "posting": "Draft posting:\nPlatform Engineer - Relaywise\nYou will design our first public API and own the endpoints, versioning and SDKs that third-party developers use.\nYou will onboard our first ten partners and keep every integration healthy.\nYou will write tutorials and blog posts, speak at conferences and grow our developer community.\nYou report to the CTO and own the platform end to end.\n\nOutcomes drafted (outcome | has a number):\n- Own the public API | no\n- Ship the first 10 partner integrations | yes\n- Grow the developer community | no\n\nLoop drafted (stage | interviewer | minutes | format):\n- Recruiter screen | recruiter | 30 | call\n- System design | staff engineer | 60 | whiteboard\n- Coding | senior engineer | 60 | live coding\n\nSourcing channels drafted:\n- PlatformCon job board\n- Backstage community Slack\n- LinkedIn",
 "carry": "",
 "facts": "The page's checks (5 fail, 2 warn, 1 pass, 4 n/a); verdict: three jobs in one seat - split the scope first:\n- The posting | calibration | na | A company bolting a public API onto its product; Platform Engineer / Architect; measured on api design quality and contract stability\n- The posting | consumer | pass | names public api, sdks, third-party\n- The posting | scope | fail | build work (design our first public api, endpoints, versioning, sdks), partner work (partners) and outreach work (tutorials, blog, conferences, community) in one seat, owned solo, with no headcount plan\n- The posting | first | warn | a real resourcing shift, not a backfill - most API teams run at 1-9 people; size the hire to the actual team\n- The scorecard | outcomes | fail | 3 outcomes; no number in \"Own the public API\", \"Grow the developer community\"\n- The scorecard | weights | na | API and system design 35%, Infrastructure delivery 25%, Developer-facing usability judgment 20%, Collaboration 10%, Written communication 10%\n- The scorecard | shape | na | Split the scope across hires > Fold into general backend or PM hiring > One dedicated specialist hire - a bolt-on public API usually folds this hire into general backend hiring; the posting stacks build work and outreach work with no headcount plan - split the scope\n- The loop and sourcing | loop | fail | a general system-design round stands in for the\n\n[... 1464 more characters cut from this display ...]"
}

Reply:

{
 "task": "scorecard",
 "summary": "Relaywise's draft stacks API build, partner onboarding and developer outreach into one solo seat; split it so this first hire owns the public booking API and its partner integrations, and outreach goes to a later hire.",
 "calibration": "This hire builds for developers outside Relaywise, the practice-management vendors booking appointments through the new public API, at a company bolting a public API onto its product, on the Platform Engineer / Architect track.",
 "mission": "Design and run Relaywise's first public booking API, a public API bolted onto a clinic scheduling product, measured on API design quality and contract stability for the vendors integrating with it.",
 "outcomes": [
  {
   "outcome": "The first public booking API ships with a published, versioned contract that practice-management vendors can build against",
   "measure": "v1 contract published by 2027-03-31 (proposed)"
  },
  {
   "outcome": "Vendors integrating with the API see no unannounced breaking changes",
   "measure": "0 breaking changes per quarter after v1 ships (proposed)"
  },
  {
   "outcome": "The first ten partner integrations go live on the API",
   "measure": "10 live partner integrations by 2027-06-30 (proposed date)"
  },
  {
   "outcome": "Vendors get a working booking call quickly from the docs and SDK",
   "measure": "median time to first successful booking call under 1 day for the first 10 partners (proposed)"
  },
  {
   "outcome": "Partner integrations stay healthy once live",
   "measure": "under 2 partner-reported integration incidents per month by 2027-06-30 (proposed)"
  }
 ],
 "competencies": [
  {
   "competency": "API and system design",
   "weight": 35
  },
  {
   "competency": "Infrastructure delivery",
   "weight": 25
  },
  {
   "competency": "Developer-facing usability judgment",
   "weight": 20
  },
  {
   "competency": "Collaboration",
   "weight": 10
  },
  {
   "competency": "Written communication",
   "weight": 10
  }
 ],
 "shape": {
  "shape": "split",
  "fix": "This Relaywise hire keeps the build work - endpoints, versioning, SDKs and the integration architecture for the first ten partners - while tutorials, blog posts, conference talks and community growth move to a separate later hire."
 },
 "posting_fixes": [
  "Cut the tutorials, blog posts, conference talks and developer-community lines, or name the separate hire who will own them.",
  "Replace own the platform end to end with ownership of the public booking API contract, versioning and SDKs.",
  "Name practice-management vendors as the developers the API serves.",
  "Swap Own the public API and Grow the developer community for outcomes with numbers and dates, such as 0 breaking changes per quarter (proposed).",
  "State the resourcing: solo ownership reporting to the CTO for now, with the outreach hire planned."
 ],
 "caveats": [
  "A bolt-on public API often folds into general backend hiring; a dedicated seat here is a resourcing shift for Relaywise, not a backfill.",
  "The $185k-$210k range comes from a salary-site platform-engineer search; re-anchor it to Relaywise's general engineering bands before posting.",
  "The drafted loop uses a general system-design round where an API-design interview belongs.",
  "PlatformCon and the Backstage community Slack reach internal-platform engineers, not this hire."
 ]
}

What step 5 prints for it: The first public booking API ships with a published, versioned contract that practice-management vendors can build against: v1 contract published by 2027-03-31 (proposed) | Vendors integrating with the API see no unannounced breaking changes: 0 breaking changes per quarter after v1 ships (proposed) | The first ten partner integrations go live on the API: 10 live partner integrations by 2027-06-30 (proposed date) | Vendors get a working booking call quickly from the docs and SDK: median time to first successful booking call under 1 day for the first 10 partners (proposed) | Partner integrations stay healthy once live: under 2 partner-reported integration incidents per month by 2027-06-30 (proposed)

The page's check: kept - nothing to flag

loop - A first public API with three jobs in one seat

The input carries the saved scorecard (R.laneForm fills carry from the scorecard reply), as the page's handoff does. The page's loop: wire, wireShown, wireNote, reply, shown, cuts, status, notes, carried, gist.

Input (facts is 2770 characters; the first 1395 are shown):

{
 "task": "loop",
 "role": "Company: Relaywise\nThe company and the role: A scheduling app for clinics that is adding its first public API so practice-management vendors can book appointments into it.\nWho consumes what the role builds: developers outside the company; archetype: A company bolting a public API onto its product; track: Platform Engineer / Architect\nFirst dedicated hire: yes; measured on: API design quality and contract stability; resourcing: solo ownership\nCompensation: from a bespoke platform-title search; range: $185k-$210k; source: salary-site search for platform engineer\nDeadline: this quarter; a one-off hire; interviewer-hours per candidate: 6; recruiter: no; effort ceiling: medium; as-of: 2026-11-01",
 "posting": "Draft posting:\nPlatform Engineer - Relaywise\nYou will design our first public API and own the endpoints, versioning and SDKs that third-party developers use.\nYou will onboard our first ten partners and keep every integration healthy.\nYou will write tutorials and blog posts, speak at conferences and grow our developer community.\nYou report to the CTO and own the platform end to end.\n\nOutcomes drafted (outcome | has a number):\n- Own the public API | no\n- Ship the first 10 partner integrations | yes\n- Grow the developer community | no\n\nLoop drafted (stage | interviewer | minutes | format):\n- Recruiter screen | recruiter | 30 | call\n- System design | staff engineer | 60 | whiteboard\n- Coding | senior engineer | 60 | live coding\n\nSourcing channels drafted:\n- PlatformCon job board\n- Backstage community Slack\n- LinkedIn",
 "carry": "Calibration: This hire builds for developers outside Relaywise, the practice-management vendors booking appointments through the new public API, at a company bolting a public API onto its product, on the Platform Engineer / Architect track.\nMission: Design and run Relaywise's first public booking API, a public API bolted onto a clinic scheduling product, measured on API design quality and contract stability for the vendors integrating with it.\nOutcomes: The first public booking API ships with a published, versioned contract that practice-management vendors can build against (v1 contract published by 2027-03-31 (proposed)); Vendors integrating with the API see no unannounced breaking changes (0 breaking changes per quarter after v1 ships (proposed)); The first ten partner integrations go live on the API (10 live partner integrations by 2027-06-30 (proposed date)); Vendors get a working booking call quickly from the docs and SDK (median time to first successful booking call under 1 day for the first 10 partners (proposed)); Partner integrations stay healthy once live (under 2 partner-reported integration incidents per month by 2027-06-30 (proposed))\nCompetencies: API and system design 35, Infrastructure delivery 25, Developer-facing usability judgment 20, Collaboration 10, Written communication 10\nHire: Split the scope across hires",
 "facts": "The page's checks (5 fail, 2 warn, 1 pass, 4 n/a); verdict: three jobs in one seat - split the scope first:\n- The posting | calibration | na | A company bolting a public API onto its product; Platform Engineer / Architect; measured on api design quality and contract stability\n- The posting | consumer | pass | names public api, sdks, third-party\n- The posting | scope | fail | build work (design our first public api, endpoints, versioning, sdks), partner work (partners) and outreach work (tutorials, blog, conferences, community) in one seat, owned solo, with no headcount plan\n- The posting | first | warn | a real resourcing shift, not a backfill - most API teams run at 1-9 people; size the hire to the actual team\n- The scorecard | outcomes | fail | 3 outcomes; no number in \"Own the public API\", \"Grow the developer community\"\n- The scorecard | weights | na | API and system design 35%, Infrastructure delivery 25%, Developer-facing usability judgment 20%, Collaboration 10%, Written communication 10%\n- The scorecard | shape | na | Split the scope across hires > Fold into general backend or PM hiring > One dedicated specialist hire - a bolt-on public API usually folds this hire into general backend hiring; the posting stacks build work and outreach work with no headcount plan - split the scope\n- The loop and sourcing | loop | fail | a general system-design round stands in for the\n\n[... 1375 more characters cut from this display ...]"
}

Reply:

{
 "task": "loop",
 "summary": "Relaywise runs a thin five-stage loop with the CTO screening, an API-design interview replacing the general system-design round, apidays plus senior backend sourcing, and pay re-anchored to the general engineering ladder.",
 "stages": [
  {
   "stage": "recruiter",
   "name": "Screen call with the CTO",
   "interviewer": "CTO, as hiring manager, since Relaywise has no recruiter",
   "minutes": 30,
   "judges": "Whether the candidate wants to build a first public booking API for practice-management vendors, solo, with outreach handed to a later hire."
  },
  {
   "stage": "manager",
   "name": "Hiring-manager interview",
   "interviewer": "CTO",
   "minutes": 45,
   "judges": "Whether the candidate can own contract stability and versioning for Relaywise's first public API without a platform team around them."
  },
  {
   "stage": "apidesign",
   "name": "API-design interview: appointment booking for vendors",
   "interviewer": "staff engineer (proposed)",
   "minutes": 60,
   "judges": "Whether the booking API the candidate designs is easy for practice-management vendors to use correctly and hard to misuse, with double bookings and versioning handled in the contract."
  },
  {
   "stage": "system",
   "name": "System and infrastructure delivery",
   "interviewer": "staff engineer",
   "minutes": 60,
   "judges": "Whether the candidate can ship and run the API alongside the clinic scheduling product reliably enough to keep ten partner integrations healthy."
  },
  {
   "stage": "practical",
   "name": "Practical coding exercise",
   "interviewer": "senior engineer",
   "minutes": 60,
   "judges": "Whether the candidate writes clear, tested endpoint and SDK code at the pace a solo owner needs."
  }
 ],
 "sourcing": [
  {
   "channel": "apidays speakers and attendees",
   "why": "It gathers the API platform engineers who have designed public contracts, which is the core of this Relaywise seat."
  },
  {
   "channel": "Referrals for senior backend engineers",
   "why": "A bolt-on API sits close to general backend work, so referrals of senior backend engineers reach people who can also run the scheduling product's services."
  },
  {
   "channel": "Open-source contributors to API tooling and SDKs",
   "why": "Public contribution history shows versioning and SDK judgment before the API-design interview."
  },
  {
   "channel": "LinkedIn senior-IC searches filtered for public API work",
   "why": "Kept from the draft but narrowed to engineers who have shipped APIs for outside developers."
  }
 ],
 "avoid": [
  "PlatformCon job board - it reaches internal developer platform engineers, not builders of an API for outside vendors.",
  "Backstage community Slack - same internal-platform population, building portals for their own company's engineers."
 ],
 "comp": {
  "anchor": "Anchor the offer to Relaywise's general engineering ladder at the senior backend engineer level (proposed), and replace the $185k-$210k range drawn from a platform-title search.",
  "source": "Relaywise general engineering ladder, senior band, reviewed 2026-11 (proposed source and date; the draft's salary-site platform-engineer search is not a valid anchor)"
 },
 "caveats": [
  "With no recruiter, the CTO carries the screen and the manager interview, 75 minutes of the 4.3 interviewer-hours.",
  "The team interview is dropped because this is a one-off hire.",
  "Re-anchoring may move the range off $185k-$210k; post no range until the ladder band is confirmed."
 ]
}

What step 5 prints for it: recruiter: 30 | manager: 45 | apidesign: 60 | system: 60 | practical: 60

The page's check: kept - nothing to flag

scorecard - An API-first company hiring a senior engineer

The page read it as: a platform hire ready to post; track platform; hire dedicated, split, fold; 6 of 6 gates; failing checks: none.

Input (facts is 2075 characters; the first 1391 are shown):

{
 "task": "scorecard",
 "role": "Company: Tollvane\nThe company and the role: An API-first payments company whose product is its API; the platform team of six is adding a senior engineer.\nWho consumes what the role builds: developers outside the company; archetype: An infrastructure or API-first company; track: Platform Engineer / Architect, senior\nFirst dedicated hire: no, an addition to a platform team; measured on: API design quality and contract stability; resourcing: a small team\nCompensation: anchored to the general ladder; range: $210k-$240k base, L5; source: Tollvane engineering ladder, L5 band, reviewed 2026-09\nDeadline: this quarter; the first of several hires; interviewer-hours per candidate: 6; recruiter: yes; effort ceiling: high; as-of: 2026-11-01",
 "posting": "Draft posting:\nSenior Platform Engineer - Tollvane\nDesign and evolve the public payments API that external developers and integrators build on.\nOwn versioning and the API contract for the payouts endpoints.\nJoin a platform team of six; we plan to hire a second engineer next year.\n\nOutcomes drafted (outcome | has a number):\n- Cut breaking changes on the payouts API to 0 per quarter | yes\n- Bring p95 latency on the payouts endpoints under 250 ms by Q3 | yes\n- Ship the v2 payouts contract to 3 pilot integrators by June | yes\n- Raise the SDK quickstart completion rate from 40% to 70% | yes\n\nLoop drafted (stage | interviewer | minutes | format):\n- Recruiter screen | recruiter | 30 | call\n- Hiring-manager interview | platform lead | 45 | conversation\n- API-design interview | staff engineer | 60 | design a webhooks API\n- System and infrastructure delivery | principal engineer | 60 | architecture\n- Practical coding exercise | senior engineer | 60 | pairing\n- Team interview | two engineers | 45 | panel\n- Executive round | CTO | 30 | conversation\n\nSourcing channels drafted:\n- apidays speaker and attendee lists\n- Referrals from the platform team\n- Open-source maintainers of API tooling\n- Senior backend engineering pipelines",
 "carry": "",
 "facts": "The page's checks (0 fail, 0 warn, 6 pass, 4 n/a); verdict: a platform hire ready to post:\n- The posting | calibration | na | An infrastructure or API-first company; Platform Engineer / Architect; measured on api design quality and contract stability\n- The posting | consumer | pass | names external developers, integrators\n- The posting | scope | pass | 1 function named\n- The scorecard | outcomes | pass | 4 outcomes; all quantified\n- The scorecard | weights | na | API and system design 35%, Infrastructure delivery 25%, Developer-facing usability judgment 20%, Collaboration 10%, Written communication 10%\n- The scorecard | shape | na | One dedicated specialist hire > Split the scope across hires > Fold into general backend or PM hiring\n- The loop and sourcing | loop | pass | 7 stages that fit the Platform Engineer / Architect track\n- The loop and sourcing | plan | na | Recruiter screen 30 min, Hiring-manager interview 45 min, API-design interview 60 min, System and infrastructure delivery 60 min, Practical coding exercise 60 min, Team interview 45 min, Executive round 30 min - 5.5 interviewer-hours\n- The loop and sourcing | sourcing | pass | apidays speaker and attendee lists, Referrals from the platform team, Open-source maintainers of API tooling, Senior backend engineering pipelines\n- Compensation | comp | pass | anchored to the general ladder at $210k-$240k base, L5 -\n\n[... 684 more characters cut from this display ...]"
}

Reply:

{
 "task": "scorecard",
 "summary": "Tollvane's senior platform engineer is a dedicated addition to a six-person API team and the posting is ready; first, give the June and Q3 targets a year before it goes out.",
 "calibration": "This hire builds the public payments API for developers and integrators outside Tollvane, an infrastructure or API-first company, on the Platform Engineer / Architect track at senior level.",
 "mission": "Evolve the payouts endpoints of Tollvane's public payments API, the product of an API-first company, measured on API design quality and contract stability for the external developers who build on it.",
 "outcomes": [
  {
   "outcome": "External developers on the payouts API stop absorbing breaking changes",
   "measure": "0 breaking changes per quarter on the payouts API"
  },
  {
   "outcome": "The payouts endpoints answer fast enough for integrators' checkout and payout flows",
   "measure": "p95 latency under 250 ms by Q3 2027 (proposed year)"
  },
  {
   "outcome": "The v2 payouts contract is proven with real integrators before general release",
   "measure": "v2 contract live with 3 pilot integrators by June 2027 (proposed year)"
  },
  {
   "outcome": "New developers get from the SDK quickstart to a working call",
   "measure": "quickstart completion rate from 40% to 70% by Q3 2027 (proposed date)"
  }
 ],
 "competencies": [
  {
   "competency": "API and system design",
   "weight": 35
  },
  {
   "competency": "Infrastructure delivery",
   "weight": 25
  },
  {
   "competency": "Developer-facing usability judgment",
   "weight": 20
  },
  {
   "competency": "Collaboration",
   "weight": 10
  },
  {
   "competency": "Written communication",
   "weight": 10
  }
 ],
 "shape": {
  "shape": "dedicated",
  "fix": "Tollvane hires one senior specialist into the existing six-person platform team to own versioning and the payouts contract, with the second engineer planned for next year kept as a separate seat."
 },
 "posting_fixes": [
  "Add the year to the June and Q3 targets, for example June 2027 and Q3 2027 (proposed).",
  "Give the quickstart completion target a date, such as Q3 2027 (proposed)."
 ],
 "caveats": [
  "The 2027 years on the June and Q3 targets are proposed; the draft gives no year."
 ]
}

What step 5 prints for it: External developers on the payouts API stop absorbing breaking changes: 0 breaking changes per quarter on the payouts API | The payouts endpoints answer fast enough for integrators' checkout and payout flows: p95 latency under 250 ms by Q3 2027 (proposed year) | The v2 payouts contract is proven with real integrators before general release: v2 contract live with 3 pilot integrators by June 2027 (proposed year) | New developers get from the SDK quickstart to a working call: quickstart completion rate from 40% to 70% by Q3 2027 (proposed date)

The page's check: kept - nothing to flag

Build the input yourself

Load the engine in node (global.window = global; require("./phkit.js"); require("./phreply.js")), then:

const K = HireKit, R = HireReply;
const f = K.form(Object.assign(K.blank(), { name: "Acme", track: "platform", archetype: "bolton", comp: "bespoke",
  posting: "Design our public API and SDKs for third-party developers. Write blog posts and speak at conferences.",
  outcomes: "Own the public API" }));
// f.scanned (the posting scan), f.shapeRank (the ranked hire), f.plan (the page's loop), f.gates
// K.auditMd(f), K.loopCsv(f) - the posting self-audit and the loop schedule
const b = K.buildInput(f, "scorecard");                      // or "loop" (R.laneForm(form, "loop", scorecard) fills carry)
const wire = K.toWire(b.input);                              // POST this to /estimate and /run
// then: const reply = R.normalize(R.parseReply(job.output.output), "scorecard");
// R.check(reply, b)                                         // {status: kept or flagged, notes}

Get a token for the steps below from /tokens.html.

Step 1 — a tiny client helper

One function that sends JSON and unwraps the response. Paste a personal token from /tokens.html, or leave it empty and mint a guest token in step 2.

BASE="https://api.skillsafe.ai/v1/app-api"
TOKEN="YOUR_TOKEN"   # from https://platform-hire.skillsafe.ai/tokens.html
api() { # api METHOD PATH [JSON-BODY]
  curl -s -X "$1" "$BASE$2" -H "Content-Type: application/json" \
    ${TOKEN:+-H "Authorization: Bearer $TOKEN"} ${3:+--data "$3"}
}

Step 2 — a token

A guest token is enough for /me and /estimate. A run is metered, so it needs a personal token: sign in on /tokens.html and copy it from there.

# a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
TOKEN=$(curl -s -X POST "$BASE/guest" -H "Content-Type: application/json" -d '{"slug":"platform-hire"}' | jq -r '.data.token')

Step 3 — GET /me

Who the token is (subject_type: user or guest) and the credit balance.

api GET /me | jq '.data | {subject_type, credits}'

Step 4 — POST /estimate

Free. The body is the run input itself, the bare object (never wrapped in {"input": ...}). hold_credits is a reservation, not the price; min_credits is what the balance must cover; model_alias reads gpt-terra.

# input.json: the run input object - {"task": "scorecard", "role": "Company: Relaywise
The company and the role: ...", "posting": "Draft posting:
Platform Engineer - Relaywise ...", "carry": "", "facts": "The page's checks (...); verdict: three jobs in one seat - split the scope first:
- The posting | scope | fail | ..."}
# - see the input table
api POST /estimate "$(cat input.json)" | jq '.data | {hold_credits, min_credits, model, model_alias, markup_bps, warnings}'

Step 5 — POST /run, then poll the job

Send an Idempotency-Key built from the lane and the input: a retry with the same key never bills twice. The page uses platform-hire:<task>:<inputHash>:a<attempt> - the lane is part of the key, retry_note is left out of the hash - and its one automatic reformat retry is a new attempt number, named in the page as one extra run. A scorecard reply carries summary, calibration, mission, outcomes, competencies, shape, posting_fixes and caveats; a loop reply carries summary, stages, sourcing, avoid, comp and caveats. The code below prints the gist of either: each outcome and its measure, or each loop stage and its minutes.

KEY="platform-hire:$(jq -r .task input.json):$(shasum -a 256 input.json | cut -c1-16):a1"
JOB=$(curl -s -X POST "$BASE/run" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: $KEY" --data @input.json | jq -r '.data.job_id')
while :; do
  J=$(api GET "/jobs/$JOB"); S=$(echo "$J" | jq -r '.data.status')
  case "$S" in succeeded|failed|cancelled) break;; esac; sleep 2
done
echo "$J" | jq -r '.data.output.output' > reply.json   # one JSON object, the reply contract
echo "$J" | jq '.data | {charged_credits, truncated}'
jq -r 'if .task == "loop" then (.stages[] | "\(.stage): \(.minutes)") 
       else (.outcomes[] | "\(.outcome): \(.measure)") end' reply.json

Step 6 — POST /run-stream

The same run as Server-Sent Events, with the same input.json. Browsers receive progress ticks rather than text deltas; the final done event carries the reply.

# Server-Sent Events: tick/delta events while the job runs, then a final event with the job
curl -N -s -X POST "$BASE/run-stream" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: platform-hire:$(jq -r .task input.json):$(shasum -a 256 input.json | cut -c1-16):a1" --data @input.json