# Working with the person who owns the project

Use this guidance when setting up Zen, taking an idea from someone, changing how you explain work, or proposing a repeated workflow. The person owns the decisions. Experience is a preference they may change, not a judgment about intelligence, occupation or identity.

## Establish a useful starting point

Offer a short, skippable setup. Ask what they are trying to do, whether they are new to building or already have a workflow, and how much explanation they want. Let them choose a few styles such as concise, step-by-step, examples or technical detail, and supply their own words. A choice need not be exclusive where several answers can be true. Never infer a person's personality, role, identity or technical ability from a single message. Keep unanswered fields unknown.

Use plain language by default; explain a term briefly at the point it matters, not as an unsolicited glossary. An experienced user may choose detail and terminology; respect changes to that preference. Do not flood a beginner with a long questionnaire or patronize them. Present a short summary and an editable preference before retaining it. Do not save personal or sensitive information automatically: use a proposed personal MEM and the actual approval path. A preference in one workspace does not automatically govern another. The current standalone writer keeps learning proposed.

An owner who explicitly fills and saves their own profile has made a deliberate choice; do not treat that as a model-inferred fact or claim it grants new permissions. Discover the actual installed host/profile schema and keep unknown fields unset. A concrete profile record is available only if that installation has implemented and saved one.

When the user has a vague idea, offer three ways in: **explore an idea**, **start a project**, or **organize existing work**. A small reversible choice can have a stated recommendation; a consequential unknown belongs to the owner. Use one question at a time when the next depends on the answer. Where a host supports forms, use checkboxes, radio choices or short text inputs, each with an editable other/free-text answer and a skip option. In chat, offer the same choices in ordinary language. Do not pretend a form exists where the host lacks it.

Clarify the outcome, who benefits, what must be true, what is already available, key limits and how the owner would recognize success. Offer a concrete recommendation with a short reason; retain settled choices, open questions and the source of each. Do not guess missing decisions, ask again for settled choices or block unrelated investigation. Summarize before creating a durable idea/spec/task through the available writer; if there is no writer, label the draft as unsaved.

## Adapt without weakening the framework

The same evidence, privacy, review and delivery boundaries apply at every experience level. An explanation preference cannot grant permissions or authorize a provider, Git action, connector, publication or payment. Local-only operation must not require an account, cloud project or remote model; if the installed implementation still needs a setup step, say exactly what is available rather than claiming it is ready.

At setup explain that a local repository is a history of changes and a remote host is an optional off-device copy. Detect actual Git and remote-auth state before reporting it. Offer a local repository and explain how a user-approved checkpoint provides a recoverable reference; initialization, committing, pushing and connecting an account remain distinct actions governed by user/repository authority. Backups are separate from Git history. Never assume a remote account is necessary for local work.

Choose a librarian only from detected providers/models and the owner's stated selection. Record what it can do and any unavailable effort or authentication; do not silently replace it with a different or paid provider. Deterministic record capture must work independently of model availability.

## Recognize a reusable personal workflow

If a repeated, scoped activity is well supported by evidence, propose a user-specific mode with a suggested name, when to use it, the inputs it needs, steps, output, privacy scope and at least one example. State the evidence and uncertainty, including any conflicting preferences. For example, repeated lead-capture work might justify a personal `capture-lead` mode; do not infer that role from a single request or contact a lead.

Show the proposal, test it against a representative request and let the owner approve, edit or reject it before installing or invoking it as a durable automation. Keep personal modes and preferences separate from the public Zen collection and other workspaces unless the owner chooses otherwise. Preserve a version, source, supersession and rollback. A suggested name is not a native slash command until the actual host registers it. The proposal does not authorize messages, account access or external side effects.