[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JQ7C3ANN9JFA3YJWVB7Z2":3,"skill-same:01M71JQ7C3ANN9JFA3YJWVB7Z2":65},{"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":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71JQ7C3ANN9JFA3YJWVB7Z2","update-spec-graph",null,"Keeps the Cognee Spec Graph (Component 6) knowledge graph in sync with the repo. Use to update the KG after doc changes (incremental), rebuild it from scratch or after editing the ontology (full), or when recall is stale, the graph looks wrong, or entities are not ontology-anchored.","eposforge\u002Feposforge","eposforge","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279313312?v=4","01M71JPA7XV61GQ0CRFCHTMZY9","01M71JPA8JK1V7CF8DG5RHSGZN",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fupdate-spec-graph\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"update","spec","graph","update spec graph","recall","changes","component","with","knowledge graph","ontology","From Scratch","rebuild","when","entities","use","cognee","knowledge","scratch","editing","repo","2026-11-10 10:12:30",false,"---\nname: update-spec-graph\ndescription: Keeps the Cognee Spec Graph (Component 6) knowledge graph in sync with the repo. Use to update the KG after doc changes (incremental), rebuild it from scratch or after editing the ontology (full), or when recall is stale, the graph looks wrong, or entities are not ontology-anchored.\ntarget_shape_of: procedure-skills-to-programs\n---\n\nUpdates the Cognee knowledge graph that backs the Spec Graph (Component 6) so\nrecall and graph queries reflect the current repo. Handles **both** update\npaths — incremental per-file sync and full corpus rebuild — and decides which\none a given change requires.\n\nThis skill owns *running* the update. Editing the ontology TTL itself is a\nseparate concern owned by [maintain-ontology](..\u002Fmaintain-ontology\u002FSKILL.md):\nedit the TTL there, then come here to rebuild. Adapter-level deployment topology,\nAPI behavior, and recovery procedures live in\n[cognee.md](..\u002F..\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fcognee.md).\n\n## Pick the path first: incremental vs full\n\nThe trigger for the change decides the path. **Get this right before running\nanything** — running incremental after an ontology edit silently leaves the\ngraph half-anchored.\n\n| What changed | Path | Why |\n|---|---|---|\n| Corpus docs only (`*.md`, non-ontology `*.ttl`) | **Incremental** | New\u002Fchanged docs anchor against the already-uploaded ontology; unchanged docs are untouched. |\n| The ontology (`00-vision\u002F01-ontology.ttl`) | **Full rebuild + KG wipe** | Anchoring is not retroactive *and* content-hash dedup skips re-extraction of unchanged docs — only a wipe forces every doc to re-anchor. |\n| Empty \u002F corrupt \u002F from scratch \u002F Ladybug stale-lock | **Full rebuild + KG wipe** | No usable prior state. |\n\n**The asymmetry to remember:** a document edit is incremental; an ontology edit\nis a full rebuild. Cognee resolves the ontology at cognify time per run and does\nnot re-anchor existing nodes, and its content-hash dedup (`PipelineRunAlreadyCompleted`)\nwill silently skip docs whose text did not change — so you cannot re-anchor a\nchanged ontology without wiping the KG.\n\n## Preconditions (both paths)\n\n- `dkr-cgnee-api` container running and healthy (the KG owner; the MCP container\n  is only a proxy — never ingest against it). See cognee.md §Deployment topology.\n- `epos-secrets` on PATH (or at `.eposforge\u002Fsecrets-key-management\u002Fbin\u002F`)\n  to inject `COGNEE_API_URL` \u002F `COGNEE_API_TOKEN`.\n- `uv` available; run from `.eposforge\u002Fspec-graph\u002Fcognee\u002Fsync`.\n- Check the inference budget before a full rebuild (~180K–200K embedding tokens\n  for the full corpus): `.eposforge\u002F.audit\u002Finference-budget-counters.json`.\n- The ontology key is `eposforge` (override via `$COGNEE_ONTOLOGY_KEY`).\n\n## Incremental path (doc changes)\n\n`sync-incremental.sh` computes the diff since the last synced commit and\ndispatches the per-file changes; it always passes `--ontology-key` so cognify\nanchors entities to the ontology.\n\n```bash\nbash \"${EPOSFORGE_HOME:?set EPOSFORGE_HOME}\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fscripts\u002Fsync-incremental.sh\" \u003Cbase-commit>\n```\n\n`\u003Cbase-commit>` = the last commit whose changes are already in the KG.\n\nNotes:\n- The ontology TTL is the **anchor, not a corpus document** — the script\n  excludes it from `--added`\u002F`--modified`. If it changed, you are on the wrong\n  path (use full rebuild).\n- Raw backlog items (`backlog\u002F`, `.eposforge\u002Fbacklog\u002F`, `plans\u002F`) are excluded from the main Spec Graph by default (EF-057). They live in the independent file-based backlog graph. The main graph may still reference backlog *mechanics* via ontology terms. Use aggregate.sh \u002F portfolio-review for backlog GraphRAG views.\n- The incremental path assumes the ontology is already uploaded. If unsure,\n  pass `--upload-ontology 00-vision\u002F01-ontology.ttl` through to cognee-sync\n  once (it is idempotent: delete + re-upload):\n  `bash \"${EPOSFORGE_HOME:?set EPOSFORGE_HOME}\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fscripts\u002Fsync-incremental.sh\" \u003Cbase-commit> --upload-ontology 00-vision\u002F01-ontology.ttl`\n- Pass `--dry-run` through to print planned actions with no API calls.\n- update = delete old `data_id` + add new; the state DB (`sync\u002F.cognee-state.db`)\n  maps `file_path → data_id` and is committed to source. Commit the updated\n  state DB after a successful run.\n\n## Full rebuild path (ontology change, or from scratch)\n\nTwo steps. **Step 1 (KG wipe) is mandatory for an ontology change** — skipping\nit means dedup leaves the old anchoring in place.\n\n### 1. Wipe the KG\n\nPer cognee.md §Recovery procedures (this destroys the entire KG):\n\n```bash\nCOMPOSE_FILE=\u003Cdocker-volume-mounts>\u002Fcognee\u002Fdocker-compose.yml\ndocker compose -f \"$COMPOSE_FILE\" stop dkr-cgnee-api\n# sudo rm -rf \u003Cdocker-volume-mounts>\u002Fcognee\u002Fdata\u002Fcognee_system\n# sudo mkdir -p \u003Cdocker-volume-mounts>\u002Fcognee\u002Fdata\u002Fcognee_system\n# sudo chown -R \u003Coperator-user>: \u003Cdocker-volume-mounts>\u002Fcognee\u002Fdata\u002Fcognee_system\ndocker compose -f \"$COMPOSE_FILE\" start dkr-cgnee-api\n# Wait ~10s for the health check before rebuilding.\n# (Use concrete values only in private adopter runbooks.)\n```\n\n### 2. Rebuild\n\n```bash\nbash \"${EPOSFORGE_HOME:?set EPOSFORGE_HOME}\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fscripts\u002Fbulk-rebuild.sh\"\n```\n\n`bulk-rebuild.sh` wipes the sync state DB, stages every tracked `*.md`\u002F`*.ttl`\n**except** the ontology TTL and raw backlog items (`backlog\u002F`, `.eposforge\u002Fbacklog\u002F`, `plans\u002F` per EF-057), uploads the ontology as the `eposforge` anchor, and\ncognifies with `ontologyKey=[eposforge]`. Use `--dry-run` to preview.\n\n**Bulk cognify is two-pass.** The first pass over 80+ docs may emit ~10 SQLite\ncontention errors (`database is locked`, `no such table: data`) — expected.\nRe-run `bulk-rebuild.sh`; the second pass picks up the missed docs cleanly. If\nthe second pass also hits lock errors, restart `dkr-cgnee-api` first, then re-run.\n\n## Verify the update\n\nAfter either path, confirm the graph reflects the change — and, after a full\nrebuild, that anchoring actually took:\n\n- **Coverage:** `TextDocument` node count should match the synced doc count. If\n  they diverge, cognify did not run (see cognee.md §Pipeline behavior).\n- **Anchoring took (full rebuild):** the definitive signal is node\n  `ontology_valid`. Fetch the graph\n  (`GET $COGNEE_API_URL\u002Fapi\u002Fv1\u002Fdatasets\u002F\u003Cid>\u002Fgraph` — see the private deployment\n  runbook for the concrete host) and confirm nodes carry\n  `properties.ontology_valid: true` — if *every* node is `false`, nothing\n  anchored. Corroborate in the API log: a storm of\n  `OntologyAdapter: No close match found for '\u003Cx>' in category 'classes'` during\n  cognify means the ontology did not load (most often it was uploaded as Turtle\n  instead of RDF\u002FXML — see cognee.md §Ontology grounding; `cognee-sync` now\n  converts automatically). When healthy, the API log shows\n  `OntologyAdapter: Lookup built: N classes, M individuals` at cognify start.\n- **Recall probe:** ask cognee MCP `recall` for a term you just changed and\n  confirm it reflects the new content.\n\n## Outputs\n\n- updated Cognee KG reflecting current repo state\n- for incremental: updated `sync\u002F.cognee-state.db` (commit it)\n- `verification report` — doc coverage, `EntityType` anchoring check (full\n  rebuild), and a recall probe result\n","Updates the Cognee knowledge graph that backs the Spec Graph (Component 6) so\nrecall and graph queries reflect the current repo. Handles **both** update\npaths — incremental per-file sync and full corpus rebuild — and decides which\none a given change requires.\n\nThis skill owns *running* the update. Editing the ontology TTL itself is a\nseparate concern owned by [maintain-ontology](..\u002Fmaintain-ontology\u002FSKILL.md):\nedit the TTL there, then come here to rebuild. Adapter-level deployment topology,\nAPI behavior, and recovery procedures live in\n[cognee.md](..\u002F..\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fcognee.md).\n\n## Pick the path first: incremental vs full\n\nThe trigger for the change decides the path. **Get this right before running\nanything** — running incremental after an ontology edit silently leaves the\ngraph half-anchored.\n\n| What changed | Path | Why |\n|---|---|---|\n| Corpus docs only (`*.md`, non-ontology `*.ttl`) | **Incremental** | New\u002Fchanged docs anchor against the already-uploaded ontology; unchanged docs are untouched. |\n| The ontology (`00-vision\u002F01-ontology.ttl`) | **Full rebuild + KG wipe** | Anchoring is not retroactive *and* content-hash dedup skips re-extraction of unchanged docs — only a wipe forces every doc to re-anchor. |\n| Empty \u002F corrupt \u002F from scratch \u002F Ladybug stale-lock | **Full rebuild + KG wipe** | No usable prior state. |\n\n**The asymmetry to remember:** a document edit is incremental; an ontology edit\nis a full rebuild. Cognee resolves the ontology at cognify time per run and does\nnot re-anchor existing nodes, and its content-hash dedup (`PipelineRunAlreadyCompleted`)\nwill silently skip docs whose text did not change — so you cannot re-anchor a\nchanged ontology without wiping the KG.\n\n## Preconditions (both paths)\n\n- `dkr-cgnee-api` container running and healthy (the KG owner; the MCP container\n  is only a proxy — never ingest against it). See cognee.md §Deployment topology.\n- `epos-secrets` on PATH (or at `.eposforge\u002Fsecrets-key-management\u002Fbin\u002F`)\n  to inject `COGNEE_API_URL` \u002F `COGNEE_API_TOKEN`.\n- `uv` available; run from `.eposforge\u002Fspec-graph\u002Fcognee\u002Fsync`.\n- Check the inference budget before a full rebuild (~180K–200K embedding tokens\n  for the full corpus): `.eposforge\u002F.audit\u002Finference-budget-counters.json`.\n- The ontology key is `eposforge` (override via `$COGNEE_ONTOLOGY_KEY`).\n\n## Incremental path (doc changes)\n\n`sync-incremental.sh` computes the diff since the last synced commit and\ndispatches the per-file changes; it always passes `--ontology-key` so cognify\nanchors entities to the ontology.\n\n```bash\nbash \"${EPOSFORGE_HOME:?set EPOSFORGE_HOME}\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fscripts\u002Fsync-incremental.sh\" \u003Cbase-commit>\n```\n\n`\u003Cbase-commit>` = the last commit whose changes are already in the KG.\n\nNotes:\n- The ontology TTL is the **anchor, not a corpus document** — the script\n  excludes it from `--added`\u002F`--modified`. If it changed, you are on the wrong\n  path (use full rebuild).\n- Raw backlog items (`backlog\u002F`, `.eposforge\u002Fbacklog\u002F`, `plans\u002F`) are excluded from the main Spec Graph by default (EF-057). They live in the independent file-based backlog graph. The main graph may still reference backlog *mechanics* via ontology terms. Use aggregate.sh \u002F portfolio-review for backlog GraphRAG views.\n- The incremental path assumes the ontology is already uploaded. If unsure,\n  pass `--upload-ontology 00-vision\u002F01-ontology.ttl` through to cognee-sync\n  once (it is idempotent: delete + re-upload):\n  `bash \"${EPOSFORGE_HOME:?set EPOSFORGE_HOME}\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fscripts\u002Fsync-incremental.sh\" \u003Cbase-commit> --upload-ontology 00-vision\u002F01-ontology.ttl`\n- Pass `--dry-run` through to print planned actions with no API calls.\n- update = delete old `data_id` + add new; the state DB (`sync\u002F.cognee-state.db`)\n  maps `file_path → data_id` and is committed to source. Commit the updated\n  state DB after a successful run.\n\n## Full rebuild path (ontology change, or from scratch)\n\nTwo steps. **Step 1 (KG wipe) is mandatory for an ontology change** — skipping\nit means dedup leaves the old anchoring in place.\n\n### 1. Wipe the KG\n\nPer cognee.md §Recovery procedures (this destroys the entire KG):\n\n```bash\nCOMPOSE_FILE=\u003Cdocker-volume-mounts>\u002Fcognee\u002Fdocker-compose.yml\ndocker compose -f \"$COMPOSE_FILE\" stop dkr-cgnee-api\n# sudo rm -rf \u003Cdocker-volume-mounts>\u002Fcognee\u002Fdata\u002Fcognee_system\n# sudo mkdir -p \u003Cdocker-volume-mounts>\u002Fcognee\u002Fdata\u002Fcognee_system\n# sudo chown -R \u003Coperator-user>: \u003Cdocker-volume-mounts>\u002Fcognee\u002Fdata\u002Fcognee_system\ndocker compose -f \"$COMPOSE_FILE\" start dkr-cgnee-api\n# Wait ~10s for the health check before rebuilding.\n# (Use concrete values only in private adopter runbooks.)\n```\n\n### 2. Rebuild\n\n```bash\nbash \"${EPOSFORGE_HOME:?set EPOSFORGE_HOME}\u002F.eposforge\u002Fspec-graph\u002Fcognee\u002Fscripts\u002Fbulk-rebuild.sh\"\n```\n\n`bulk-rebuild.sh` wipes the sync state DB, stages every tracked `*.md`\u002F`*.ttl`\n**except** the ontology TTL and raw backlog items (`backlog\u002F`, `.eposforge\u002Fbacklog\u002F`, `plans\u002F` per EF-057), uploads the ontology as the `eposforge` anchor, and\ncognifies with `ontologyKey=[eposforge]`. Use `--dry-run` to preview.\n\n**Bulk cognify is two-pass.** The first pass over 80+ docs may emit ~10 SQLite\ncontention errors (`database is locked`, `no such table: data`) — expected.\nRe-run `bulk-rebuild.sh`; the second pass picks up the missed docs cleanly. If\nthe second pass also hits lock errors, restart `dkr-cgnee-api` first, then re-run.\n\n## Verify the update\n\nAfter either path, confirm the graph reflects the change — and, after a full\nrebuild, that anchoring actually took:\n\n- **Coverage:** `TextDocument` node count should match the synced doc count. If\n  they diverge, cognify did not run (see cognee.md §Pipeline behavior).\n- **Anchoring took (full rebuild):** the definitive signal is node\n  `ontology_valid`. Fetch the graph\n  (`GET $COGNEE_API_URL\u002Fapi\u002Fv1\u002Fdatasets\u002F\u003Cid>\u002Fgraph` — see the private deployment\n  runbook for the concrete host) and confirm nodes carry\n  `properties.ontology_valid: true` — if *every* node is `false`, nothing\n  anchored. Corroborate in the API log: a storm of\n  `OntologyAdapter: No close match found for '\u003Cx>' in category 'classes'` during\n  cognify means the ontology did not load (most often it was uploaded as Turtle\n  instead of RDF\u002FXML — see cognee.md §Ontology grounding; `cognee-sync` now\n  converts automatically). When healthy, the API log shows\n  `OntologyAdapter: Lookup built: N classes, M individuals` at cognify start.\n- **Recall probe:** ask cognee MCP `recall` for a term you just changed and\n  confirm it reflects the new content.\n\n## Outputs\n\n- updated Cognee KG reflecting current repo state\n- for incremental: updated `sync\u002F.cognee-state.db` (commit it)\n- `verification report` — doc coverage, `EntityType` anchoring check (full\n  rebuild), and a recall probe result\n",{"name":5,"description":7,"target_shape_of":43},"procedure-skills-to-programs","main","ecf0afdd9413ab02342e811f43178dddbae1fa4c","skills\u002Fupdate-spec-graph",0,"https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge","https:\u002F\u002Fgithub.com\u002Feposforge","2026-10-12 06:39:48",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add eposforge\u002Feposforge --skill update-spec-graph",{"tool":57,"command":58},"bunx","bunx skills add eposforge\u002Feposforge --skill update-spec-graph",{"tool":60,"command":61},"pnpm","pnpm dlx skills add eposforge\u002Feposforge --skill update-spec-graph","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fupdate-spec-graph\u002FSKILL.md",true,[],[66,95,123,132,155,168],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":77,"publishedAt":38},"01M71JQ9FR8PKMT1JMV3FV910A","upstream-bug-report","File a well-formed bug report against an upstream open-source dependency (GitHub issue). Use when EposForge or one of its adapter dependencies exhibits a reproducible defect that must be fixed upstream, particularly for silent failures, incorrect defaults, or API contract violations that affect ontology grounding, graph correctness, or agent reliability.","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-bug-report\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[78,79,80,81,82,83,84,85,86,87,88,89,90,91,32,27,92,30,93,94],"bug report","bug","report","upstream bug report","upstream","one","api","grounding","for","Reproducible","api contract","open","contract","adapter","reliability","correctness","file",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":106,"publishedAt":38},"01M71JQ5H57DT8J7VSBNE9HB4X","refine-prompt","Technique-driven prompt transformation for under-specified asks. Discovers techniques from data files, elicits missing required slots in one batch, rewrites with strict traceability, and gates submission behind explicit yes\u002Fno confirmation.","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Frefine-prompt\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[107,108,109,83,110,111,112,113,114,115,116,117,86,118,119,120,121,25,122],"refine prompt","refine","prompt","gates","confirmation","files","yes","techniques","missing","submission","traceability","transformation","driven","data","slots","batch",{"skillNo":124,"name":125,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":38},"01M71JQ36VW2ZH2E2R3JE4PXY4","portfolio-review","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fportfolio-review\u002FSKILL.md",[],[129,130,131],"review","portfolio","portfolio review",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":38},"01M71JQ0AD94NHJ39GB0V0N9SB","milestone-elicitation","Guided interview for discovering milestones and value-harvest points. Writes confirmed anchors back as ordinary backlog items and keeps durable elicitation records. Re-runnable — subsequent runs diff against existing anchors and prior records so the milestone map evolves without replaying history.","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fmilestone-elicitation\u002FSKILL.md",[],[139,140,141,142,143,144,145,146,147,148,86,149,150,151,152,153,154],"milestone elicitation","elicitation","milestone","history","Existing","map","milestones","records","backlog","re","diff","value","harvest","as","interview","back",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":38},"01M71JPYGQWYVFTZ82E1R7P8PH","maintain-ontology","Keeps 00-vision\u002F01-ontology.ttl well-formed, internally consistent, and aligned with adapter cards under .eposforge\u002F so Cognee extraction remains ontology-grounded.","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fmaintain-ontology\u002FSKILL.md",[],[162,163,27,91,33,164,165,166,25,167],"maintain ontology","maintain","extraction","vision","cards","ttl",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":38},"01M71JPTWNNV19ZSPD9VPDWTMB","idea-capture","Keep a per-repo register of notional product ideas — ideas not yet decided, kept as food for future development instead of being forgotten, and kept out of the backlog. Captures napkin notes as structured idea entries (one per idea, duplicate-checked, with typed edges to related ideas and backlog items), promotes an idea to an ordinary backlog item, rejects an idea with a reason, and reads the register as a graph. Use when the operator says \"capture this idea\", \"napkin note\", \"notional feature\", \"food for future development\", \"add to ideas\", \"park this idea\", \"not a backlog item yet\", \"promote IDEA-NNN to the backlog\", \"reject that idea\", or \"what's in the ideas register\". Do not use for work that is already decided — that is a backlog item.","https:\u002F\u002Fgithub.com\u002Feposforge\u002Feposforge\u002Fblob\u002Fmain\u002Fskills\u002Fidea-capture\u002FSKILL.md",[],[175,176,177,178,179,30,32,180,181,147,37,86,182,183,184,185,186,187,188,152],"capture","idea","idea capture","ideas","promote idea","entries","food","development","feature","register","promote","napkin","nnn","do"]