Menü
Core behavioral rules - loaded by ALL agents
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | core-rules |
| description | Core behavioral rules - loaded by ALL agents |
| disable-model-invocation | true |
The FIRST lines of every response to the USER MUST be this exact format:
[CONFIG] Skills: [list of loaded skills]
**BLUF: [bottom-line-up-front answer]**
**Optimizing for:** USER OUTCOMES > components, journeys > health checks, results > narration.
This fires BEFORE any other content in user-facing responses. When reporting to a supervisor agent, use the worker-reporting format (STATUS/ACCOMPLISHED/REMAINING) instead.
END OF RESPONSE: If the response exceeds ~1.5 screen rows (~3-4 lines of content), add a **TLDR:** at the very end summarizing the key outcome in one line. The user is impatient — front-load with BLUF, close with TLDR.
I optimize for USER OUTCOMES, not components.
curl /healthBefore claiming ANY deployment/fix is complete:
kubectl get podsWhen UI verification is needed, use headless Puppeteer (npm install puppeteer in /tmp/e2e-<project>/).
Take screenshots as part of the work — don't announce it, just do it and show the result.
Use commander-mcp tools for on-demand data: get_skill("name"), get_context_servers, get_context_ports, etc.
Local slash commands: /commander, /project, /testing
Auto /remember on: "remember that", "note:", "save this"
Chat: http://dev-01:8099 (65.21.153.235:8099) On start: GET /generate-name for unique ID, then POST /send {agent,message,location,working_on} to announce. Periodically: GET /messages?limit=10, POST /heartbeat {agent,working_on}. GET /online to see who's here. POST /offline {agent} when done. Converse if useful, stay token-lean.
All work items (FIX-, CR-, FB-, WI-) use EXACTLY these statuses:
| Status | Meaning | Who Sets It |
|---|---|---|
| pending | Not started | Default |
| started | Work in progress | Agent/supervisor when work begins |
| untested | Code deployed, awaiting user verification | Agent/supervisor after deploy |
| accepted | Formally accepted by user | USER ONLY — NEVER set by agent |
Rules:
accepted — only the user can formally accept workuntested — not "done", "complete", "verified", or "fixed"TRACKER.md in the project run directory — update it when status changesNote: Work item status (pending/started/untested/accepted) tracks a TICKET's lifecycle. Session report status (DONE/PARTIAL/BLOCKED) is a worker's one-time report to their supervisor about their session. These are different systems — don't confuse them.
On compaction: re-read MEMORY.md + tasks
Load CI/CD pipeline configuration and deployment information when working with automation or deployments
Load database relationships, shared resources, and schema information when working with data models or database configuration
Load development environment information including folder structure, OrbStack setup, and system configuration
Load port mappings for all projects when working with networking, docker-compose, or service configuration
Load GitHub/GitLab repository information when working with git, CI/CD, or repository management
Load server information, infrastructure details, and access patterns when working with deployment or server configuration