Use this skill when you need to coordinate the full WhatsApp-to-Medium article workflow: trigger daily topic research, resolve shortlist selections, generate drafts, wait for explicit approval, and publish approved articles. Trigger on cron runs, topic-selection replies, draft-approval replies, or requests to start the content pipeline.
Use this skill when you need to coordinate the full WhatsApp-to-Medium article workflow: trigger daily topic research, resolve shortlist selections, generate drafts, wait for explicit approval, and publish approved articles. Trigger on cron runs, topic-selection replies, draft-approval replies, or requests to start the content pipeline.
Tech Medium Pipeline
This is the main orchestrator skill for the entire Medium content workflow. It coordinates discovery, topic selection, drafting, approval, and publication while preserving conversation state across WhatsApp messages.
When to Use This Skill
Use this skill when:
the user wants the full Medium workflow rather than a single subtask
a cron trigger should start the daily research cycle
an incoming WhatsApp reply must be interpreted as topic selection, edit intent, or publish approval
shared state must be advanced to the next valid stage
Do not use this skill when the user explicitly wants only isolated research, only drafting, or only publication and no orchestration is required.
Mission
Manage the full lifecycle of a tech article:
discover timely topics
send the shortlist to the user
resolve the user's selected topic
draft the article
wait for explicit publishing approval
publish to Medium
send the live URL back to the user
This skill should feel like one coherent assistant, even though it delegates to specialized skills internally.
Internal Skills
Delegate to these skills whenever the corresponding stage is reached:
tech-news-researcher
medium-article-drafter
medium-browser-publisher
Do not duplicate their core work unless invocation is impossible. Orchestration belongs here; specialized execution belongs in the worker skills.
Defaults and Gotchas
Default to reading shared state before interpreting the latest user message.
Default to advancing exactly one workflow stage per invocation unless a worker skill completes synchronously and hands back the next state.
Never treat ambiguous acknowledgements like ok or looks good as publish approval.
Never let a fresh cron run overwrite an active draft awaiting approval unless the user explicitly wants a reset.
Operating Model
Treat WhatsApp as the primary user interface and shared memory as the source of truth for pipeline state.
On the very first invocation the tech-medium-pipeline namespace will not exist in memory. Before reading any state, check whether conversation_state is present in the namespace.
If it is missing or empty, initialise the namespace with a clean baseline:
After writing this baseline, continue with normal trigger handling as if the phase is idle.
Do not re-initialise if the namespace already contains a valid conversation_state. Only overwrite if the key is absent or the phase field is missing entirely.
State Machine
idle
No active cycle is underway.
Allowed next actions:
start fresh research
show the latest shortlist if it still exists and the user asks for it
awaiting_topic_selection
The shortlist has been sent and the pipeline is waiting for the user to choose a topic.
Allowed user inputs:
numeric selection such as 1, 4, or topic 2
fuzzy selection such as the second one
topic-name selection such as do the local llm one
a request to refresh or regenerate the shortlist
drafting
The selected topic is being researched and drafted.
While in this state:
avoid parallel draft attempts for the same conversation
complete the draft before switching stages
awaiting_publish_confirmation
The user has received the draft and the system is waiting for explicit publish approval.
Treat these as positive publish intents:
yes
publish
post
approve
approved
go ahead
ship it
post it
Treat these as non-publish responses:
edit requests
revision requests
questions about the draft
vague acknowledgements like ok when intent is not explicit
When intent is ambiguous, ask a short confirmation question instead of publishing.
publishing
The browser publisher is actively posting to Medium. Avoid duplicate publish attempts unless recovery is clearly needed.
published
The story is live. The user can ask for the URL, request a new cycle, or ask for a follow-up article.
Trigger Handling
Cron Trigger
When triggered by cron:
set state to idle if no active publish-critical stage exists
invoke tech-news-researcher
save the refreshed shortlist
set state to awaiting_topic_selection
send the shortlist over WhatsApp
Do not auto-draft or auto-publish from cron alone.
User Trigger: New Research Request
If the user says anything equivalent to:
find topics
research today's topics
what should I write about
give me options
Invoke tech-news-researcher and send a fresh shortlist.
User Trigger: Topic Selection
If the system is waiting for a topic and the user responds with a valid selection:
resolve the selected topic against latest_shortlist
store the resolved topic in selected_topic
set state to drafting
invoke medium-article-drafter
set state to awaiting_publish_confirmation
send the draft over WhatsApp
User Trigger: Publish Approval
If the system is waiting for approval and the user sends an approval phrase:
verify a draft exists
set state to publishing
invoke medium-browser-publisher
save the publication result
set state to published
send the live URL over WhatsApp
Input Resolution Rules
Numeric Selection Resolution
When the user sends a number:
parse integers conservatively
resolve the topic whose stored number exactly matches the user's selected number
reject out-of-range values and ask the user to choose a valid topic
Topic Name Resolution
When the user sends a topic phrase:
compare it against shortlist headlines and angles
prefer exact or near-exact matches
if two entries are plausible, ask a disambiguation question
Approval Resolution
Only publish when the approval is clearly affirmative and clearly refers to the current draft. If the user asks a question and says yes in the same message, interpret the overall intent before acting.
WhatsApp Messaging Rules
Every outbound message should be optimized for chat:
short introduction
clear action or outcome
no internal state dumps
no raw JSON
Message patterns:
shortlist message: numbered topics plus selection instruction
draft message: full Markdown article plus explicit publish instruction
publish message: title plus live URL plus short confirmation
error message: brief explanation plus next step
Recovery Rules
If the user selects a topic before a shortlist exists, either regenerate one or ask whether to research the named topic directly.
If the draft is missing at publish time, do not publish. Rebuild or ask the user to pick a topic again.
If publication fails after the browser opens, preserve state and report whether the issue is login, UI, content insertion, or final publish confirmation.
If a new cron run arrives while waiting for publish approval on an existing draft, do not overwrite the active cycle unless the user explicitly wants a new one.
Concurrency and Safety Rules
Never run two publish attempts for the same draft at once.
Never publish from an old approval if a newer draft has replaced the active one.
Never overwrite the active shortlist during an in-progress drafting or publishing stage unless the user requests a refresh.
Never discard prior memory silently; update it deliberately.
Editorial Rules
The pipeline should bias toward:
timely but technically meaningful stories
clear builder relevance
concrete implications rather than vague trend talk
strong articles over fast articles
The pipeline should avoid:
duplicate article cycles for the same story unless the angle changed materially
publication without approval
shallow output produced only to keep the flow moving
Completion Checklist
Before ending any invocation:
Determine the current phase from shared memory.
Interpret the incoming trigger correctly.
Execute only the next valid stage in the workflow.
Update shared memory to reflect the new state.
Send the correct WhatsApp response for that stage.
Leave the pipeline in a recoverable state if any downstream step fails.
