Lint a draft
lint_draftRead-onlyIdempotent
Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). The site's rule-based checks (slop, claims, known errors, voice, opening, title, description, FAQ, diagram, images, links, a case study's rules) on a post's Markdown, frontmatter included: about a second, free, filing nothing. Iterate with this, never with check_draft: rewrite each passage in rewrite_plan as its fix says and lint again until ready, then review the draft against the judge_rubric it returns. With id, it lints a draft of yours: its saved text, or the markdown you send as an edit to it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A draft of yours (the id submit_draft returned). Alone: lints its saved text. With markdown: lints that edit as this draft (its kind, slug, images and sources) before you save it | |
| 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 |
| slug | No | The draft's slug, when it has one already (get_status draft.slug); otherwise it comes from the title | |
| images | No | The images the post refers to by name (names only; no data needed) | |
| rubric | No | Also return judge_rubric while checks still fail (it comes anyway once they pass) | |
| 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 | |
| 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. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| kind | No | ||
| mode | No | The writing partner's edit mode (editorial/voices-of-techfabric.md): show the redlines, change only what the engineer accepts | |
| next | Yes | ||
| todo | No | The findings as the engineer's to-do list (the draft app's cards): each card's where, why in plain words and remedies | |
| items | Yes | ||
| ready | Yes | Every rule-based check passes on this text | |
| route | No | ||
| saved | No | ||
| voice | No | How every sentence is said (editorial/voices-of-techfabric.md, "Before you write a sentence"): follow it in the outline, the draft and every rewrite. | |
| failing | Yes | ||
| redlines | No | rewrite_plan as a redline for the engineer: each passage with its rule, reason, suggestion, state and options. The engineer decides; never hand back a rewritten post | |
| 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 | Yes | ||
| next_action | Yes | The one next step. Do what instruction says; call is the tool and the arguments the server already knows | |
| judge_rubric | No | What the model-read checks will ask of this draft: sent once the rule-based checks pass, or with rubric: true | |
| redline_plan | No | With id: what to propose with propose_edits, card by card (find, the limit), or what the engineer answers (confirm, ask_author) | |
| rewrite_plan | Yes | ||
| edit_instruction | No | How to show the redlines (edit mode) | |
| judge_rubric_note | No |