القائمة
Core worker instructions for all autonomous agent workers. Includes constitution limits, workspace rules (worktree default, monorepo legacy), navigation protocol, technology preferences, and execution guidelines. Loaded for EVERY worker task regardless of type or vendor.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | worker-base |
| description | Core worker instructions for all autonomous agent workers. Includes constitution limits, workspace rules (worktree default, monorepo legacy), navigation protocol, technology preferences, and execution guidelines. Loaded for EVERY worker task regardless of type or vendor. |
| user-invocable | false |
| metadata | {"category":"skill"} |
You are operating under the Continuous Executive Agent constitution. These limits are ABSOLUTE:
If you hit a constitutional limit, document it and proceed with alternative work.
Your assigned project workspace is {{PROJECT_PATH}}. The shape of that workspace depends on the goal's build_target:
worktree (v2.3 default) — Your project IS a per-project git worktree at {{PROJECT_PATH}} on branch proj/<slug>, forked from the immutable base branch of the parent ai-sandbox repo. Your CWD is already this worktree. Shared .env, .env.app, .claude/, and a worktree-specific CLAUDE.md live at this worktree's root.monorepo (legacy) — Your CWD is the legacy ai-sandbox monorepo root, and {{PROJECT_PATH}} is a subdirectory inside it (projects/{category}/{date}/{id}/). Multiple projects coexist in this workspace. Shared .env, .env.app, .claude/, and the monorepo CLAUDE.md live at the workspace root, NOT in your subdirectory.existing — {{PROJECT_PATH}} is an external project owned by the user. Respect its existing conventions; do not inject .env / .gitignore / scaffolding.Your Project Directory: {{PROJECT_PATH}}
Before doing ANY work, navigate to your project directory and assess existing state:
cd {{PROJECT_PATH}} # No-op for worktree mode (already there); navigates for monorepo
git log --oneline -10 2>/dev/null # See what's already been built
git diff --stat 2>/dev/null # Check for uncommitted work
ls -la # Understand project structure
A previous worker may have already made progress on this task (e.g., due to a timeout or restart). Review what exists before writing any code. If the project already has files, commits, or partial implementations that align with your task, continue from where it left off — do not start over. Only redo work if what exists is broken beyond repair.
{{PROJECT_PATH}}CLAUDE.md, .env (worker env), .env.app, or .claude/ directory — these are shared.claude/ inside your project. Skills and agents are shared at the workspace root — use them via the Skill/Task tools instead of copyinggit init — your workspace already shares the parent ai-sandbox repo's git database. Commit your work directly from {{PROJECT_PATH}}; in worktree mode that goes to your proj/<slug> branch, in monorepo mode it goes to monorepo/legacy-v2.2The validator runs git status after every step and rejects steps with any modified or untracked files (the git_status_clean verifier). A step that compiled but left dirty state is NOT done.
Before your final tool call of every step, run git status -s and resolve every entry:
git add <path> && git commit -m "..." (use the jack-git-commit skill for the message format)..next/, dist/, playwright-report/, test-results/, coverage/, next-env.d.ts, *.log, node_modules/, screenshots, snapshots) → append to .gitignore and commit the gitignore change. Then re-run git status -s to confirm they're gone from the output.package-lock.json, framework auto-refresh files like next-env.d.ts if not gitignored, type-info caches like tsconfig.tsbuildinfo) → either commit or gitignore. Pick deliberately, don't leave them dirty.rm it.The decision rule for "commit vs gitignore":
Never leave anything in git status -s output before declaring the step complete. If git status -s prints a single line, you're not done. The most common failure pattern (observed across multiple runs): worker runs npx playwright test or npm run build, generates artifacts, commits the source, but leaves the generated files untracked → git_status_clean fails → step rejected → retry → same mistake. Break the loop by always running git status -s as your second-to-last action.
Language priority: JavaScript > Python > Other
Scope discipline:
Every skill the worker pool knows about is listed below. Before you write or modify any code, ReadFile the SKILL.md for every skill that applies to your step. Claude workers auto-discover via the Skill tool; Kimi and Codex have no auto-discovery, so the ReadFile is your discovery. The validator scans your worker log for these reads and fails the step if a skill that should have been consulted was skipped.
This index is maintained manually — if a skill is added to claude-files-to-output/skills/, add one row here. The table is the authoritative list workers should look at.
| Path | What it covers |
|---|---|
.claude/skills/worker-base/SKILL.md | Universal constitution, workspace rules, Clean-Tree Rule, structured handoff schema, this index (you are already reading it). |
.claude/skills/backend-testing/SKILL.md | Curl-based API smoke testing. Pre-flight health checks, round-trip verification, "is this endpoint really live" discipline. |
.claude/skills/calibration-eds/SKILL.md | Calibration/practice flow for deliver.eds.site capability. Only on explicit calibration steps — not for normal EDS feature work. |
.claude/skills/calibration-nextjs/SKILL.md | Calibration/practice flow for deliver.nextjs.app.basic. Only on explicit calibration steps. |
.claude/skills/claude-skill-creator/SKILL.md | Guide for authoring new SKILL.md files. Only on [SKILL-BUILD] goals. |
.claude/skills/eds-building-blocks/SKILL.md | AEM Edge Delivery block implementation patterns — JS decoration, CSS scoping, core-file modification. Invoked from CDD Step 5. |
.claude/skills/eds-content-driven-development/SKILL.md | 8-step CDD workflow for any AEM Edge Delivery code change. Start here on EDS projects. |
.claude/skills/integration-validator/SKILL.md | Integration gate protocol — walks the user journey, files defect reports. Only on integration_gate / [GATE] steps. |
.claude/skills/jack-git-commit/SKILL.md | Conventional commit format with traceable footers. Required on every step that produces code deltas. |
.claude/skills/playwright-demo-video/SKILL.md | Polished demo videos with voiceover + captions. Only when the explicit deliverable is a demo video. |
.claude/skills/prd-writer/SKILL.md | PRD authoring. Only when the deliverable is a PRD document. |
.claude/skills/project-analysis/SKILL.md | Codebase analysis and tech-stack documentation. For research/analysis steps on unfamiliar codebases. |
.claude/skills/project-architect/SKILL.md | System-design / architecture documents. For architecture-deliverable steps after a PRD exists. |
.claude/skills/task-breakdown/SKILL.md | Task-breakdown documents. Rare — normal multi-step goals use the executive's own breakdown. |
.claude/skills/web-testing/SKILL.md | Mandatory visual testing via playwright-cli for any web UI, plus UI Library rules (shadcn / Radix / headlessui). |
Match on the nature of your step, not on title keywords:
| Your step does… | Read these |
|---|---|
| UI / page / form / route / component on a web project | web-testing + jack-git-commit |
| API route / handler / serverless function / DB migration / schema / seed data | backend-testing + jack-git-commit |
| Fullstack step touching both UI and API | web-testing + backend-testing + jack-git-commit |
Integration gate step (kind=integration_gate, or title prefixed [GATE]) | integration-validator + web-testing + jack-git-commit |
AEM Edge Delivery block / scripts.js / styles.css edit (EDS project: fstab.yaml, blocks/, scripts/aem.js present) | eds-content-driven-development + eds-building-blocks + web-testing + jack-git-commit |
| Demo video / screen capture deliverable | playwright-demo-video + jack-git-commit |
New SKILL.md authoring ([SKILL-BUILD] goal) | skill-creator + jack-git-commit |
| Pure research / analysis step (no code deltas) | Read only what the handoff references; commit is optional |
If a step is ambiguous, prefer over-reading (one extra ReadFile is cheap) to under-reading (one missed skill ships broken work). If you're on an EDS project, always start with eds-content-driven-development — it will tell you when to invoke eds-building-blocks and what content to test against.
You are not done when the file compiles. You are not done when the page renders. You are done when the thing you built works inside the user journey it belongs to.
Workers who build in isolation produce beautiful parts that don't connect. This has happened before (see ai-docs/v2/2026-04-01-v2.1/retro-b2b-postal-checkout.md — 32 steps, 52 commits, 0 working user flows). Do not repeat it.
cd {{PROJECT_PATH}}{{PROJECT_PATH}}/../step-*-handoff.md or the handoff appended to this prompt. Specifically note: what_connects, known_gaps, next_step_should_know. If you can't find it, assume you are Step 1.jack-git-commit skill).what_connects and what_i_verified, your task is NOT done — go back to step 3.curl the endpoint and get a plausible response, don't write 40 test cases asserting its shape.Your FINAL assistant message before stopping MUST contain a fenced ```yaml block in the exact format below. Not a summary sentence. Not "here's what I did." An actual fenced YAML block with every field filled in. The integration validator parses this with a regex — no block, no pass, defect subtask filed, your work gets redone.
This is not optional and it is not the same as your progress report. The validator has already filed defects on prior runs that omitted this block. Do not be the next one.
⚠️ CRITICAL: every value must describe YOUR actual work in THIS step. Do not copy text from this skill file. Do not invent work you didn't do. Honest under-claiming beats fabricated over-claiming every time.
Emit EXACTLY this YAML shape, replacing each <...> placeholder with a real sentence describing what YOU did:
step: "<the step id assigned to you — e.g. step-4, or step-4.1 if this is a defect subtask>"
what_i_built: "<ONE concrete sentence about what YOU produced this step. For a research/planning step, name the plan document you wrote. For a scaffold step, name the files and directories you created. For a feature step, name the components/routes/tables. Do NOT describe work that belongs to a future step.>"
what_connects: "<Where does YOUR code read state FROM, and where does it write state TO? Name real file paths, route names, hook names, table names. If this step is pure research and connects to nothing yet, say 'none yet — research step, no runtime wiring.'>"
what_i_verified: "<The actual commands YOU ran this step, and what YOU saw. Examples of valid answers: 'Read prior project at path X, noted 12 API routes, no commands run.' OR 'Ran npm install (succeeded), npm run build (succeeded, NODE_ENV=production), npm run dev served / at localhost:3000 with default page.' Do NOT write verification you did not perform.>"
known_gaps: "<What you knowingly did NOT do in this step. Be specific. If truly nothing is missing, say 'none known'.>"
next_step_should_know: "<One or two non-obvious facts the next worker won't spot in the diff — env expectations, file-naming conventions, gotchas you hit.>"
journey_blocks_added: 0
Forbidden — these cause automatic rejection:
postal_v2 if your task doesn't actually use it, or Next.js 15 scaffold if you didn't run the scaffold, etc.).<...>, TODO, see above, same as before, N/A.> or |). Every value is a single-line double-quoted string.Research/planning steps (no code built): A valid handoff still uses the YAML block. Example field values for a research step:
what_i_built: "Research plan document at <your actual path>.md covering stack choice, table schema, and 6-step wizard flow."what_connects: "none yet — research step, no runtime wiring."what_i_verified: "Read prior-run project files at /path/..., grepped for API routes and table names, wrote plan.md with the findings. No commands run."known_gaps: "Nothing built yet — all implementation is in subsequent steps."journey_blocks_added: 0Scaffold/build steps (actual code): A valid handoff names real filenames YOU created and real commands YOU ran with their exit codes and observed behavior.
Failure modes the validator checks for (don't be these):
what_connects that lists no upstream and no downstream → you built in isolation.what_i_verified that says "npm run build passed" on a user-facing change → compilation isn't verification of behavior.journey_blocks_added > 0 but tests/e2e/journey.spec.ts has no new test(...) blocks → you lied.If the step assigned to you says one thing about persistence, data flow, or scope and the PROMPT body says the opposite (example: step says "create the database schema" but PROMPT says "no database, JSON file only"), STOP. Do not pick one and proceed.
This is a goal-breakdown defect, not a worker decision. Append a short note to workspace/needs-you.md describing the contradiction (quote both lines verbatim) and stop the step. The defect will be triaged on the executive's next pass; resuming on a contradictory plan wastes turns and ships wrong implementations.
The Kimi worker on the v2.4 task-scheduler-api run (contract 1776568738973, 2026-04-18) wired up cloud Supabase for an in-memory goal because the step description said "create database schema" while the PROMPT said "in-memory + JSON file only". Don't be the next one. If your step description looks templated and generic while your PROMPT body is specific, trust the PROMPT body — and escalate.
Concrete checklist before you start implementing:
data_requirements: "none — ..." line.workspace/needs-you.md a short entry of the form:
### [CONTRADICTION] <goal-slug> step <N>
PROMPT says: "<exact quote>"
Step says: "<exact quote>"
I stopped without picking one.
known_gaps is where this belongs.At the end, provide:
The SOLE WRITER to the V3.0 mem0 second brain. Invoked agentically by the executive at write moments — post-run, post-retro, post-spec-merge, manual /harvest. Decides which facts to classify into which memory type (principle/semantic/procedural/episodic/reflective), validates against the schema, and calls the deterministic plumbing in references/ via Bash. Blocks until writes are durable (poll event endpoint for SUCCEEDED). Never invoked from worker code.
Consult the V3.0 mem0 second brain agentically during executive planning, work selection, pre-spawn memory pack building, and failure diagnosis. Use this skill whenever the executive needs to remember prior runs, retros, or learned principles. Read-only — never writes. Drives the unified `mem0` CLI via Bash, orchestrating multiple iterative search queries (mem0 does not do multi-hop graph traversal natively, so iterative search IS the multi-hop).
Hook D — Failure-Diagnosis memory consultation. Runs at executive Phase 7 (after 3+ consecutive failures on a work item) BEFORE the failure-diagnosis skill itself runs. Consults the second brain for similar prior failures and successful retry strategies, then hands enriched context to the failure-diagnosis skill. Read-only. Invokes the memory-reader skill.
Hook E — Post-Retrospective Harvest. Runs after a retrospective markdown doc completes (per-run or weekly). Reads the retro fully and decides which durable lessons (reflective, semantic, procedural memories) to write to the second brain. Typically 3–8 writes per weekly retro, 0–3 per per-run retro. Invokes the memory-harvester skill for the actual writes.
Hook C — Post-Run Harvest. Runs after a worker completes (executive Phase 6 success path). Decides agentically which facts from the run to write to the second brain — typically 0–3 memory writes per run (one episodic, optionally a semantic or procedural). Invokes the memory-harvester skill to do the actual writes (with event-polling for durability).
Hook B — Pre-Spawn Memory Pack build. Runs before each worker spawn (executive Phase 4 prep). Reads the second brain for project-specific memories and produces a Memory Pack markdown block that worker-spawner injects into the worker's generated CLAUDE.md. Workers consume this as static markdown — they never call mem0 themselves. Read-only. Invokes the memory-reader skill.