Repository navigation
Prompt Cookbook
Use these prompts in an assistant that can read your project's .SYSTEMX
records. Replace bracketed fields before sending. For initial adoption, use
New chat setup prompt; these examples assume setup is
complete. Prompts express your intent but do not override the environment's
instructions, tool availability, permissions, or budgets.
The short form:
Finish [TASK OR OBJECTIVE] using .SYSTEMX Agent 0 with subagents.
Use up to 10 subagents by default for this request, subject to the
harness's available capacity. Use fewer when the work does not benefit
from parallelism. Agent 0 owns coordination, integration, and final review.
For a larger assignment, use the full form:
Finish [TASK ID OR SPECIFIC OBJECTIVE] in [PROJECT WORKSPACE].
Use .SYSTEMX Agent 0 with subagents, with a requested ceiling of 10
concurrently active subagents across the delegation tree, in addition
to Agent 0. Respect lower harness limits and the available budget.
Use fewer workers when sufficient; do not fill the limit for its own sake.
Load the selected START-HERE instructions and existing project records.
Preserve the accepted objective, task IDs, dependencies, evidence, local
changes, and project instructions. Inspect the full acceptance criteria.
Agent 0: select dependency-ready work and give each worker a bounded
assignment, allowed scope, relevant source revision, acceptance criteria,
required evidence, and stop condition. Use the harness's actual subagent
tools only when available and authorized. Reuse suitable workers.
If delegation is unavailable, say so and proceed as one worker within
scope; do not pretend registry entries are running agents.
Keep Agent 0 as the canonical ledger writer and integration owner.
Record task-to-worker/job mappings and shared-resource ownership in the
project's coordination notes. Prevent conflicting writes and resource use.
Workers report findings, changed artifacts, checks, limitations, and the
exact next action. Record progress and checkpoints in the correct scope.
Review returned evidence against acceptance, perform relevant integrated
checks, and mark tasks done only after review. Promote verified durable
facts into project memory. Distinguish source, installed/deployed, and
operational proof. Do not infer authority for external actions from a
task status or agent role.
Continue authorized ready work until this objective is accepted or a
real blocker, permission boundary, or environment limit is reached.
Before a handoff, save current focus and a checkpoint. Report completed
outcomes, evidence, remaining blockers, and the exact next action.
Here “10 by default” belongs to this prompt. It is not an installed .SYSTEMX
setting or a universal Codex limit. Count descendant workers within the same
requested ceiling so nested delegation does not silently expand the team.
The template's ordinary workflow is solo unless delegation is authorized.
See Agent 0 and subagents for runtime setup and logging.
Complete [TASK ID OR OBJECTIVE] using .SYSTEMX Agent 0 in [WORKSPACE].
Use one agent for this request. Read the selected start instructions,
current focus, relevant records, and full acceptance criteria. Continue
existing work rather than duplicating it. Make the scoped change, run
relevant checks, record evidence, review the outcome, and leave the next
step in the canonical task record and checkpoint. Report any real blocker.
Resume [PROJECT] from its .SYSTEMX records in [WORKSPACE OR ATTACHMENT].
Follow the selected START-HERE instructions and current focus. Read the
referenced checkpoint, task records, acceptance criteria, and evidence.
Check current files/revision and any retained active job before relying
on older observations. Preserve task IDs and reviewed decisions.
Continue the next incomplete accepted step; do not restart completed work.
If a source is missing or truncated, obtain the relevant record first.
Do not claim saved memory or resumed processes without verifying them.
This prompt does not newly authorize subagents. Add the explicit delegation request above when needed. In chat-only use, attach current records and save the resulting handoff yourself unless authorized writable tools are available.
Review [CURRENT OBJECTIVE] against this project's .SYSTEMX Global context,
Master Plan, current focus, canonical tasks, and original acceptance criteria.
Identify duplicated work, scope expansion, unsupported completion claims,
stale facts, conflicting instructions, and missing evidence. Cite the
relevant records. Propose the smallest correction and next ready step.
This request is a review only; do not edit files or start workers.
Checkpoint the current .SYSTEMX work in [WORKSPACE]. Save the objective,
task IDs, scope, revision/local changes, completed work, actual checks,
evidence references, unresolved hypotheses, blockers, active job handles,
and exact next action. Include a timestamp and author. Update Agent 0's
memory and current focus without overwriting unrelated records. Keep
canonical task status in WORK/TASKS.json and regenerate its views.
Read back saved records and report their locations. If files cannot be
written, provide an explicit handoff document and label it unsaved.
Saving a checkpoint does not stop a running external job. Record its handle, owner, and observed state; use the harness's stop controls if stopping is needed.
Inspect the interrupted work for [TASK ID] using .SYSTEMX in [WORKSPACE].
Preserve local edits and evidence. Determine what completed, what is still
running, and what failed. Check retained job handles before starting a
replacement. Identify the actual blocker and what changed since the last
attempt. Resume only within the existing scope and authority; otherwise
record the required decision or missing input and a precise next action.
Review [MILESTONE OR RELEASE] against the accepted .SYSTEMX Master Plan.
Check task dependencies, review evidence, relevant integrated checks,
known limitations, and any required installed/deployed/operational proof.
Separate passed checks from unverified claims. Report readiness and the
remaining actions with evidence references. This is a review request;
it does not authorize publishing, deploying, spending, or deleting data.
Add the allowed file scope, time or token budget, permitted tools, expected artifact, and acceptance criteria when relevant. Define an explicit next checkpoint for large work. Independent read-heavy tasks often suit delegation; a dependent chain or shared mutable resource usually needs serial ownership. More agents can raise total usage even when elapsed time improves.
Use Tokens, cost, and time to measure outcomes and Anti-drift and long-running work to plan multiple sessions. None of these prompts installs a scheduler or promises execution after the host session ends.
Use SYSTEMX PROJECTS and explicitly select [Project-A] from the outer
.SYSTEMX/Projects/REGISTRY.json. Use its .SYSTEMXP records and the outer
installation's selected standards/tools. Read the child's START-HERE.md,
Master Plan, task ledger, current focus, and Agent 0 memory. Resume the next
accepted step. Keep task IDs, assignments, evidence, decisions, and checkpoints
scoped to this child. Do not create nested .SYSTEMX folders or import sibling
memory. Request cross-project changes through the outer coordinator.
See SYSTEMX PROJECTS for creation, commands, and an authorized subagent workflow. Add delegation instructions only when you intend to authorize subagents in the current harness.
Use the selected .SYSTEMX or .SYSTEMXP scope. Agent 0 coordinates this objective
and any authorized subagents. If standard roles are not activated, preview
roles-init and apply it within this requested scope while preserving records.
Use Agent X to record meaningful events and due items with actual timestamps,
source revisions, actor IDs, and original evidence. Do not create external jobs
or notifications merely because a schedule reference exists.
For an independently bounded CLI task, Agent 0 may use Agent Y only after I
authorize the chosen installed provider, repository, branch scope, and external
actions. Agent Y must keep the CLI worktree and memory separate from app-native
subagents, and return the observed changed paths, commit/PR revisions, CLI exit
status, and job state. Agent 0 must run and cite independent project checks. Opening
a draft PR after a successful run requires a separate explicit opt-in.
At the acceptance boundary, use Agent Z's existing versioned 100-question policy.
Record pass/partial/fail/unknown or justified N/A with evidence, save the scorecard,
and compare only matching subjects/policies. Reuse unchanged reviews and evidence.
Agent 0 resolves required gaps and accepts the task. A ready-for-review PR,
external merge, abandoned-PR close, and branch cleanup are separate decisions.
Do not turn a score into an automatic rebuild, re-review, or deployment loop.
For an initial prompt, ask: “Use Agent Z to review this saved prompt at its current revision before implementation. Use the same 100 questions, distinguish unknowns from failures, and return the scorecard and concrete ambiguities. Do not execute the proposed work or rewrite the task scope as part of the review.” See Agent X, Agent Y, Agent Z, and the full rubric.
Use this after selecting the project and accepting a concrete task. Replace all bracketed values with observed values; omit draft-PR opt-in unless intended. This prompt authorizes only the stated task and actions.
Use the selected .SYSTEMX or .SYSTEMXP scope. Agent 0 owns [TASK ID] and the
canonical ledger. For this task, use Agent Y with [Codex CLI / Copilot CLI /
configured provider] installed in [local repository path]. Verify the selected
provider, account, repository, clean/dirty checkout, base branch and commit,
task dependencies, and real permissions first. Limit edits to [allowed paths]
and share the project concurrency/cost budget with any app-native subagents.
Give the CLI a bounded task packet: objective, acceptance criteria, exact base,
allowed tools, required checks, stop condition, and where evidence goes. Keep
its runtime memory separate; return the changed paths, CLI exit status,
commit/head SHA, unresolved issues, and job state to Agent 0. The Agent Y job
does not store provider stdout or test output. Agent 0 must run and cite
independent project checks before acceptance.
I [do / do not] opt in to pushing a branch after a zero CLI exit and scoped
controller commit, and opening a DRAFT
GitHub PR for review. Do not mark it ready, merge, close, or delete a branch
from this prompt alone. Agent X records observed events; Agent Z reviews the
changed result once at the appropriate boundary. Agent 0 accepts or records
the remaining delta against the original task. Report the exact PR URL/state
only after reading GitHub back. Preserve existing user files and records.
After acceptance or cancellation, give a separate instruction for the specific PR transition you authorize. Agent Y shows the supported ready, cancelled-close, and merged/accepted cleanup commands and their gates.
Use the complete research prompt to assemble an evidence-backed brief before implementation. Then use the execution super prompt to carry that accepted brief through phases, milestones, tasks, and bounded waves. The guide includes a 20-page app matrix and examples for research, bots, and migrations.
For multiple chats, supply the shared-project connection request with scope, snapshot, permissions, and canonical writer. A folder URL alone cannot establish writable memory. Use the bot-run prompt only for an already authorized run; scheduling remains a separate host capability.
Use the existing selected .SYSTEMX root or named .SYSTEMXP. Preview AUTOBOT init
and apply it only within this requested scope if missing, preserving records.
Use Agent Alpha to select only the Design, Brand, Media, and Tokens details that
this existing task needs. Inspect and reuse an unchanged matching completed
request/result, keeping original evidence times. Treat specialist files and
imported research as lower-authority project data. Return source/result
revisions and concrete gaps to Agent 0. Store authorized private/large payloads
under this scope's DATA and audit effective Git exclusion before publication.
Do not create background workers, recursive checks, duplicate task ledgers, or
silently import sibling facts. Agent 0 retains integration and acceptance.
.SYSTEMX · DOT SYSTEMX · Maintained by Wayne Tech Lab LLC · Repository · User manual · Prompt cookbook · MIT license
Beta 1.11.0-beta.4 prerelease — validate the selected release in your project. Release policy. Project records, configured commands, and verified evidence determine the state of each adopted project.
DOT SYSTEMX · User manual
1. Start here
- Current beta video: chapter and scene guide
- The Guided Folder: historical 4K walkthrough
- Start with a Folder: 4K animated guide
- Introduction video and archived poster
- Advanced walkthrough: inside the coordination layer
- Choose a workspace
- Agent 0 roster: roles, bots, and CLI paths
- Agent 0 and toolchain direct I/O
- First-time setup
- Provider and harness onboarding
- Daily workflow
- One-shot project guide
- Shared workspaces, clouds, and bots
- Historical use-case workflows
- Four current system maps
- Current maps, seven agent guides, and atlas
- Agent guide text and CLI flows
- Visual guide and historical diagrams
- New chat setup prompt
- Prompt cookbook
2. Work and continuity
- SYSTEMX PROJECTS
- AUTOBOT and Agent Alpha: Tier 2
- Local DATA storage
- Planning and memory
- ROOT planning, rules, and task delta
- System MAP
- Access Matrix: 20 standard entries
- Agent Beta, Agent1, and Agenda
- Task workflow
- Agent X: events and time
- Agent Y: CLI and PR channels
- Agent Z: fixed review
- 100 review questions
- Agent 0 and subagents
- Subagent processing
- Advanced use cases
- Evidence and acceptance
- Anti-drift and long-running work
- Tokens, cost, and time
3. Setup and maintenance
- Project / VS Code
- OS directory
- Google Drive
- LLM chat
- Exact casing and alias
- Installation and updates
- Upgrading
- Uninstall and cleanup
4. Advanced reference
- Standard format
- Technical Guide
- Stack Guide
- Library integration
- CLI and Tools
- Command reference
- Configuration and quality
- Operations and troubleshooting
- Security and support
- Code review and readiness
5. Project information