V1 Automation Plan

V1 Automation Plan

Historical plan. The Discord capture and GitHub review queue described below were retired from this repo on 2026-09-27. The social-drafting skill remains; references to the former fetch script describe the old prototype.

1. Current State

Today, Volume and Velocity already has two important ingredients:

  • a Discord fetch script at volume-and-velocity/discord-inbox/fetch.py
  • an AI polishing skill at volume-and-velocity/skills/fast-social-orchestrator/SKILL.md

This has now moved beyond abstract planning into early workflow testing.

What works today:

  • we can fetch raw updates from #whats-cooking
  • we can turn rough notes into social drafts
  • we already have context, vision, motivation, and channel guidance in place
  • we have run real prototypes from Discord update -> brief -> draft options
  • we have a dedicated prototypes/ folder for concrete workflow tests
  • we now have a stronger strategic context layer in volume-and-velocity/context/strategic-priority-and-reader-pain.md
  • we now have a lightweight GitHub-native review flow using GitHub Issues
  • we have validated that one real DataHub update can be turned into a reviewable LinkedIn post candidate with minimal friction

What does not work well enough today:

  • the flow still depends on manual handoffs
  • many source updates are too short to reliably generate strong posts without enrichment
  • publishing is not yet integrated
  • the review process is only lightly tested on one example
  • we still need to test this on more products and thinner source updates

2. Goal

The v1 goal is:

  • AI scans #whats-cooking
  • AI identifies updates worth turning into public content
  • AI drafts strong posts for X, LinkedIn, and Instagram/Facebook
  • marketing reviews and approves
  • approved posts publish automatically

The intended operating model is that marketing is no longer acting as the main writer and coordinator for social posts. Instead, marketing should behave more like an editor:

  • review
  • approve or reject
  • make small edits only when needed

The system should increase both volume and frequency of publishing while reducing the effort required from the marketing person.

3. Why The Current Setup Is Not Enough

The biggest problem is friction.

If posting internally in #whats-cooking becomes too demanding, people will not share enough useful updates. But if updates are too thin, the AI will often generate generic or low-value posts. That is the core design tension:

  • lower friction enough that team members actually post updates
  • preserve enough signal that AI can generate thoughtful, informative, engaging content from them

The current setup does not yet solve that tension well enough.

More specifically:

  • the fetch step and the drafting step are separate
  • there is no explicit process for deciding whether an update has enough substance
  • there is no explicit process for enriching weak but promising updates
  • the default drafting flow can still produce generic output when the source is thin
  • there is still no direct path from approval to publishing

So the next phase should not be about adding complexity to internal posting. It should be about making the downstream system better at handling lightweight internal updates.

4. V1 Operating Model

Scope for v1:

  • source: #whats-cooking only
  • channels: X, LinkedIn, Instagram/Facebook
  • approval: human approval required for every post

Principles:

  • internal sharing should stay lightweight
  • the system should do the heavy lifting after the update is posted
  • the default should be ready-to-publish drafts with almost no edits
  • posts should be informative and engaging
  • posts should fit into a broader strategic narrative for each product

The working flow for v1 should be:

  1. A team member drops a lightweight update in #whats-cooking.
  2. The system captures the update.
  3. The system evaluates whether the update is directly usable or needs more context.
  4. If needed, the system enriches it using whatever context is already available nearby.
  5. The system drafts channel-specific posts.
  6. The drafts enter a review queue.
  7. Marketing approves or rejects.
  8. Approved posts publish automatically.

The key design choice here is that the burden should sit on the system, not on the person posting the original update.

For now, GitHub Issues is the best review queue.

Why GitHub Issues is the right fit at this stage:

  • it is already part of the team's workflow
  • it avoids introducing another tool too early
  • it is easy to comment on, iterate in, assign, and close
  • it is good enough for review and approval without setup overhead
  • it keeps drafts, discussion, and iteration close to the repo context

For v1, one GitHub issue should represent one post opportunity derived from one internal update.

The issue should contain:

  • one Discord source URL
  • 2-3 draft options
  • one option marked (Recommended)
  • available visual assets

The issue should not try to be a full knowledge base.

Comments should be used for:

  • feedback
  • approval discussion
  • edit requests

Labels, assignees, and open/closed state should handle workflow state.

This keeps the review burden small: marketing should mostly be scanning, comparing options, commenting, and deciding whether a post should move forward.

6. Content Strategy Layer

The system should not just turn internal updates into standalone announcements.

It should turn them into posts that reinforce the broader story each product is trying to tell.

That means every post candidate should be framed through two lenses:

  • what happened
  • why this matters in the broader strategic line for this product

Examples:

  • a DataHub update should usually reinforce themes like better data publishing, better discoverability, better usability, stronger datasets, or better ways to work with public data
  • a Flowershow update should usually reinforce themes like easier publishing, markdown-native workflows, AI-friendly publishing, or publishing freedom
  • a PortalJS or Queryless update should usually reinforce themes like discoverability, easier data access, better portal UX, or practical data infrastructure

This strategy layer matters because otherwise the system will create lots of disconnected posts without building a coherent product narrative over time.

For v1, the system does not need a perfect strategy engine. But it does need enough guidance to avoid random, contextless posting.

7. Low-Friction Input Philosophy

The system should treat a Discord update as a trigger, not as the full brief.

This is important because the workflow will fail if internal contribution becomes too demanding. People should be able to post quick updates in #whats-cooking without needing to think about templates, metadata, or writing mini marketing briefs.

That means the burden should not sit on the person posting the update. The burden should sit on the system.

The system should assume that many useful updates will be sparse, for example:

  • a short sentence and a link
  • a screenshot and a few words
  • a video link with almost no explanation

Those updates should still be usable if the system can gather enough surrounding context.

For v1, the intended approach should be:

  • keep the input format lightweight
  • use the Discord message as the starting point
  • enrich it automatically with broader product context and nearby signals
  • draft only after the system has assembled enough context to produce a valuable post

The main context sources should be:

  • the original Discord message
  • thread replies and nearby discussion
  • the linked page or asset
  • reusable product context already present in the repo
  • the current strategic line for the product
  • recent related updates for that same product

In practice, this means a short update like "new demo here" plus a link should not be treated as too weak by default. It should first be interpreted in the broader context of:

  • what this product is
  • what the team is currently trying to communicate
  • what has recently shipped
  • why this update might matter now

This is the core design principle:

  • do not require rich internal inputs
  • build a stronger downstream context and enrichment layer instead

If the system does this well, internal sharing stays easy while public output becomes more thoughtful and strategic.

8. Next Implementation Steps

These next steps are ordered for speed and practical value.

Step 1: Repeat the prototype on more real updates

This has now been done once successfully for DataHub.

The next step is to repeat it on:

  • a thinner DataHub update
  • a second product such as Queryless, PortalJS, Flowershow, or AutoClaw

The purpose is to see whether the workflow generalizes.

Step 2: Define what makes a lightweight update still usable

We should not impose a heavy posting template on the team.

Instead, define a soft minimum for useful updates. For example, a good lightweight update usually contains at least one or two of:

  • what changed
  • a link
  • an image or video
  • one useful concrete detail
  • a short why-it-matters clue

This is important because the answer is not "force people to write better internal briefs." The answer is "teach the system to get more from low-friction updates."

Step 3: Keep strengthening the brief and context layer

This has already improved output quality once.

The strongest observed improvement so far came from:

  • adding Current strategic priority
  • adding Reader pain
  • adding Core message
  • adding Client outcome

Next step:

  • keep using volume-and-velocity/context/strategic-priority-and-reader-pain.md
  • test whether those fields consistently improve outputs across products

Step 4: Design the enrichment step

When an update is thin but promising, the system should try to enrich it before drafting.

Possible enrichment sources:

  • Discord thread replies
  • links shared in the update
  • page titles
  • attachment names
  • embeds
  • nearby product context already stored in the repo

The system should only ask for extra human input when the update is too thin to support a worthwhile post.

Step 5: Keep tightening drafting for quality, not just speed

The drafting flow should be optimized for:

  • clear
  • informative
  • engaging
  • ready to publish

That means the next version of the workflow should be better at:

  • choosing one strong angle
  • making the value legible quickly
  • avoiding generic product marketing language
  • drafting conservatively when confidence is low

Step 6: Use the GitHub review flow in practice

This is now set up.

Next step:

  • open real review issues for marketing
  • gather feedback in comments
  • see whether the issue format is light enough to be used repeatedly

Step 7: Add approval-based publishing automation

Only after the queue and review flow work should approved items auto-publish.

For v1:

  • every item requires approval
  • approval triggers publishing to the selected channels
  • publishing results should be written back to the queue

Step 8: Validate on real #whats-cooking traffic

The system should be tested on real internal updates, not just polished examples.

The main questions are:

  • does it produce publishable drafts from typical updates
  • how often does marketing need to edit heavily
  • what kinds of updates are too weak
  • what kinds of updates work especially well

That validation should guide implementation decisions.

9. Open Questions

These questions do not block the vision, but they will matter during implementation:

  • Should every product always get all three channel variants, or should some products skip Instagram/Facebook by default?
  • How should product-account routing work for publishing?
  • What should happen with updates that are genuinely interesting but too thin to support a strong post?
  • How should the system distinguish between "needs context" and "not worth posting"?
  • How should the strategic themes for each product be stored and maintained?

End State For V1

If this works well, the v1 end state should feel like this:

  • team members post lightweight updates in #whats-cooking without much thought or formatting burden
  • AI systems scan those updates and do the hard work of interpretation, enrichment, and drafting
  • marketing opens GitHub issues and sees strong, reviewable post candidates
  • marketing mainly approves, rejects, or makes tiny edits
  • approved posts publish automatically
  • social output becomes more frequent, more systematic, and less dependent on manual effort

That is the intended balance:

  • low friction for internal contribution
  • high leverage from AI downstream
  • minimal burden on the marketing person
  • more consistent public output across products
Edit this page
Built with LogoFlowershow