Daniel J. Dick

Disclosure: This page contains affiliate links. If you purchase through them, we may earn a commission at no extra cost to you.

Why I’m Writing This

My script-based AI ghostwriter system has grown from a personal experiment into a

serious tool I rely on for multiple websites. It can:

• Capture a site’s purpose, tone, and goals in configuration.
• Generate drafts via LLMs.
• Review and score drafts for quality.
• Create rewrite drafts and queue them for improvement.
• Upload content to WordPress as safe drafts.

This is now approaching the point where I can responsibly offer consulting to

others. Before I do that, I want to be clear about a few things:

1. How to tell when an article is truly “published” and ready to promote.

2. How to handle social media and newsletter notifications around publication.

3. How to capture a safe snapshot of the current system for consulting use.

4. When it makes sense to start accepting consulting clients.

5. How to make sure I don’t miss new leads and can respond quickly.

This article is my own reference and a potential behind-the-scenes look for

future clients.

1. When Is an Article Really “Published”?

There are three distinct stages in the content lifecycle:

1. Draft created – The ghostwriter and I produce a draft in `clients//content/`.

2. Published on site – An editor (often me) finishes editing in the CMS and

changes status to `publish`, or schedules a post for a specific time.

3. Promoted – I send out newsletter and social media notices.

Right now, my tools handle (1) and (part of) (2). For consulting clients, I

need a clear source of truth for “this article is live”.

For WordPress, that lives in the REST API:

• `status = publish` and
• a `date` / `date_gmt` field set to a time in the past or at least not in the future

Longer term, I have two options:

Option A: Treat CMS publish status as the trigger

In this model:

• The editor finishes tweaking the article in WordPress.
• They set the post to `publish` (or a scheduled future time).
• A script (or eventually a background service) periodically:

– Fetches posts via `wp-json/wp/v2/posts`.

– Finds posts that are `status=publish` and have not yet been promoted.

– Generates social and newsletter snippets.

– Marks them as “promoted” (either via WP meta or a local log).

The act of setting `status=publish` becomes the trigger for promotion.

Option B: Add a “ready for promotion” flag

Sometimes I might want to publish an article quietly without immediately

promoting it everywhere. In that case:

• The editor sets `status=publish`.
• They also set a custom flag like `ready_for_promotion = true`.
• The promotion script looks only for posts where:

– `status = publish` and

– `ready_for_promotion = true` and

– `promoted = false`.

In the early phases, I may implement this with a local publication log

rather than modifying WP meta. The idea is the same:

• One place that says “this post is live and we haven’t yet told the world”.

2. Publication Logs and Notifications

To avoid guessing or double-notifying, I intend to keep a small publication

log for each site. At minimum it will track:

• `slug` or `post_id`
• `published_at`
• which channels have been notified (site only, newsletter, social)
• timestamps for each notification

With that in place, a promotion script (and eventually a menu option) can:

1. Look for posts that are published in the CMS.

2. Cross-check the publication log for anything not yet notified.

3. Generate social media blurbs and newsletter snippets via the AI.

4. Mark them as notified so I don’t spam people twice.

Early on, I’m comfortable doing the actual posting manually, using the system to

prepare high-quality snippets that I then copy and paste into Mastodon, X,

LinkedIn, or newsletters.

3. Handling the Gap Between Editing and Promotion

There is always some gap between:

• The moment the draft leaves the ghostwriter system, and
• The moment an editor in the CMS says “yes, this is ready to publish”.

I don’t want to send social/newsletter notices until the article on the site

reflects the editor’s final changes.

The two models above (status-based trigger vs. explicit “ready for promotion”

flag) help manage that gap. At small scale, I can:

• Treat `status=publish` as the implicit “ready” flag, and
• Double-check the article visually before copying snippets out to social or

newsletter channels.

As the system matures, especially for consulting clients, I can move toward a

more explicit “ready for promotion” signal in the CMS UI or in a lightweight

internal UI.

4. Taking a Stable Snapshot for Consulting

Because this system is evolving quickly, it is important to have a known-good

baseline I can trust when using it for client work.

My plan is to:

1. Use it heavily across my own sites (like smfree.org, Avoid Epic, and others)

until I’m confident in the flows.

2. Commit all current improvements (including review, rewrite queues, and offer

pages) into version control.

3. Create a tag such as `consulting-baseline-v1` so I can always return to

that state.

4. Optionally create a tarball or Docker image for disaster recovery.

Later, I can document this baseline in a `CONSULTING_BASELINE.md` file that

lists:

• Which menu options are considered stable.
• Which client setups (e.g. `smfree-1`, `avoidepic-1`, `djd-1`) are my reference

implementations.

This gives me a safe foundation I can reuse when I onboard consulting clients.

5. When Am I Ready to Start Offering Consulting?

Perfection is not required; responsible stability is.

I consider myself ready for a small pilot group of consulting clients when:

• I can set up a new `clients/` directory from templates without touching

code.

• I can reliably:

– Generate drafts.

– Review and score drafts.

– Queue rewrites.

– Upload drafts to WordPress.

– Preview and manually correct the few issues that slip through.

• I understand the current rough edges and have a roadmap to improve them.

At that point, it’s reasonable to:

• Publish a modest offer page.
• Start with one to three consulting clients.
• Use their feedback to refine the system and my processes.

I already have a generated offer page at `out/offer-values/index.html`. Once its

copy and links are finalized (Calendly, payments, etc.) and tested, I can link

it from one or more sites as a “Work with me” or “Get consulting” call to

action.

6. Lead Capture: How Will I Know When a Client Contacts Me?

The system side is only half of the consulting story. The other half is not

missing opportunities and responding quickly when someone reaches out.

My basic plan:

1. Dedicated consulting email

– Use an address like `consulting@mydomain` or `daniel@mydomain`.

– Forward it to my main inbox and/or a secondary inbox on my phone so I get

push notifications.

2. Calendly

– Ensure Calendly sends confirmations and reminders to my email.

– Sync Calendly with a calendar that has notifications enabled on my phone.

– Test: book a dummy appointment to confirm I see it right away.

3. Contact form on the offer page

– Include a simple contact form on the `/offer` page.

– Wire it to an email handler (Formspree, Netlify Forms, a small backend) so

submissions land in the consulting inbox.

– Test: send myself a message and verify delivery.

4. Payment notifications

– For now, rely on PayPal/Stripe’s own email notifications.

– Later, I may wire webhooks into a simple tracking system (Notion/Trello

board or a local log) for engagements.

5. Personal SOP (Standard Operating Procedure)

– Check the consulting inbox at least twice per day.

– Aim to respond to any lead within 24 hours (preferably much faster).

– Keep a short discovery checklist handy for first calls so I can quickly

understand the client’s:

– goals,

– current site setup,

– content workflow,

– constraints and timelines.

This doesn’t require heavy tooling. It requires being intentional and

consistent.

7. Social and Newsletter Notifications in the Bigger Picture

Once I have:

• A way to reliably detect when an article is published (via CMS status or an

explicit “ready” flag), and

• A publication log of which posts have already been promoted,

then I can add:

• A script (and corresponding menu option) that:

– Reads new, unpromoted published posts.

– Uses an LLM prompt to generate a handful of:

– Social media blurbs.

– A short newsletter summary.

– Outputs these snippets for manual posting in the early stages.

This is a natural later step; I don’t need it fully automated before I start

consulting. For now, my focus is:

• Getting the generation → review → rewrite → upload loop solid.
• Being confident that I can see and respond to new consulting leads quickly.

8. Summary

In preparing this AI ghostwriter system for consulting work, I’m focusing on a

few priorities:

• Clarity about state – knowing which drafts exist, which posts are

published, and which have been promoted.

• Controlled evolution – capturing a stable baseline (`consulting-baseline`)

even as I continue to improve the tools.

• Small, real-world tests – using the system on my own sites first, then

with a few early clients.

• Reliable lead handling – making sure every Calendly booking, contact form

submission, or payment triggers a clear notification and a timely follow-up.

As the tooling becomes more polished, I’ll be able to move the same capabilities

from this script-based environment into the web UI, making it easier to scale my

service and eventually empower other consultants to offer similar capabilities

to their own clients.

---