Submit a draft
submit_draftIdempotent
Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). File a post (or, with kind "case-study", a case study) under the engineer's byline, exactly as written: the site builds its preview and emails it to them. Send the whole Markdown with frontmatter (title and description at least), the engineer's own words as sources, and brief_id when it comes from get_brief, or from_idea when it continues an idea they emailed. Lint it clean first. Returns the draft's id and text_hash; next, check_draft with the id. Never publishes.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| title | Yes | The post's working title | |
| 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. | |
| brief_id | No | The brief_id get_brief returned, when the post is from today's brief: it marks the brief done | |
| markdown | Yes | The whole post, with its frontmatter (title, description at least): it becomes the draft as sent | |
| from_idea | No | The id of an idea the engineer emailed that is waiting for their own agent (get_status says so): the post continues it, and that idea is closed in its favour | |
| post_type | No | 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. | |
| from_idea_notes | No | With from_idea: the author_notes_hash get_status returned for it, so an email they sent since is never closed unread | |
| 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. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The draft's id: every other draft tool takes it | |
| kind | No | ||
| next | Yes | ||
| state | Yes | ||
| 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 | No | ||
| duplicate | No | ||
| from_idea | No | With from_idea: the emailed idea this continues, and whether it was closed in its favour (if not, note says what to do) | |
| post_type | No | The post type the draft carries (postType in its frontmatter; story when it has none). Not for a case study | |
| text_hash | No | The submitted text's sha256. Filing adds author, date and draft to the frontmatter, so the first update_draft takes draft.base_hash from get_status | |
| first_hand | No | When first_hand was sent: nothing is recorded here. The engineer is asked on check_draft with the id (in their client, where it can ask them), or, for update_draft in a client that can't, this carries the question and a one-time confirmation to hand back on check_draft only after they say yes | |
| editor_link | No | ||
| next_action | Yes | The one next step. Do what instruction says; call is the tool and the arguments the server already knows | |
| preview_url | No |