Claude Code SEO agent: Build a draft-only workflow

The demonstration's skill search passed all 20 original requests, then missed a fresh one about decaf beans. A Claude Code SEO workflow can prepare work without publishing it, but its routing and review rules need testing. This tutorial builds the editable rules, skill instructions and task records, then explains what to establish before scheduling an unattended run.

The files above give you a review policy, a skill procedure, memory records and a test contract. They do not create a working search engine, enforce filesystem permissions or install an unattended job. A missing input still needs a person, and prepared work still needs approval.

For someone maintaining articles, the useful outcome is a prepared draft and a clear next action—not another draft for a task already awaiting approval. The demonstration describes a file-based workflow that separates instructions, skills, memory, search and scheduling. Missing inputs are brought back to a person rather than guessed. YouTube link

Set up the Claude Code SEO workspace with Git and article review

Start with one repeated task, not a collection of loosely defined agents. The demonstrated approach begins with a folder under Git, so changes can be inspected and undone. Start with article review: it gives the workflow a concrete input, a reviewable output, and an obvious reason to stop when information is missing.

The underlying second-brain idea moves through capture, organize, distill and express. Here, expressing means preparing work rather than merely storing notes. The agent needs instructions for what to do, task records showing what has happened, and a boundary separating preparation from publication. I would probably inspect changes to those instructions as carefully as changes to a draft: a small rule edit can affect later runs, and Git provides a way to examine and undo it.

The examples below are original plain-text instructions and record templates. They are editable content, not Python implementations, permission settings or undocumented tool configuration.

1. Put draft-only rules in claude.md

   Claude Code reads claude.md for its working instructions. Keep the rules short and focused on decisions that apply to every task, rather than putting the entire article-review procedure here.

   The demonstration distinguishes this file from agents.md, which Codex and Cursor read at session start. It says Claude Code ignores agents.md unless claude.md imports it. If you maintain shared rules, check that connection rather than assuming both files are automatically read. The source also reports guidance to keep Claude Code instructions under 200 lines: these rules are read on every run, while task-specific procedures belong in skills.

   Save these instructions in claude.md to define the review boundary and the response to missing information.

   # Working rules
   
   Draft only. Never publish.
   
   Begin every generated draft with this review label:
   Needs human review
   
   Keep the label until a person approves the draft.
   
   If a required input is missing, stop and ask for it.
   Do not invent a target keyword.
   
   During the preparation pass, edit only drafts and task state.
   Leave tasks already awaiting human review alone.

   The label here is an editorial convention chosen for this example. It makes pending work visible, but it is not an access restriction. The workflow also needs an execution boundary, addressed below.

2. Write one skill with explicit inputs

   A skill in the demonstration is a folder containing skill.md, with a name, description and procedure. Its description should explain both the work and when to select it, using language a requester would actually type.

   The demonstration uses six skills: article review, schema, keywords, internal links, meta descriptions and content briefs. At the start, the assistant reads each skill's name and description; the remaining instructions load when needed. That makes the description part of task routing, not decorative documentation. Ask a colleague to select the skill using only its description before expanding the procedure.

   Put this plain-text procedure in the article-review skill's skill.md; it defines the task content without inventing tool-specific metadata.

   # Article review
   
   Description:
   Review an article draft against its target keyword.
   Use when a writer asks for an article review or has
   provided a new version that needs review.
   
   Required inputs:
   - The current article draft
   - The target keyword
   
   Procedure:
   1. Check that both required inputs are present.
   2. If either input is missing, stop and ask for it.
   3. Prepare a review draft for a person to approve.
   4. Begin the draft with: Needs human review
   5. Record what was drafted and the exact next step.
   6. Never publish the review or the article.

   Notice the distinction between selecting a skill and executing it. A request may clearly belong to article review while still lacking the keyword needed to proceed. Selecting the right skill does not give the agent permission to fill that gap itself.

3. Keep decisions, progress and corrections separate

   The demonstrated memory has three parts: decisions, task state and a feedback inbox. They answer different questions. A decision records authority, task state records progress, and feedback records a correction that should influence later work.

   Use this template for a decision record, retaining the date, decision-maker and place where the decision can be checked.

   Decision date:
   Decided by:
   Decision:
   Where to verify:

   Use this task record to make completed work and the next action explicit.

   Task:
   Gathered:
   Drafted:
   Delivered:
   Waiting for human review:
   Missing required inputs:
   Exact next step:

   Use this feedback record to connect a correction to the work it applies to.

   Correction:
   Applies to:
   Check to perform before the next review:

   These records should not collapse into a general notes file. For example, a task waiting for approval should remain distinguishable from a task that cannot start because its target keyword is missing. The morning run handles those cases differently.

   The source's feedback example is a schema draft broken by a trailing comma. The correction becomes a check that runs before a person receives the file, rather than remaining an isolated note about a previous mistake. I would probably review each correction for that same opportunity: specify what it applies to, translate it into a repeatable check where possible, and verify that the check catches the original failure.

With a small skill collection, the source says a list is sufficient; keep that simpler arrangement for manual work.

Test skill search against unfamiliar requests

A description that matches its author's test phrases can still miss ordinary language. The demonstration uses a small Python script, built with the standard library, to score skills against a request and return the top five. Its lesson is about testing the descriptions, not assuming retrieval works because the script runs.

The reason to add search is scale: the source contrasts a manageable list of six skills with a collection of 60 that takes up room needed for the actual work. Returning five candidates narrows that list. It does not prove the first candidate is correct, which is why the evaluation separately checks first place and inclusion in the top three.

The demonstration reports the following results; they are local retrieval tests, not an independent benchmark.

The missed request asked what people were typing into Google about decaf beans. The keyword skill's description did not include that way of expressing the task. Adding the wording fixed the demonstrated miss, but those requests had then become examples used to tune the system.

I would keep newly collected requests separate from the examples used to edit descriptions. Once a failed request teaches you what to change, use different wording for the next evaluation. Otherwise, a better score may show only that the description now matches familiar examples.

Keep a plain-text test record like this, then record the actual result from your search implementation.

Request:
What are people typing into Google about decaf beans?

Expected skill:
Keywords

Actual selected skills:

Was the expected skill in the top three?

Description changed after this test?

Fresh request needed for the next evaluation?

Also test requests that should select nothing. The demonstration includes unrelated requests and checks that no skill fits. For a Claude Code SEO workflow, refusing an unrelated task is part of correct routing—not an error to hide by always returning something.

One demonstrated negative case concerns the office Wi-Fi password. I would probably run such unrelated requests alongside the SEO requests after a description change. The check is not just whether the decaf request now finds keywords, but whether unrelated work still stays outside the skill collection. Record both outcomes before treating the change as an improvement.

Prepare a restartable morning run

The morning process should record progress before handing off more work. The demonstrated run proceeds through inventory, selection, preparation and a briefing. It records stage completion and demonstrates resuming after a deliberate interruption following task selection.

I'd establish that restart behaviour before adding a schedule. An unattended run is much less useful if repeating it means selecting work again without knowing what already happened.

1. Inventory the tasks. Read what has been gathered, drafted and delivered, along with missing inputs and review status.

2. Select work that can proceed. The demonstration prioritizes an article with a new version, leaves an existing review awaiting approval alone, and separates a task missing its target keyword.

3. Prepare only the permitted drafts and state changes. The demonstrated agent pass restricts editing to those areas and caps both turns and spending.

4. Write a briefing that names the starting task, the work already waiting on a person, and the inputs that still need attention.

For a worked example, use the source's espresso guide. The writer has posted a new version, so the run selects it for preparation. A separate review is already waiting on a person and remains untouched. Another task lacks its target keyword and goes into the briefing as needing human input. I would probably compare the records before and after the run: the selected task should show its progress, the pending review should remain unchanged, and the incomplete task should still identify the missing keyword rather than contain an invented one.

Use this record to make stage completion inspectable rather than relying on a final message alone.

Morning run

Inventory completed:
Selection completed:
Preparation completed:
Briefing completed:

Selected task:
Existing review left unchanged:
Missing input requiring a person:
Exact next step after interruption:

Before relying on unattended execution, repeat the demonstrated interruption test: stop after selection, restart, and inspect whether the workflow continues from recorded progress. The exact implementation is not supplied here, so this is a behaviour to verify, not a guarantee provided by the template.

Plain-text rules do not enforce agent permissions

Draft-only instructions are not the whole safety boundary. The demonstration warns about combining private information, untrusted content and a route for sending information out: malicious content can then induce an agent to leak data. Its advice includes reviewing skills before installing them and keeping approval with a person.

The restricted preparation pass therefore matters separately from the wording in claude.md. Limit what the agent may edit, set turn and spending caps, and verify that the chosen invocation actually loads the rules and skills. Do not assume the presence of an instruction file proves that a particular run used it.

In particular, the source warns against adding the bare flag to this pass because it skips the instruction files and skills the workflow depends on. A visible review label cannot compensate for instructions that were never loaded. I would probably make that verification part of the manual trial, before connecting real tools or allowing unattended preparation.

My recommendation is to use the Claude Code SEO setup manually for one recurring task first. Expand it only after unfamiliar requests select the right skill, incomplete tasks stop correctly, and interrupted runs resume from recorded progress. Scheduling should automate a workflow whose boundaries you have checked, not substitute for those checks.

Neither automated selection nor an overnight run removes the need to supply missing inputs, review the prepared work, and decide whether it should be published.