copy

name	copy
description	Write, edit, and review Creed user-facing language in its calm, precise, editorial voice. Apply automatically whenever changing product copy, marketing copy, onboarding text, UI labels, buttons, errors, toasts, prompts, documentation, pricing language, or public claims.

Copy

Make Creed immediately understandable while preserving its quiet, document-first character.

Start With Truth

1. Read the surrounding copy and the relevant product behavior before writing.
2. Identify the audience, surface, action, and single idea the text must communicate.
3. Reuse canonical product terms. Do not invent a synonym for an established concept merely for variety.
4. Verify features, prices, limits, integrations, and availability against current source-of-truth code before making a public claim.
5. Preserve the user's requested meaning. Do not turn a focused copy change into an unsolicited rewrite of the whole surface.

Voice

Write like a quiet design publication or a well-set book, not a generic SaaS landing page.

• Lead with the outcome or concrete object.
• Prefer short, declarative sentences.
• Use concrete nouns such as file, section, agent, proposal, connection, and context.
• Explain the product in language a serious non-developer can understand.
• Let sublines explain the headline in one clause rather than repeat it.
• Sound assured without sounding inflated, cute, corporate, or defensive.
• Preserve the idea that one small, true file is held sacred and kept sharp.

Hard Rules

• Never use an em dash. Rephrase or use a comma, colon, full stop, or hyphen.
• Avoid hype such as revolutionary, AI-powered, next-gen, supercharge, game-changing, and effortless.
• Avoid unnecessary all-caps, exclamation marks, and emoji unless the user requests them.
• Do not describe Creed as a notes app, memory feed, dashboard, wiki, generic profile, or AI wrapper.
• Do not imply that Creed silently remembers everything. Emphasize explicit, curated, portable context.
• Do not make unsupported security, privacy, performance, compatibility, pricing, or availability claims.
• Do not expose internal implementation language when a user-facing term exists.

Surface Rules

Interface

• Use the shortest label that remains unambiguous.
• Write buttons as clear actions, not vague states.
• Keep helper text local and useful. Do not restate the heading.
• Write errors in plain language: what happened, then what the user can do.
• Keep toasts to one user-facing sentence with a full stop.
• Account for narrow mobile layouts before accepting a longer label.

Marketing

• Make the user problem and changed outcome understandable before introducing mechanisms.
• Prefer specific behavior over abstract benefit claims.
• Preserve One file across every agent as the central promise unless the user changes it.
• Treat ownership, portability, curation, and reduced re-explanation as real product claims, not decorative slogans.
• Keep Creed relevant to serious AI users beyond developers.

Onboarding

• Write as if the questions were made for the person reading them.
• Keep examples broad enough for founders, writers, researchers, operators, students, and builders.
• Teach one product idea at a time and keep the next action unmistakable.
• Do not front-load technical connection details before the user understands the file's value.

Prompts and documentation

• Preserve exact commands, identifiers, paths, payload shapes, and protocol terms.
• Separate user-facing explanation from literal technical text.
• Treat agent-contract wording as a public behavioral interface. Do not casually rewrite it for style.

GitHub git vs GitHub release

• Commit and PR titles follow the commit skill. They are git history, not marketing copy. A product release is release open 1.0.0.
• Changelog entries and GitHub Release name/notes are product copy. Use Creed Open vX.Y.Z and the calm sentence. Do not paste a git title into the release notes, and do not paste release prose into a commit title.

Review

Before finishing:

1. Read the copy aloud for rhythm, repetition, and unnecessary setup.
2. Remove abstract filler and duplicated meaning.
3. Check touched text for em dashes, hype, unsupported claims, and inconsistent terminology.
4. Confirm labels and supporting text fit the actual UI state, including mobile where relevant.
5. Verify shared facts such as pricing or feature availability still match their canonical source.
6. Inspect the final diff so a local copy change did not alter unrelated strings.

Report

Summarize the message clarified, the surfaces changed, and any factual source checked. Do not provide a lengthy writing critique unless the user asked for one.