[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PC67HJCJ7RY7RHCP5Q8W1W":3,"skill-same:01M6PC67HJCJ7RY7RHCP5Q8W1W":97},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":33,"commitSha":60,"skillDirectory":61,"forksCount":13,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":64,"install":65,"resources":78},"01M6PC67HJCJ7RY7RHCP5Q8W1W","project-state-governor",null,"Govern evidence-backed canonical project state across sessions, branches, reviews, and research cycles without inventing product intent.","duc-duy-1612\u002FOnline-Delivery-Systems-Web","duc-duy-1612","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F192231384?v=4","01M6NSDKQQDKVTHZ8DZMZ1VYY6","01M6NSDKW8DDVTQHBT1HBDDJPT",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fproject-state-governor\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"project state governor","state","project","intent","canonical","reviews","project-memory","critical","across","branches","main","memory","community","context-engineering","opencode","multi-agent","project-management","product","documentation","copilot","2026-11-10 10:12:30",false,"---\nname: project-state-governor\ndescription: \"Govern evidence-backed canonical project state across sessions, branches, reviews, and research cycles without inventing product intent.\"\ncategory: project-management\nrisk: critical\nsource: community\nsource_repo: Ghost011118\u002Fproject-state-governor\nsource_type: community\ndate_added: \"2026-08-20\"\nauthor: Ghost011118\ntags: [project-state, project-memory, documentation, governance, context-engineering, multi-agent]\ntools: [claude, cursor, gemini, codex, copilot, opencode]\nlicense: \"Apache-2.0\"\nlicense_source: \"https:\u002F\u002Fgithub.com\u002FGhost011118\u002Fproject-state-governor\u002Fblob\u002Fmain\u002FLICENSE\"\n---\n\n# Project State Governor\n\n## Mission\n\nMaintain the project's durable, evidence-backed state so a competent agent entering a fresh conversation can quickly determine:\n\n- why the project exists;\n- what is authoritative now;\n- what is active, blocked, deferred, or done;\n- what failed and should not be repeated;\n- which decisions and constraints govern future work;\n- what should happen next.\n\nOperate as the project-state and documentation governor, not as the product owner, coding agent, research executor, or release approver.\n\nUse this model:\n\n- Git preserves history.\n- The canonical project-state system preserves current durable knowledge.\n- `AGENTS.md` defines how agents operate.\n- Conversation history is working context, not authoritative project memory.\n- Single source of truth means one canonical state system, not necessarily one giant file.\n\nRead `references\u002Fproject-state-schema.md` when creating or repairing canonical project state.\nRead `references\u002Fpersistence-lifecycle.md` when deciding what to recall, stage, persist, review, or consolidate.\nRead `references\u002Freconstruction-workflow.md` when cleaning fragmented history or contradictory documentation.\nRead `references\u002Fmanifest-routing.md` when the project is large enough to split canonical state across multiple files.\n\n## When to Use This Skill\n\n- Use when resuming a substantial project after conversation, agent, or branch changes.\n- Use when plans, status files, reviews, tests, and implementation evidence disagree.\n- Use when a completion claim must be verified before it becomes durable project state.\n- Use when expensive negative evidence or a recurring lesson should survive future sessions.\n- Use when fragmented project documentation needs bounded consolidation.\n\nDo not use this skill as a substitute for implementation, domain research, product ownership, or release approval.\n\n## Limitations\n\n- It cannot determine undefined business intent or choose among legitimate owner decisions.\n- It requires access to relevant project evidence; unsupported conclusions remain `UNKNOWN`.\n- It does not replace engineering, security, or domain-specific verification workflows.\n- It may modify canonical documentation when authorized, so broad cleanup or deletion must be staged and reviewed before application.\n\n## Worked Example\n\nA feature branch claims that `export-redesign` is complete. The canonical\n`PROJECT_STATE.md` still marks it `ACTIVE`, and its definition of done requires\nboth targeted tests and an integration test.\n\n1. Resolve every applicable `AGENTS.md` for the canonical state file and the\n   evidence paths before reading or changing them.\n2. Verify that the branch was merged and that targeted tests passed.\n3. Record that the required integration test has not run; classify this as an\n   evidence gap rather than inferring success from the merge.\n4. Preserve `export-redesign: ACTIVE`, record the missing integration evidence,\n   and identify running that test as the next authoritative step.\n\nThe durable result is a minimal state delta, not a rewritten history:\n\n```text\nStatus: ACTIVE (unchanged)\nVerified: implementation merged; targeted tests passed\nMissing evidence: required integration test\nNext step: run and evaluate the integration test\n```\n\nOnly after that test satisfies the approved definition of done may the task\ntransition to `DONE`.\n\n## 1. Authority hierarchy\n\nBefore ranking conflicting sources, enforce a hard boundary: no owner or product\ndecision may override applicable law, an actual authorization boundary,\nnon-waivable security or safety constraints, or objective facts. Verify that a\nclaimed constraint is real and applicable; convention, preference, and\nspeculation do not become non-overridable merely by being labelled a risk.\n\nWithin the owner's legitimate decision authority, apply this default order:\n\n1. current explicit owner decision;\n2. current approved requirements and acceptance criteria;\n3. formal product and technical contracts, schemas, APIs, protocols, and risk controls;\n4. tests traceable to authoritative requirements;\n5. current verified implementation behavior;\n6. current canonical project-state records;\n7. historical documentation;\n8. historical review reports;\n9. historical AI conversations, summaries, suggestions, or speculation.\n\nLower-authority evidence must not silently override higher-authority evidence.\n\nTreat code as evidence of current behavior, not automatic proof of intended behavior.\nTreat historical documentation as evidence of prior belief, not automatic proof of current truth.\nTreat reviewer findings as hypotheses until verified.\nTreat prior AI output as non-authoritative unless supported by stronger evidence.\n\nIf materially conflicting evidence leaves multiple legitimate business outcomes, escalate only the smallest unresolved owner decision.\n\n## 2. Canonical state modes\n\nUse the smallest structure that stays clear.\n\n### Compact mode\n\nPrefer for small and medium projects:\n\n```text\nAGENTS.md\nPROJECT_STATE.md\n```\n\n### Scaled mode\n\nUse when `PROJECT_STATE.md` becomes too large, mixes unrelated subsystems, or repeatedly forces irrelevant context loading:\n\n```text\nAGENTS.md\n.project\u002F\n  MANIFEST.md\n  STATE.md\n  DECISIONS.md\n  CONSTRAINTS.md\n  NEGATIVE_EVIDENCE.md\n  areas\u002F\n    \u003Csubsystem>.md\n```\n\nThe files together form one canonical state system.\nDo not split merely for aesthetics.\nDo not duplicate the same fact across canonical files unless one copy is clearly a pointer.\n\nAllow separate durable technical documentation when it has an independent stable purpose, such as README, API\u002Fprotocol specifications, architecture docs, schemas, security policies, runbooks, dataset specifications, legal\u002Fcompliance docs, or user-facing docs.\n\nDo not fragment progress, roadmap, current TODOs, review conclusions, decisions, or GPT session summaries across ad hoc files.\n\n## 3. Classify intent before persisting\n\nUse the smallest fitting type.\n\n### MISSION\nA long-lived reason the project exists. It survives many implementations and experiments.\n\n### SUCCESS_CRITERION\nA durable definition of meaningful project success. Never invent one merely to make a mission measurable.\n\n### WORKSTREAM\nA coherent multi-task initiative with a meaningful end or pause condition.\n\n### MILESTONE\nA bounded intermediate outcome spanning multiple tasks.\n\n### TASK\nBounded work with a recognizable closure condition.\n\n### RESEARCH_HYPOTHESIS\nA falsifiable proposition requiring evidence. A failed hypothesis does not fail the mission.\n\n### DECISION\nAn owner-approved or objectively established choice that materially constrains future work.\n\n### CONSTRAINT\nA technical, business, risk, authorization, compatibility, data, research-integrity, or operational rule future work must respect.\n\n### BLOCKER\nA confirmed condition preventing meaningful progress.\n\n### DEFERRED\nReal work intentionally postponed.\n\n### QUESTION\nPersist only if unresolved status materially affects future work.\n\n### LESSON\nA concise, validated pitfall or correction worth retaining because future agents are likely to repeat an expensive mistake.\n\n## 4. Closure and hierarchy\n\nClassify goals using this default test:\n\n- one clear code\u002Fconfiguration change can finish it -> `TASK`;\n- multiple tasks are required but a bounded intermediate finish exists -> `MILESTONE` or `WORKSTREAM`;\n- it is an ongoing strategic objective across many iterations -> `MISSION` or long-term `WORKSTREAM`;\n- experimentation is required to determine truth -> `RESEARCH_HYPOTHESIS`.\n\nUse hierarchical completion rather than one global `DONE` claim:\n\n- `SESSION_DOD`: what this execution session promised to complete;\n- `TASK_DOD`: acceptance and verification required for the bounded task;\n- `MILESTONE_DOD`: required child outcomes for the milestone;\n- `WORKSTREAM_DOD`: conditions for the initiative to complete or pause;\n- `MISSION_SUCCESS`: owner-defined project success criteria.\n\nNever infer that a parent is complete merely because a child completed.\n\nExample:\n\n```text\nsession DONE != task DONE\ntask DONE != milestone DONE\nmilestone DONE != workstream DONE\nworkstream COMPLETED != mission success\n```\n\n## 5. Session bootstrap and recall\n\nWhen repository access exists and project-level conclusions are required:\n\n1. read the repository-root `AGENTS.md` when present;\n2. identify candidate paths that may be inspected, written, moved, or deleted;\n3. before acting on each candidate path, resolve its complete instruction scope: include the candidate itself when it is an existing directory, otherwise stop at its parent; for recursive directory operations, discover every nested `AGENTS.md` in the affected subtree before inspecting or mutating that subtree; deeper rules govern only their subtree;\n4. detect compact or scaled canonical-state mode;\n5. in scaled mode, read `.project\u002FMANIFEST.md` first;\n6. read current state\u002Fbrief before historical material;\n7. identify current Git branch and working tree;\n8. inspect relevant recent commits, code, tests, configuration, and contracts;\n9. load domain-specific governance files when applicable;\n10. load only task-relevant canonical area files;\n11. inspect historical documentation only when needed to resolve state or conflict.\n\nUse progressive retrieval. Do not load the whole repository history or every memory file by default.\n\nIf canonical state is missing, reconstruct it from repository evidence rather than fabricating it from conversation alone.\n\n## 6. Provenance and confidence\n\nFor durable facts whose reliability materially matters, capture concise provenance and confidence.\n\nPreferred provenance includes:\n\n- owner decision or issue ID;\n- commit SHA;\n- test name\u002Fresult;\n- contract\u002Fschema path;\n- experiment\u002Fcandidate\u002Fmanifest ID;\n- authoritative file path and section.\n\nUse confidence labels only when they add value:\n\n- `CONFIRMED`: directly supported by authoritative evidence;\n- `INFERRED`: best current interpretation, but not directly authoritative;\n- `UNKNOWN`: unresolved or insufficiently supported.\n\nNever persist `INFERRED` as if it were settled fact.\nRepresent material inference explicitly as hypothesis, question, or provisional state.\n\nDo not add provenance noise to obvious low-impact facts.\n\n## 7. Semantic State Diff\n\nAfter meaningful work, ask:\n\n> Did this work create, remove, invalidate, complete, clarify, or materially modify a durable project fact?\n\nPersist when one or more occurred:\n\n- mission or owner-defined success criteria changed;\n- a workstream\u002Fmilestone began, ended, paused, blocked, or materially changed;\n- a task changed lifecycle state;\n- a durable decision was made;\n- an important invariant or constraint was discovered;\n- a blocker appeared or was removed;\n- a research hypothesis changed validated state;\n- negative evidence changed future direction;\n- project phase or roadmap priority materially changed;\n- meaningful debt was explicitly deferred;\n- a historical project belief was proven obsolete;\n- a validated recurring pitfall or owner correction should become a `LESSON`.\n\nDo not persist merely because:\n\n- a conversation occurred;\n- code or files were inspected;\n- commands were run;\n- an intermediate debugging theory appeared;\n- an AI suggested an idea;\n- a reviewer raised an unverified concern;\n- wording changed without semantic consequence;\n- a known fact was repeated.\n\nNo durable state change means no canonical-state write.\n\n## 8. Persistence lifecycle and write gate\n\nUse the lifecycle in `references\u002Fpersistence-lifecycle.md`:\n\n```text\nRECALL -> PROPOSE -> VERIFY -> APPLY -> CONSOLIDATE\n```\n\nNever jump from conversation directly to permanent state when material uncertainty exists.\n\nFor low-risk deterministic updates, apply after evidence verification and a semantic-diff self-check.\n\nRequire owner review or explicit prior authorization before applying changes that:\n\n- redefine mission or success criteria;\n- choose among legitimate business outcomes;\n- delete documentation with uncertain unique value;\n- perform broad\u002Fmass cleanup outside previously authorized scope;\n- convert an inferred state into an owner commitment;\n- accept release, research-integrity, security, legal, or operational risk.\n\nWhen reconstruction or broad cleanup is requested but deletion authority is unclear, stage the cleanup set and report the proposed diff rather than deleting.\n\n## 9. Convert conversations into semantic state, not transcripts\n\nNever archive raw conversation history by default.\n\nDo not persist chronology such as:\n\n> User asked X, GPT suggested Y, then we considered Z.\n\nPersist only the durable semantic result.\n\nIf a long discussion ends in a verified rejection of an expensive research direction, preserve the concise rejection, reason, and evidence reference.\nIf the discussion produced no durable lesson, store nothing.\n\n## 10. Status transitions\n\nUse these defaults unless the project defines authoritative alternatives.\n\nTasks:\n\n- `PROPOSED`\n- `ACTIVE`\n- `BLOCKED`\n- `DONE`\n- `CANCELLED`\n- `DEFERRED`\n\nResearch hypotheses:\n\n- `PROPOSED`\n- `ACTIVE`\n- `SUPPORTED`\n- `REJECTED`\n- `INCONCLUSIVE`\n- `INVALIDATED`\n- `FORWARD_ONLY`\n\nWorkstreams:\n\n- `PLANNED`\n- `ACTIVE`\n- `BLOCKED`\n- `COMPLETED`\n- `PAUSED`\n- `CANCELLED`\n\nDo not invent new status vocabularies unless necessary.\n\n## 11. Completion claims\n\nNever mark a task `DONE` merely because code was written or an agent says it is finished.\n\nBefore accepting a completion claim:\n\n1. identify the relevant DoD level;\n2. identify authoritative acceptance criteria;\n3. verify implementation\u002Fbuild\u002Ftest\u002Fintegration evidence appropriate to the task;\n4. verify required decisions\u002Fdependencies are resolved;\n5. ensure no child-only completion is being promoted to a parent-level claim;\n6. record only the resulting durable state transition.\n\nIf verification is incomplete, do not change lifecycle status based on the\ncompletion claim. Preserve the item's existing status and record the missing\nevidence or blocker separately; transition status only when independent\nevidence supports that change.\n\n## 12. Documentation, branch, and evidence hygiene\n\n- Follow `references\u002Freconstruction-workflow.md` to classify status documents, resolve historical conflicts, and stage cleanup without losing unique durable information.\n- Keep branch-local implementation state branch-local until it is merged or accepted under project rules; never blend divergent branches silently.\n- Preserve only decision-relevant negative evidence and recurring lessons. Git remains the detailed historical archive.\n- Consolidate duplicate and obsolete state when it impairs retrieval, but stage any deletion whose significance is uncertain.\n- Never persist secrets, authentication material, or unnecessary sensitive personal data in canonical project state.\n\n## 13. Coordination with other governors\n\nEngineering governors own technical defect classification, fixes, verification, and release risk. Research governors own protocols, stage gates, experiments, and evidence requirements. Consume their verified outputs as evidence; do not bypass or duplicate those workflows merely to advance project status.\n\n## 14. Owner authority boundary\n\nAutonomously:\n\n- classify evidence;\n- identify duplicate status docs;\n- identify objectively obsolete information;\n- update lifecycle state when completion is objectively verified;\n- compress redundant state;\n- reconcile deterministic factual conflicts;\n- remove clearly redundant generated status docs when deletion is already authorized.\n\nDo not autonomously:\n\n- redefine mission;\n- redefine product semantics;\n- invent acceptance criteria;\n- accept unresolved release\u002Fresearch\u002Fsecurity\u002Flegal risk;\n- choose among multiple legitimate business outcomes;\n- erase uniquely valuable history when significance is uncertain;\n- treat prior AI output as authoritative because an AI wrote it.\n\nEscalate only the smallest unresolved owner decision.\n\n## 15. Repository reconstruction mode\n\nWhen asked to clean, repair, consolidate, or reconstruct a repository with fragmented history, enter `REPOSITORY_STATE_RECONSTRUCTION` and follow `references\u002Freconstruction-workflow.md`.\n\nDo not use reconstruction as justification for unrelated feature work.\n\n## 16. State update equation\n\nBefore applying canonical state, compute:\n\n```text\nOLD_STATE\n+ VERIFIED_NEW_FACTS\n- INVALIDATED_FACTS\n= NEW_STATE\n```\n\nFor material updates, make the proposed semantic delta explicit before applying it.\nDistinguish `CONFIRMED`, `INFERRED`, and `UNKNOWN` where reliability matters.\n\n## 17. Final reporting\n\nAfter meaningful governance work, report only:\n\n### Project State Changes\nDurable state transitions applied.\n\n### Current Focus\nActive mission\u002Fworkstream\u002Fmilestone\u002Ftask\u002Fresearch direction.\n\n### Remaining Blockers \u002F Decisions\nOnly genuine unresolved blockers or owner decisions.\n\n### Documentation Actions\nCanonical docs changed, staged, consolidated, or removed.\n\n### Evidence Notes\nOnly provenance or confidence caveats that materially affect trust.\n\nIf no durable state changed, say so briefly and do not manufacture an update.\n\n## 18. Anti-patterns\n\nNever:\n\n- dump conversations into project docs;\n- create a new status\u002Freview\u002FTODO file after each session;\n- assume code automatically defines intended behavior;\n- assume reviewer findings are automatically true;\n- persist unsupported inference as settled fact;\n- accumulate completed\u002Fcancelled\u002Fduplicate TODOs indefinitely;\n- confuse session, task, milestone, workstream, and mission completion;\n- declare `DONE` without required verification;\n- keep obsolete status files merely \"for reference\" when Git already preserves them;\n- delete conflicting docs before extracting unique durable information;\n- load every memory file for every task;\n- use documentation cleanup as permission to rewrite unrelated code.\n\nThe objective is not maximum documentation.\nThe objective is minimum sufficient, high-confidence, continuously maintained project knowledge.\n","# Project State Governor\n\n## Mission\n\nMaintain the project's durable, evidence-backed state so a competent agent entering a fresh conversation can quickly determine:\n\n- why the project exists;\n- what is authoritative now;\n- what is active, blocked, deferred, or done;\n- what failed and should not be repeated;\n- which decisions and constraints govern future work;\n- what should happen next.\n\nOperate as the project-state and documentation governor, not as the product owner, coding agent, research executor, or release approver.\n\nUse this model:\n\n- Git preserves history.\n- The canonical project-state system preserves current durable knowledge.\n- `AGENTS.md` defines how agents operate.\n- Conversation history is working context, not authoritative project memory.\n- Single source of truth means one canonical state system, not necessarily one giant file.\n\nRead `references\u002Fproject-state-schema.md` when creating or repairing canonical project state.\nRead `references\u002Fpersistence-lifecycle.md` when deciding what to recall, stage, persist, review, or consolidate.\nRead `references\u002Freconstruction-workflow.md` when cleaning fragmented history or contradictory documentation.\nRead `references\u002Fmanifest-routing.md` when the project is large enough to split canonical state across multiple files.\n\n## When to Use This Skill\n\n- Use when resuming a substantial project after conversation, agent, or branch changes.\n- Use when plans, status files, reviews, tests, and implementation evidence disagree.\n- Use when a completion claim must be verified before it becomes durable project state.\n- Use when expensive negative evidence or a recurring lesson should survive future sessions.\n- Use when fragmented project documentation needs bounded consolidation.\n\nDo not use this skill as a substitute for implementation, domain research, product ownership, or release approval.\n\n## Limitations\n\n- It cannot determine undefined business intent or choose among legitimate owner decisions.\n- It requires access to relevant project evidence; unsupported conclusions remain `UNKNOWN`.\n- It does not replace engineering, security, or domain-specific verification workflows.\n- It may modify canonical documentation when authorized, so broad cleanup or deletion must be staged and reviewed before application.\n\n## Worked Example\n\nA feature branch claims that `export-redesign` is complete. The canonical\n`PROJECT_STATE.md` still marks it `ACTIVE`, and its definition of done requires\nboth targeted tests and an integration test.\n\n1. Resolve every applicable `AGENTS.md` for the canonical state file and the\n   evidence paths before reading or changing them.\n2. Verify that the branch was merged and that targeted tests passed.\n3. Record that the required integration test has not run; classify this as an\n   evidence gap rather than inferring success from the merge.\n4. Preserve `export-redesign: ACTIVE`, record the missing integration evidence,\n   and identify running that test as the next authoritative step.\n\nThe durable result is a minimal state delta, not a rewritten history:\n\n```text\nStatus: ACTIVE (unchanged)\nVerified: implementation merged; targeted tests passed\nMissing evidence: required integration test\nNext step: run and evaluate the integration test\n```\n\nOnly after that test satisfies the approved definition of done may the task\ntransition to `DONE`.\n\n## 1. Authority hierarchy\n\nBefore ranking conflicting sources, enforce a hard boundary: no owner or product\ndecision may override applicable law, an actual authorization boundary,\nnon-waivable security or safety constraints, or objective facts. Verify that a\nclaimed constraint is real and applicable; convention, preference, and\nspeculation do not become non-overridable merely by being labelled a risk.\n\nWithin the owner's legitimate decision authority, apply this default order:\n\n1. current explicit owner decision;\n2. current approved requirements and acceptance criteria;\n3. formal product and technical contracts, schemas, APIs, protocols, and risk controls;\n4. tests traceable to authoritative requirements;\n5. current verified implementation behavior;\n6. current canonical project-state records;\n7. historical documentation;\n8. historical review reports;\n9. historical AI conversations, summaries, suggestions, or speculation.\n\nLower-authority evidence must not silently override higher-authority evidence.\n\nTreat code as evidence of current behavior, not automatic proof of intended behavior.\nTreat historical documentation as evidence of prior belief, not automatic proof of current truth.\nTreat reviewer findings as hypotheses until verified.\nTreat prior AI output as non-authoritative unless supported by stronger evidence.\n\nIf materially conflicting evidence leaves multiple legitimate business outcomes, escalate only the smallest unresolved owner decision.\n\n## 2. Canonical state modes\n\nUse the smallest structure that stays clear.\n\n### Compact mode\n\nPrefer for small and medium projects:\n\n```text\nAGENTS.md\nPROJECT_STATE.md\n```\n\n### Scaled mode\n\nUse when `PROJECT_STATE.md` becomes too large, mixes unrelated subsystems, or repeatedly forces irrelevant context loading:\n\n```text\nAGENTS.md\n.project\u002F\n  MANIFEST.md\n  STATE.md\n  DECISIONS.md\n  CONSTRAINTS.md\n  NEGATIVE_EVIDENCE.md\n  areas\u002F\n    \u003Csubsystem>.md\n```\n\nThe files together form one canonical state system.\nDo not split merely for aesthetics.\nDo not duplicate the same fact across canonical files unless one copy is clearly a pointer.\n\nAllow separate durable technical documentation when it has an independent stable purpose, such as README, API\u002Fprotocol specifications, architecture docs, schemas, security policies, runbooks, dataset specifications, legal\u002Fcompliance docs, or user-facing docs.\n\nDo not fragment progress, roadmap, current TODOs, review conclusions, decisions, or GPT session summaries across ad hoc files.\n\n## 3. Classify intent before persisting\n\nUse the smallest fitting type.\n\n### MISSION\nA long-lived reason the project exists. It survives many implementations and experiments.\n\n### SUCCESS_CRITERION\nA durable definition of meaningful project success. Never invent one merely to make a mission measurable.\n\n### WORKSTREAM\nA coherent multi-task initiative with a meaningful end or pause condition.\n\n### MILESTONE\nA bounded intermediate outcome spanning multiple tasks.\n\n### TASK\nBounded work with a recognizable closure condition.\n\n### RESEARCH_HYPOTHESIS\nA falsifiable proposition requiring evidence. A failed hypothesis does not fail the mission.\n\n### DECISION\nAn owner-approved or objectively established choice that materially constrains future work.\n\n### CONSTRAINT\nA technical, business, risk, authorization, compatibility, data, research-integrity, or operational rule future work must respect.\n\n### BLOCKER\nA confirmed condition preventing meaningful progress.\n\n### DEFERRED\nReal work intentionally postponed.\n\n### QUESTION\nPersist only if unresolved status materially affects future work.\n\n### LESSON\nA concise, validated pitfall or correction worth retaining because future agents are likely to repeat an expensive mistake.\n\n## 4. Closure and hierarchy\n\nClassify goals using this default test:\n\n- one clear code\u002Fconfiguration change can finish it -> `TASK`;\n- multiple tasks are required but a bounded intermediate finish exists -> `MILESTONE` or `WORKSTREAM`;\n- it is an ongoing strategic objective across many iterations -> `MISSION` or long-term `WORKSTREAM`;\n- experimentation is required to determine truth -> `RESEARCH_HYPOTHESIS`.\n\nUse hierarchical completion rather than one global `DONE` claim:\n\n- `SESSION_DOD`: what this execution session promised to complete;\n- `TASK_DOD`: acceptance and verification required for the bounded task;\n- `MILESTONE_DOD`: required child outcomes for the milestone;\n- `WORKSTREAM_DOD`: conditions for the initiative to complete or pause;\n- `MISSION_SUCCESS`: owner-defined project success criteria.\n\nNever infer that a parent is complete merely because a child completed.\n\nExample:\n\n```text\nsession DONE != task DONE\ntask DONE != milestone DONE\nmilestone DONE != workstream DONE\nworkstream COMPLETED != mission success\n```\n\n## 5. Session bootstrap and recall\n\nWhen repository access exists and project-level conclusions are required:\n\n1. read the repository-root `AGENTS.md` when present;\n2. identify candidate paths that may be inspected, written, moved, or deleted;\n3. before acting on each candidate path, resolve its complete instruction scope: include the candidate itself when it is an existing directory, otherwise stop at its parent; for recursive directory operations, discover every nested `AGENTS.md` in the affected subtree before inspecting or mutating that subtree; deeper rules govern only their subtree;\n4. detect compact or scaled canonical-state mode;\n5. in scaled mode, read `.project\u002FMANIFEST.md` first;\n6. read current state\u002Fbrief before historical material;\n7. identify current Git branch and working tree;\n8. inspect relevant recent commits, code, tests, configuration, and contracts;\n9. load domain-specific governance files when applicable;\n10. load only task-relevant canonical area files;\n11. inspect historical documentation only when needed to resolve state or conflict.\n\nUse progressive retrieval. Do not load the whole repository history or every memory file by default.\n\nIf canonical state is missing, reconstruct it from repository evidence rather than fabricating it from conversation alone.\n\n## 6. Provenance and confidence\n\nFor durable facts whose reliability materially matters, capture concise provenance and confidence.\n\nPreferred provenance includes:\n\n- owner decision or issue ID;\n- commit SHA;\n- test name\u002Fresult;\n- contract\u002Fschema path;\n- experiment\u002Fcandidate\u002Fmanifest ID;\n- authoritative file path and section.\n\nUse confidence labels only when they add value:\n\n- `CONFIRMED`: directly supported by authoritative evidence;\n- `INFERRED`: best current interpretation, but not directly authoritative;\n- `UNKNOWN`: unresolved or insufficiently supported.\n\nNever persist `INFERRED` as if it were settled fact.\nRepresent material inference explicitly as hypothesis, question, or provisional state.\n\nDo not add provenance noise to obvious low-impact facts.\n\n## 7. Semantic State Diff\n\nAfter meaningful work, ask:\n\n> Did this work create, remove, invalidate, complete, clarify, or materially modify a durable project fact?\n\nPersist when one or more occurred:\n\n- mission or owner-defined success criteria changed;\n- a workstream\u002Fmilestone began, ended, paused, blocked, or materially changed;\n- a task changed lifecycle state;\n- a durable decision was made;\n- an important invariant or constraint was discovered;\n- a blocker appeared or was removed;\n- a research hypothesis changed validated state;\n- negative evidence changed future direction;\n- project phase or roadmap priority materially changed;\n- meaningful debt was explicitly deferred;\n- a historical project belief was proven obsolete;\n- a validated recurring pitfall or owner correction should become a `LESSON`.\n\nDo not persist merely because:\n\n- a conversation occurred;\n- code or files were inspected;\n- commands were run;\n- an intermediate debugging theory appeared;\n- an AI suggested an idea;\n- a reviewer raised an unverified concern;\n- wording changed without semantic consequence;\n- a known fact was repeated.\n\nNo durable state change means no canonical-state write.\n\n## 8. Persistence lifecycle and write gate\n\nUse the lifecycle in `references\u002Fpersistence-lifecycle.md`:\n\n```text\nRECALL -> PROPOSE -> VERIFY -> APPLY -> CONSOLIDATE\n```\n\nNever jump from conversation directly to permanent state when material uncertainty exists.\n\nFor low-risk deterministic updates, apply after evidence verification and a semantic-diff self-check.\n\nRequire owner review or explicit prior authorization before applying changes that:\n\n- redefine mission or success criteria;\n- choose among legitimate business outcomes;\n- delete documentation with uncertain unique value;\n- perform broad\u002Fmass cleanup outside previously authorized scope;\n- convert an inferred state into an owner commitment;\n- accept release, research-integrity, security, legal, or operational risk.\n\nWhen reconstruction or broad cleanup is requested but deletion authority is unclear, stage the cleanup set and report the proposed diff rather than deleting.\n\n## 9. Convert conversations into semantic state, not transcripts\n\nNever archive raw conversation history by default.\n\nDo not persist chronology such as:\n\n> User asked X, GPT suggested Y, then we considered Z.\n\nPersist only the durable semantic result.\n\nIf a long discussion ends in a verified rejection of an expensive research direction, preserve the concise rejection, reason, and evidence reference.\nIf the discussion produced no durable lesson, store nothing.\n\n## 10. Status transitions\n\nUse these defaults unless the project defines authoritative alternatives.\n\nTasks:\n\n- `PROPOSED`\n- `ACTIVE`\n- `BLOCKED`\n- `DONE`\n- `CANCELLED`\n- `DEFERRED`\n\nResearch hypotheses:\n\n- `PROPOSED`\n- `ACTIVE`\n- `SUPPORTED`\n- `REJECTED`\n- `INCONCLUSIVE`\n- `INVALIDATED`\n- `FORWARD_ONLY`\n\nWorkstreams:\n\n- `PLANNED`\n- `ACTIVE`\n- `BLOCKED`\n- `COMPLETED`\n- `PAUSED`\n- `CANCELLED`\n\nDo not invent new status vocabularies unless necessary.\n\n## 11. Completion claims\n\nNever mark a task `DONE` merely because code was written or an agent says it is finished.\n\nBefore accepting a completion claim:\n\n1. identify the relevant DoD level;\n2. identify authoritative acceptance criteria;\n3. verify implementation\u002Fbuild\u002Ftest\u002Fintegration evidence appropriate to the task;\n4. verify required decisions\u002Fdependencies are resolved;\n5. ensure no child-only completion is being promoted to a parent-level claim;\n6. record only the resulting durable state transition.\n\nIf verification is incomplete, do not change lifecycle status based on the\ncompletion claim. Preserve the item's existing status and record the missing\nevidence or blocker separately; transition status only when independent\nevidence supports that change.\n\n## 12. Documentation, branch, and evidence hygiene\n\n- Follow `references\u002Freconstruction-workflow.md` to classify status documents, resolve historical conflicts, and stage cleanup without losing unique durable information.\n- Keep branch-local implementation state branch-local until it is merged or accepted under project rules; never blend divergent branches silently.\n- Preserve only decision-relevant negative evidence and recurring lessons. Git remains the detailed historical archive.\n- Consolidate duplicate and obsolete state when it impairs retrieval, but stage any deletion whose significance is uncertain.\n- Never persist secrets, authentication material, or unnecessary sensitive personal data in canonical project state.\n\n## 13. Coordination with other governors\n\nEngineering governors own technical defect classification, fixes, verification, and release risk. Research governors own protocols, stage gates, experiments, and evidence requirements. Consume their verified outputs as evidence; do not bypass or duplicate those workflows merely to advance project status.\n\n## 14. Owner authority boundary\n\nAutonomously:\n\n- classify evidence;\n- identify duplicate status docs;\n- identify objectively obsolete information;\n- update lifecycle state when completion is objectively verified;\n- compress redundant state;\n- reconcile deterministic factual conflicts;\n- remove clearly redundant generated status docs when deletion is already authorized.\n\nDo not autonomously:\n\n- redefine mission;\n- redefine product semantics;\n- invent acceptance criteria;\n- accept unresolved release\u002Fresearch\u002Fsecurity\u002Flegal risk;\n- choose among multiple legitimate business outcomes;\n- erase uniquely valuable history when significance is uncertain;\n- treat prior AI output as authoritative because an AI wrote it.\n\nEscalate only the smallest unresolved owner decision.\n\n## 15. Repository reconstruction mode\n\nWhen asked to clean, repair, consolidate, or reconstruct a repository with fragmented history, enter `REPOSITORY_STATE_RECONSTRUCTION` and follow `references\u002Freconstruction-workflow.md`.\n\nDo not use reconstruction as justification for unrelated feature work.\n\n## 16. State update equation\n\nBefore applying canonical state, compute:\n\n```text\nOLD_STATE\n+ VERIFIED_NEW_FACTS\n- INVALIDATED_FACTS\n= NEW_STATE\n```\n\nFor material updates, make the proposed semantic delta explicit before applying it.\nDistinguish `CONFIRMED`, `INFERRED`, and `UNKNOWN` where reliability matters.\n\n## 17. Final reporting\n\nAfter meaningful governance work, report only:\n\n### Project State Changes\nDurable state transitions applied.\n\n### Current Focus\nActive mission\u002Fworkstream\u002Fmilestone\u002Ftask\u002Fresearch direction.\n\n### Remaining Blockers \u002F Decisions\nOnly genuine unresolved blockers or owner decisions.\n\n### Documentation Actions\nCanonical docs changed, staged, consolidated, or removed.\n\n### Evidence Notes\nOnly provenance or confidence caveats that materially affect trust.\n\nIf no durable state changed, say so briefly and do not manufacture an update.\n\n## 18. Anti-patterns\n\nNever:\n\n- dump conversations into project docs;\n- create a new status\u002Freview\u002FTODO file after each session;\n- assume code automatically defines intended behavior;\n- assume reviewer findings are automatically true;\n- persist unsupported inference as settled fact;\n- accumulate completed\u002Fcancelled\u002Fduplicate TODOs indefinitely;\n- confuse session, task, milestone, workstream, and mission completion;\n- declare `DONE` without required verification;\n- keep obsolete status files merely \"for reference\" when Git already preserves them;\n- delete conflicting docs before extracting unique durable information;\n- load every memory file for every task;\n- use documentation cleanup as permission to rewrite unrelated code.\n\nThe objective is not maximum documentation.\nThe objective is minimum sufficient, high-confidence, continuously maintained project knowledge.\n",{"name":5,"risk":30,"tags":48,"tools":51,"author":56,"source":35,"license":14,"category":39,"date_added":57,"description":7,"source_repo":58,"source_type":35,"license_source":59},[49,29,41,50,36,38],"project-state","governance",[52,53,54,55,42,37],"claude","cursor","gemini","codex","Ghost011118","2026-08-20","Ghost011118\u002Fproject-state-governor","https:\u002F\u002Fgithub.com\u002FGhost011118\u002Fproject-state-governor\u002Fblob\u002Fmain\u002FLICENSE","f3312ba749561b6159f477dbfc9313c875d40a56",".agents\u002Fskills_archive\u002Fproject-state-governor","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612","2026-10-25 23:50:58",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill project-state-governor",{"tool":71,"command":72},"bunx","bunx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill project-state-governor",{"tool":74,"command":75},"pnpm","pnpm dlx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill project-state-governor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fproject-state-governor\u002FSKILL.md",true,[79,85,89,93],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fmanifest-routing.md","REFERENCE","参考文档",1646,"https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fproject-state-governor\u002Freferences\u002Fmanifest-routing.md",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fpersistence-lifecycle.md",2823,"https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fproject-state-governor\u002Freferences\u002Fpersistence-lifecycle.md",{"path":90,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fproject-state-schema.md",4852,"https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fproject-state-governor\u002Freferences\u002Fproject-state-schema.md",{"path":94,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Freconstruction-workflow.md",5779,"https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fproject-state-governor\u002Freferences\u002Freconstruction-workflow.md",[98,125,149,173,200,224],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":108,"publishedAt":43},"01M6Q0FA5FZ410Z33Z3TFQ4DBA","zero-trust","Implement zero-trust network architecture. Configure identity-based access, micro-segmentation, and continuous verification. Use when implementing modern security architectures.","MIT","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzero-trust\u002FSKILL.md",[105],{"categoryNo":106,"categoryName":107,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",[109,110,111,112,113,114,100,115,116,117,118,119,35,33,120,30,121,122,123,124],"ZeRO","trust","zero trust","architecture","assessment","verification","segmentation","devops-security","access","configure","only","active","scope","scripts","relevant","implementing",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":43},"01M6Q0F1YZJW3KX5FBKEVZ8CV4","zcode-delegate","Delegate coding tasks to the Z.AI ZCode CLI only when the user explicitly requests it, while the orchestrator retains review and landing responsibility.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzcode-delegate\u002FSKILL.md",[],[132,133,134,135,136,137,138,139,140,141,142,143,144,119,145,35,146,147,30,148],"delegate","zcode","zcode delegate","review","cli","orchestration","tasks","run","Bash","model","node","read","orchestrator","files","desktop app","app","agent-orchestration",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":43},"01M6Q0ETK41VGNMYEXW0T00AJN","youtube-transcript","Fetch YouTube transcripts through DeepAPI or local fallback tooling and save clean text output.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript\u002FSKILL.md",[],[156,157,158,159,160,55,161,162,163,164,165,166,167,35,33,168,169,170,171,172],"transcript","youtube transcript","youtube","safe","github","research","license","https","text","fetch","tooling","clean","local","output","deepapi","youtube transcripts","blob",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":190,"publishedAt":43},"01M6Q0EPPH2PVMDW40017F8WX0","youtube-transcript-skills","Fetch YouTube video transcripts, search videos\u002Fchannels, browse channels, and extract playlists via the getyoutubetranscript.com API - free tier, no card required.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript-skills\u002FSKILL.md",[179,182,185],{"categoryNo":180,"categoryName":181,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":183,"categoryName":184,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":186,"categoryName":187,"taxonomyType":188,"taxonomyTypeDesc":189},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[156,157,158,191,159,54,160,55,162,192,193,194,195,165,196,35,33,197,198,199],"youtube transcript skills","search","api","Video","browse","api-integration","free","card","channels",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":210,"publishedAt":43},"01M6Q0EAB96PX83W5PTE8A0R8D","youtube-notetaker","Turn YouTube talks into local study notes with slides, transcripts, editable annotations, and a markdown-backed viewer.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-notetaker\u002FSKILL.md",[206,209],{"categoryNo":207,"categoryName":208,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":183,"categoryName":184,"taxonomyType":20,"taxonomyTypeDesc":21},[158,211,212,136,159,213,214,215,216,162,194,217,218,219,220,33,221,168,222,223],"youtube notetaker","notetaker","workflow","official","notes","code","markdown","slides","annotations","README","study","dair-academy","viewer",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":231,"publishedAt":43},"01M6Q0E55F0GW5MX48V8HXS8B5","youtube-full","Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-full\u002FSKILL.md",[230],{"categoryNo":180,"categoryName":181,"taxonomyType":20,"taxonomyTypeDesc":21},[232,158,233,234,159,54,192,235,236,193,194,195,165,237,196,35,33,197,238,171],"youtube full","full","google","server","dlp","credits","automatic"]