1. What is Purposewrite

1.1 Definition

Purposewrite is a platform for creating scripted, human-in-the-loop AI workflows.

It allows you to build small, focused “apps” using a simple text-based scripting language. Each app guides a user through a structured, step-by-step process where humans and AI collaborate to produce consistent, high-quality results.

Purposewrite is designed for work that:

Follows best practices
Requires human judgment
Happens in multiple steps
Often spans more than one session
Must be repeatable across people and teams

In short:
Purposewrite helps you turn good ways of working into reusable AI-assisted systems.

1.2 Who Purposewrite is for

Purposewrite is primarily built for people and teams who want to create systems around quality work — not just generate one-off outputs.

Primary users (ranked)

Teams
Content teams, marketing teams, ops teams, internal knowledge teams.
Teams that need shared workflows, consistency, and predictable output regardless of who runs the process.
Agencies
Agencies delivering repeatable AI-assisted services to clients, where structure, quality control, and reusability matter.
Solo professionals
Individuals who want to formalize their own best practices and avoid reinventing the wheel every time.
Consultants
Consultants who use structured frameworks and want AI support without losing control over the process.

What these users have in common

They typically:

Work with multi-step processes
Care about how the result is produced, not just the final output
Need consistency across runs
Want AI support without giving up responsibility
Reuse the same base information (clients, brands, frameworks) repeatedly

1.3 What Purposewrite is NOT

Understanding what Purposewrite is not helps set the right expectations.

Purposewrite is not:

A chatbot or chat replacement
A freeform brainstorming tool
An autonomous agent framework
A background automation tool (like Zapier)
A visual drag-and-drop workflow builder

Purposewrite does not aim to:

Fully automate complex judgment-based work
Replace human decision-making
Let AI decide the workflow on its own

Instead, Purposewrite assumes that humans design the process, and AI assists within clearly defined steps.

1.4 Typical use cases

Purposewrite is best suited for work that benefits from structure, checkpoints, and reuse.

Common examples

Content & writing

Research → outline → draft → review → final output
SEO and thought-leadership workflows
Multi-stage content production with feedback loops

Research & analysis

Structured research processes
Competitive analysis
Market or company deep dives
Reusable research frameworks

Internal processes

Onboarding flows
Audits and reviews
SOP-driven tasks
Internal knowledge work

Agency & client work

Client-specific workflows with saved base data
Reusable service “apps”
Controlled hand-offs between team members

In all cases, the defining characteristics are:

Multiple steps
Human input at key points
AI used in focused, controlled tasks
The ability to pause, resume, and reuse work

1.5 Purposewrite compared to other AI platform categories

Purposewrite exists because other AI categories solve different problems.

Compared to chat tools (ChatGPT, Claude, Gemini)

Chat tools are excellent for:

One-off questions
Brainstorming
Exploration

Limitations for structured work:

No enforced process
Inconsistent results between runs
Hard to share and standardize across teams

Purposewrite focuses on defined workflows, not conversation.

Compared to Custom GPTs / AI assistants with instructions

Custom GPTs are useful for:

Simple helpers
One large instruction set
Lightweight personalization

Limitations:

Everything happens inside one prompt
No real branching or step control
Hard to inspect or reuse intermediate steps

Purposewrite breaks work into explicit steps with logic, checkpoints, and saved state.

Compared to automation platforms (Zapier, Make, n8n)

Automation platforms are good at:

Moving data between systems
Event-driven background tasks
Fully automated flows

Limitations:

Weak support for long human interactions
Not designed for deep work or writing
Human-in-the-loop UX is often fragmented

Purposewrite is built for interactive human workflows, not background automation.

Compared to autonomous agents

Agents are designed to:

Explore and reason autonomously
Decide their own path
Optimize for minimal human involvement

Limitations:

Unpredictable
Hard to control
Difficult to standardize

Purposewrite assumes the opposite:

Humans define the path
AI executes within constraints
Predictability is more important than autonomy

1.6 How to think about Purposewrite (mental model)

A useful way to understand Purposewrite:

It is a scripted interview, not a chat
A guided process, not improvisation
A workflow with memory, not a conversation thread
A system where humans are in control, and AI does focused work

If chat tools feel like talking to a very smart assistant,
Purposewrite feels like running a well-designed process — with AI embedded exactly where it adds value.

2. How to Use Purposewrite

This section explains how Purposewrite works from a user’s point of view: how apps are run, how input is handled, and how progress is managed.

2.1 The App List

When you open Purposewrite, you are presented with a list of available apps.

An app is a scripted workflow:

It defines the steps
It defines when AI is used
It defines when human input is required
It defines how the process can branch or loop

Apps are not conversations. They are predefined processes.

App sources

An app can be:

Created by you
Shared with you by another user
Provided as a built-in example

All apps appear in the same list and are run in the same way.

All built in purposewrite scripts are open source and available on GitHub so you can have a look, edit them and upload your own version to purposewrite.

2.2 Running an app

To use Purposewrite, you run an app.

Running an app means:

The script starts executing from the first step
The system follows the script line by line
Execution pauses whenever user input is required

Important characteristics:

Apps are designed to be run in one focused session
You can pause and resume using Save Points (covered later)
The app controls the flow — not the user

2.3 This is not a chat

Purposewrite deliberately does not behave like a chat interface.

Key differences:

You do not “talk freely” to the AI

You answer specific questions
You make selections when prompted
You do not steer the conversation arbitrarily

You should answer the question asked

Each prompt is intentional.
Answering something unrelated may still work, but it breaks the assumptions of the workflow.

Think of it as:

Filling out a structured interview
Not chatting with an assistant

2.4 Answering questions

When an app asks a question:

You must provide an answer
Empty answers are not allowed
The script decides what happens next

Questions may:

Ask for free text
Ask you to choose between numbered options
Ask you to confirm or refine previous information

Using numbered menus

When a menu is shown:

Reply with the number(s), not the full text
Multi-choice menus allow comma-separated answers (e.g. 1,3,5)
If you enter something unexpected, the script usually defaults to a safe option

Menus exist to:

Reduce typing
Increase consistency
Make workflows faster and more reliable

2.5 Credits and usage (conceptual overview)

Purposewrite uses a credit-based system.

Credits are consumed mainly when:

An LLM is called
External APIs are used (search, scraping, SEO, etc.)

Important notes:

Credits are tied to the account, not individual users
There is no per-seat cost
Sub-users draw from the same credit pool

Exact credit usage depends on:

Which models are used
How many steps the app contains
How many loops or retries occur

(Exact numbers are intentionally abstracted; the focus is on workflow design, not token math.)

2.6 Save Points: pausing and resuming work

A Save Point captures the full state of a running app.

This includes:

The current step in the workflow
All user inputs so far
All generated outputs
All internal variables

When you resume from a Save Point:

The app continues exactly where it stopped
Nothing is re-generated unless the script explicitly does so

Why Save Points matter

Save Points allow you to:

Pause long workflows
Get feedback from another person
Resume later without losing context
Reuse base information across future runs

Save Points are a core concept in Purposewrite.
They turn workflows into multi-session processes, not one-off runs.

2.7 Suggested previous answers

Purposewrite remembers previous answers per variable, not per conversation.

When a question is asked:

Previous answers to that same variable may be shown
You can reuse them instead of retyping

This is especially useful for:

Brand descriptions
Client information
Tone of voice
Repeated project data

Advanced input options

When answering a question, you can control how the answer is stored:

## at the start
→ The answer will not be remembered for future runs
[display name] prefix
→ A short label is shown in the UI, while the full value is stored internally

This allows:

Clean UI for long inputs
Reusable base data
Branching workflows that share variables intentionally

2.8 Loading vs running

Conceptually:

Running an app starts a new execution
Loading a Save Point resumes an existing execution

You can think of:

Running = starting a new instance of the workflow
Loading = continuing an unfinished one

Both follow the same script — only the starting state differs.

2.9 What to expect as a user

When using Purposewrite for the first time, it may feel:

Slower than chat
More structured
Less flexible

This is intentional.

The goal is not speed at all costs, but:

Fewer mistakes
Better reuse
Higher consistency
Clear human checkpoints

Purposewrite rewards users who:

Follow the process
Treat apps as systems, not conversations
Invest once, then reuse many times

3. Scripts

Scripts define how apps in Purposewrite work.

Every app in Purposewrite is powered by a script written in the Purposewrite scripting language. The script defines:

The sequence of steps
When the user is asked for input
When AI or external APIs are called
How logic branches or loops
What information is shown to the user

If you understand scripts, you understand Purposewrite.

3.1 What a script is

A script is a text-based workflow definition.

Key characteristics:

Written in a strict but readable scripting language
Executed sequentially, from top to bottom
Explicit about logic, state, and user interaction
Designed to represent real human + AI processes

Scripts are not prompts.
They are programs that orchestrate work.

All built in purposewrite scripts are open source and available on GitHub so you can have a look, edit them and upload your own version to purposewrite.

3.2 Apps vs scripts

The distinction is simple:

Script
The underlying workflow definition.
App
A runnable instance of a script that appears in the app list.

When a user runs an app, they are executing the script behind it.

3.3 Creating a script

You can create a script in two ways.

Option 1: Write the script in the interface editor

Purposewrite includes a built-in script editor where you can:

Write a script from scratch
Save it as an app
Run and test it immediately

This is the most common workflow when iterating quickly.

Option 2: Write a script externally and upload it

Scripts are plain text files.

You can:

Write or edit a script in any text editor
Upload the file into Purposewrite
Save it as an app

This is useful for:

Version control
Sharing scripts between environments
Working offline

3.4 Editing a script

Scripts can be edited at any time using:

The built-in editor, or
An updated file upload

Important notes:

Changes apply to future runs of the app
Existing Save Points are not modified
Syntax errors will prevent execution

Because scripts define workflows others may rely on, edits should be made deliberately.

3.5 Upcoming: script writing without code

A script-writing app is being introduced.

This app will:

Guide you through an interactive process
Ask what the app should do
Propose workflow steps
Generate the script for you

With this approach:

You describe the goal and logic
The app generates the script
No scripting knowledge is required

This lowers the barrier to building apps, while keeping the underlying workflow fully transparent and editable.

3.6 Script execution model

Scripts execute line by line, top to bottom.

Execution pauses only when:

A question requires user input
A loop or conditional alters the flow

There is:

No background execution
No hidden state
No implicit behavior

Everything that happens is defined explicitly in the script.

3.7 Variables and workflow state

All data in a script is stored in variables.

Variables may contain:

User input
AI-generated output
API responses
Intermediate results

Variables:

Persist for the entire app run
Are stored in Save Points
Can be reused across steps

This explicit state model is what enables pause, resume, and reuse.

3.8 Users, credits, and script usage

Scripts themselves do not consume credits.
Running an app does.

Important rules:

Sub-users use credits from the admin user’s credit pool
There is no per-seat cost
All internal usage draws from the same pool

This allows teams to share workflows freely without managing licenses per user.

3.9 Sharing apps and profit sharing

Scripts are shared by sharing apps.

Sharing behavior

Apps can be shared with other admin users
Shared users run the app using their own credits
The original creator retains ownership

Profit sharing (usage kickback)

You receive a usage kickback only when the app is shared with another admin user
You do not receive kickback from runs by your own sub-users
Sub-users are treated as internal usage

In short:

External admin user → kickback applies
Internal sub-user → no kickback

This model supports script reuse without penalizing internal collaboration.

3.10 Designing scripts for real users

Well-designed scripts:

Minimize free-text input
Use menus and defaults
Guide users clearly step by step
Include human checkpoints
Assume no prior scripting knowledge

Poor scripts:

Mimic chat behavior
Overload single steps
Hide logic in long prompts
Require unnecessary typing

Writing scripts is closer to process design than prompt writing.

3.11 When not to use a script

Scripts are not always appropriate.

Avoid scripts when:

The task is exploratory
The work is one-off
No repeatable structure exists

Scripts are an investment.
They pay off through reuse, consistency, and quality control.

4. Users and Sub-Users

Purposewrite is designed for team usage without per-seat friction.
The user model is intentionally simple and credit-based.

4.1 User roles

There are two main user roles in Purposewrite:

Admin user

An admin user:

Owns the account
Holds the credit balance
Can create, edit, and delete scripts
Can create apps
Can share apps with other admin users
Can invite sub-users

Each account has at least one admin user.

Sub-user

A sub-user:

Belongs to an admin user’s account
Can run apps
Can create Save Points
Can reuse previous inputs
Cannot own credits
Cannot receive usage kickback

Sub-users are intended for:

Team members
Internal collaborators
Contributors who run workflows but do not manage billing or distribution

4.2 No per-seat cost

Purposewrite does not charge per seat.

You can:

Add sub-users freely
Remove sub-users at any time
Share workflows internally without licensing concerns

The cost model is based on credits, not headcount.

4.3 Credit pooling

All sub-users draw from the admin user’s credit pool.

Important implications:

Credits are shared across the account
There is no individual credit balance per sub-user
Internal collaboration does not multiply costs

This makes it easy to:

Standardize workflows across teams
Avoid internal cost allocation
Focus on process design rather than usage accounting

4.4 Running apps as different users

When an app is run:

The running user is tracked
The workflow state belongs to that user
Save Points are user-specific

This allows:

Multiple users to run the same app independently
Parallel usage without interference
Personal Save Points per user, even within the same account

4.5 Sharing apps internally

Apps are automatically available to:

The admin user
All sub-users within the same account

Internal sharing:

Uses the same credit pool
Does not trigger profit sharing
Is intended for collaboration and standardization

4.6 Sharing apps externally

Apps can also be shared with other admin users outside your account.

When an external admin user runs your app:

They use their own credits
You retain ownership of the app
Usage is tracked separately

This enables:

Cross-company collaboration
Client-facing apps
Distribution of reusable workflows

4.7 Profit sharing (usage kickback)

Purposewrite supports usage-based kickback for shared apps.

Rules

Kickback applies only when an app is run by another admin user
No kickback is generated by sub-users
Sub-users are always considered internal usage

In practice:

Internal team usage → no kickback
External admin usage → kickback applies

This ensures:

Internal collaboration stays frictionless
External distribution is incentivized
Script creators are rewarded without affecting team workflows

4.8 Practical examples

Example 1: Internal team

One admin user
Five sub-users
All run the same content workflow
Credits are shared
No kickback applies

Example 2: Agency client

Agency admin shares an app with a client admin
Client runs the app using their own credits
Agency receives usage kickback

Example 3: Mixed usage

Internal team uses the app daily
External partners use it occasionally
Only external usage generates kickback

4.9 Summary

Purposewrite has no per-seat pricing
Sub-users use the admin’s credits
Apps can be shared internally or externally
Usage kickback applies only to external admin users
The model is designed to encourage reuse, not restrict collaboration

5. Hello World

This section introduces Purposewrite through the smallest possible working example.

The goal is not to teach the full language, but to show:

What running an app feels like
How user input works
How an AI call fits into a scripted workflow

5.1 What this example does

The “Hello World” app will:

Ask the user a question
Call an LLM with that input
Show the result

That’s it.

5.2 The script

Below is a minimal script.

#Question: name

“What is your name?”

#chatGPT: greeting

“Write a short, friendly greeting to someone named [name].”

#Show: “[greeting]”

This script contains:

One user input
One AI call
One output

5.3 What happens when you run it

Step by step:

The app starts
The user is asked:
“What is your name?”
The user enters a value (for example: Alex)
The script calls the AI with:
“Write a short, friendly greeting to someone named Alex.”
The generated greeting is shown to the user

There is no conversation.
There is no back-and-forth.
The script defines the entire flow.

5.4 Key concepts demonstrated

Even this small example shows several important ideas.

Questions are explicit

The script decides what to ask
The user must answer
The answer is stored in a variable

AI calls are isolated

The AI is called for one specific task
The result is stored in its own variable
The output does not “leak” into other steps

Output is controlled

Only what the script shows is displayed
The AI does not continue talking
There is no implicit next step

5.5 Why this matters

In chat-based tools, the same task would be done with an open-ended prompt.

In Purposewrite:

The workflow is fixed
The logic is visible
The behavior is repeatable

This becomes more valuable as workflows grow:

More steps
More inputs
More logic
More users

5.6 Extending this example

From this starting point, you could easily add:

A menu instead of free text
A Save Point
A second AI step
A review loop
Branching logic

Those concepts are covered in later sections.

6. Language Reference (Detailed)

This section documents the Purposewrite scripting language.

The language is:

Text-based
Deterministic
Strictly parsed
Designed for human-in-the-loop workflows

It is intentionally small, explicit, and opinionated.

6.1 Execution model

Scripts execute top to bottom
There is no implicit concurrency
No background execution
Flow changes only through explicit control structures
All state is stored in variables

Nothing happens unless the script explicitly defines it.

6.2 Case sensitivity

Command keywords are NOT case sensitive
(#Show, #show, #SHOW are equivalent)
Variable names ARE case sensitive

This allows flexible writing while keeping data handling precise.

6.3 Comments

Comments are used for documentation only and are ignored during execution.

Syntax rules

A comment line starts with ##
## must be at the start of the line
The comment occupies its own line
Inline comments are not allowed

Valid

## This explains the next step

Invalid

#Show: “Hello” ## inline comments are not allowed

6.4 Variables

Variables store all workflow state.

Properties

Case-sensitive
Persist for the entire app run
Stored inside Save Points
Reusable across steps

Referencing variables

[name]

6.4.1 Question metadata

Variables created via #Question expose metadata:

[name.q]

This contains the question text that created the variable.

6.5 Strings and text behavior

Strings are plain text
No expressions are evaluated inside strings
This is invalid:

“[count]+1”

Only direct variable substitution is supported

6.6 #Show

Displays content to the user.

Syntax

#Show: “Text”

Notes

Supports markdown
Variables are interpolated
Line breaks can be written directly or via \n

Examples

#Show: “Line one

Line two”

#Show: “Line one\nLine two”

6.7 #Question

Asks the user for input.

Syntax

#Question: variable

“Question text”

Rules

Question text must be on a new line
User input can never be empty
Answer is stored in variable
Question text is stored in variable.q

UX guideline

Because empty input is not allowed, always provide:

Clear defaults
Quick keys (e = English, n = No, etc.)
Menus where possible

6.8 #Text

Stores or updates text.

Syntax

#Text: variable

“Text value”

Important rule (variable reuse)

#Text and #Question may share the same variable
LLM commands must NOT reuse those variable names

This allows patterns like:

#Question: brief

“What is the brief?”

#Text: brief

“[brief]

Additional notes”

6.9 LLM commands

Each LLM command:

Stores output in a variable
Maintains its own context
Reuses context when the same variable is used again

Supported LLMs

#chatGPT
#chatGPT35
#claude
#gemini

Example

#chatGPT: analysis

“Analyze [input]”

6.9.1 Context flushing

All LLMs support context flushing:

#chatGPT: analysis

“–flush”

This clears the stored context for that variable.

Use this:

Inside loops
Between unrelated tasks
When output quality degrades

6.10 Control flow

6.10.1 #If / #Else / #End

#If [score]>80 and [approved]=”y” #Begin

…

#Else-Begin

…

#End

Supported operators

=, <>
<, >, <=, >=
and, or, not
Parentheses ()

Conditions are evaluated explicitly and predictably.

6.10.2 #Loop-Until

#Loop-Until: [done]=”y”

…

#End

Used for:

Feedback loops
Validation
Iterative refinement

6.11 Menus

6.11.1 Fixed menus

#Text: menu

“1. Option A

2. Option B”

#Question: choice

“Choose:

[menu]”

6.11.2 #Multi-List

Allows multiple selections.

#Multi-List: items

#Start-List: “Choose items:”

#List: “1. Research

2. Writing

3. Editing”

#End-List: “Select options:”

Result is stored as a list.

6.12 Looping over Multi-List selections

#For-All is used only with #Multi-List.

#For-All i=[items] #Begin

#Question: input{i}

“Input for [items.i]?”

#End

6.13 Image generation

ChatGPT image generation

#chatgpt-img: img

size: 1536×1024

“Image prompt”

Gemini image generation

#gemini-img: img

“Image prompt”

Display image

#showimage: [img]

6.14 Web scraping

#Scrape: content

“url”

Selector variants

#Scrape: content

“title :[url]”

#Scrape: content

“h1, p :[url]”

Supported selectors:

title
h1
p
combinations thereof

6.15 Web search

#chatgptsearch: result

“search terms”

Returns summaries with sources.

6.16 SEO (#SEO)

Purposewrite provides built-in access to DataForSEO APIs.

#SEO: seo_result

URL = https://api.dataforseo.com/v3/…

JSON = { … }

No API keys required
Raw JSON is returned
Always post-process with an LLM

(See Appendix A for full coverage.)

6.17 Code-in-code patterns

Scripts can safely manipulate other scripts or code as text.

#Text: instruction

“Modify the following script and return only the updated version:

[script]”

Used for:

Script refactoring
Template generation
Controlled code updates

6.18 Common rules and pitfalls

No inline comments
User input is never empty
Strings do not evaluate expressions
Reuse LLM variable names intentionally
Prefer menus over free text
Flush LLM context in loops

6.19 Summary

The Purposewrite language is:

Minimal
Explicit
Predictable
Designed for real human workflows

It prioritizes:

Control over improvisation
Reuse over speed
Process over conversation

7. Common Script Modules

This section describes reusable script patterns (“modules”) that are commonly used when building Purposewrite apps.

These are not language features.
They are proven ways of combining features to create reliable, human-friendly workflows.

7.1 Start-of-app mode selection

Used when an app supports multiple modes (e.g. simple vs advanced).

Pattern

Present a numbered menu
Normalize the result into a simple variable (y / n, basic / advanced)
Continue with clean logic

Example

#Text: mode_q

“n”

#Loop-Until: [mode_q]=”y”

#Question: mode

“Choose mode:

1. Standard

2. Advanced”

#If [mode]=”1″ #Begin

#Text: mode_q

“y”

#Text: mode

“standard”

#End

#If [mode]=”2″ #Begin

#Text: mode_q

“y”

#Text: mode

“advanced”

#End

Why it works:

Avoids invalid input
Keeps downstream logic clean
Improves UX

7.2 Reusable base data (Save-Point-friendly)

Used for:

Client info
Brand voice
Target audience
Project context

Pattern

Ask once
Reuse everywhere
Let old answers appear automatically

Example

#Question: brand

“What is the brand or company name?”

Because answers are stored per variable:

Future runs suggest previous values
Save Points preserve this data
Branches can reuse the same variables

7.3 Fixed menus with hidden prompts

Used when you want:

Simple user choice
Rich internal prompt logic

Pattern

Store menu with prompts
Display only labels
Extract selected prompt text

Example

#Text: tone_list

“1. Professional – Formal and clear

2. Casual – Relaxed and friendly”

#chatGPT: tone_menu

“Show the menu below but hide everything after ‘-‘.

[tone_list]”

#Question: tone_choice

“Choose tone:

[tone_menu]”

#chatGPT: tone_prompt

“From the menu below, return only the prompt text for option [tone_choice].

[tone_list]”

Why it works:

Clean UX
Strong internal control
No prompt leakage

7.4 Multi-list + loop processing

Used when the user selects multiple topics that each need processing.

Pattern

Present a multi-list
Loop over selections
Collect structured input or output

Example

#Multi-List: sections

#Start-List: “Choose sections:”

#List: “1. Introduction

2. Analysis

3. Conclusion”

#End-List: “Select sections:”

#Text: section_prompt

“”

#For-All i=[sections] #Begin

#Question: section_input{i}

“Your input for [sections.i]?”

#Text: section_prompt

“[section_prompt]

[sections.i]: [section_input{i}]”

#End

Why it works:

Scales gracefully
Avoids repeated menus
Keeps structure intact

7.5 Feedback and revision loops

Used for:

Writing
Strategy drafts
Iterative improvement

Pattern

Generate output
Ask for feedback
Loop until approved

Example

#claude: draft

“Write a draft based on [brief]”

#Show: “[draft]”

#Question: feedback

“Any feedback? (‘n’ = accept)”

#Loop-Until: [feedback]=”n”

#claude: draft

“[feedback]”

#Show: “[draft]”

#Question: feedback

“Any feedback? (‘n’ = accept)”

#End

Why it works:

Keeps humans in control
Prevents silent errors
Produces higher-quality results

7.6 Context flushing inside loops

Used when:

Loops are long
Output quality degrades
Token usage increases

Pattern

Flush LLM context after each iteration

Example

#chatGPT: analysis

“–flush”

Use this:

After each loop iteration
Before a fresh task
When context is no longer relevant

7.7 Web research + cleanup module

Used for:

Website analysis
Research workflows
SEO preparation

Pattern

Scrape
Clean with Gemini
Use clean result downstream

Example

#Scrape: raw

“https://example.com”

#gemini: clean

“Clean and summarize the following content:

[raw]”

Why it works:

Separates retrieval from reasoning
Avoids prompt overload
Improves reliability

7.8 Debug output module

Used while building or testing scripts.

Pattern

#Show: “DEBUG – variable = [variable]”

Remove before sharing production apps.

7.9 Safe defaults for user input

Because user input cannot be empty, always provide:

Clear choices
Simple defaults
Fast acceptance paths

Pattern

#Question: language

“Language? (‘e’ = English)”

#If [language]=”e” #Begin

#Text: language

“English”

#End

7.10 Summary

These modules exist to:

Reduce user friction
Increase consistency
Improve output quality
Make workflows easier to maintain

Good Purposewrite apps are built from:

Small steps
Clear choices
Explicit control
Human checkpoints

8. Common Bugs and Problems

This section lists the most common problems encountered when writing or running Purposewrite scripts, along with their causes and how to avoid them.

8.1 Inline comments

Problem

Using inline comments after a command.

Example (invalid)

#Show: “Hello” ## this will break the script

Why it fails

The parser does not allow comments after commands.

Solution

Place comments on their own line, starting with ##.

8.2 Wrong line breaks

Problem

Putting content on the wrong line.

Example (invalid)

#Question: name “What is your name?”

Correct

#Question: name

“What is your name?”

Rule of thumb

If the syntax shows content on a new line in the documentation, it must be on a new line in the script.

8.3 Reusing variable names across command types

Problem

Using the same variable name for different command types.

Example (invalid)

#Text: answer

“Hello”

#chatGPT: answer

“Rewrite this”

Why it fails

Variables are strongly tied to command types.

Solution

Use unique variable names per command type.

8.4 Assuming empty user input is possible

Problem

Checking for empty input.

Example (invalid)

#If [name]=”” #Begin

Why it fails

Users cannot submit empty responses.

Solution

Use explicit menus and defaults instead.

8.5 Invalid menu handling

Problem

Assuming users will always choose valid menu options.

Example

User enters 23 instead of 2.

Why it fails

The language has limited input validation.

Solution

Normalize choices
Default to a safe option
Use loops to re-ask when needed

8.6 Context drift in long workflows

Problem

LLM output degrades over time.

Cause

Context window pollution from repeated calls.

Solution

Flush the LLM context periodically:

#chatGPT: analysis

“–flush”

8.7 Overloading single LLM prompts

Problem

Putting too much logic into one prompt.

Symptoms

Hallucinations
Ignored instructions
Inconsistent structure

Solution

Break the task into multiple focused steps.

8.8 Forgetting to show output

Problem

The script runs but shows nothing.

Cause

LLM output is stored in a variable but never displayed.

Solution

Explicitly use #Show:

#Show: “[result]”

8.9 Save Point script version mismatch

Problem

Expecting script updates to affect an existing Save Point.

Reality

A Save Point stores the entire workflow state
This includes the exact script version active at the time
Loading a Save Point continues execution using that stored script version

Implication

Script edits affect new runs only
Loaded Save Points will continue using the old logic

Solution

If logic has changed:

Start a new run of the app, or
Create a new Save Point using the updated script

8.10 Image generation confusion

Problem

Generating an image but not displaying it.

Cause

The image variable exists, but #showimage is missing.

Solution

#showimage: [img]

8.11 Debugging strategy

When something goes wrong:

Reduce the script to the smallest failing example
Add temporary #Show debug output
Check variable names carefully
Verify line breaks and command placement
Test changes incrementally

8.12 Summary

Most issues come from:

Chat-like assumptions
Syntax strictness
Overloaded prompts
Missing explicit steps
Misunderstanding Save Point behavior

Purposewrite rewards:

Explicit logic
Small, focused steps
Clear user guidance
Treating scripts as versioned systems, not conversations

9. FAQ

Is Purposewrite a chatbot?

No.

Purposewrite uses AI models internally, but the user experience is scripted and structured, not conversational. The script defines the flow, the questions, and when AI is used.

Can I just talk to the AI freely?

No.

You interact with the workflow by:

Answering specific questions
Choosing from menus
Reviewing outputs

Freeform conversation is intentionally avoided to ensure consistency and repeatability.

When should I use chat tools instead?

Use chat tools when:

You are exploring ideas
You don’t yet know what you need
The task is truly one-off
Structure would slow you down

Purposewrite is for defined processes, not exploration.

Do I need to know the scripting language to use Purposewrite?

No.

You can:

Run existing apps
Use shared apps
Use Save Points and previous answers

An interactive script-writing app is also being introduced, which allows you to create apps by describing what they should do — without writing code.

Can I still edit the generated script?

Yes.

Even scripts created by the script-writing app are:

Fully visible
Fully editable
Plain text

There is no lock-in or hidden logic.

Can I pause a workflow and continue later?

Yes.

You can create a Save Point at any time.
When you load it later, the app continues from the exact same step, with all variables and outputs preserved.

What happens if the script changes after I save?

Nothing changes for that Save Point.

Each Save Point stores:

The workflow state
The variable values
The script version that was active at the time

Loading a Save Point always runs the original script version.

Can multiple people run the same app at the same time?

Yes.

Each run is isolated per user:

Separate variables
Separate Save Points
No shared state unless explicitly designed

How does credit usage work for teams?

Credits belong to the admin user
All sub-users draw from the same credit pool
There is no per-seat cost

This allows unrestricted internal collaboration.

Do I get charged when someone else uses my app?

Yes — for sub-users.
No — for external admin users.

How it works:

Sub-users
- Use credits from your credit pool
- This is considered internal usage
- No usage kickback applies
External admin users (shared apps)
- Use their own credits
- You are not charged
- You receive a usage kickback

In short:

Internal team usage → you pay (via your credits)
External shared usage → they pay, you earn kickback

Can I use multiple AI models in one app?

Yes.

A single script can use:

ChatGPT
Claude
Gemini
Image generation
Search, scraping, and SEO APIs

Each step can use the model best suited for the task.

Does Purposewrite remember previous answers?

Yes.

Previous answers are stored per variable and suggested automatically in future runs. This makes repeated workflows significantly faster.

Is Purposewrite good for fully autonomous workflows?

No.

If you want:

The AI to decide the path
Minimal human involvement
Fire-and-forget execution

Then an agent framework or automation platform is a better fit.

Purposewrite is built for human-controlled workflows.

Is Purposewrite replacing chat tools or automation platforms?

No.

Purposewrite is designed to complement them.

Chat → exploration
Automation → background execution
Purposewrite → structured human work

Where should I start as a new user?

Start by:

Running an existing app
Observing the structure
Reusing previous inputs
Saving progress mid-run

Once familiar, move on to:

Editing scripts
Creating your own apps
Designing reusable workflows

Appendix A: Using the #SEO Command (DataForSEO)

Purposewrite includes built-in access to a wide range of DataForSEO APIs via the #SEO command.

This allows scripts to perform:

SERP analysis
Keyword research
Domain and page analysis
Backlink and competitive analysis
Technical SEO checks
Brand and reputation analysis

No API keys are required.
Authentication, rate limits, and billing are handled by Purposewrite.

A.1 What the #SEO command does

The #SEO command:

Sends a request to a DataForSEO endpoint
Stores the raw JSON response in a variable
Does not perform interpretation or formatting

You are expected to:

Post-process the response using an LLM
Extract and format only the relevant parts

A.2 Basic syntax

#SEO: result_variable

URL = https://api.dataforseo.com/v3/…

JSON = { … }

Rules:

URL must be a valid DataForSEO endpoint
JSON must be valid JSON
Purposewrite variables can be injected using ${variable_name}

A.3 Common preparation steps

Most SEO workflows require normalization before calling #SEO.

Location code (GeoTarget ID)

#chatGPT: location

“give me the numeric ‘Geotarget ID’ code used by google ads API for:

[location_input]”

Language code (ISO 639-1)

#chatGPT35: language

“give me the ISO 639-1 language code for:

[language_input]”

Domain cleanup

#chatGPT35: url

“give me the full URL excluding https:// and www for:

[input]”

These steps are not optional.
Incorrect combinations of location, language, or URL format will cause API errors.

A.4 SERP endpoints

Google Organic SERP

#SEO: serp

URL = https://api.dataforseo.com/v3/serp/google/organic/live/advanced

JSON = {

“keyword”:”${kw}”,

“location_code”:${location},

“language_code”:”${language}”,

“device”:”desktop”,

“os”:”windows”,

“depth”:30

}

Used for:

Ranking analysis
SERP feature inspection
Competitive visibility

Google News SERP

#SEO: serp

URL = https://api.dataforseo.com/v3/serp/google/news/live/advanced

JSON = {

“keyword”:”${kw}”,

“location_code”:${location},

“language_code”:”${language}”

}

Google Local SERP

#SEO: serp

URL = https://api.dataforseo.com/v3/serp/google/local_finder/live/advanced

JSON = {

“keyword”:”${kw}”,

“location_code”:${location},

“language_code”:”${language}”

}

A.5 Keyword research endpoints

Keyword search volume

#SEO: volume

URL = https://api.dataforseo.com/v3/keywords_data/google_ads/search_volume/live

JSON = {

“keywords”:[${kw_list}],

“sort_by”:”relevance”

}

Keyword difficulty

#SEO: difficulty

URL = https://api.dataforseo.com/v3/dataforseo_labs/google/bulk_keyword_difficulty/live

JSON = {

“keywords”:[${kw_list}],

“location_code”:${location},

“language_code”:”${language}”

}

Keyword suggestions

#SEO: suggestions

URL = https://api.dataforseo.com/v3/dataforseo_labs/google/keyword_suggestions/live

JSON = {

“keyword”:”${kw}”,

“location_code”:${location},

“language_code”:”${language}”,

“limit”:10

}

A.6 Google Trends

#SEO: trends

URL = https://api.dataforseo.com/v3/keywords_data/google_trends/explore/live

JSON = {

“time_range”:”past_30_days”,

“type”:”web”,

“keywords”:[${kw_list}],

“location_code”:${location},

“language_code”:”${language}”

}

Used for:

Trend direction
Seasonality
Interest comparison

A.7 Domain & site analysis

Ranking keywords for a domain

#SEO: rankings

URL = https://api.dataforseo.com/v3/dataforseo_labs/google/ranked_keywords/live

JSON = {

“target”:”${domain}”,

“location_code”:${location},

“language_code”:”${language}”,

“limit”:100

}

Best pages (relevant pages)

#SEO: pages

URL = https://api.dataforseo.com/v3/dataforseo_labs/google/relevant_pages/live

JSON = {

“target”:”${domain}”,

“location_code”:${location},

“language_code”:”${language}”

}

Missing keywords vs competitor

#SEO: gap

URL = https://api.dataforseo.com/v3/dataforseo_labs/google/domain_intersection/live

JSON = {

“target1″:”${competitor}”,

“target2″:”${you}”,

“location_code”:${location},

“language_code”:”${language}”

}

A.8 Backlink analysis (advanced)

Note: Some backlink endpoints require a higher DataForSEO commitment.

Backlinks overview

#SEO: backlinks

URL = https://api.dataforseo.com/v3/backlinks/backlinks/live

JSON = {

“target”:”${domain}”,

“limit”:100

}

Referring domain gap

#SEO: ref_gap

URL = https://api.dataforseo.com/v3/backlinks/domain_intersection/live

JSON = {

“targets”:{

“Competitor”:”${domain1}”,

“You”:”${domain2}”

“limit”:100

}

A.9 Technical SEO

On-page analysis

#SEO: onpage

URL = https://api.dataforseo.com/v3/on_page/instant_pages

JSON = {

“url”:”${url}”,

“enable_javascript”:false

}

Google Lighthouse report

#SEO: lighthouse

URL = https://api.dataforseo.com/v3/on_page/lighthouse/live/json

JSON = {

“url”:”${url}”,

“categories”:[“seo”,”performance”,”accessibility”]

}

A.10 Brand & business analysis

Brand sentiment analysis

#SEO: sentiment

URL = https://api.dataforseo.com/v3/content_analysis/sentiment_analysis/live

JSON = {

“keyword”:”${brand}”

}

Google My Business info

#SEO: gmb

URL = https://api.dataforseo.com/v3/business_data/google/my_business_info/live

JSON = {

“keyword”:”${business}”,

“location_code”:${location},

“language_code”:”${language}”

}

A.11 Post-processing best practice

Always follow #SEO with an LLM step:

#chatGPT: analysis

“Analyze the following JSON and return only the useful results in markdown.

JSON:

[seo_result]”

Guidelines:

Strip metadata
Avoid repeating API structure
Return human-readable output
Never expose raw JSON to end users

A.12 Summary

#SEO provides raw, powerful data
You control interpretation and presentation
Always normalize inputs
Always post-process with an LLM
Design SEO workflows as multi-step processes, not single calls

This makes SEO apps in Purposewrite:

Repeatable
Auditable
Safe to use across teams