AI content repurposing
By Ai Flowi · Published .
AI content repurposing turns one approved source into drafts suited to different formats and audiences. Preserve the source’s claims and qualifications, change the structure for each destination, and keep every variant linked to the source version for editorial review. The output here is a review queue, with no social posting or account integration.
example configuration, not a recorded test. The source-to-variant design is documented in the catalogue; not production-tested by Ai Flowi.
1. Select one approved source and define its limits
Begin with supplied article text, a permitted transcript or a Google document you can access. Record its identifier, version, approval status and intended audience. Add instructions about passages that must retain their wording or qualification. A summary of a conditional claim must preserve the condition, even when the target format is short.
Define each output before asking for prose. A newsletter introduction needs a reason to read the source; a blog outline needs sections and evidence anchors; a short explainer needs a clear task and an appropriate amount of context. These are separate draft contracts. Creating several shortened copies of the same paragraph does not establish useful format differences.
You need AI Flowi Workflow, access to the approved source and a model provider configured with your own account/API key where required. The provider is paid separately. For Google Docs input and a Sheets review queue, use your own Google account, a saved connection and permission for both services. File-source access depends on the selected storage route.
2. Read the source without losing its identity
Read the approved source through Read File using the file-selection instructions, or through Get Text using the Docs reading reference.
Before shortening anything, divide the source into core claim, evidence, qualification and context. Identify passages whose meaning depends on nearby text, such as an exception in a later paragraph. Keep that dependency in the format brief. A newsletter introduction may omit detailed evidence while linking the full source, but it must not omit a condition that determines whether the central claim applies.
When the source document contains several tabs, decide which belong to the approved edition. A planning tab may contain abandoned claims that were intentionally removed from the finished article. Mixing it into the source pack can reintroduce those claims through a summary. Compare the extracted material with the approved reading order before producing any variant.
3. Define the variant contract in Structured Output
Give Structured Output input_value the approved source and each format’s brief as inspected text. In the variant plan, distinguish what is retained, restructured and omitted. A format change does not permit new factual content; additions that are absent from the source belong in an editor’s research request instead of the variant draft.
| Field group | What belongs there | Editorial check |
|---|---|---|
| Source identifier and version | The exact approved material used for this draft. | Every variant points to the same reviewed source version. |
| Target format and audience | The variant’s purpose and reader context. | The structure fits that purpose. |
| Claim and evidence anchor | A source passage for each retained factual claim. | Conditions and limitations survive rewriting. |
| Draft text and omitted context | The proposed copy plus what compression removed. | No omission changes the meaning. |
| Review status and reviewer | A supplied editorial decision after inspection. | A generated status cannot approve its own draft. |
Use the Structured Output schema reference to implement the variant plan, with system_prompt prohibiting new statistics, endorsements and causal claims.
4. Draft each format from the accepted plan
The prompt component guide and model reference cover the connection used to draft an accepted variant plan.
For a newsletter introduction, set template to identify the reader’s reason to open the source and preserve its main qualification. For a blog outline, ask for a sequence of section questions with evidence anchors rather than finished sentences. For a short explainer, request one bounded task and the caveat needed to act on it. Use system_message to require an omitted-context note alongside each draft so the editor can assess compression deliberately.
For a video transcript blog outline, retain transcript locators where available and mark uncertain speaker attribution. Do not infer a position from a fragment that lacked its surrounding discussion. For a concise announcement, keep eligibility and scope beside the central claim. The format can change while the evidence boundary stays attached.
5. Store reviewed variants in an explicit queue
Configure Append Rows through the Sheets append reference, using value_input_option "RAW" for this literal-text review queue.
Prepare values manually with source version, variant identifier, format, draft text, omitted context and editorial decision. Treat a revised variant as a new review entry linked to the previous one, so an editor can compare what changed. Before repeating an uncertain append, look for that variant identifier; duplicated queue entries can send reviewers to different revisions of the same copy.
For the queue’s intake setup, consult the Sheets tutorial; the source-to-variant review remains a separate configuration. Avoid repeating a save after an uncertain failure until you have inspected the queue for the existing variant.
6. How do I review semantic changes and version drift in content repurposing?
Read each variant against its source anchors. Test an ambiguous transcript, a qualified product claim and a source update after drafting. The review should catch missing context, preserve uncertainty and identify drafts tied to the older version. Keep rejected text available for diagnosis instead of replacing the approved source with generated copy.
As an illustrative compression check, take a source that describes a capability only for reviewed inputs. Reject a short variant that drops “reviewed,” even if its remaining words are accurate individually. Compare the inferred audience too: wording addressed to an experienced operator may become misleading when rewritten as advice for a beginner. If the necessary explanation will not fit the chosen format, narrow the claim or use that format to point readers to the full source instead.
Do not use this design to publish automatically, invent endorsements or transform restricted material without permission. It has no social delivery step and no measured content-performance result. If there is no approved source yet, begin with content creation from a brief; if the source is outdated, use the source-version audit.
Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.
The component catalogue supplies the underlying contracts, and use cases describe existing starters. This guide adds a source-linked variant queue and editorial decision record.