Update to Engineering Project OS
Snapshot Oct 1, 2026 · 06:02 UTC · version 2.2.1
Collection source: not recorded for this historical snapshot. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.
Instructions updated for project-os
Added to an instruction: “canonical JSON, validation after each intake or cancellation, ”. 1 additional added or edited line is in the evidence.
Observed in instructions or declared skills. Runtime behavior has not been tested.
Skill instructions
contract revisions and compaction recovery. Authorized clarifications require no separate permission to record or integrate.
canonical JSON, validation after each intake or cancellation, contract revisions and compaction recovery. Authorized clarifications require no separate permission to record or integrate. - Before final checkpoints, readiness claims or pu...
Supporting 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.m...
[{"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.m...
Compare saved observations
Download comparison JSONFull technical diff · 2 changed fields
changed /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": 4374
},
{
"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": 3137
},
{
"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": 4493
},
{
"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": 6249
},
{
"relative_path": "evals/continuity.json",
"size_in_bytes": 6883
},
{
"relative_path": "evals/discovery.json",
"size_in_bytes": 8010
},
{
"relative_path": "evals/prepare_fixture.py",
"size_in_bytes": 13516
},
{
"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": 7194
},
{
"relative_path": "references/maintenance.md",
"size_in_bytes": 12232
},
{
"relative_path": "scripts/project_os.py",
"size_in_bytes": 258291
}
][
{
"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": 8050
},
{
"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": 4493
},
{
"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": 8010
},
{
"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": 7194
},
{
"relative_path": "references/maintenance.md",
"size_in_bytes": 12962
},
{
"relative_path": "scripts/project_os.py",
"size_in_bytes": 258974
}
]changed /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## 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.\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, contract revisions and compaction recovery. Authorized clarifications require no separate permission to record or integrate.\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"
"---\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## 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.\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, 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.\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"
SKILL.md line diff
--- before +++ after @@ -95,7 +95,8 @@ - Existing user and repository instructions take precedence. - Never overwrite `AGENTS.md`, context, state, a Program, plan, finding, evidence or knowledge blindly. - Keep application code, production configuration, credentials, personal data and runtime artifacts outside Project OS operations unless the user's request independently authorizes them. -- Follow the connected repository WORKFLOW for immediate durable user-request intake, contract revisions and compaction recovery. Authorized clarifications require no separate permission to record or integrate. +- 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. +- Before final checkpoints, readiness claims or publication recommendations, 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. - Record only verified repository facts. Mark unresolved claims as unverified. - Keep project incidents separate from portable lessons. Approve only confirmed, sanitized mechanisms and never require a Project OS release to transfer user knowledge. - Do not imply a daemon, watcher, hook, MCP server, hidden database, automatic upload or automatic cross-repository synchronization.
Full snapshot data
{
"name": "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": 8050
},
{
"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": 4493
},
{
"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": 8010
},
{
"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": 7194
},
{
"relative_path": "references/maintenance.md",
"size_in_bytes": 12962
},
{
"relative_path": "scripts/project_os.py",
"size_in_bytes": 258974
}
],
"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## 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.\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, 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.\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"
}SHA-256: 85728e95ab3269240422d2d8cb43fa875eace0418535a86c08cd7faef6f1473d