Turn a blog post into an X Article and publish it

Turn SOURCE_URL into an X Article for my connected X account.

Read the full source page. Write a source-faithful X Article with a clear title, section headings, paragraphs, and lists where they help. Keep the original technical claims and useful links. Do not add facts that are not in the source. Save the working draft on the agent's disk.

Before any write, check that X_API_KEY, X_API_SECRET, X_ACCESS_TOKEN, and X_ACCESS_TOKEN_SECRET exist as sealed Environment values. Never print them or ask me to paste them into chat. Verify the account with one signed read request to GET https://api.x.com/2/users/me.

Show me the complete title and body. Then ask for explicit approval to make exactly two X API writes: create one Article draft with POST /2/articles/draft, then publish that returned article ID with POST /2/articles/{article_id}/publish.

After I approve, convert the article into a locally validated payload. Put each paragraph in its own block. For this run, use only unstyled, header-two, ordered-list-item, and unordered-list-item blocks. Do not use header-three. Make one draft request. If it fails, stop and show the status and safe error message without printing credentials or retrying blindly. If the draft succeeds, publish it once and return the public X URL.

Why does the draft stay local at first?

Creating an X Article draft is already an external write. It can incur API usage and put content into the publishing account, even though readers cannot see it yet. The agent therefore writes the first draft to its own disk and shows it in chat. You can change the argument, title, or tone without touching X.

The approval should name both operations. Approving "publish this" is less clear than approving one draft request followed by one publish request. If the draft call fails, the agent stops before the publish call because it has no valid article ID.

What went wrong in the first attempt?

The source article used third-level headings. Our first X payload represented those as header-three blocks, and the draft endpoint returned HTTP 503. We did not keep sending the same request.

The agent rebuilt the payload with one block per paragraph and a smaller set of block types: unstyled, header-two, ordered-list-item, and unordered-list-item. The revised payload had 91 blocks and was 12,647 bytes. It passed local schema checks, then the draft and publish calls succeeded in one pass.

That is a result from this run, not a promise about every X Article payload. X can change the endpoint or accepted schema. Keep the local validation and stop-on-error rule in the prompt so a provider change produces one useful failure instead of repeated writes.

How do you test it safely?

1. Let the agent fetch the source and show the complete article. This part does not write to X.
2. Check the title, factual claims, links, and account named in the approval request.
3. Confirm that the four credentials live in sealed Environment values. They should not appear in the transcript or a saved script.
4. Let the agent run the signed GET /2/users/me check. Confirm that it found the intended account.
5. Inspect the local payload summary and validation result.
6. Approve one draft request and one publish request.
7. Open the returned public URL in a signed-out browser and read the title, headings, lists, and final paragraphs.

The signed read catches bad keys and the wrong account before a write. It cannot prove that the app has enough balance or that the Article endpoints will accept the payload. Only the approved calls prove those parts.

What do common errors mean?

• A 401 on the account check usually means one of the four values is wrong or comes from another app.
• A 403 on a write can mean the user token was minted before the app had write permission. Set the app to Read and Write, then regenerate the user token and secret.
• A 402 on a write means the X developer account needs API credit. Changing the OAuth signer will not fix the balance.
• A 5xx response is a provider-side failure or a payload X could not process cleanly. Stop, inspect the safe error, and revise once before asking for another write approval.

What are the limits?

Plori does not have a one-click X connection today. You bring an X developer app and keep its four OAuth 1.0a values in the agent's sealed Environment. The example also assumes you have the right to adapt the source and that the publishing account can use X Articles.

This process publishes one reviewed article. It does not schedule a queue, select images, or keep a blog and X synchronized after publication. Add those jobs only after the basic draft, approval, and publish path works for your account.