[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WXWVGMB4HHXTZMJ4SMZQSW":3,"skill-same:01M6WXWVGMB4HHXTZMJ4SMZQSW":100},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":14,"repositoryHtmlUrl":68,"repositoryHomepageUrl":69,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":71,"install":72,"resources":85},"01M6WXWVGMB4HHXTZMJ4SMZQSW","note-management",null,"Captures, reviews, and promotes Note entities — the lightweight knowledge capture primitive in processkit. Notes are quick-capture units (thoughts, insights, questions, references) that are reviewed periodically and promoted to WorkItems, DecisionRecords, or other primitives when they ripen. Use when the user says \"remember this\", \"note that\", \"I had an idea\", or when running a periodic note review session.","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.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fnote-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"note management","management","note","wed","when","title","review session","reviews","insights","quick","artifact","review","references","primitives","decide","work","knowledge","promote","notes","knowledge capture","2026-11-10 10:12:30",false,"---\nname: note-management\ndescription: |\n  Captures, reviews, and promotes Note entities — the lightweight knowledge capture primitive in processkit. Notes are quick-capture units (thoughts, insights, questions, references) that are reviewed periodically and promoted to WorkItems, DecisionRecords, or other primitives when they ripen. Use when the user says \"remember this\", \"note that\", \"I had an idea\", or when running a periodic note review session.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-note-management\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: processkit\n    layer: 2\n    commands:\n      - name: note-management-capture\n        args: \"title\"\n        description: \"Capture a new fleeting note with the given title\"\n      - name: note-management-review\n        args: \"\"\n        description: \"Review all fleeting notes and decide what to promote or discard\"\n      - name: note-management-promote\n        args: \"note-id\"\n        description: \"Promote a fleeting note to a more permanent artifact\"\n---\n\n# Note Management\n\n## Intro\n\nNotes are processkit's capture layer — the place where ideas land\nbefore they are ready to become backlog items, decisions, or\nartifacts. Inspired by the Zettelkasten model: capture fast (fleeting),\nrefine deliberately (permanent), link explicitly, and promote when\nsomething becomes actionable. The review cycle is what gives notes\ntheir value — unreviewed notes are just noise.\n\n## Overview\n\n### Note types\n\nNote types map to the Luhmann\u002FAhrens Zettelkasten taxonomy:\n\n| Type | Luhmann equivalent | When to use | Review horizon |\n|---|---|---|---|\n| **fleeting** | Fleeting note | Quick thought, idea, or observation — not yet refined | Within 1 week |\n| **insight** | Permanent note | A self-contained conclusion or realization; part of the knowledge base — never discarded | Evergreen (not discarded, only promoted or refined) |\n| **reference** | Literature note | Pointer to an external source, with your own summary | Evergreen |\n| **question** | — | An open question you want to revisit | Until answered |\n\nStart with `fleeting` when in doubt. If a note survives a review\nsession unchanged and seems worth keeping, refine and set to `insight`\nor `reference`. **Insight notes are permanent — they are never\ndiscarded, only promoted or further refined.**\n\n### Note file location and format\n\nNotes live in `context\u002Fnotes\u002F` as individual Markdown files with YAML\nfrontmatter:\n\n```\ncontext\u002Fnotes\u002F\n  NOTE-20260408_1432-amber-fox-better-error-messages.md\n  NOTE-20260408_1455-silver-wolf-rag-chunking-question.md\n  ...\n```\n\nFile naming: `{id}.md` where `{id}` is the full ID returned by\n`generate_id(\"Note\", slug_text=title)`. No separate INDEX.md —\nthe SQLite index (via `index-management`) replaces it.\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Note\nmetadata:\n  id: NOTE-20260408_1501-amber-fox-error-field-names\n  created: 2026-04-08\nspec:\n  title: \"Error messages should cite the field that caused the \\\nerror, not just the error code\"\n  type: insight\n  state: captured\n  tags: [ux, error-handling, api-design]\n  review_due: 2026-04-15\n---\n\nWhen a validation error returns `code: 400`, the user has no way to\nknow which field failed. Every error response should include `field`,\n`message`, and a `docs_url` for context. I've seen this pattern\nin Stripe's and GitHub's APIs — it's the right model.\n```\n\n### Capturing a note\n\nWhen the user says something note-worthy (\"remember this\", \"I had\nan idea\", \"note that\"):\n\n1. **Generate the Note ID** via `generate_id(\"Note\", slug_text=title)`\n   → e.g. `NOTE-20260408_1432-amber-fox-better-error-messages`\n2. **Pick the type**: fleeting (quick thought) or one of the specific\n   types if already clear\n3. **Write the title as a self-contained claim or question** — not\n   a topic label. \"Error messages should include the field name\" is\n   a note title; \"Error messages\" is a topic, not a note.\n4. **Set `review_due`**: today + 7 days for fleeting, today + 30 days\n   for insight\u002Fquestion, none for reference\n5. **Write `context\u002Fnotes\u002F{id}.md`** — no INDEX.md update needed\n\nNotes are discovered and queried via the SQLite index\n(`index-management`). To list active notes, use:\n\n```\nquery_entities(kind=\"Note\")\nsearch_entities(text=\"\u003Ckeyword>\")\n```\n\nThere is no hand-maintained INDEX.md — the index is authoritative.\n\n### Running a review session\n\nA periodic review session works through all notes whose\n`review_due` has passed or is within 2 days:\n\nFor each overdue note, make one of four decisions:\n\n**Promote** — the idea is ready to become a real primitive:\n1. Create the downstream entity (WorkItem, DecisionRecord, etc.)\n2. Add `promotes_to: { kind: WorkItem, id: BACK-042 }` to the\n   note frontmatter\n3. Transition the note to `promoted`\n\n**Keep as permanent** — the note is worth keeping but not yet\nactionable:\n1. Refine the body if the capture was rough\n2. Set type to `insight` (permanent note — never discarded) or\n   `reference` (literature note — evergreen)\n3. Transition state to `permanent`\n4. Set `review_due` to null (permanent notes don't expire) or to a\n   far-future date if you want a reminder to link it further\n5. Add `links` to related notes with relation and context sentence\n\n**Archive** — the note is no longer useful:\n1. Transition state to `archived`\n\n**Defer** — not ready to decide yet:\n1. Keep state at `captured`\n2. Extend `review_due` by 7 days\n3. Add a one-line note on why it was deferred\n\n### Linking notes\n\nThe `links` field is how Zettelkasten insight is built. Every link must\nname the relation and provide a context sentence explaining *why* the\nconnection matters — not just *that* it exists. Tags group notes by\ntopic; links with context build arguments.\n\n```yaml\nlinks:\n  - target: NOTE-20260408_1455-SilverWolf-rag-chunking-question\n    relation: elaborates\n    context: \"Both notes address retrieval quality; this note proposes\n      a concrete chunking strategy for the problem identified there.\"\n```\n\n| Relation | When to use |\n|---|---|\n| **elaborates** | This note expands on or adds depth to the target |\n| **contradicts** | This note challenges or refutes the target |\n| **supports** | This note provides evidence for the target |\n| **is-example-of** | This note is a concrete case of an abstract claim |\n| **see-also** | Loosely related; reader may find the target useful |\n| **refines** | This note improves on or supersedes the target |\n| **sourced-from** | This note's ideas draw from the target (for literature notes) |\n\nLinks are directional (from this note → to target). Bidirectional\nlinking is intentional — add the reciprocal link in the target note\nwhen the relationship is symmetric (e.g. two `supports` notes).\n\n### Promotion patterns\n\n| Note type | Common promotion target | Trigger |\n|---|---|---|\n| question | WorkItem (spike), Discussion | The question needs research or a team answer |\n| insight | DecisionRecord | The insight captures a choice that was made |\n| fleeting | WorkItem (task\u002Fchore) | The quick idea turns out to be actionable |\n| reference | Artifact | The source becomes a formal reference material |\n\nThis skill also provides the `\u002Fnote-management-capture` slash command for direct invocation — see `commands\u002Fnote-management-capture.md`. This skill also provides the `\u002Fnote-management-review` slash command for direct invocation — see `commands\u002Fnote-management-review.md`. This skill also provides the `\u002Fnote-management-promote` slash command for direct invocation — see `commands\u002Fnote-management-promote.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Capturing topic labels instead of claims or questions.** \"Error messages\" is not a note — it's a tag. A note's title must be a self-contained claim (\"Error messages should include the field name, not just the error code\") or a specific question (\"Does the auth middleware re-validate tokens on every request?\"). Vague labels create a pile of notes with no re-discoverable content.\n- **Reviewing notes without making a decision.** Reading through notes and doing nothing is not a review — it resets the review clock without advancing the note. Every note in a review session must exit with one of four decisions: promote, keep as permanent, archive, or defer with a reason and new date.\n- **Never archiving notes.** A notes index that only grows and never shrinks stops being useful. Not every idea deserves to become permanent — many are superseded, wrong in retrospect, or simply no longer interesting. Archive aggressively; promoted and permanent notes are the signal.\n- **Promoting a fleeting note without refining it first.** A rough, first-draft thought promoted directly to a DecisionRecord or WorkItem brings the roughness with it. Before promoting, read the note and refine: does the title accurately capture the claim? Is the body complete enough for a newcomer to understand without the original context?\n- **Writing notes that require the original context to make sense.** \"The thing we discussed about the API\" is meaningless six weeks later. A note must be self-contained: include enough context that the note makes sense to the author (or an agent) who has no memory of the conversation or session where the idea was captured.\n- **Not writing the review decision back to the file.** After a\n  review session, every note that was touched must have its `state`,\n  `review_due`, and (if promoted) `promotes_to` fields updated in\n  the file. The SQLite index is kept current by re-indexing, but\n  the file is the source of truth.\n- **Using notes as a dumping ground for everything instead of a capture layer for non-backlog ideas.** Notes are for ideas not yet ready to be backlog items. Things that are clearly tasks should go directly into a WorkItem. Things that are clearly decisions should go into a DecisionRecord. Notes are the intermediate capture for things that haven't crystallized yet — not a general-purpose inbox for all project work.\n\n## Full reference\n\n### Note ID assignment\n\nIDs are generated by `generate_id(\"Note\", slug_text=title)` and\nfollow the standard processkit timestamp-word-pair format:\n`NOTE-YYYYMMDD_HHMM-word-pair[-slug]`\n\nExample: `NOTE-20260408_1432-amber-fox-better-error-messages`\n\nIDs encode the capture time and are globally unique. No counter or\nINDEX.md is needed — the SQLite index replaces both.\n\n### State transitions\n\n```\ncaptured → reviewing → permanent\n                     → promoted  (terminal)\n                     → archived  (terminal)\ncaptured → archived\npermanent → reviewing\npermanent → promoted\npermanent → archived\n```\n\n### Review cadence\n\nSuggested cadence for a solo developer:\n\n| Frequency | Action |\n|---|---|\n| Daily | Capture freely — do not review |\n| Weekly | Review all fleeting notes past their review_due |\n| Monthly | Review all permanent notes; check if any should be promoted |\n| Quarterly | Archive anything in permanent that hasn't been revisited in >90 days |\n\nFor teams, assign a note review owner per sprint or rotate the\nresponsibility on a weekly basis.\n\n### Note template\n\n```markdown\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Note\nmetadata:\n  id: NOTE-{{YYYYMMDD_HHMM}}-{{word-pair}}[-{{slug}}]\n  created: {{date}}\nspec:\n  title: \"{{self-contained claim or question}}\"\n  type: {{fleeting|insight|reference|question}}\n  state: captured\n  tags: []\n  review_due: {{date + 7 days for fleeting, + 30 for question, null for insight\u002Freference}}\n  # links: optional — add when you know related notes\n  # links:\n  #   - target: NOTE-xxx-yyy\n  #     relation: elaborates  # see relation table above\n  #     context: \"One sentence explaining why this connection matters.\"\n---\n\n{{Note body — enough context to understand without memory of the\nsession}}\n```\n\nFile name: `context\u002Fnotes\u002F{id}.md` (the full ID, no extra suffix).\n\n### Relationship to other primitives\n\n| Primitive | How notes relate |\n|---|---|\n| **WorkItem** | Notes often promote to WorkItems when an idea becomes a task |\n| **DecisionRecord** | Insight notes about choices promote to DecisionRecords |\n| **BACKLOG.md** | High-priority, well-understood items go here directly — not in notes |\n| **STANDUPS.md** | Standups reference the work done; notes capture the ideas generated |\n","# Note Management\n\n## Intro\n\nNotes are processkit's capture layer — the place where ideas land\nbefore they are ready to become backlog items, decisions, or\nartifacts. Inspired by the Zettelkasten model: capture fast (fleeting),\nrefine deliberately (permanent), link explicitly, and promote when\nsomething becomes actionable. The review cycle is what gives notes\ntheir value — unreviewed notes are just noise.\n\n## Overview\n\n### Note types\n\nNote types map to the Luhmann\u002FAhrens Zettelkasten taxonomy:\n\n| Type | Luhmann equivalent | When to use | Review horizon |\n|---|---|---|---|\n| **fleeting** | Fleeting note | Quick thought, idea, or observation — not yet refined | Within 1 week |\n| **insight** | Permanent note | A self-contained conclusion or realization; part of the knowledge base — never discarded | Evergreen (not discarded, only promoted or refined) |\n| **reference** | Literature note | Pointer to an external source, with your own summary | Evergreen |\n| **question** | — | An open question you want to revisit | Until answered |\n\nStart with `fleeting` when in doubt. If a note survives a review\nsession unchanged and seems worth keeping, refine and set to `insight`\nor `reference`. **Insight notes are permanent — they are never\ndiscarded, only promoted or further refined.**\n\n### Note file location and format\n\nNotes live in `context\u002Fnotes\u002F` as individual Markdown files with YAML\nfrontmatter:\n\n```\ncontext\u002Fnotes\u002F\n  NOTE-20260408_1432-amber-fox-better-error-messages.md\n  NOTE-20260408_1455-silver-wolf-rag-chunking-question.md\n  ...\n```\n\nFile naming: `{id}.md` where `{id}` is the full ID returned by\n`generate_id(\"Note\", slug_text=title)`. No separate INDEX.md —\nthe SQLite index (via `index-management`) replaces it.\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Note\nmetadata:\n  id: NOTE-20260408_1501-amber-fox-error-field-names\n  created: 2026-04-08\nspec:\n  title: \"Error messages should cite the field that caused the \\\nerror, not just the error code\"\n  type: insight\n  state: captured\n  tags: [ux, error-handling, api-design]\n  review_due: 2026-04-15\n---\n\nWhen a validation error returns `code: 400`, the user has no way to\nknow which field failed. Every error response should include `field`,\n`message`, and a `docs_url` for context. I've seen this pattern\nin Stripe's and GitHub's APIs — it's the right model.\n```\n\n### Capturing a note\n\nWhen the user says something note-worthy (\"remember this\", \"I had\nan idea\", \"note that\"):\n\n1. **Generate the Note ID** via `generate_id(\"Note\", slug_text=title)`\n   → e.g. `NOTE-20260408_1432-amber-fox-better-error-messages`\n2. **Pick the type**: fleeting (quick thought) or one of the specific\n   types if already clear\n3. **Write the title as a self-contained claim or question** — not\n   a topic label. \"Error messages should include the field name\" is\n   a note title; \"Error messages\" is a topic, not a note.\n4. **Set `review_due`**: today + 7 days for fleeting, today + 30 days\n   for insight\u002Fquestion, none for reference\n5. **Write `context\u002Fnotes\u002F{id}.md`** — no INDEX.md update needed\n\nNotes are discovered and queried via the SQLite index\n(`index-management`). To list active notes, use:\n\n```\nquery_entities(kind=\"Note\")\nsearch_entities(text=\"\u003Ckeyword>\")\n```\n\nThere is no hand-maintained INDEX.md — the index is authoritative.\n\n### Running a review session\n\nA periodic review session works through all notes whose\n`review_due` has passed or is within 2 days:\n\nFor each overdue note, make one of four decisions:\n\n**Promote** — the idea is ready to become a real primitive:\n1. Create the downstream entity (WorkItem, DecisionRecord, etc.)\n2. Add `promotes_to: { kind: WorkItem, id: BACK-042 }` to the\n   note frontmatter\n3. Transition the note to `promoted`\n\n**Keep as permanent** — the note is worth keeping but not yet\nactionable:\n1. Refine the body if the capture was rough\n2. Set type to `insight` (permanent note — never discarded) or\n   `reference` (literature note — evergreen)\n3. Transition state to `permanent`\n4. Set `review_due` to null (permanent notes don't expire) or to a\n   far-future date if you want a reminder to link it further\n5. Add `links` to related notes with relation and context sentence\n\n**Archive** — the note is no longer useful:\n1. Transition state to `archived`\n\n**Defer** — not ready to decide yet:\n1. Keep state at `captured`\n2. Extend `review_due` by 7 days\n3. Add a one-line note on why it was deferred\n\n### Linking notes\n\nThe `links` field is how Zettelkasten insight is built. Every link must\nname the relation and provide a context sentence explaining *why* the\nconnection matters — not just *that* it exists. Tags group notes by\ntopic; links with context build arguments.\n\n```yaml\nlinks:\n  - target: NOTE-20260408_1455-SilverWolf-rag-chunking-question\n    relation: elaborates\n    context: \"Both notes address retrieval quality; this note proposes\n      a concrete chunking strategy for the problem identified there.\"\n```\n\n| Relation | When to use |\n|---|---|\n| **elaborates** | This note expands on or adds depth to the target |\n| **contradicts** | This note challenges or refutes the target |\n| **supports** | This note provides evidence for the target |\n| **is-example-of** | This note is a concrete case of an abstract claim |\n| **see-also** | Loosely related; reader may find the target useful |\n| **refines** | This note improves on or supersedes the target |\n| **sourced-from** | This note's ideas draw from the target (for literature notes) |\n\nLinks are directional (from this note → to target). Bidirectional\nlinking is intentional — add the reciprocal link in the target note\nwhen the relationship is symmetric (e.g. two `supports` notes).\n\n### Promotion patterns\n\n| Note type | Common promotion target | Trigger |\n|---|---|---|\n| question | WorkItem (spike), Discussion | The question needs research or a team answer |\n| insight | DecisionRecord | The insight captures a choice that was made |\n| fleeting | WorkItem (task\u002Fchore) | The quick idea turns out to be actionable |\n| reference | Artifact | The source becomes a formal reference material |\n\nThis skill also provides the `\u002Fnote-management-capture` slash command for direct invocation — see `commands\u002Fnote-management-capture.md`. This skill also provides the `\u002Fnote-management-review` slash command for direct invocation — see `commands\u002Fnote-management-review.md`. This skill also provides the `\u002Fnote-management-promote` slash command for direct invocation — see `commands\u002Fnote-management-promote.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Capturing topic labels instead of claims or questions.** \"Error messages\" is not a note — it's a tag. A note's title must be a self-contained claim (\"Error messages should include the field name, not just the error code\") or a specific question (\"Does the auth middleware re-validate tokens on every request?\"). Vague labels create a pile of notes with no re-discoverable content.\n- **Reviewing notes without making a decision.** Reading through notes and doing nothing is not a review — it resets the review clock without advancing the note. Every note in a review session must exit with one of four decisions: promote, keep as permanent, archive, or defer with a reason and new date.\n- **Never archiving notes.** A notes index that only grows and never shrinks stops being useful. Not every idea deserves to become permanent — many are superseded, wrong in retrospect, or simply no longer interesting. Archive aggressively; promoted and permanent notes are the signal.\n- **Promoting a fleeting note without refining it first.** A rough, first-draft thought promoted directly to a DecisionRecord or WorkItem brings the roughness with it. Before promoting, read the note and refine: does the title accurately capture the claim? Is the body complete enough for a newcomer to understand without the original context?\n- **Writing notes that require the original context to make sense.** \"The thing we discussed about the API\" is meaningless six weeks later. A note must be self-contained: include enough context that the note makes sense to the author (or an agent) who has no memory of the conversation or session where the idea was captured.\n- **Not writing the review decision back to the file.** After a\n  review session, every note that was touched must have its `state`,\n  `review_due`, and (if promoted) `promotes_to` fields updated in\n  the file. The SQLite index is kept current by re-indexing, but\n  the file is the source of truth.\n- **Using notes as a dumping ground for everything instead of a capture layer for non-backlog ideas.** Notes are for ideas not yet ready to be backlog items. Things that are clearly tasks should go directly into a WorkItem. Things that are clearly decisions should go into a DecisionRecord. Notes are the intermediate capture for things that haven't crystallized yet — not a general-purpose inbox for all project work.\n\n## Full reference\n\n### Note ID assignment\n\nIDs are generated by `generate_id(\"Note\", slug_text=title)` and\nfollow the standard processkit timestamp-word-pair format:\n`NOTE-YYYYMMDD_HHMM-word-pair[-slug]`\n\nExample: `NOTE-20260408_1432-amber-fox-better-error-messages`\n\nIDs encode the capture time and are globally unique. No counter or\nINDEX.md is needed — the SQLite index replaces both.\n\n### State transitions\n\n```\ncaptured → reviewing → permanent\n                     → promoted  (terminal)\n                     → archived  (terminal)\ncaptured → archived\npermanent → reviewing\npermanent → promoted\npermanent → archived\n```\n\n### Review cadence\n\nSuggested cadence for a solo developer:\n\n| Frequency | Action |\n|---|---|\n| Daily | Capture freely — do not review |\n| Weekly | Review all fleeting notes past their review_due |\n| Monthly | Review all permanent notes; check if any should be promoted |\n| Quarterly | Archive anything in permanent that hasn't been revisited in >90 days |\n\nFor teams, assign a note review owner per sprint or rotate the\nresponsibility on a weekly basis.\n\n### Note template\n\n```markdown\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Note\nmetadata:\n  id: NOTE-{{YYYYMMDD_HHMM}}-{{word-pair}}[-{{slug}}]\n  created: {{date}}\nspec:\n  title: \"{{self-contained claim or question}}\"\n  type: {{fleeting|insight|reference|question}}\n  state: captured\n  tags: []\n  review_due: {{date + 7 days for fleeting, + 30 for question, null for insight\u002Freference}}\n  # links: optional — add when you know related notes\n  # links:\n  #   - target: NOTE-xxx-yyy\n  #     relation: elaborates  # see relation table above\n  #     context: \"One sentence explaining why this connection matters.\"\n---\n\n{{Note body — enough context to understand without memory of the\nsession}}\n```\n\nFile name: `context\u002Fnotes\u002F{id}.md` (the full ID, no extra suffix).\n\n### Relationship to other primitives\n\n| Primitive | How notes relate |\n|---|---|\n| **WorkItem** | Notes often promote to WorkItems when an idea becomes a task |\n| **DecisionRecord** | Insight notes about choices promote to DecisionRecords |\n| **BACKLOG.md** | High-priority, well-understood items go here directly — not in notes |\n| **STANDUPS.md** | Standups reference the work done; notes capture the ideas generated |\n",{"name":5,"metadata":44,"description":64},{"processkit":45},{"id":46,"layer":47,"created":48,"version":49,"category":50,"commands":51,"apiVersion":63},"SKILL-note-management",2,1775606400000,"1.0.0","processkit",[52,55,59],{"args":24,"name":53,"description":54},"note-management-capture","Capture a new fleeting note with the given title",{"args":56,"name":57,"description":58},"","note-management-review","Review all fleeting notes and decide what to promote or discard",{"args":60,"name":61,"description":62},"note-id","note-management-promote","Promote a fleeting note to a more permanent artifact","processkit.projectious.work\u002Fv1","Captures, reviews, and promotes Note entities — the lightweight knowledge capture primitive in processkit. Notes are quick-capture units (thoughts, insights, questions, references) that are reviewed periodically and promoted to WorkItems, DecisionRecords, or other primitives when they ripen. Use when the user says \"remember this\", \"note that\", \"I had an idea\", or when running a periodic note review session.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fnote-management","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":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add projectious-work\u002Fprocesskit --skill note-management",{"tool":78,"command":79},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill note-management",{"tool":81,"command":82},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill note-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fnote-management\u002FSKILL.md",true,[86,92,96],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"commands\u002Fnote-management-capture.md","REFERENCE","参考文档",128,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fnote-management\u002Fcommands\u002Fnote-management-capture.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"commands\u002Fnote-management-promote.md",132,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fnote-management\u002Fcommands\u002Fnote-management-promote.md",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"commands\u002Fnote-management-review.md",143,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fnote-management\u002Fcommands\u002Fnote-management-review.md",[101,127,146,167,184,201],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":112,"publishedAt":39},"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",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,113,114,115,116,117,34,118,119,120,103,121,122,123,124,125,126],"skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":134,"publishedAt":39},"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",[133],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},[20,135,136,137,138,139,117,34,140,141,119,142,22,143,121,144,145],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","deterministic","contract","mode",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":39},"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",[],[20,153,154,114,115,155,117,34,156,157,158,159,121,160,161,162,163,164,165,166],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":39},"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",[],[20,120,174,114,117,175,176,140,177,156,119,178,179,121,180,181,161,182,124,183],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":39},"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",[],[191,192,193,194,117,195,35,196,34,197,198,199,200],"okf","compatibility","okf compatibility","validate","open","format","export","bundles","bundle","import",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":207,"publishedAt":39},"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",[],[20,208,209,114,115,155,117,175,34,118,156,210,119,158,121,181,161,162,211,126],"capability","capability management","queries","changes"]