Update to Engineering Project OS

{
  "description": "Use this when Codex engineering work must survive multiple sessions, preserve verified repository state or transfer reviewed failure lessons between the user's own projects. Explain, inspect, bootstrap, adopt, validate, upgrade or maintain the repository-local control plane. ChatGPT is a companion for explanations, supplied project files and portable knowledge bundles. Do not use for ordinary one-session coding, generic project management or automatic global knowledge sharing.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 375
    },
    {
      "relative_path": "assets/icon-large.svg",
      "size_in_bytes": 643
    },
    {
      "relative_path": "assets/icon-small.svg",
      "size_in_bytes": 641
    },
    {
      "relative_path": "assets/overlays/react-native-expo.md",
      "size_in_bytes": 1035
    },
    {
      "relative_path": "assets/packs/README.md",
      "size_in_bytes": 1028
    },
    {
      "relative_path": "assets/packs/data.md",
      "size_in_bytes": 833
    },
    {
      "relative_path": "assets/packs/delivery.md",
      "size_in_bytes": 829
    },
    {
      "relative_path": "assets/packs/mobile.md",
      "size_in_bytes": 966
    },
    {
      "relative_path": "assets/packs/service.md",
      "size_in_bytes": 797
    },
    {
      "relative_path": "assets/packs/web.md",
      "size_in_bytes": 850
    },
    {
      "relative_path": "assets/templates/core/.agents/CONTEXT.md",
      "size_in_bytes": 1096
    },
    {
      "relative_path": "assets/templates/core/.agents/README.md",
      "size_in_bytes": 1833
    },
    {
      "relative_path": "assets/templates/core/.agents/STATE.md",
      "size_in_bytes": 739
    },
    {
      "relative_path": "assets/templates/core/.agents/WORKFLOW.md",
      "size_in_bytes": 16307
    },
    {
      "relative_path": "assets/templates/core/.agents/evidence/README.md",
      "size_in_bytes": 420
    },
    {
      "relative_path": "assets/templates/core/.agents/findings/README.md",
      "size_in_bytes": 513
    },
    {
      "relative_path": "assets/templates/core/.agents/findings/findings.json",
      "size_in_bytes": 60
    },
    {
      "relative_path": "assets/templates/core/.agents/knowledge/README.md",
      "size_in_bytes": 547
    },
    {
      "relative_path": "assets/templates/core/.agents/knowledge/project/failures.json",
      "size_in_bytes": 76
    },
    {
      "relative_path": "assets/templates/core/.agents/knowledge/reusable/failures.json",
      "size_in_bytes": 43
    },
    {
      "relative_path": "assets/templates/core/.agents/plans/README.md",
      "size_in_bytes": 3707
    },
    {
      "relative_path": "assets/templates/core/.agents/plans/index.json",
      "size_in_bytes": 138
    },
    {
      "relative_path": "assets/templates/core/.agents/requests.json",
      "size_in_bytes": 60
    },
    {
      "relative_path": "assets/templates/core/AGENTS.md",
      "size_in_bytes": 4978
    },
    {
      "relative_path": "assets/templates/program/PROGRAM.md",
      "size_in_bytes": 561
    },
    {
      "relative_path": "assets/templates/program/history/README.md",
      "size_in_bytes": 417
    },
    {
      "relative_path": "evals/README.md",
      "size_in_bytes": 6691
    },
    {
      "relative_path": "evals/continuity.json",
      "size_in_bytes": 8009
    },
    {
      "relative_path": "evals/discovery.json",
      "size_in_bytes": 8368
    },
    {
      "relative_path": "evals/prepare_fixture.py",
      "size_in_bytes": 14954
    },
    {
      "relative_path": "evals/prompts.json",
      "size_in_bytes": 11869
    },
    {
      "relative_path": "evals/submission.json",
      "size_in_bytes": 13959
    },
    {
      "relative_path": "references/bootstrap.md",
      "size_in_bytes": 5075
    },
    {
      "relative_path": "references/knowledge.md",
      "size_in_bytes": 14667
    },
    {
      "relative_path": "references/maintenance.md",
      "size_in_bytes": 21134
    },
    {
      "relative_path": "scripts/project_os.py",
      "size_in_bytes": 296898
    }
  ],
  "name": "project-os",
  "skill_md_contents": "---\nname: project-os\ndescription: Use this when Codex engineering work must survive multiple sessions, preserve verified repository state or transfer reviewed failure lessons between the user's own projects. Explain, inspect, bootstrap, adopt, validate, upgrade or maintain the repository-local control plane. ChatGPT is a companion for explanations, supplied project files and portable knowledge bundles. Do not use for ordinary one-session coding, generic project management or automatic global knowledge sharing.\n---\n\n# Project OS\n\nEngineering Project OS was built for Codex. Create and maintain a small repository control plane that lets Codex resume real engineering work from visible state without changing application behavior unless the user separately asks for application work. ChatGPT can use the same skill as a companion over project material supplied in the conversation.\n\n## Invocation boundary\n\nIn Codex, `$project-os` explicitly selects the bundled skill. In ChatGPT, `@Engineering Project OS` explicitly selects the plugin or bundled skill. The request text is ordinary natural language in any language. It is not a shell command, environment variable, rigid command grammar or persistent mode.\n\nInstalling the plugin makes the skill available in Codex and exposes its companion workflow in ChatGPT. It does not modify a repository. Once Project OS is connected, ordinary Codex engineering requests follow applicable `AGENTS.md` instructions without requiring `$project-os`.\n\nUse this skill only for Project OS requests. The host may expose it automatically when the installed plugin is selected or the request clearly matches, but do not apply it to unrelated coding work.\n\nBefore inspecting or changing a repository, identify the available project input. In Codex, use the repository workspace selected for the current task and accept an explicit path to another schema 5 repository as a read-only knowledge source. In ChatGPT, setup advice and a new starter package may begin from the user's project description, selected project files or an archive provided in the current chat. Ask only for the missing details required to choose a safe setup and mark conclusions that are not backed by files as unverified. Reviewing, validating, repairing, adopting or upgrading an existing Project OS setup requires the relevant repository files, normally `AGENTS.md` and `.agents/`; ask for them when they are missing. Knowledge import requires an approved reusable bundle plus the destination Project OS context. Knowledge export requires the source reusable registry. Never inspect an empty host workspace or claim that the plugin is unavailable. Installation alone does not attach or connect a repository on either surface.\n\n## Everyday knowledge requests\n\nIn a connected repository, ordinary development follows repository instructions that require Codex to record findings discovered during the task without a separate save request. Keep evidence, hypotheses and confirmed mechanisms distinct; prepare project lessons only after confirmation. This is agent-led work, not a background scan or a guarantee of exhaustive discovery.\n\nUse the connected WORKFLOW's required writeback before any engineering response or returned project snapshot, including bounded repairs and ChatGPT companion operations. A reproduced user-reported defect is a finding too. Save actual evidence with `finding record`, update the checkpoint through `checkpoint --draft` or guarded plan completion and pass `checkpoint --check`; plan completion writes its fresh idle receipt atomically. Successful application tests or knowledge import alone do not persist that handoff. On fresh recovery, verify the saved checkpoint against current files before using its next action. See [maintenance.md](references/maintenance.md) for the deterministic commands.\n\nReturn only a validated snapshot of freshly reread on-disk bytes after all writes and checks. Preserve complete STATE including its HTML receipt, compute each file hash from those exact bytes and reconstruct the exact serialized snapshot into a new temporary directory. Run check and checkpoint --check on that reconstructed copy and compare original source hashes again after export. Never assemble returned files from drafts, cached variables or rendered Markdown. An exported-file mismatch is NOT_READY even when the source check reported CURRENT; deliver only the validated snapshot file. The connected WORKFLOW and maintenance reference give the full export protocol.\n\nWhen the user asks to reuse accumulated lessons in another repository, treat that as an outcome to carry through, not a request for a manual command catalog. Read [knowledge.md](references/knowledge.md), inspect the destination and the read-only source, handle any required setup and preparation, select lessons that fit the destination and show one batch review of lesson changes. This approval-dependent outcome needs a small plan: route its request and later approval to the same contract, then verify gates and mark the requests implemented before guarded completion. Captured requests are unresolved even if their decision text says completed. After approval, finish the reviewed transfer and validate the result. If the source has only confirmed findings or project lessons, prepare sanitized proposals outside both repositories and approve matching entries directly into the destination; do not modify the source merely to complete a transfer. Keep approval and applicability boundaries explicit.\n\n## Interpret short requests\n\nTreat the following as canonical, memorable prompts rather than parser tokens:\n\n- `overview`: read-only product explanation. No argument or repository input.\n- `help`: read-only menu. No argument.\n- `inspect`: read-only repository and setup inspection. No argument.\n- `bootstrap`: create Standard. No argument.\n- `adopt`: map compatible existing records. No argument.\n- `check`: read-only deterministic validation. No argument.\n- `repair`: repair verified Project OS errors. Require an error or scope if it is not already clear.\n- `upgrade`: upgrade to the installed release. No argument.\n- `program start: <initiative>`: require the initiative.\n- `program status`: read-only status. No argument.\n- `program close completed`: require complete exit evidence.\n- `program close stopped: <reason>`: require a reason.\n- `plan open: <outcome>`: require one observable outcome.\n- `plan checkpoint`, `plan complete`: require an active plan. Completion uses the guarded helper and atomically writes a current idle checkpoint receipt.\n- `plan status[: <plan-id>]`: read-only gate and request report; require an ID when no single active plan exists.\n- `plan resume[: <plan-id>]`: continue the active plan or reactivate a selected blocked plan after verifying its blocker is resolved. Require a plan ID when the selection is ambiguous.\n- `plan block: <reason>`, `plan supersede: <reason>`: require a reason.\n- `finding add: <observation>`: require a concrete observation.\n- `knowledge capture: <finding-id>`: require a confirmed finding.\n- `knowledge list: project|reusable`: list the selected user-owned knowledge without writing.\n- `knowledge prepare: <lesson-id|all>`: prepare a sanitized proposal outside the repository and remain read-only.\n- `knowledge approve: <proposal> <lesson-id|all>`: write only the reviewed proposal entries selected by the user.\n- `knowledge revise: <lesson-id>`: prepare a reviewed replacement revision rather than silently overwriting an entry.\n- `knowledge retire: <lesson-id> because <reason>`: retire a reusable lesson while preserving its lifecycle.\n- `knowledge remove: <lesson-id>`: require a separate destructive preview and explicit confirmation, then refuse removal when the lesson belongs to a replacement chain.\n- `knowledge export: <destination>`: export approved reusable lessons and complete lifecycle chains to a deterministic portable bundle.\n- `knowledge import: <repo-or-bundle>`: preview active lessons applicable to the target plus lifecycle tombstones, then include every linked entry needed to keep selected replacement chains complete.\n- `knowledge import all: <repo-or-bundle>`: explicitly preview every non-draft lesson and lifecycle tombstone before importing.\n- `knowledge propose-shared: <lesson-id>`: deprecated read-only alias for `knowledge prepare` during the 2.1.0 transition.\n\nAdditional text, synonyms, punctuation and another language may refine the same intent. Prefer the clear intended operation over exact wording. A user constraint such as `do not change files` always keeps the request read-only.\n\nFor `overview`, never inspect a repository, ask for files or write anything. Explain that Engineering Project OS was built for Codex and is for developers whose AI-assisted engineering work spans sessions. Lead with the practical benefits: resume from verified repository state, preserve decisions and evidence, preview control-plane changes and turn confirmed failures into user-owned reusable knowledge. Explain that project knowledge stays local while a sanitized lesson moves directly from one user-controlled repository to another or through a portable bundle, always after human review and an explicit import. Do not imply a central database, publication requirement, hidden service or automatic learning. End with the next useful Codex workflow, then mention the ChatGPT companion for supplied files and portable bundles.\n\nFor `help`, never write files or run an applying helper operation. Return a concise menu of every supported short request above, its purpose, required argument and one or two examples. Explicitly separate requests typed in Codex chat from Python helper commands run in Terminal.\n\nIf a request is ambiguous, show the relevant part of help or ask one focused question before any write. If the requested work is unrelated to Project OS, handle it as ordinary repository work and do not create control-plane records merely because the user included the prefix.\n\n## Standard and Program\n\nStandard is the complete default system. Bootstrap always creates Standard and never creates `PROGRAM.md`.\n\nProgram is a temporary umbrella contract for one explicitly started multi-phase initiative. A long task or durable plan alone does not justify Program. Start one only through a clear `program start: <initiative>` request and only after initiative, overall outcome, authority, at least two phases with phase outcomes and exit conditions, evidence requirements, cost boundaries, exclusions and overall exit conditions are complete.\n\nStarting Program does not open a plan. Closing requires no active plan. A completed close requires exit evidence. A stopped close requires a reason. Close archives the exact contract and returns the repository to Standard.\n\nProgram archives are SHA-256 checked and tamper-evident, not technically immutable, signed or remotely protected.\n\nWhen upgrading a closed legacy Program, require its actual closure date in canonical `YYYY-MM-DD` form from repository evidence. Never substitute the upgrade date.\n\n## Route to focused instructions\n\n- For `inspect`, `bootstrap` or `adopt`, read [bootstrap.md](references/bootstrap.md).\n- For `check`, `repair`, `upgrade`, Program lifecycle, request intake or plan lifecycle, read [maintenance.md](references/maintenance.md).\n- For findings or failure knowledge, read [knowledge.md](references/knowledge.md).\n- `overview` and `help` are fully specified above and do not require loading every reference.\n\n## Mutation protocol\n\nFor every operation that may change Project OS files:\n\n1. Inspect the target repository, Git status, applicable instructions and current record owners.\n2. Prepare the intended change and use the matching helper `--dry-run` when available.\n3. Review the complete preview. Stop on ambiguity, unsafe ownership, stale state or conflict.\n4. Apply only the same clean operation.\n5. Run the deterministic checker and report changed files and remaining unverified boundaries.\n\nFor reasoned plan, finding or knowledge edits without a dedicated helper subcommand, produce the equivalent read-only preview before writing and run the checker afterward.\n\n## Shared constraints\n\n- Existing user and repository instructions take precedence.\n- Never overwrite `AGENTS.md`, context, state, a Program, plan, finding, evidence or knowledge blindly.\n- Keep application code, production configuration, credentials, personal data and runtime artifacts outside Project OS operations unless the user's request independently authorizes them.\n- Follow the connected repository WORKFLOW for immediate durable user-request intake, canonical JSON, validation after each intake or cancellation, contract revisions and compaction recovery. Authorized clarifications require no separate permission to record or integrate.\n- Before final checkpoints, readiness claims or publication recommendations for a named durable plan, run plan status --require-ready. Lead with NOT_READY when required acceptance is open; never present source checks or a ZIP as a verified release candidate. Bounded plan-free engineering still requires finding/checkpoint writeback and checkpoint --check.\n- When Codex Review is configured or required, preserve a separate exact-final-commit review gate. Wait for completed code/security reviews and disposition of every remark before merge or publication; green CI is separate. A new source commit invalidates the old review evidence. A blocked delivery-readiness assessment still needs the connected WORKFLOW's checkpoint writeback when local record writes are allowed; forbidding external actions alone does not forbid that save. Explicit read-only or no-file-change requests remain read-only. Follow the repository review guard.\n- Record only verified repository facts. Mark unresolved claims as unverified.\n- Keep project incidents separate from portable lessons. Approve only confirmed, sanitized mechanisms and never require a Project OS release to transfer user knowledge.\n- Do not imply a daemon, watcher, hook, MCP server, hidden database, automatic upload or automatic cross-repository synchronization.\n- Project OS does not grant authority to install dependencies, delete files, commit, push, deploy, publish or contact external systems.\n\nThe helper entrypoint is `scripts/project_os.py` relative to the installed skill directory. Resolve that path from the installed skill, not from the target repository, except when explicitly testing the candidate helper while developing Project OS itself.\n"
}