Complete product flows, forms, onboarding, permissions, account and billing messages, transactional emails, and task-based chat or voice conversations. It can also revise existing strings and prepare a content handoff.

What should I provide first?

The task people need to complete, the intended audience, the surface or flow, and approved product facts. Screenshots, existing strings, brand voice and length limits help when available.

What do I receive beyond the copy?

For substantial work, a string or turn register ties exact text to its state, trigger, variables and next action. Consequential open questions and draft strings awaiting policy decisions stay easy to locate.

Can it handle errors and uncertain outcomes?

Yes. It writes relevant validation, correction, interruption and recovery paths. It distinguishes a request from its completed effect, including cases where a timeout leaves the outcome unknown.

Can it localize content or write in another language?

English is the default. Request another output language or locale; the method preserves meaning, product rules and variables while identifying any product differences that need your decision.

How do I use UX Content Designer?

Connect your AI agent to Agensi through MCP, then ask it to use UX Content Designer on your task. Your agent loads the latest approved version each time. Paid skills require a purchase or active subscription. Skill files are not available for download; your licence does not allow you to save, copy or export any part of a skill.

UX Content Designer

Bicycle repair appointment request

The rider provides a preferred date and repair details, reviews them, and submits a request. The completed online task is

request received. An appointment remains unconfirmed until staff arrange a time. Use “request” for the online submission and “appointment” for the later workshop visit.

Finished screen content and string register

The

Exact visible text column contains the copy. Conditions and behavior belong to implementation and must not appear in the interface.

ID	Surface / condition	Exact visible text	Action or implementation relationship
BR-ENTRY-01	Entry heading	Request a bicycle repair appointment	Establishes the task.
BR-ENTRY-02	Entry introduction	Tell us about your bicycle and your preferred date. Staff will email available times within two business days after receiving your request. Your appointment is not confirmed when you submit.	Show before the rider starts.
BR-ENTRY-03	Entry payment note	No payment is taken when you submit a request.	Show near the start action.
BR-ENTRY-04	Entry action	Start request	Opens the request form; does not submit.
BR-FORM-01	Form heading	Your repair request	Collect the four supplied fields.
BR-FORM-02	Form introduction	Add your details and the day you would prefer. You can review everything before submitting.	No completion implied.
BR-NAME-01	Name field label	Name	Persistent label.
BR-NAME-02	Name field hint	Enter the name you want staff to use for this request.	Associate with the name field.
BR-EMAIL-01	Email field label	Email (required)	Persistent label. Email is required by this content contract.
BR-EMAIL-02	Email field hint	Staff will email available times to this address within two business days after receiving your request.	Associate with the email field.
BR-DATE-01	Preferred date field label	Preferred date	Persistent label; selected date is a preference.
BR-DATE-02	Preferred date field hint	Choose the day you would prefer. Staff will confirm which times are available by email.	Associate with the preferred date field. Does not reserve a time.
BR-PROBLEM-01	Problem description field label	Problem description	Persistent label.
BR-PROBLEM-02	Problem description field hint	Describe the problem with your bicycle and what you would like checked.	Associate with the description field.
BR-FORM-03	Form next action	Review request	Validate required email, then open review. Does not submit.
BR-EMAIL-03	Email is empty	Enter your email address.	Inline required-field error. Preserve other values.
BR-EMAIL-04	Email fails the product's email-format validation	Enter an email address in the format name@example.com.	Inline format error. This example is not a support address. Preserve the entered value for correction.
BR-ERROR-01	Form has a missing email error	Check your email address before continuing.	Error summary heading; associate a summary item with the email field.
BR-ERROR-02	Summary item for missing email	Email: enter your email address.	Link/focus destination is the email field.
BR-ERROR-03	Summary item for invalid email	Email: enter an address in the format name@example.com.	Show instead of BR-ERROR-02 for invalid format.
BR-REVIEW-01	Review heading	Review your repair request	Review precedes submission.
BR-REVIEW-02	Review introduction	Check your details before submitting. This is a request for an appointment, not a confirmed appointment.	State the commitment clearly.
BR-REVIEW-03	Review name label	Name	Value: `{name}`.
BR-REVIEW-04	Review email label	Email	Value: `{email}`.
BR-REVIEW-05	Review date label	Preferred date	Value: `{preferred_date}`.
BR-REVIEW-06	Review description label	Problem description	Value: `{problem_description}`.
BR-CHANGE-01	Change name control	Change name	Return to editable name; preserve other values.
BR-CHANGE-02	Change email control	Change email	Return to editable email; validate the changed email before review.
BR-CHANGE-03	Change date control	Change preferred date	Return to date selection; refresh any actual availability dependency.
BR-CHANGE-04	Change description control	Change problem description	Return to editable description.
BR-REVIEW-07	Review next-step note	After receiving your request, staff will email available times within two business days. No payment is taken when you submit.	Show near the submission control.
BR-REVIEW-08	Submission control	Submit request	Sends the latest reviewed values once.
BR-SUBMIT-01	Submission has started; no result yet	Submitting your request…	Replace the submission control's active state. Prevent another submission while awaiting this operation.
BR-SUBMIT-02	Pending status text	Your appointment is not confirmed yet.	No invented completion time or background-processing promise.
BR-RECEIVED-01	Authoritative result confirms request received	Repair request received	Heading; never use for a timeout or request merely started.
BR-RECEIVED-02	Same confirmed received result	Staff will email available times to {email} within two business days. Your appointment is not confirmed yet.	Uses the submitted email. Does not claim an email has already been sent.
BR-RECEIVED-03	Same confirmed received result	No payment has been taken.	The brief confirms no payment in this flow.
BR-UNKNOWN-01	Network timeout; receipt cannot be established	We couldn't confirm whether your request was received	Heading. Distinct from confirmed failure.
BR-UNKNOWN-02	Same unknown-outcome state	Your appointment is not confirmed. Please don't submit this request again while the outcome is unknown. If your request was received, staff will email available times within two business days.	Conditional next step preserves the policy without promising a reply to an unreceived request.
BR-EMPTY-01	Authoritative availability result confirms no appointments available, before submission	No workshop appointments available	Do not display for loading failure or timeout.
BR-EMPTY-02	Same verified empty state; no request submitted	There are no workshop appointments available right now. No request has been submitted.	Do not promise future availability, a waiting list or an email notification.
BR-EMPTY-03	Same empty state	Back	Returns to the preceding step without sending a request.

Variables and presentation

The braces above are a proposed handoff notation for data supplied by the implementation, not literal text to display.

Variable	Source and meaning	Display requirement
`{name}`	Rider's name field	Display the reviewed value as text.
`{email}`	Rider's email field, validated before submission	Use the latest reviewed/submitted address. Never invent a fallback address. If receipt is confirmed but the address is unavailable, use: “Staff will email available times within two business days. Your appointment is not confirmed yet.”
`{preferred_date}`	Rider's selected date	Render an unambiguous human-readable date using the product's locale.
`{problem_description}`	Rider's description	Display as text without executing markup.

If non-email fields may be left blank, the review value is

“Not provided” for each genuinely absent value. If the product requires them, the product owner must confirm that contract and supply its validation rules before those validation paths can be finalized. Their labels and hints above remain usable now.

Field hints and errors should be programmatically associated with their fields. A changed value must appear in the refreshed review; the old review must not authorize submission. The implementation should announce submission and results with enough context to be understood without seeing the rest of the screen, and verify focus behavior in the interface.

Recovery dependency and proposals

The brief supplies no receipt-status check or safe retry mechanism. The unknown-outcome copy therefore offers neither a retry button nor an invented support channel.

Proposal for the product owner and backend owner: provide a way to reconcile the original request, or guarantee deduplicated retry, before adding a recovery action. This is a proposed capability, not a current product fact. The timeout state is usable as an honest holding state; resolution remains a product dependency.

Confirm with the product owner whether “no appointments available” blocks the whole request flow or only a chosen date. The supplied empty-state copy applies only to a verified, pre-submission lack of appointments; if only one date is unavailable, that narrower state needs a separate message and supported date-change behavior.

Walkthrough acceptance cases

Entry → completed fields → review → submit → confirmed received: every commitment says “request”; staff email within two business days; no confirmed appointment or payment implied.
Empty or invalid email: the specific email error appears, other values remain available, and review does not proceed until email is valid.
Change preferred date or email from review: the new values appear in a fresh review and only those values are submitted.
Timeout after submit: display the unknown state, never the received heading or an immediate retry action.
Verified no availability before submit: display the empty state; no request or notification is claimed.

These are content and behavior acceptance requirements. The text walkthrough does not verify actual form validation, network effects, rendering or accessibility.

UX Content Designer