Push

Push

Use Push as the gateway around the configured Claude Code, Codex, or Pi runtime. Push owns channels, scheduling, history, security checks, and delivery. The agent runtime owns reasoning, tools, skill execution, permissions, MCP servers, and authentication.

Work in the assistant repository

• Treat SOUL.md as user-owned identity and AGENTS.md as user-owned repository guidance. Do not edit either unless the user asks.
• Read context/README.md first when durable user context is relevant. Keep useful durable notes under context/ and evaluation criteria under evals/.
• Store complete job runbooks under jobs/.
• Treat skills/push/ and the push links under .agents/skills/ and .claude/skills/ as Push-managed. Do not edit them. Codex and Pi share the .agents/skills/ discovery path.
• Keep credentials, configuration containing credentials, sessions, databases, audit logs, and job runtime files outside the assistant repository.

Use the current CLI

Run push help when the accepted command forms are unclear. The stable commands are:

• push help
• push version
• push init [path]
• push
• push doctor
• push status
• push paths
• push reload or push restart
• push job validate
• push job list
• push job show <name>
• push job run <name>
• push job runs [<name>]
• push job reviews [<name>]

All commands accept --config <path>, although service status and restart use the installed service definition. Inspection commands support --json where documented by push help: help, version, doctor, status, paths, job validation, job inspection, runs, and reviews. Commands that start the gateway, change service state, scaffold files, or run a job reject JSON mode. The first upgraded inspection that loads configuration and job state records the one-time schedule migration baseline; follow the release upgrade notes before running it. Prefer JSON for automation, but still treat paths, handles, and operational metadata as sensitive. Never expose tokens, message content, or sensitive runtime state in diagnostics or replies.

Author jobs safely

1. Read the job format and existing runbooks before editing.
2. Write the complete Markdown runbook directly under jobs/ when the user asks to create or change a job.
3. Keep secrets out of the runbook. Use the configured service or agent environment for credentials.
4. Run push job validate after every job change. Do not claim success if validation fails.
5. Saving a new or changed enabled schedule does not activate it. Tell the user that Push will present the exact revision for separate owner review.
6. Use push job show <name> to inspect the installed result, push job reviews <name> to inspect schedule activation state, and push job runs <name> to inspect execution and delivery history.
7. Run push job run <name> only when the user asked for the job to execute or when execution is a clearly authorized part of the task.

Reply normally

For an ordinary conversation, return the final reply normally. Push sends it back through the originating channel. Do not invoke the Push CLI merely to send a chat reply.