Best for
- B2B teams with insights scattered across internal systems
- Content teams producing redundant assets despite abundant source material
- Organizations requiring evidence and claim review before publication
Use governed Slack, HubSpot, and content sources to select original opportunities, create evidence-backed briefs and drafts, check claims and redundancy, route approval, and create restricted WordPress drafts.
A persistent editorial operating system with source governance, opportunity scoring, content inventory, claim-aware drafting, QA, approval history, least-privilege WordPress drafts, publication, and learning.
Quick view
Check the audience, core tools, and access before you start the detailed steps.
Best for
Core tools
4 tools used across the workflow.
Access
Preview the open steps, then unlock the remaining implementation details and prompts.
Why this works
Content operations fail when the team has more signals than editorial judgment and when AI drafting is disconnected from existing content, evidence, and approval. This workflow curates source scope, compares opportunities with the content inventory, and separates read access from restricted WordPress draft creation. Human editors retain priority and publication authority while the workbench preserves source and decision context.
Expected results
Monthly production
12-20 hours saved
Curated signal collection, opportunity scoring, source-cited briefs, QA, and draft creation replace repeated manual research and handoff.
Originality
Create, refresh, merge, or reject decisions
Every opportunity is compared with the existing inventory before production.
Evidence control
Sources and approved claims travel into drafts
Missing proof becomes a visible placeholder or hold instead of fabricated content.
Publishing safety
Restricted draft creation plus human publish
Read connectors and WordPress write scope are separated, with preview, approval, post ID verification, and rollback.
Step-by-step workflow
The first 2 steps are open. Pro unlocks the remaining steps, copy-paste prompts, pro tips, tool-by-tool setup guidance, and implementation details.
60-90 min
60-90 min
Define the workbench’s users, source systems, content types, target audiences, business priorities, editorial authority, and publishing limits. Specify that Claude may discover, recommend, synthesize, draft, and create WordPress drafts, but may not publish without human approval. List prohibited source material, sensitive CRM fields, private Slack channels, and claim classes requiring specialist review. Name the editorial owner and source-system owners. Run this template in the workflow’s persistent Claude Project after attaching or linking the approved source records named for this step. Record the operation against stable identifiers such as signal_id, source_system, source_url, sensitivity, content_inventory_id, preserve the raw source reference and capture time, and write any transformation or decision into the system’s change history rather than replacing the prior value. Use an explicit pass, warning, or hold disposition, attach the supporting evidence IDs, and assign every unresolved exception to an owner and due date before moving to the next step. Write down the decision criteria, owner, required inputs, and what is deliberately out of scope so the rest of the workflow does not drift.
An editorial mandate with source, action, and publication boundaries.
The workbench should not read every available channel or CRM field. Curate sources that produce legitimate editorial evidence.
1-2 hours
1-2 hours
Create project folders or knowledge sections for `00-instructions`, `01-brand-and-audience`, `02-campaign-priorities`, `03-source-register`, `04-opportunity-queue`, `05-content-inventory`, `06-claim-register`, `07-drafts`, `08-approvals`, and `99-archive`. Add naming rules, schemas, source refresh cadence, ownership, and changelog. Keep client or sensitive source packs separate when access differs. Version prompts and editorial rubrics. Within the workspace, maintain `instructions.md`, `field-dictionary.json`, `source-register.csv`, `review-rubric.md`, `approved-examples.md`, and `changelog.md`; name releases `vYYYY.MM` and assign an editorial systems owner and backup. Refresh source exports on the editorial cadence, archive superseded inputs by source ID and date, and review connector permissions, instructions, and maintenance needs quarterly. Run this template in the workflow’s persistent Claude Project after attaching or linking the approved source records named for this step. Use an explicit pass, warning, or hold disposition, attach the supporting evidence IDs, and assign every unresolved exception to an owner and due date before moving to the next step. Ask for a working draft with named sections, assumptions, gaps, and review flags rather than treating the first AI answer as final.
A persistent editorial project with versioned instructions and governed knowledge.
Pro workflow preview
Previewing 2 of 15 steps
Get the remaining 13 steps, copy-paste prompts, pro tips, tool-by-tool setup guidance, and ongoing workflow and prompt releases.
$9/month
ROLE
You are the governed analysis and operations assistant supporting the content operations lead and editorial approver. You are working inside the agentic content workbench from signals to WordPress, where traceability, stable identifiers, and human authority matter more than producing a polished but unsupported answer.
OBJECTIVE
Complete workflow step 1, “Define the editorial workbench mandate and write limits,” and produce this operational outcome: An editorial mandate with source, action, and publication boundaries. The result must be immediately usable by the named operator without inventing records, silently changing approved state, or obscuring uncertainty.
INPUTS
1. SOURCE RECORDS: {{define_the_editorial_workbench_mandate_and_write_source_records}}
2. FIELD DICTIONARY AND ALLOWED VALUES: {{define_the_editorial_workbench_mandate_and_write_field_dictionary}}
3. OPERATING, PERMISSION, AND DECISION RULES: {{define_the_editorial_workbench_mandate_and_write_operating_rules}}
4. APPROVAL CONTEXT, OWNERS, AND DEADLINES: {{define_the_editorial_workbench_mandate_and_write_approval_context}}
5. PRIOR VERSION, SNAPSHOT, OR CURRENT STATE: {{define_the_editorial_workbench_mandate_and_write_prior_version_or_state}}
Authoritative evidence may include approved Slack and HubSpot sources, existing collateral, content inventory, claim evidence, human edits, connector logs, and WordPress revisions.
WORK TO PERFORM
1. Execute the specific job described by “Define the editorial workbench mandate and write limits”; do not broaden the task into a generic strategy exercise.
2. Use the canonical field names and IDs supplied in the inputs, especially signal_id, source_system, source_url, sensitivity, content_inventory_id, opportunity_id.
3. Separate observed facts, operator-entered decisions, calculations, and model inferences so reviewers can trace how each conclusion was produced.
4. Return records that can be copied into the agentic content workbench from signals to WordPress without renaming identifiers or collapsing one-to-many relationships.
5. Follow the approved operating rule for this step and make the next action, owner, review gate, and exception state explicit.
6. Identify duplicates, conflicts, stale records, missing IDs, permission problems, and records that must be held for human resolution.
7. Produce a compact review summary explaining what changed, what did not change, what remains uncertain, and what the operator should do next.
OUTPUT SCHEMA
Return valid JSON only, using this exact top-level structure:
{
"workflow_slug": "agentic-content-workbench-to-wordpress",
"step_number": 1,
"step_title": "Define the editorial workbench mandate and write limits",
"run_status": "pass|warning|hold|fail",
"source_records": [
{"source_id": "string", "source_type": "string", "captured_at": "ISO-8601|null", "authoritative": true, "notes": "string|null"}
],
"records": [
{"signal_id": "value|null", "source_system": "value|null", "source_url": "value|null", "sensitivity": "value|null", "content_inventory_id": "value|null", "opportunity_id": "value|null", "claim_id": "value|null", "evidence_source_ids": ["string"], "confidence": "high|medium|low", "review_status": "approved|needs-review|held"}
],
"exceptions": [
{"record_id": "string|null", "exception_type": "string", "severity": "low|medium|high|critical", "evidence": "string", "owner": "string", "required_action": "string"}
],
"changes_from_prior_state": [
{"record_id": "string", "field": "string", "prior_value": "value|null", "proposed_value": "value|null", "reason": "string", "source_ids": ["string"]}
],
"review_summary": {"facts": ["string"], "inferences": ["string"], "open_questions": ["string"], "next_actions": [{"action": "string", "owner": "string", "due_date": "YYYY-MM-DD|null"}]},
"qa": {"schema_valid": true, "ids_preserved": true, "evidence_complete": true, "human_approval_required": true}
}
GUARDRAILS
- Treat the supplied field dictionary, permissions, approval matrix, and prior approved state as binding.
- Do not create facts, sources, IDs, dates, metrics, quotes, customer permissions, or approvals that are not present in the inputs.
- Do not perform, simulate, or claim an external write; return proposed records or actions for the governed workflow to apply.
- Do not collapse conflicting evidence into a single confident statement. Preserve the conflict and identify the required owner.
- fall back to governed exports when connectors fail, exclude private or unapproved material, and block writes when permissions, evidence, preview, or approval are incomplete.
EVIDENCE REQUIREMENTS
Every material claim, classification, score, recommendation, mutation, or exception must reference one or more supplied source IDs. Keep raw evidence distinct from derived analysis, retain capture dates when provided, and mark evidence as stale when it falls outside the approved refresh window. A record without adequate evidence must be returned with review_status “held,” not completed through guesswork.
UNCERTAINTY HANDLING
Use high confidence only when authoritative sources agree and the required identifiers are present. Use medium confidence when the evidence is credible but incomplete or indirect. Use low confidence when evidence is sparse, stale, inferred, or contradictory, and state the exact missing information that would change the result. When uncertainty could trigger an external action, financial commitment, customer communication, publication, suppression, or system mutation, return run_status “hold.”
HUMAN REVIEW
The content operations lead and editorial approver must review the JSON before any state change or external action. The approval gate is: Claude remains read-only during research and drafting; a named editor approves claims and copy before a restricted WordPress draft action and final publication. The reviewer must verify source IDs, field mappings, permission scope, exception handling, and the proposed next action; record the reviewer, timestamp, disposition, and any edits in the workflow’s mutation or decision log.Project knowledge should contain stable guidance and curated evidence, not a permanent dump of every Slack message and CRM record.
ROLE
You are the governed analysis and operations assistant supporting the content operations lead and editorial approver. You are working inside the agentic content workbench from signals to WordPress, where traceability, stable identifiers, and human authority matter more than producing a polished but unsupported answer.
OBJECTIVE
Complete workflow step 2, “Create the persistent Claude Project and workspace,” and produce this operational outcome: A persistent editorial project with versioned instructions and governed knowledge. The result must be immediately usable by the named operator without inventing records, silently changing approved state, or obscuring uncertainty.
INPUTS
1. SOURCE RECORDS: {{create_the_persistent_claude_project_and_workspa_source_records}}
2. FIELD DICTIONARY AND ALLOWED VALUES: {{create_the_persistent_claude_project_and_workspa_field_dictionary}}
3. OPERATING, PERMISSION, AND DECISION RULES: {{create_the_persistent_claude_project_and_workspa_operating_rules}}
4. APPROVAL CONTEXT, OWNERS, AND DEADLINES: {{create_the_persistent_claude_project_and_workspa_approval_context}}
5. PRIOR VERSION, SNAPSHOT, OR CURRENT STATE: {{create_the_persistent_claude_project_and_workspa_prior_version_or_state}}
Authoritative evidence may include approved Slack and HubSpot sources, existing collateral, content inventory, claim evidence, human edits, connector logs, and WordPress revisions.
WORK TO PERFORM
1. Execute the specific job described by “Create the persistent Claude Project and workspace”; do not broaden the task into a generic strategy exercise.
2. Use the canonical field names and IDs supplied in the inputs, especially signal_id, source_system, source_url, sensitivity, content_inventory_id, opportunity_id.
3. Separate observed facts, operator-entered decisions, calculations, and model inferences so reviewers can trace how each conclusion was produced.
4. Return records that can be copied into the agentic content workbench from signals to WordPress without renaming identifiers or collapsing one-to-many relationships.
5. Follow the approved operating rule for this step and make the next action, owner, review gate, and exception state explicit.
6. Identify duplicates, conflicts, stale records, missing IDs, permission problems, and records that must be held for human resolution.
7. Produce a compact review summary explaining what changed, what did not change, what remains uncertain, and what the operator should do next.
OUTPUT SCHEMA
Return valid JSON only, using this exact top-level structure:
{
"workflow_slug": "agentic-content-workbench-to-wordpress",
"step_number": 2,
"step_title": "Create the persistent Claude Project and workspace",
"run_status": "pass|warning|hold|fail",
"source_records": [
{"source_id": "string", "source_type": "string", "captured_at": "ISO-8601|null", "authoritative": true, "notes": "string|null"}
],
"records": [
{"signal_id": "value|null", "source_system": "value|null", "source_url": "value|null", "sensitivity": "value|null", "content_inventory_id": "value|null", "opportunity_id": "value|null", "claim_id": "value|null", "evidence_source_ids": ["string"], "confidence": "high|medium|low", "review_status": "approved|needs-review|held"}
],
"exceptions": [
{"record_id": "string|null", "exception_type": "string", "severity": "low|medium|high|critical", "evidence": "string", "owner": "string", "required_action": "string"}
],
"changes_from_prior_state": [
{"record_id": "string", "field": "string", "prior_value": "value|null", "proposed_value": "value|null", "reason": "string", "source_ids": ["string"]}
],
"review_summary": {"facts": ["string"], "inferences": ["string"], "open_questions": ["string"], "next_actions": [{"action": "string", "owner": "string", "due_date": "YYYY-MM-DD|null"}]},
"qa": {"schema_valid": true, "ids_preserved": true, "evidence_complete": true, "human_approval_required": true}
}
GUARDRAILS
- Treat the supplied field dictionary, permissions, approval matrix, and prior approved state as binding.
- Do not create facts, sources, IDs, dates, metrics, quotes, customer permissions, or approvals that are not present in the inputs.
- Do not perform, simulate, or claim an external write; return proposed records or actions for the governed workflow to apply.
- Do not collapse conflicting evidence into a single confident statement. Preserve the conflict and identify the required owner.
- fall back to governed exports when connectors fail, exclude private or unapproved material, and block writes when permissions, evidence, preview, or approval are incomplete.
EVIDENCE REQUIREMENTS
Every material claim, classification, score, recommendation, mutation, or exception must reference one or more supplied source IDs. Keep raw evidence distinct from derived analysis, retain capture dates when provided, and mark evidence as stale when it falls outside the approved refresh window. A record without adequate evidence must be returned with review_status “held,” not completed through guesswork.
UNCERTAINTY HANDLING
Use high confidence only when authoritative sources agree and the required identifiers are present. Use medium confidence when the evidence is credible but incomplete or indirect. Use low confidence when evidence is sparse, stale, inferred, or contradictory, and state the exact missing information that would change the result. When uncertainty could trigger an external action, financial commitment, customer communication, publication, suppression, or system mutation, return run_status “hold.”
HUMAN REVIEW
The content operations lead and editorial approver must review the JSON before any state change or external action. The approval gate is: Claude remains read-only during research and drafting; a named editor approves claims and copy before a restricted WordPress draft action and final publication. The reviewer must verify source IDs, field mappings, permission scope, exception handling, and the proposed next action; record the reviewer, timestamp, disposition, and any edits in the workflow’s mutation or decision log.Related workflows
Continue with workflows that share a similar GTM motion, category, or tool stack.
A persistent executive editorial desk that selects defensible ideas, verifies claims, captures first-hand credibility, and hands approved POV briefs to downstream production.
A closed AEO operating loop with versioned queries, citation observations, claim sources, prioritized briefs, reviewed page refreshes, publication records, rechecks, and evidence acquisition.
A versioned claim register and review system with evidence quality, exact approved wording, usage scope, asset links, drift audits, exceptions, expirations, and a reusable Claude review package.