Build with AI Agents

A dependable publishing agent starts by learning the Cli Blog workflow. It inspects existing content, prepares a complete draft, returns what needs review, waits for approval, and verifies the public result after publication.

This guide shows the conversation from setup to a working blog view. The prompts are examples you can adapt to your agent and project.

Add the Cli Blog skill

Add the Cli Blog agent skill to your agent or project:

npx skills add https://github.com/cli-blog/cli-blog-skill --skill cli-blog

You can review the skill on skills.sh or inspect its GitHub repository. Start the conversation by making the operating boundary explicit:

Read the Cli Blog skill before taking action. Tell me which Cli Blog tool fits this project. Keep new posts as drafts and ask before publishing, scheduling, deleting, or making broad changes.

The agent should confirm that it understands the available surfaces and the approval boundary:

I can use the CLI, Node SDK, or REST API. I will inspect the project and existing blog resources first. I will create drafts without publish permission unless you approve a specific post version.

Use llms.txt or the full documentation Markdown when the agent needs more product context.

Ask the agent to prepare its tools

Let the agent inspect the repository before choosing an installation path:

Inspect this project and prepare the Cli Blog tools it needs. Install the CLI if terminal commands fit the workflow. Use the Node SDK for trusted Node.js code. Use the REST API for another technology. Show me what you chose and why.

A terminal-based agent may propose:

npm install -g @cli-blog/cli
cli-blog --version

Do not paste a private key into the conversation. Store it in the trusted shell, continuous integration secret store, or agent environment. Give the key only the resource actions required by this workflow.

Inspect drafts before creating content

Ask the agent to read the current state without changing it:

List the current en-US draft posts. Return the title, slug, status, version, authors, categories, tags, and last update time. Also list reusable authors and categories. Do not create or update anything.

The response should be concise and reviewable:

I found three drafts. “July launch notes” already uses the requested slug at version 4. Maya Chen and the Product category already exist. The Release notes tag is missing. No changes made.

This inspection prevents duplicate posts, slugs, authors, categories, tags, and media.

Ask for a complete draft

Give the agent approved source material and acceptance criteria. Name the intended result instead of asking for “a post” without context:

Create an en-US draft from the approved July release notes in ./release-notes.md. Reuse Maya Chen and the Product category. Create the Release notes tag if it is still missing. Add a title, slug, excerpt, Markdown body, SEO title, SEO description, and useful image alt text. Return a review packet and do not publish.

The agent can use the CLI, SDK, or API under the hood. What matters is the returned result:

{
  "id": "post_2f51de",
  "slug": "july-release-notes",
  "status": "draft",
  "version": 5,
  "author": "Maya Chen",
  "category": "Product",
  "tags": ["Release notes"],
  "checks": {
    "source_claims_verified": true,
    "links_checked": true,
    "alt_text_present": true,
    "seo_fields_present": true
  },
  "review_notes": ["Confirm the release date in the introduction."]
}

Treat missing facts as review notes. The agent should not invent a date, customer quote, performance number, or product claim to make the draft look complete.

Review the draft in conversation

You can ask focused questions before changing the post:

Show me the title, excerpt, section outline, links, SEO fields, and unresolved claims for post_2f51de. Do not update it yet.

Then request a bounded revision:

Update only the introduction and SEO description using the approved release date of July 21. Keep the slug, author, category, tags, and image unchanged. Return the new version and a before-and-after summary. Do not publish.

You can also review the same draft in the dashboard. The agent and dashboard use the same post ID and version.

Publish a specific version

Approval should name the post and version. This prevents the agent from publishing changes you did not review:

Publish post_2f51de only if its current version is 6. Stop if the version changed. After publication, verify the public slug through the delivery API and return the result.

The agent should stop on a version conflict:

The post is now version 7, so I did not publish it. Review the newer draft or approve version 7 explicitly.

After a successful publication, expect a verification result:

Published post_2f51de at version 6. Public delivery returned status 200 for /v1/posts/july-release-notes?locale=en-US. The response status is published, and the author, category, tags, content, and SEO fields are present.

Use a separate approval for scheduling, deletion, or broad updates. Approval to draft does not imply approval for any public change.

Ask the agent to create the blog view

Build the frontend only after delivery works. Ask the agent to inspect your framework and reuse its routing and design system:

The published delivery request now works. Inspect this frontend and add a blog index that reads published post summaries with a public Cli Blog key. Reuse the existing layout and components. Keep private publishing keys out of browser code, and show me the files you plan to change before editing.

For React, the delivered component may start with a small public read:

import { useEffect, useState } from "react";

export function BlogIndex() {
  const [posts, setPosts] = useState<Array<{ id: string; title: string }>>([]);

  useEffect(() => {
    fetch("https://api.cli-blog.com/v1/posts?status=published&fields=summary", {
      headers: { "x-api-key": import.meta.env.PUBLIC_CLI_BLOG_KEY },
    })
      .then((response) => response.json())
      .then((result) => setPosts(result.data));
  }, []);

  return posts.map((post) => <article key={post.id}>{post.title}</article>);
}

Use the matching guide from the documentation navigation. The Next.js guide shows the full routing, rendering, caching, metadata, and Markdown pattern.

Reuse the workflow for other jobs

The same conversation pattern supports recurring publishing work:

• Editorial refresh: inspect the current version, make a focused update, return a diff, and wait for approval
• Release notes: read an approved changelog, create a dated draft, attach existing resources, then schedule a reviewed version
• Localization: retrieve the source post, create a linked translation, and route the draft to a fluent reviewer
• Content inventory: traverse posts with cursor pagination, report missing authors, alt text, or SEO fields, and wait before bulk changes
• Programmatic pages: create a bounded batch from approved structured data, return failures and IDs, and publish only the reviewed set

Keep the agent boundary explicit

• Give each workflow its own narrowly scoped private key
• Keep private values in the trusted environment, not prompts or generated files
• Ask the agent to inspect before creating resources
• Create drafts before public changes
• Require a post ID and expected_version for publication
• Require separate approval for publish, schedule, delete, and bulk update actions
• Ask the agent to return assumptions, unresolved checks, IDs, slugs, status, locale, and version
• Verify the public delivery request after publication