[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X3V2PPRZJBES9TEGRDCPJS":3,"skill-same:01M6X3V2PPRZJBES9TEGRDCPJS":120},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":73,"commitSha":74,"skillDirectory":75,"forksCount":14,"repositoryHtmlUrl":76,"repositoryHomepageUrl":77,"ownerHtmlUrl":78,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":79,"install":80,"resources":93},"01M6X3V2PPRZJBES9TEGRDCPJS","event-log",null,"Append-only event log — the probabilistic record of everything that happened in the project. Use whenever something notable happens that the project should remember — work items created\u002Ftransitioned, decisions recorded, bindings changed, incidents occurred, releases shipped.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"event log","event","log","project","Existing","v1","incidents","keep","events","id","fresh","remember","query","releases","only","use","append","decisions","work","sqlite","2026-11-10 10:12:30",false,"---\nname: event-log\ndescription: |\n  Append-only event log — the probabilistic record of everything that happened in the project. Use whenever something notable happens that the project should remember — work items created\u002Ftransitioned, decisions recorded, bindings changed, incidents occurred, releases shipped.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-event-log\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: process\n    layer: 0\n    uses:\n      - skill: index-management\n        purpose: Query existing entities and keep the SQLite index fresh after writes.\n      - skill: id-management\n        purpose: Allocate unique entity identifiers via central ID generation.\n    provides:\n      primitives: [LogEntry]\n      mcp_tools: [log_event, query_events, recent_events]\n      templates: [logentry]\n---\n\n# Event Log\n\n## Intro\n\nThe event log is the project's append-only history of significant events. Every\ntime a work item changes state, a decision is recorded, an actor is assigned,\nor an incident occurs, a `LogEntry` file captures what happened, when, and\nwho caused it. LogEntries are never edited — corrections are added as new\nentries.\n\n> **MCP server.** This skill ships a self-contained MCP server at\n> `mcp\u002Fserver.py` (PEP 723 script — requires `uv` and Python ≥ 3.10 on\n> PATH). Agent harnesses reach its tools by reading a single MCP config\n> file at startup, so the contents of `mcp\u002Fmcp-config.json` must be merged\n> into the harness's MCP config and placed at the harness-specific path\n> before this skill is usable. If processkit was installed by an installer,\n> that wiring is the installer's responsibility; if processkit was\n> installed manually, the project owner must do it by hand.\n\n## Overview\n\n### When to write a LogEntry\n\nWrite a LogEntry whenever you do something the project should be able to\nreconstruct later. Typical triggers:\n\n- A WorkItem was created, transitioned, reassigned, or completed\n- A DecisionRecord was proposed, accepted, or superseded\n- A Binding was created or ended (role changed, scope reassigned)\n- An external event was observed (deploy, incident, outage, release)\n- A process step began or completed\n- An automated check passed or failed at a gate\n\nIf you are asking \"should I log this?\", the answer is almost always yes.\nOver-logging is cheap; under-logging erases history.\n\n### Shape of a LogEntry\n\nEvery LogEntry is a YAML-frontmatter Markdown file:\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: LogEntry\nmetadata:\n  id: LOG-\u003Cgenerated-id>\n  created: \u003Cnow>\nspec:\n  event_type: workitem.transitioned\n  timestamp: \u003Cwhen-it-happened>\n  actor: ACTOR-alice\n  subject: BACK-calm-fox\n  subject_kind: WorkItem\n  summary: \"Moved BACK-calm-fox from in-progress to review\"\n  details:\n    from_state: in-progress\n    to_state: review\n---\n\nOptional body: human-readable narrative, context, links.\n```\n\n### Workflow\n\n1. Decide on `event_type`. Use dotted lowercase: `workitem.created`,\n   `decision.accepted`, `binding.ended`, `incident.started`. Conventions emerge\n   per project — write new types freely; the index MCP server (Phase 3) will\n   surface them.\n2. Fill in `actor` (who), `subject` + `subject_kind` (what it affected),\n   `timestamp` (when the event occurred — distinct from `metadata.created`\n   which is when the log file was written).\n3. Write a one-line `summary`. This is what appears in timelines and queries.\n4. Put anything structured in `details`. Freeform object.\n5. Save the file to `context\u002Flogs\u002F` (or whatever directory the project uses).\n\n### Never edit a LogEntry\n\nIf you realize a LogEntry was wrong, do not edit it. Write a new LogEntry with\n`event_type: logentry.corrected` and reference the original in `details.corrects`.\nThe original stays as historical record.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Editing a LogEntry instead of writing a correction.** LogEntries\n  are append-only. If you discover a previous entry was wrong, write\n  a NEW entry with `event_type: logentry.corrected` and reference\n  the original via `details.corrects`. Editing the original silently\n  rewrites history.\n- **Skipping LogEntry writes after hand-edits.** When you bypass an\n  MCP server and edit an entity file directly, you also have to\n  write the corresponding LogEntry yourself. The audit trail relies\n  on it. Forgetting causes the index and the event log to disagree\n  about what happened.\n- **Logging every file save as an event.** LogEntries are signal,\n  not noise. If you save the same file three times in a minute\n  fixing typos, that's one logical edit, not three events. Log the\n  logical operation, not the keystrokes.\n- **Using vague event_type values.** Use dotted lowercase\n  `\u003Cnoun>.\u003Cverb-past>` (e.g., `workitem.transitioned`,\n  `decision.recorded`). Free-form strings like \"stuff happened\"\n  break event filtering and make the audit trail un-queryable.\n- **Putting structured data in the body instead of `details`.** The\n  `details` field is the structured payload that downstream queries\n  parse. Putting \"transitioned from backlog to in-progress\" in the\n  body and leaving `details` empty hides the data from\n  `query_events`.\n- **Hand-rolling timestamps.** Use the current UTC time in ISO 8601\n  format from a real clock, never a fabricated value. Wrong\n  timestamps poison time-range queries.\n- **Logging events for entities that don't exist.** Verify via\n  `get_entity(subject)` before logging — referencing a non-existent\n  ID creates an orphaned event the index can't link back to anything.\n\n## Full reference\n\n### event_type conventions\n\nUse dotted, lowercase, `\u003Csubject>.\u003Cverb-past>` names. Examples that are already\nwell-established:\n\n| event_type                | When to emit                                                 |\n|---------------------------|--------------------------------------------------------------|\n| `workitem.created`        | New WorkItem file written                                    |\n| `workitem.transitioned`   | WorkItem state changed; include `from_state`\u002F`to_state`      |\n| `workitem.assigned`       | WorkItem assignee changed                                    |\n| `workitem.linked`         | Cross-reference or parent\u002Fchild relationship added           |\n| `workitem.completed`      | WorkItem reached a terminal state (done\u002Fcancelled)           |\n| `decision.proposed`       | New DecisionRecord in `proposed` state                       |\n| `decision.accepted`       | DecisionRecord transitioned to `accepted`                    |\n| `decision.superseded`     | DecisionRecord transitioned to `superseded`                  |\n| `binding.created`         | New Binding written                                          |\n| `binding.ended`           | Binding `valid_until` reached or Binding deleted             |\n| `process.step.started`    | A step in a declared process began                           |\n| `process.step.completed`  | A step in a declared process ended                           |\n| `gate.passed` \u002F `gate.failed` | A gate validation result                                 |\n| `incident.started` \u002F `incident.resolved` | Incident lifecycle                            |\n| `release.shipped`         | A release was published                                      |\n| `logentry.corrected`      | Correction of an earlier LogEntry (referenced in details)    |\n| `session.handover`        | End-of-session handover written before container shutdown    |\n| `session.standup`         | Standup update recording what was done and what comes next   |\n\n### Fields\n\n- `event_type` (required): See above.\n- `timestamp` (required): ISO 8601 UTC. When the event *occurred*, not when\n  it was *logged*. If the agent is logging retroactively, use the original\n  event time and set `details.logged_late: true`.\n- `actor` (required): `ACTOR-\u003Cid>` for a processkit Actor; raw string for\n  external agents (`\"github-actions\"`, `\"claude-cli\"`, `\"alice@example.com\"`).\n- `subject` (optional): ID of the entity the event concerns. Omit for\n  project-level events.\n- `subject_kind` (optional): The `kind` of the subject entity, for fast\n  filtering in queries.\n- `summary` (required): One line. Human-readable. Appears in timelines.\n- `details` (optional): Structured object with event-specific fields.\n- `correlation_id` (optional): Links related events across a workflow run.\n\n### Session entry types\n\n`session.handover` and `session.standup` are the two session-lifecycle\nentry types. They have a fixed `details` schema:\n\n**`session.handover`** — written at container shutdown or at the user's\nrequest before stopping work. Use the `session-handover` skill to author\nthese; do not write them manually.\n\n```yaml\ndetails:\n  session_date: \"2026-04-08\"        # ISO date of the session being closed\n  current_state: |                  # 2-4 sentences on where things stand\n    ...\n  open_threads:                     # list of unresolved items\n    - \"BACK-042 blocked on auth review\"\n  next_recommended_action: |        # what the next session should pick up first\n    ...\n  branch: \"main\"                    # git branch at handover time\n  commit: \"d56f4c8\"                 # git SHA at handover time\n```\n\n**`session.standup`** — written at the user's request to record progress.\nUse the `standup-context` skill to author these.\n\n```yaml\ndetails:\n  session_date: \"2026-04-08\"\n  done:                             # what was completed in this session\n    - \"Built session-handover skill\"\n  doing:                            # what is in progress right now\n    - \"Extending event-log\"\n  next:                             # what comes next\n    - \"Build standup-context skill\"\n  blockers: []                      # anything blocking progress\n```\n\n### Directory layout\n\nDefault: `context\u002Flogs\u002F` flat. Projects may shard by date in `aibox.toml`:\n\n```toml\n[context.sharding.LogEntry]\nscheme = \"date\"\npattern = \"context\u002Flogs\u002F{year}\u002F{month}\u002F\"\n```\n\nWhen sharded, the index MCP server still sees the full log; only the filesystem\nlayout differs.\n\n### File naming\n\nDefault: `LOG-\u003Cgenerated-id>.md` where the ID format follows the project's\n`aibox.toml` setting. With date-sharded storage, consider including a time\nprefix in the ID (`LOG-2026-04-06T10-30-00-calm-owl.md`) so chronological\nsort matches filesystem order.\n\n### Interaction with the index MCP server\n\nIn Phase 3, the `index-management` MCP server reads all LogEntries into a\nSQLite `events` table and exposes:\n\n- `query_events(event_type?, actor?, subject?, since?, until?)`\n- `recent_events(limit)`\n- `events_for_entity(subject_id)`\n- `timeline(start, end, filters)`\n\nUntil the MCP server exists, agents query by reading files directly — filesystem\nglob + grep is adequate for small projects.\n\n### Relationship to deterministic logging\n\nPer DISC-002, processkit's event log is **all probabilistic** — it is written\nby agents via this skill, not by instrumentation. If an enterprise deployment\nneeds tamper-evident event logs for audit or compliance, that is a governance\nplatform's responsibility, not processkit's. Do not build a second, deterministic\nevent source here.\n","# Event Log\n\n## Intro\n\nThe event log is the project's append-only history of significant events. Every\ntime a work item changes state, a decision is recorded, an actor is assigned,\nor an incident occurs, a `LogEntry` file captures what happened, when, and\nwho caused it. LogEntries are never edited — corrections are added as new\nentries.\n\n> **MCP server.** This skill ships a self-contained MCP server at\n> `mcp\u002Fserver.py` (PEP 723 script — requires `uv` and Python ≥ 3.10 on\n> PATH). Agent harnesses reach its tools by reading a single MCP config\n> file at startup, so the contents of `mcp\u002Fmcp-config.json` must be merged\n> into the harness's MCP config and placed at the harness-specific path\n> before this skill is usable. If processkit was installed by an installer,\n> that wiring is the installer's responsibility; if processkit was\n> installed manually, the project owner must do it by hand.\n\n## Overview\n\n### When to write a LogEntry\n\nWrite a LogEntry whenever you do something the project should be able to\nreconstruct later. Typical triggers:\n\n- A WorkItem was created, transitioned, reassigned, or completed\n- A DecisionRecord was proposed, accepted, or superseded\n- A Binding was created or ended (role changed, scope reassigned)\n- An external event was observed (deploy, incident, outage, release)\n- A process step began or completed\n- An automated check passed or failed at a gate\n\nIf you are asking \"should I log this?\", the answer is almost always yes.\nOver-logging is cheap; under-logging erases history.\n\n### Shape of a LogEntry\n\nEvery LogEntry is a YAML-frontmatter Markdown file:\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: LogEntry\nmetadata:\n  id: LOG-\u003Cgenerated-id>\n  created: \u003Cnow>\nspec:\n  event_type: workitem.transitioned\n  timestamp: \u003Cwhen-it-happened>\n  actor: ACTOR-alice\n  subject: BACK-calm-fox\n  subject_kind: WorkItem\n  summary: \"Moved BACK-calm-fox from in-progress to review\"\n  details:\n    from_state: in-progress\n    to_state: review\n---\n\nOptional body: human-readable narrative, context, links.\n```\n\n### Workflow\n\n1. Decide on `event_type`. Use dotted lowercase: `workitem.created`,\n   `decision.accepted`, `binding.ended`, `incident.started`. Conventions emerge\n   per project — write new types freely; the index MCP server (Phase 3) will\n   surface them.\n2. Fill in `actor` (who), `subject` + `subject_kind` (what it affected),\n   `timestamp` (when the event occurred — distinct from `metadata.created`\n   which is when the log file was written).\n3. Write a one-line `summary`. This is what appears in timelines and queries.\n4. Put anything structured in `details`. Freeform object.\n5. Save the file to `context\u002Flogs\u002F` (or whatever directory the project uses).\n\n### Never edit a LogEntry\n\nIf you realize a LogEntry was wrong, do not edit it. Write a new LogEntry with\n`event_type: logentry.corrected` and reference the original in `details.corrects`.\nThe original stays as historical record.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Editing a LogEntry instead of writing a correction.** LogEntries\n  are append-only. If you discover a previous entry was wrong, write\n  a NEW entry with `event_type: logentry.corrected` and reference\n  the original via `details.corrects`. Editing the original silently\n  rewrites history.\n- **Skipping LogEntry writes after hand-edits.** When you bypass an\n  MCP server and edit an entity file directly, you also have to\n  write the corresponding LogEntry yourself. The audit trail relies\n  on it. Forgetting causes the index and the event log to disagree\n  about what happened.\n- **Logging every file save as an event.** LogEntries are signal,\n  not noise. If you save the same file three times in a minute\n  fixing typos, that's one logical edit, not three events. Log the\n  logical operation, not the keystrokes.\n- **Using vague event_type values.** Use dotted lowercase\n  `\u003Cnoun>.\u003Cverb-past>` (e.g., `workitem.transitioned`,\n  `decision.recorded`). Free-form strings like \"stuff happened\"\n  break event filtering and make the audit trail un-queryable.\n- **Putting structured data in the body instead of `details`.** The\n  `details` field is the structured payload that downstream queries\n  parse. Putting \"transitioned from backlog to in-progress\" in the\n  body and leaving `details` empty hides the data from\n  `query_events`.\n- **Hand-rolling timestamps.** Use the current UTC time in ISO 8601\n  format from a real clock, never a fabricated value. Wrong\n  timestamps poison time-range queries.\n- **Logging events for entities that don't exist.** Verify via\n  `get_entity(subject)` before logging — referencing a non-existent\n  ID creates an orphaned event the index can't link back to anything.\n\n## Full reference\n\n### event_type conventions\n\nUse dotted, lowercase, `\u003Csubject>.\u003Cverb-past>` names. Examples that are already\nwell-established:\n\n| event_type                | When to emit                                                 |\n|---------------------------|--------------------------------------------------------------|\n| `workitem.created`        | New WorkItem file written                                    |\n| `workitem.transitioned`   | WorkItem state changed; include `from_state`\u002F`to_state`      |\n| `workitem.assigned`       | WorkItem assignee changed                                    |\n| `workitem.linked`         | Cross-reference or parent\u002Fchild relationship added           |\n| `workitem.completed`      | WorkItem reached a terminal state (done\u002Fcancelled)           |\n| `decision.proposed`       | New DecisionRecord in `proposed` state                       |\n| `decision.accepted`       | DecisionRecord transitioned to `accepted`                    |\n| `decision.superseded`     | DecisionRecord transitioned to `superseded`                  |\n| `binding.created`         | New Binding written                                          |\n| `binding.ended`           | Binding `valid_until` reached or Binding deleted             |\n| `process.step.started`    | A step in a declared process began                           |\n| `process.step.completed`  | A step in a declared process ended                           |\n| `gate.passed` \u002F `gate.failed` | A gate validation result                                 |\n| `incident.started` \u002F `incident.resolved` | Incident lifecycle                            |\n| `release.shipped`         | A release was published                                      |\n| `logentry.corrected`      | Correction of an earlier LogEntry (referenced in details)    |\n| `session.handover`        | End-of-session handover written before container shutdown    |\n| `session.standup`         | Standup update recording what was done and what comes next   |\n\n### Fields\n\n- `event_type` (required): See above.\n- `timestamp` (required): ISO 8601 UTC. When the event *occurred*, not when\n  it was *logged*. If the agent is logging retroactively, use the original\n  event time and set `details.logged_late: true`.\n- `actor` (required): `ACTOR-\u003Cid>` for a processkit Actor; raw string for\n  external agents (`\"github-actions\"`, `\"claude-cli\"`, `\"alice@example.com\"`).\n- `subject` (optional): ID of the entity the event concerns. Omit for\n  project-level events.\n- `subject_kind` (optional): The `kind` of the subject entity, for fast\n  filtering in queries.\n- `summary` (required): One line. Human-readable. Appears in timelines.\n- `details` (optional): Structured object with event-specific fields.\n- `correlation_id` (optional): Links related events across a workflow run.\n\n### Session entry types\n\n`session.handover` and `session.standup` are the two session-lifecycle\nentry types. They have a fixed `details` schema:\n\n**`session.handover`** — written at container shutdown or at the user's\nrequest before stopping work. Use the `session-handover` skill to author\nthese; do not write them manually.\n\n```yaml\ndetails:\n  session_date: \"2026-04-08\"        # ISO date of the session being closed\n  current_state: |                  # 2-4 sentences on where things stand\n    ...\n  open_threads:                     # list of unresolved items\n    - \"BACK-042 blocked on auth review\"\n  next_recommended_action: |        # what the next session should pick up first\n    ...\n  branch: \"main\"                    # git branch at handover time\n  commit: \"d56f4c8\"                 # git SHA at handover time\n```\n\n**`session.standup`** — written at the user's request to record progress.\nUse the `standup-context` skill to author these.\n\n```yaml\ndetails:\n  session_date: \"2026-04-08\"\n  done:                             # what was completed in this session\n    - \"Built session-handover skill\"\n  doing:                            # what is in progress right now\n    - \"Extending event-log\"\n  next:                             # what comes next\n    - \"Build standup-context skill\"\n  blockers: []                      # anything blocking progress\n```\n\n### Directory layout\n\nDefault: `context\u002Flogs\u002F` flat. Projects may shard by date in `aibox.toml`:\n\n```toml\n[context.sharding.LogEntry]\nscheme = \"date\"\npattern = \"context\u002Flogs\u002F{year}\u002F{month}\u002F\"\n```\n\nWhen sharded, the index MCP server still sees the full log; only the filesystem\nlayout differs.\n\n### File naming\n\nDefault: `LOG-\u003Cgenerated-id>.md` where the ID format follows the project's\n`aibox.toml` setting. With date-sharded storage, consider including a time\nprefix in the ID (`LOG-2026-04-06T10-30-00-calm-owl.md`) so chronological\nsort matches filesystem order.\n\n### Interaction with the index MCP server\n\nIn Phase 3, the `index-management` MCP server reads all LogEntries into a\nSQLite `events` table and exposes:\n\n- `query_events(event_type?, actor?, subject?, since?, until?)`\n- `recent_events(limit)`\n- `events_for_entity(subject_id)`\n- `timeline(start, end, filters)`\n\nUntil the MCP server exists, agents query by reading files directly — filesystem\nglob + grep is adequate for small projects.\n\n### Relationship to deterministic logging\n\nPer DISC-002, processkit's event log is **all probabilistic** — it is written\nby agents via this skill, not by instrumentation. If an enterprise deployment\nneeds tamper-evident event logs for audit or compliance, that is a governance\nplatform's responsibility, not processkit's. Do not build a second, deterministic\nevent source here.\n",{"name":5,"metadata":49,"description":72},{"processkit":50},{"id":51,"uses":52,"layer":14,"created":59,"version":60,"category":61,"provides":62,"apiVersion":71},"SKILL-event-log",[53,56],{"skill":54,"purpose":55},"index-management","Query existing entities and keep the SQLite index fresh after writes.",{"skill":57,"purpose":58},"id-management","Allocate unique entity identifiers via central ID generation.",1775433600000,"1.0.0","process",{"mcp_tools":63,"templates":67,"primitives":69},[64,65,66],"log_event","query_events","recent_events",[68],"logentry",[70],"LogEntry","processkit.projectious.work\u002Fv1","Append-only event log — the probabilistic record of everything that happened in the project. Use whenever something notable happens that the project should remember — work items created\u002Ftransitioned, decisions recorded, bindings changed, incidents occurred, releases shipped.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":81,"prompt":91,"zipAvailable":92},[82,85,88],{"tool":83,"command":84},"npx","npx skills add projectious-work\u002Fprocesskit --skill event-log",{"tool":86,"command":87},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill event-log",{"tool":89,"command":90},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill event-log","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002FSKILL.md",true,[94,100,106,110,114],{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"assets\u002Flogentry.yaml","ASSET","资产文件",757,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002Fassets\u002Flogentry.yaml",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"examples\u002Fworkitem-transitioned.md","REFERENCE","参考文档",1528,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002Fexamples\u002Fworkitem-transitioned.md",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"mcp\u002Fmcp-config.json",190,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002Fmcp\u002Fmcp-config.json",{"path":111,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":112,"sourceHtmlUrl":113},"mcp\u002FSERVER.md",1295,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002Fmcp\u002FSERVER.md",{"path":115,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":118,"sourceHtmlUrl":119},"mcp\u002Fserver.py","SCRIPT","脚本",4053,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fevent-log\u002Fmcp\u002Fserver.py",[121,143,163,181,197,215],{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":128,"publishedAt":44},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[127],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[129,130,131,132,133,134,42,135,136,137,123,138,139,140,29,141,142],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":44},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[149],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[129,151,152,153,154,155,134,42,156,157,136,158,159,160,138,161,162],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":44},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[129,170,171,131,132,172,134,42,26,173,174,36,138,175,25,176,177,178,179,180],"proposition","proposition management","index","world","record","creation","interface","updates","facts","claims","WSJF",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":44},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[129,137,188,131,134,189,190,156,191,26,136,192,193,138,194,31,25,195,29,196],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","measurement","generic",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":44},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[204,205,206,207,134,208,209,210,42,211,212,213,214],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":221,"publishedAt":44},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[129,222,223,131,132,172,134,189,42,135,26,224,136,174,138,31,25,176,225,142],"capability","capability management","queries","changes"]