Check a draft
check_draftIdempotent
Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). The final verification publish_draft needs. With id: the full checks on your saved draft (judge, slop classifier, fact-check), about a minute; call it after lint_draft passes, never to iterate. Each call waits up to 25 seconds and then reports progress: call it again, never two at once, for the answer (nothing runs twice; a client with the tasks extension gets a task). Right after submit_draft it waits while the draft is filed. Without id it checks markdown and files nothing, which publish_draft doesn't count. On next_action confirm, send first_hand_to_confirm back as first_hand: the engineer confirms, never you.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A draft of yours (the idea id from submit_draft): checks its saved text, the final verification publish_draft needs | |
| kind | No | What the draft is: "post" (the default, a blog post) or "case-study" (content/case-studies, at /case-studies/<slug>). A case study's frontmatter is title, description, sector, stack, track (ai, migration or other) and client when the client register approves naming them or the engineer says the client agreed (client_confirmed); its body opens with ## Challenge, ## Strategy, ## Solution and ## Results, each with a bold one-line statement first. See the editorial_rules resource. | post |
| images | No | ||
| sources | No | The engineer's own words the draft's claims come from, as text. For a post: what the engineer told you about their own work (what they built, measured, saw and decided, and any result, client or number they gave you), quoted as they said it, and their notes; the fact-check treats these as the author's own account of the work, so a first-hand sentence they don't back is a finding. Never write them yourself: ask the engineer. For a case study: the engineer's own notes and the project's records (README, changelog, metrics they gave you) its numbers come from. Every number in the case study is checked against these; one that isn't here is a finding. A source is not an approval: a client's metric also needs the client register's approval. Ask the engineer for outcome numbers; never invent them. At most 100,000 characters. | |
| markdown | No | The whole post: frontmatter (title, description at least) and body. With id: optional, and must be the saved text | |
| post_type | No | Only with markdown (a check of text not filed): The post type, which sets the opening rule and how hard the fact-check reads it. story (the default): work someone at TechFabric did. The opening has TechFabric doing that work by paragraph two, and every claim gets the full fact-check. perspective: a talk or conference the author attended, a conversation with an industry leader, others' work, or our view of what's possible. TechFabric's view by paragraph two ("we think", "we'd", "I believe" count). What a speaker or another company said is attributed in the sentence ("In her demo, ...") and must match what the author provided; forward-looking views need no source. whats-new: a new feature in AI, Databricks or related tech, and how it could help future projects. Open on what changed (its date and source), then our view. Product facts (name, preview or GA, date, what it does) are checked against the vendor's docs or release notes; forward-looking views need no source. personal: the author's own essay or position, in the first person, about where the work or the industry is going and what people should do. Opening and fact-check as perspective, and the only type that may take the memo register: conviction carried as "I believe" and the reader addressed as "you" throughout, up to three bold thesis sentences, one "this is not X" thesis reframe and a closing call to act (other types keep every slop rule, though a perspective opening may still state its view as "we think" or "I believe"). Never for an engineer explaining a feature or their own project. Choose personal only when the engineer writes in their own voice about a position, never for an engineer explaining a feature or their project. Left out, it is story; an explainer is always whats-new. Not for a case study. | |
| first_hand | No | First-hand claims only the engineer can source, which the fact-check flagged first_hand (first_hand_to_confirm): each the sentence exactly as quoted, with what it rests on. Sending it asks the engineer; it never confirms anything on your word. check_draft asks them in their client (an elicitation) where it can, otherwise answers with a question and a one-time confirmation: ask them that question, and only if they say yes, send it back as first_hand_confirmation with the same first_hand. submit_draft and update_draft answer with the question and confirmation too, which come back on check_draft with the id. Never a client's result: a number about a client needs the client's confirmation, as a source. | |
| confirm_via | No | With first_hand or first_hand_all: how the engineer is asked. Default: a form in their client where it can show one. "token": the question and a one-time confirmation instead, for a UI that asks them itself (an MCP App's button) | |
| wait_seconds | No | Without the tasks extension: how long to wait for the result before answering with progress (default and most 25; a larger value, accepted for older agents, waits 25) | |
| first_hand_all | No | Confirm all listed: true asks the engineer to confirm, in one go, every first-hand claim the last check of this text listed (first_hand_to_confirm), instead of listing them in first_hand. The list is the server's, from that check: a client's result, a client's fact and a known error are never in it and come back apart (first_hand.excluded). It asks as first_hand does (one form showing every claim, or a question and a one-time confirmation to send back with first_hand_all: true); it never confirms anything on your word. Each claim is still recorded on its own under the engineer's name. | |
| client_confirmed | No | Only when the engineer tells you they have the client's confirmation to name the client this draft names (its client:, or a client in its text the register doesn't approve). Recorded under the engineer's name with the draft and its text; never send it on your own judgement. It covers naming the client, not results: numbers still need sources. | |
| first_hand_confirmation | No | Only after asking the engineer and hearing yes: the confirmation an earlier answer gave for exactly this first_hand (first_hand.confirmation). It works once, for ten minutes, for those claims in that text |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| kind | No | ||
| next | Yes | ||
| note | No | ||
| error | No | ||
| items | Yes | ||
| ready | Yes | Every item passed on this exact text | |
| stage | No | ||
| steps | No | Where the draft is, step by step (the same steps the progress notifications name): done, active (under way now), pending or failed | |
| status | Yes | confirmation_required: check_draft was sent first_hand and waits on the engineer (first_hand); nothing was checked | |
| failing | Yes | ||
| missing | No | ||
| check_id | Yes | ||
| post_type | No | The post type the draft carries (postType in its frontmatter; story when it has none). Not for a case study | |
| first_hand | No | The question to ask the engineer about first_hand (or first_hand_all), and its one-time confirmation | |
| next_action | Yes | The one next step. Do what instruction says; call is the tool and the arguments the server already knows | |
| rewrite_plan | No | ||
| could_not_run | Yes | ||
| fact_check_scope | No | Only on a revision of a live post (revise_post): what the fact-check covered. scoped true: it read only the new or changed sentences; every sentence unchanged from the published post is verified, and so is every changed sentence whose facts the live post already states (carried_facts), so never ask the engineer to confirm or source one again (first_hand_to_confirm lists only what is new or changed in substance). scoped false: the published version couldn't be loaded (why), so every sentence was checked. Say note to the engineer as it is | |
| first_hand_recorded | No | The first-hand claims the engineer confirmed on this call, recorded under their name | |
| first_hand_to_confirm | No | First-hand claims only the engineer can source: ask them to confirm each (first_hand), never confirm one yourself |