New Chat Setup Prompt

New chat setup prompt

Use this page to start a new project with .SYSTEMX or carry its current records into another chat. Copy the prompt below, replace the three project fields, and paste it into your assistant. It works with an assistant that can write project files and includes a separate path for a chat without writable tools.

Alpha: use at your own risk; may change daily. This prompt targets 1.11.0-alpha.6. The 1.9.0-alpha.1 tag was withdrawn after a distribution manifest mismatch; do not install or select it. An exact release identifies the defaults you chose. See release policy.

Setup URLs

Purpose	Link
Share this reusable setup prompt	New Chat Setup Prompt
Authoritative instructions for this release	START-HERE.md and FIRST-RUN.md
Wiki setup walkthrough (reference)	First-Time Setup
Repository or VS Code project root	Project setup
Windows, macOS, or Linux working directory	Directory setup
Locally synchronized Google Drive folder	Google Drive setup
LLM chat with attachments or authorized tools	LLM Chat Setup
Download only the operating folder	.SYSTEMX 1.11.0-alpha.6 ZIP
Exact release and checksums	Alpha.6 release

For this exact release, the raw GitHub codeload tag ZIP SHA-256 is a50f0566c07f5a0c51b14a38bf6e3eb38b3c61d2953352304b186fa4fca0b464. That digest differs from the folder-only ZIP's checksum. Verify it through a channel you trust before treating it as an independent pin.

The ZIP contains a directory named exactly .SYSTEMX. Enable hidden-file display if your file browser hides names beginning with a dot. The installation target is the containing project directory, such as C:\Projects\Example or /home/me/projects/example, rather than the .SYSTEMX directory or an OS root. The wiki can change between releases. Use the selected release's versioned .SYSTEMX/START-HERE.md and .SYSTEMX/docs/FIRST-RUN.md as the setup instructions when this page or a README summary differs from them.

Copy into a new chat

Set up the public .SYSTEMX template for my project, then use it to
coordinate this project's work.

Project name: [PROJECT NAME]
Project folder or workspace: [FULL PATH, OR "CHAT ONLY"]
Initial objective: [WHAT THIS PROJECT SHOULD ACCOMPLISH]

Public template:
https://github.com/WayneTechLab/dotSYSTEMX

Pinned release: 1.11.0-alpha.6
https://github.com/WayneTechLab/dotSYSTEMX/releases/tag/v1.11.0-alpha.6

The 1.9.0-alpha.1 tag is withdrawn; do not install it as a fallback.

Remote manager codeload ZIP SHA-256 for this exact release:
a50f0566c07f5a0c51b14a38bf6e3eb38b3c61d2953352304b186fa4fca0b464

Folder-only download:
https://github.com/WayneTechLab/dotSYSTEMX/releases/download/v1.11.0-alpha.6/dotSYSTEMX-1.11.0-alpha.6.zip

Authoritative release instructions:
https://github.com/WayneTechLab/dotSYSTEMX/blob/v1.11.0-alpha.6/.SYSTEMX/START-HERE.md
https://github.com/WayneTechLab/dotSYSTEMX/blob/v1.11.0-alpha.6/.SYSTEMX/docs/FIRST-RUN.md

Wiki walkthrough for reference:
https://github.com/WayneTechLab/dotSYSTEMX/wiki/First-Time-Setup

1. Determine whether you have filesystem access, authorized workspace
   tools, or only chat access. Ask for the project location if it is
   missing and required. If you cannot read the versioned release instructions,
   request the release ZIP or the relevant extracted files instead of guessing.

2. Treat dotSYSTEMX as the reusable public source template. Install its
   .SYSTEMX content into MY project. Keep my project facts, tasks, and
   memory in my project, outside the public template repository.

3. Use the exact folder name ".SYSTEMX", including the leading dot and
   uppercase letters. Inspect existing hidden folders first. Never create
   a separate ".systemx" folder. Keep the lowercase symbolic-link option
   disabled unless I request it. If conflicting folders already exist,
   preserve them and explain the conflict before making changes.

4. With local filesystem access, read the selected release's
   .SYSTEMX/START-HERE.md and .SYSTEMX/docs/FIRST-RUN.md, then use its manager
   to preview setup and apply it if
   there are no conflicts. Choose the appropriate project, directory,
   or locally synchronized Drive profile. Preserve existing files,
   project records, Git settings, and repository instructions.
   Keep new installations pinned with manual updates. An already managed
   project retains its selected version and policy; explain any mismatch
   with the requested release and follow the documented update workflow
   rather than overwriting its installation state. If an independently trusted
   SHA-256 of the exact GitHub codeload tag ZIP is trusted, use the manager's
   `--archive-sha256` option with this explicit version and report its receipt.
   For a managed update, use the new external tool to preview `bootstrap-refresh`
   and inspect its `add`, `replace`, and `conflicts` fields. Apply only recognized
   stock bootstrap/launcher changes; back up replaced files, and add a missing
   stock file only if no retained release ever contained it. Stop on customized
   files. The current manager newly selects only releases 1.8.7-alpha.1 or newer;
   historical recovery needs a separately reviewed backup or legacy path. A
   fresh install must stop on conflicting executable defaults.

5. Follow START-HERE.md from the selected defaults. Initialize this
   project's Global context, Master Plan, project memory, current focus,
   and task ledger using only facts and objectives established here.
   Record unknowns instead of inventing requirements. Do not import
   the template repository's development history or another project's
   backlog. In managed installs, write project records to the outer
   .SYSTEMX directory, never into the cached default snapshots.

6. Use agent.0 as coordinator. Keep WORK/TASKS.json as the task-status
   authority and generate its status views with the supplied tools.
   Creating a role record does not authorize spawning subagents.

7. Validate the adopted project, inspect the Agent 0 context, and report
   the actual folder path, selected version, changes, operation-log
   location, unresolved questions, and next actionable step.

If this is chat-only or you cannot write files, follow:
https://github.com/WayneTechLab/dotSYSTEMX/wiki/Setup-LLM-Chat

Use the same structure through attached records and explicit handoff
documents. Clearly distinguish proposed changes from saved changes.
Do not claim a folder was installed or memory persisted without a
successful write and readback.

The prompt authorizes adopting the format in the identified project. It does not change the assistant's instruction hierarchy or grant access to unrelated files, accounts, agents, or services. .SYSTEMX remains a public blank template; each adopting project owns its populated records.

Chat-only sessions and continuity

A URL provides instructions but does not give an LLM filesystem access or durable memory. Use CHAT ONLY when there is no writable project folder. Attach relevant files or an exported context packet. If an assistant cannot read ZIP files, provide the extracted documents it needs. Keep proposed updates as explicit documents or record changes that the owner can save and later reload.

For an existing managed project, use the installed command to export context:

systemx export-chat --target "/path/to/project" --output "/path/to/new-session.md"

Choose a new output filename: the exporter refuses to overwrite an existing file. Review the packet for private information before attaching it. It contains bounded context, so provide referenced source records when the packet indicates truncation or the next task requires more detail. Export does not upload anything.

To resume an existing project, attach its current packet and use:

Resume this project's .SYSTEMX workflow using the attached current context.
Project: [PROJECT NAME]
Objective: [CURRENT OBJECTIVE]

Use the recorded selected version and START-HERE instructions. Inspect the
current focus, project context, Master Plan, canonical tasks, and agent.0
memory. Continue from the next incomplete accepted step. Recheck live facts
before relying on them. Preserve existing task IDs, evidence, and memory;
do not replace them with blank template records or restart completed work.
If context is missing or truncated, request the relevant source records.
Distinguish proposed edits from applied, read-back file changes, and leave
a clear checkpoint for the next session.

Keep session exports and project records according to that project's privacy and retention rules. For removal, use Uninstall and Cleanup.

After setup

Use Daily workflow for the first task and Prompt cookbook for execution, review, and checkpoint prompts. To request Agent 0 with up to ten subagents, copy its explicit delegation prompt and read Agent 0 and subagents. That requested ceiling is subject to the harness's available capacity; setup itself starts no workers.

An existing multi-project workspace

Do not run the installer inside .SYSTEMX. Set up the outer installation once, then follow SYSTEMX PROJECTS to create a blank child.

Use the existing outer .SYSTEMX at [WORKSPACE PATH]. Select [Project-A] from
Projects/REGISTRY.json and load projects context --project Project-A --agent agent.0.
Read Projects/Project-A/.SYSTEMXP/START-HERE.md and continue that child's accepted
objective. Preserve exact case, existing files, task IDs, evidence, and memory.
Use the selected outer defaults. Do not create a nested .SYSTEMX or switch projects
implicitly. If this is a new child, preview projects add Project-A first and apply
only within the requested setup scope; never replace an existing destination.

For chat-only handoff, export with systemx export-chat --target WORKSPACE_PATH --project Project-A --output NEW_PACKET.md, review it, then attach it. The packet contains selected records and shared guidance; an upload or URL alone does not grant persistent filesystem access.

Standard event, CLI, and review roles

With selected 1.9.0-alpha.2 or newer defaults, add this to the setup request. For an existing managed project, check its selected version first: 1.8.9-alpha.1 supports only X/Z and requires an explicit update before Agent Y activation.

Preview roles-init in the selected scope, then activate Agent X (event-time),
Agent Y (external CLI channel), and Agent Z (review) records as part of this
setup. Preserve existing files and adopted policies. Activation alone launches
no provider or PR. Keep the fixed 100-question rubric and version it explicitly
for company/project changes. Use X for actual event/due facts; use Y only for
a separately authorized existing task, selected installed provider, explicit
repo/base and allowed paths, with draft-PR opt-in if requested; use Z for one
completion review or an explicitly requested prompt review. Reuse unchanged
reports. No role should start a scheduler or a reprocessing loop.

Activation requires compatible selected defaults. Older tools cannot read the new named role IDs; preserve a backup before activation and review Upgrading. See Agent Y for CLI/PR authority gates and a task-specific prompt.

Starting a larger project or joining shared work

For an idea that needs research and implementation, begin with the one-shot project guide. Its research prompt creates the brief/source index; its execution prompt connects the accepted brief to phases, milestones, tasks, waves, X event records, and Z review. One comprehensive brief can support many turns without restarting the plan in each new chat.

For an existing shared project, use the connection request. Include the canonical URL/path, named child if any, expected revision, coordinator, and this chat's read/write scope. Verify access and freshness before changes.

Optional Tier 2 detail after setup

After selecting reviewed 1.11.0-alpha.6 defaults, inspect AUTOBOT and local DATA
setup in the selected root or named child only. Preview separate Alpha
initialization and preserve existing records when applying it. Populate only
authorized project facts; leave unknown company/brand/design/research details
blank. Request only specialists needed for the next existing task and reuse an
unchanged completed request with original evidence time. Audit effective DATA
ignore policy before publication; do not upload private/large payloads or create
background bots/check loops. Agent 0 keeps canonical task acceptance.

See AUTOBOT and Agent Alpha and Local DATA storage for exact paths, commands, and limits.