Update to Vaiz
Snapshot Oct 27, 2026 · 00:52 UTC · version 1.1.0
Collection source: downloaded plugin package.
Payment or plan references changed
Full description — Now says: code on GitHub or GitLab.
Observed in published text. Live prices and checkout terms have not been verified by this change.
Up to 10 plugins free · no card required.
All fields and original values.
Full description
Oct 24, 2026 · 13:47 UTC
GitHub.
Oct 27, 2026 · 00:52 UTC
code on GitHub or GitLab.
Skill instructions
Oct 24, 2026 · 13:47 UTC
GitHub. Vaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__get_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_get_tasks` (sometimes with a longer app prefix such as `vaiz_t...
Oct 27, 2026 · 00:52 UTC
code on GitHub or GitLab. Vaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__query_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_query_tasks` (sometimes with a longer app ...
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -1,6 +1,6 @@ --- name: vaiz-memories -description: Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and GitHub. +description: Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and code on GitHub or GitLab. --- # Vaiz Space Memory @@ -11,7 +11,7 @@ The Vaiz MCP server (`https://api.vaiz.com/mcp`) must be available through the installed Vaiz plugin and authorized with OAuth. This skill does not replace authentication: if the Vaiz tools are missing or return an authorization error, open the Vaiz connection and complete OAuth sign-in first. -Vaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__get_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_get_tasks` (sometimes with a longer app prefix such as `vaiz_testing_`) when Vaiz is installed as an app. Match tool names case-insensitively and by the tool suffix (`get_tasks`, `query_tasks`, …), not by an exact `Vaiz` prefix. Tools may also be loaded lazily: a Vaiz tool that is not in the current tool list is not missing — load it through tool search (for example `Vaiz get_tasks`) before concluding it is unavailable. Work with Vaiz only through these tools: do not open app.vaiz.com in a browser or drive the Vaiz desktop app with Computer Use, even if the user's `@Vaiz` mention also resolves to that app. +Vaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__query_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_query_tasks` (sometimes with a longer app prefix such as `vaiz_testing_`) when Vaiz is installed as an app. Match tool names case-insensitively and by the tool suffix (`query_tasks`, `show_tasks`, …), not by an exact `Vaiz` prefix. Tools may also be loaded lazily: a Vaiz tool that is not in the current tool list is not missing — load it through tool search (for example `Vaiz query_tasks`) before concluding it is unavailable. Work with Vaiz only through these tools: do not open app.vaiz.com in a browser or drive the Vaiz desktop app with Computer Use, even if the user's `@Vaiz` mention also resolves to that app. ## When to use @@ -53,9 +53,9 @@ ## Reading -- `get_task_context` — pass a task database id or its HRID (for example `PRJ-123`). Returns the task together with the memories linked to it and to its project. Use it first when starting on a task. -- `search_memory` — natural-language query across the space. Results are ranked with lifecycle awareness, so active records surface first. Use it for "how do we…", "why did we…", and "has anyone seen…" questions. -- `list_memories` — filter by kind, status, project, task, tag, or author when you want a structured view rather than a semantic search. +- `get_task_context` — pass a task database id or its HRID (for example `PRJ-123`). Returns the task with compact sections for decisions, open problems, active risks, relevant context, recent Devlogs, and deduplicated code links. `limitPerSection` caps each section (default 5, max 20). Use it first when starting on a task. +- `search_memory` — natural-language query across the space. Results are ranked with lifecycle awareness, so active records surface first; only `Active` and `Resolved` records are returned unless you pass `statuses`. Use it for "how do we…", "why did we…", and "has anyone seen…" questions. +- `list_memories` — filter by kind, status, project, related task, tag, or source (`Human` / `Agent`) when you want a structured view rather than a semantic search. Without `statuses` it returns every status, so pass `statuses: ["Active"]` for current knowledge. Always search before creating. If an equivalent record already exists, update its status, supersede it, or link it to the task instead of creating a duplicate. @@ -69,14 +69,15 @@ - arrays of `Decision`, `Problem`, and `Risk` entries discovered during the session (each becomes its own durable record); - `relatedTasks` — the task ids or HRIDs this work belongs to; - `projectId` — the project the work lives in; -- `relatedGitHubEntities` — pull requests, issues, commits, or branches touched; +- `relatedCodeEntities` — GitHub/GitLab branches, pull/merge requests, or commits touched; +- `commits` — commit provenance for the records; - a stable `idempotencyKey` — reuse the exact same key when retrying after a failure so the Devlog is not written twice. -Set `clientName` to `Codex`. Leave `linkGitHubEntitiesToRelatedTasks` at `false` unless the same code link genuinely belongs on every related task. +Set `clientName` to `Codex`. Leave `linkCodeEntitiesToRelatedTasks` at `false` unless the same code link genuinely belongs on every related task. `Context` and `Convention` are not part of a Devlog; record them with `create_memory`. ### Single record: `create_memory` -Use `create_memory` for one durable record outside a Devlog — for example a `Convention` agreed in a review, or a `Decision` made before any code is written. Give it a kind, a clear title, the body, and any related tasks, project, tags, and GitHub entities. Set `clientName` to `Codex`. +Use `create_memory` for one durable record outside a Devlog — for example a `Convention` agreed in a review, or a `Decision` made before any code is written. Give it a kind, a clear title, the body, and any related tasks, project, tags, and `commits`. Set `clientName` to `Codex`. To attach a branch or PR/MR to the new record, call `link_code_entity` with its `memoryEntryId` afterwards. ### What not to store @@ -85,17 +86,17 @@ ### Tags -Tags are cross-cutting themes such as `oauth`, `billing`, or `migrations`. Do not use tags for task ids, dates, or GitHub references — those belong in `relatedTasks`, timestamps, and `relatedGitHubEntities`. +Tags are cross-cutting themes such as `oauth`, `billing`, or `migrations`. Do not use tags for kinds, statuses, task ids, dates, client names, or branch/PR/commit references — those belong in their dedicated fields (`relatedTasks`, `relatedCodeEntities`, `commits`). -## GitHub links +## Code links -To connect memories and tasks with code: +To connect memories and tasks with code on GitHub or GitLab (details in the `vaiz-code-links` skill): -1. `get_github_repositories` — list repositories connected to the space. -2. `search_github` — find the pull request, issue, commit, or branch to link. -3. `link_github_entity` — attach it to a task or memory. -4. `get_github_links` — review what is already linked. -5. `unlink_github_entity` — remove a link that no longer applies. +1. `get_code_repositories` — list repositories connected to the space. +2. `search_code_entities` — find the pull/merge request, commit, or branch to link. +3. `link_code_entity` — attach it to a task or memory entry. +4. `get_code_links` — review what is already linked. +5. `unlink_code_entity` — remove a link that no longer applies, by its link `_id`. ## Further reading
Full technical diff · 2 changed fields
changed /description
"Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and GitHub."
"Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and code on GitHub or GitLab."
changed /skill_md_contents
"---\nname: vaiz-memories\ndescription: Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and GitHub.\n---\n\n# Vaiz Space Memory\n\nSpace Memory is the shared, long-lived knowledge base of a Vaiz space. This skill explains how to read from it before starting work, how to write back what the team should remember, and how to keep records accurate over time.\n\n## Prerequisite\n\nThe Vaiz MCP server (`https://api.vaiz.com/mcp`) must be available through the installed Vaiz plugin and authorized with OAuth. This skill does not replace authentication: if the Vaiz tools are missing or return an authorization error, open the Vaiz connection and complete OAuth sign-in first.\n\nVaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__get_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_get_tasks` (sometimes with a longer app prefix such as `vaiz_testing_`) when Vaiz is installed as an app. Match tool names case-insensitively and by the tool suffix (`get_tasks`, `query_tasks`, …), not by an exact `Vaiz` prefix. Tools may also be loaded lazily: a Vaiz tool that is not in the current tool list is not missing — load it through tool search (for example `Vaiz get_tasks`) before concluding it is unavailable. Work with Vaiz only through these tools: do not open app.vaiz.com in a browser or drive the Vaiz desktop app with Computer Use, even if the user's `@Vaiz` mention also resolves to that app.\n\n## When to use\n\n- **Starting a task** — pull the task's context and the memories that govern it before writing code.\n- **Ending a session** — record what was done, decided, and discovered so the next person (or agent) does not start from zero.\n- **Recording decisions or risks** — as soon as a choice is made or a hazard is identified, even mid-session.\n- **Searching team knowledge** — when you need to know how something is done in this space, why it is done that way, or whether a problem has been seen before.\n\n## Kinds\n\nEvery memory has exactly one kind. Use these names and no others:\n\n| Kind | Meaning |\n| --- | --- |\n| `Decision` | A choice that was made and the reasoning behind it |\n| `Context` | Background a reader needs to understand the work |\n| `Problem` | Something that is broken, blocked, or wrong |\n| `Risk` | Something that may go wrong and what to watch for |\n| `Convention` | A rule or pattern the team follows |\n| `SessionLog` | Narrative of a single work session |\n\nDo not invent kinds such as `Devlog`, `Fact`, or `Note`. A **Devlog** is not a kind: it is created with `create_devlog` and stored as one `SessionLog` plus the durable `Decision`, `Problem`, and `Risk` records you pass alongside it.\n\n## Lifecycle\n\nEach memory has a status: `Active`, `Resolved`, `Superseded`, or `Obsolete`.\n\n- `Resolved` applies **only** to `Problem` and `Risk`. It means the problem was fixed or the risk no longer exists.\n- `Decision`, `Context`, and `Convention` stay `Active` for as long as they still govern the work. They are never \"resolved\".\n- `Superseded` is set **only** through `supersede_memory`, passing the newer memory id first and the older id second. The older record is marked superseded and points to its replacement.\n- `set_memory_status` accepts only `Active`, `Resolved`, or `Obsolete`. Use `Obsolete` when a record is simply no longer true and nothing replaces it.\n- `set_memory_archived` hides a duplicate or test record from normal listings. Archiving is **not** the same as `Obsolete`; it does not make a statement about whether the record was ever correct.\n\nSearch ranks `Active` records above `Resolved`, `Superseded`, and `Obsolete` ones, so keeping statuses accurate directly improves what future readers see first.\n\n## Hygiene\n\nIf the current session fixes a recorded `Problem` or eliminates a recorded `Risk`, call `set_memory_status` with `Resolved` on that record **in the same session** — usually right after `create_devlog`. Only do this when you have confirmed the fix; do not guess. If you are not sure whether the problem is gone, leave it `Active` and say so in the SessionLog.\n\n## Reading\n\n- `get_task_context` — pass a task database id or its HRID (for example `PRJ-123`). Returns the task together with the memories linked to it and to its project. Use it first when starting on a task.\n- `search_memory` — natural-language query across the space. Results are ranked with lifecycle awareness, so active records surface first. Use it for \"how do we…\", \"why did we…\", and \"has anyone seen…\" questions.\n- `list_memories` — filter by kind, status, project, task, tag, or author when you want a structured view rather than a semantic search.\n\nAlways search before creating. If an equivalent record already exists, update its status, supersede it, or link it to the task instead of creating a duplicate.\n\n## Writing\n\n### End of session: `create_devlog`\n\nPrefer `create_devlog` when closing a session. Provide:\n\n- a `SessionLog` narrative: what was attempted, what changed, what remains;\n- arrays of `Decision`, `Problem`, and `Risk` entries discovered during the session (each becomes its own durable record);\n- `relatedTasks` — the task ids or HRIDs this work belongs to;\n- `projectId` — the project the work lives in;\n- `relatedGitHubEntities` — pull requests, issues, commits, or branches touched;\n- a stable `idempotencyKey` — reuse the exact same key when retrying after a failure so the Devlog is not written twice.\n\nSet `clientName` to `Codex`. Leave `linkGitHubEntitiesToRelatedTasks` at `false` unless the same code link genuinely belongs on every related task.\n\n### Single record: `create_memory`\n\nUse `create_memory` for one durable record outside a Devlog — for example a `Convention` agreed in a review, or a `Decision` made before any code is written. Give it a kind, a clear title, the body, and any related tasks, project, tags, and GitHub entities. Set `clientName` to `Codex`.\n\n### What not to store\n\n- Transient local state: `git status` output, whether tests are currently running, which files are open in the editor, or anything that is only true on your machine right now.\n- Several topics in one entry. Keep one topic per record so it can be found, superseded, or resolved independently.\n\n### Tags\n\nTags are cross-cutting themes such as `oauth`, `billing`, or `migrations`. Do not use tags for task ids, dates, or GitHub references — those belong in `relatedTasks`, timestamps, and `relatedGitHubEntities`.\n\n## GitHub links\n\nTo connect memories and tasks with code:\n\n1. `get_github_repositories` — list repositories connected to the space.\n2. `search_github` — find the pull request, issue, commit, or branch to link.\n3. `link_github_entity` — attach it to a task or memory.\n4. `get_github_links` — review what is already linked.\n5. `unlink_github_entity` — remove a link that no longer applies.\n\n## Further reading\n\n- How to connect Vaiz to MCP: https://vaiz.com/help/tutorials/how-to-connect-vaiz-to-mcp\n- Vaiz: https://vaiz.com\n"
"---\nname: vaiz-memories\ndescription: Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and code on GitHub or GitLab.\n---\n\n# Vaiz Space Memory\n\nSpace Memory is the shared, long-lived knowledge base of a Vaiz space. This skill explains how to read from it before starting work, how to write back what the team should remember, and how to keep records accurate over time.\n\n## Prerequisite\n\nThe Vaiz MCP server (`https://api.vaiz.com/mcp`) must be available through the installed Vaiz plugin and authorized with OAuth. This skill does not replace authentication: if the Vaiz tools are missing or return an authorization error, open the Vaiz connection and complete OAuth sign-in first.\n\nVaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__query_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_query_tasks` (sometimes with a longer app prefix such as `vaiz_testing_`) when Vaiz is installed as an app. Match tool names case-insensitively and by the tool suffix (`query_tasks`, `show_tasks`, …), not by an exact `Vaiz` prefix. Tools may also be loaded lazily: a Vaiz tool that is not in the current tool list is not missing — load it through tool search (for example `Vaiz query_tasks`) before concluding it is unavailable. Work with Vaiz only through these tools: do not open app.vaiz.com in a browser or drive the Vaiz desktop app with Computer Use, even if the user's `@Vaiz` mention also resolves to that app.\n\n## When to use\n\n- **Starting a task** — pull the task's context and the memories that govern it before writing code.\n- **Ending a session** — record what was done, decided, and discovered so the next person (or agent) does not start from zero.\n- **Recording decisions or risks** — as soon as a choice is made or a hazard is identified, even mid-session.\n- **Searching team knowledge** — when you need to know how something is done in this space, why it is done that way, or whether a problem has been seen before.\n\n## Kinds\n\nEvery memory has exactly one kind. Use these names and no others:\n\n| Kind | Meaning |\n| --- | --- |\n| `Decision` | A choice that was made and the reasoning behind it |\n| `Context` | Background a reader needs to understand the work |\n| `Problem` | Something that is broken, blocked, or wrong |\n| `Risk` | Something that may go wrong and what to watch for |\n| `Convention` | A rule or pattern the team follows |\n| `SessionLog` | Narrative of a single work session |\n\nDo not invent kinds such as `Devlog`, `Fact`, or `Note`. A **Devlog** is not a kind: it is created with `create_devlog` and stored as one `SessionLog` plus the durable `Decision`, `Problem`, and `Risk` records you pass alongside it.\n\n## Lifecycle\n\nEach memory has a status: `Active`, `Resolved`, `Superseded`, or `Obsolete`.\n\n- `Resolved` applies **only** to `Problem` and `Risk`. It means the problem was fixed or the risk no longer exists.\n- `Decision`, `Context`, and `Convention` stay `Active` for as long as they still govern the work. They are never \"resolved\".\n- `Superseded` is set **only** through `supersede_memory`, passing the newer memory id first and the older id second. The older record is marked superseded and points to its replacement.\n- `set_memory_status` accepts only `Active`, `Resolved`, or `Obsolete`. Use `Obsolete` when a record is simply no longer true and nothing replaces it.\n- `set_memory_archived` hides a duplicate or test record from normal listings. Archiving is **not** the same as `Obsolete`; it does not make a statement about whether the record was ever correct.\n\nSearch ranks `Active` records above `Resolved`, `Superseded`, and `Obsolete` ones, so keeping statuses accurate directly improves what future readers see first.\n\n## Hygiene\n\nIf the current session fixes a recorded `Problem` or eliminates a recorded `Risk`, call `set_memory_status` with `Resolved` on that record **in the same session** — usually right after `create_devlog`. Only do this when you have confirmed the fix; do not guess. If you are not sure whether the problem is gone, leave it `Active` and say so in the SessionLog.\n\n## Reading\n\n- `get_task_context` — pass a task database id or its HRID (for example `PRJ-123`). Returns the task with compact sections for decisions, open problems, active risks, relevant context, recent Devlogs, and deduplicated code links. `limitPerSection` caps each section (default 5, max 20). Use it first when starting on a task.\n- `search_memory` — natural-language query across the space. Results are ranked with lifecycle awareness, so active records surface first; only `Active` and `Resolved` records are returned unless you pass `statuses`. Use it for \"how do we…\", \"why did we…\", and \"has anyone seen…\" questions.\n- `list_memories` — filter by kind, status, project, related task, tag, or source (`Human` / `Agent`) when you want a structured view rather than a semantic search. Without `statuses` it returns every status, so pass `statuses: [\"Active\"]` for current knowledge.\n\nAlways search before creating. If an equivalent record already exists, update its status, supersede it, or link it to the task instead of creating a duplicate.\n\n## Writing\n\n### End of session: `create_devlog`\n\nPrefer `create_devlog` when closing a session. Provide:\n\n- a `SessionLog` narrative: what was attempted, what changed, what remains;\n- arrays of `Decision`, `Problem`, and `Risk` entries discovered during the session (each becomes its own durable record);\n- `relatedTasks` — the task ids or HRIDs this work belongs to;\n- `projectId` — the project the work lives in;\n- `relatedCodeEntities` — GitHub/GitLab branches, pull/merge requests, or commits touched;\n- `commits` — commit provenance for the records;\n- a stable `idempotencyKey` — reuse the exact same key when retrying after a failure so the Devlog is not written twice.\n\nSet `clientName` to `Codex`. Leave `linkCodeEntitiesToRelatedTasks` at `false` unless the same code link genuinely belongs on every related task. `Context` and `Convention` are not part of a Devlog; record them with `create_memory`.\n\n### Single record: `create_memory`\n\nUse `create_memory` for one durable record outside a Devlog — for example a `Convention` agreed in a review, or a `Decision` made before any code is written. Give it a kind, a clear title, the body, and any related tasks, project, tags, and `commits`. Set `clientName` to `Codex`. To attach a branch or PR/MR to the new record, call `link_code_entity` with its `memoryEntryId` afterwards.\n\n### What not to store\n\n- Transient local state: `git status` output, whether tests are currently running, which files are open in the editor, or anything that is only true on your machine right now.\n- Several topics in one entry. Keep one topic per record so it can be found, superseded, or resolved independently.\n\n### Tags\n\nTags are cross-cutting themes such as `oauth`, `billing`, or `migrations`. Do not use tags for kinds, statuses, task ids, dates, client names, or branch/PR/commit references — those belong in their dedicated fields (`relatedTasks`, `relatedCodeEntities`, `commits`).\n\n## Code links\n\nTo connect memories and tasks with code on GitHub or GitLab (details in the `vaiz-code-links` skill):\n\n1. `get_code_repositories` — list repositories connected to the space.\n2. `search_code_entities` — find the pull/merge request, commit, or branch to link.\n3. `link_code_entity` — attach it to a task or memory entry.\n4. `get_code_links` — review what is already linked.\n5. `unlink_code_entity` — remove a link that no longer applies, by its link `_id`.\n\n## Further reading\n\n- How to connect Vaiz to MCP: https://vaiz.com/help/tutorials/how-to-connect-vaiz-to-mcp\n- Vaiz: https://vaiz.com\n"
Full snapshot data
{
"description": "Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and code on GitHub or GitLab.",
"included_files": [],
"name": "vaiz-memories",
"skill_md_contents": "---\nname: vaiz-memories\ndescription: Persist and retrieve team knowledge in Vaiz Space Memory — assemble task context, write Devlogs and durable records, search with lifecycle-aware ranking, and link entries to tasks and code on GitHub or GitLab.\n---\n\n# Vaiz Space Memory\n\nSpace Memory is the shared, long-lived knowledge base of a Vaiz space. This skill explains how to read from it before starting work, how to write back what the team should remember, and how to keep records accurate over time.\n\n## Prerequisite\n\nThe Vaiz MCP server (`https://api.vaiz.com/mcp`) must be available through the installed Vaiz plugin and authorized with OAuth. This skill does not replace authentication: if the Vaiz tools are missing or return an authorization error, open the Vaiz connection and complete OAuth sign-in first.\n\nVaiz tools can appear under different names depending on how Vaiz is connected: `mcp__Vaiz__query_tasks` for a directly configured MCP server, or `mcp__codex_apps__vaiz_query_tasks` (sometimes with a longer app prefix such as `vaiz_testing_`) when Vaiz is installed as an app. Match tool names case-insensitively and by the tool suffix (`query_tasks`, `show_tasks`, …), not by an exact `Vaiz` prefix. Tools may also be loaded lazily: a Vaiz tool that is not in the current tool list is not missing — load it through tool search (for example `Vaiz query_tasks`) before concluding it is unavailable. Work with Vaiz only through these tools: do not open app.vaiz.com in a browser or drive the Vaiz desktop app with Computer Use, even if the user's `@Vaiz` mention also resolves to that app.\n\n## When to use\n\n- **Starting a task** — pull the task's context and the memories that govern it before writing code.\n- **Ending a session** — record what was done, decided, and discovered so the next person (or agent) does not start from zero.\n- **Recording decisions or risks** — as soon as a choice is made or a hazard is identified, even mid-session.\n- **Searching team knowledge** — when you need to know how something is done in this space, why it is done that way, or whether a problem has been seen before.\n\n## Kinds\n\nEvery memory has exactly one kind. Use these names and no others:\n\n| Kind | Meaning |\n| --- | --- |\n| `Decision` | A choice that was made and the reasoning behind it |\n| `Context` | Background a reader needs to understand the work |\n| `Problem` | Something that is broken, blocked, or wrong |\n| `Risk` | Something that may go wrong and what to watch for |\n| `Convention` | A rule or pattern the team follows |\n| `SessionLog` | Narrative of a single work session |\n\nDo not invent kinds such as `Devlog`, `Fact`, or `Note`. A **Devlog** is not a kind: it is created with `create_devlog` and stored as one `SessionLog` plus the durable `Decision`, `Problem`, and `Risk` records you pass alongside it.\n\n## Lifecycle\n\nEach memory has a status: `Active`, `Resolved`, `Superseded`, or `Obsolete`.\n\n- `Resolved` applies **only** to `Problem` and `Risk`. It means the problem was fixed or the risk no longer exists.\n- `Decision`, `Context`, and `Convention` stay `Active` for as long as they still govern the work. They are never \"resolved\".\n- `Superseded` is set **only** through `supersede_memory`, passing the newer memory id first and the older id second. The older record is marked superseded and points to its replacement.\n- `set_memory_status` accepts only `Active`, `Resolved`, or `Obsolete`. Use `Obsolete` when a record is simply no longer true and nothing replaces it.\n- `set_memory_archived` hides a duplicate or test record from normal listings. Archiving is **not** the same as `Obsolete`; it does not make a statement about whether the record was ever correct.\n\nSearch ranks `Active` records above `Resolved`, `Superseded`, and `Obsolete` ones, so keeping statuses accurate directly improves what future readers see first.\n\n## Hygiene\n\nIf the current session fixes a recorded `Problem` or eliminates a recorded `Risk`, call `set_memory_status` with `Resolved` on that record **in the same session** — usually right after `create_devlog`. Only do this when you have confirmed the fix; do not guess. If you are not sure whether the problem is gone, leave it `Active` and say so in the SessionLog.\n\n## Reading\n\n- `get_task_context` — pass a task database id or its HRID (for example `PRJ-123`). Returns the task with compact sections for decisions, open problems, active risks, relevant context, recent Devlogs, and deduplicated code links. `limitPerSection` caps each section (default 5, max 20). Use it first when starting on a task.\n- `search_memory` — natural-language query across the space. Results are ranked with lifecycle awareness, so active records surface first; only `Active` and `Resolved` records are returned unless you pass `statuses`. Use it for \"how do we…\", \"why did we…\", and \"has anyone seen…\" questions.\n- `list_memories` — filter by kind, status, project, related task, tag, or source (`Human` / `Agent`) when you want a structured view rather than a semantic search. Without `statuses` it returns every status, so pass `statuses: [\"Active\"]` for current knowledge.\n\nAlways search before creating. If an equivalent record already exists, update its status, supersede it, or link it to the task instead of creating a duplicate.\n\n## Writing\n\n### End of session: `create_devlog`\n\nPrefer `create_devlog` when closing a session. Provide:\n\n- a `SessionLog` narrative: what was attempted, what changed, what remains;\n- arrays of `Decision`, `Problem`, and `Risk` entries discovered during the session (each becomes its own durable record);\n- `relatedTasks` — the task ids or HRIDs this work belongs to;\n- `projectId` — the project the work lives in;\n- `relatedCodeEntities` — GitHub/GitLab branches, pull/merge requests, or commits touched;\n- `commits` — commit provenance for the records;\n- a stable `idempotencyKey` — reuse the exact same key when retrying after a failure so the Devlog is not written twice.\n\nSet `clientName` to `Codex`. Leave `linkCodeEntitiesToRelatedTasks` at `false` unless the same code link genuinely belongs on every related task. `Context` and `Convention` are not part of a Devlog; record them with `create_memory`.\n\n### Single record: `create_memory`\n\nUse `create_memory` for one durable record outside a Devlog — for example a `Convention` agreed in a review, or a `Decision` made before any code is written. Give it a kind, a clear title, the body, and any related tasks, project, tags, and `commits`. Set `clientName` to `Codex`. To attach a branch or PR/MR to the new record, call `link_code_entity` with its `memoryEntryId` afterwards.\n\n### What not to store\n\n- Transient local state: `git status` output, whether tests are currently running, which files are open in the editor, or anything that is only true on your machine right now.\n- Several topics in one entry. Keep one topic per record so it can be found, superseded, or resolved independently.\n\n### Tags\n\nTags are cross-cutting themes such as `oauth`, `billing`, or `migrations`. Do not use tags for kinds, statuses, task ids, dates, client names, or branch/PR/commit references — those belong in their dedicated fields (`relatedTasks`, `relatedCodeEntities`, `commits`).\n\n## Code links\n\nTo connect memories and tasks with code on GitHub or GitLab (details in the `vaiz-code-links` skill):\n\n1. `get_code_repositories` — list repositories connected to the space.\n2. `search_code_entities` — find the pull/merge request, commit, or branch to link.\n3. `link_code_entity` — attach it to a task or memory entry.\n4. `get_code_links` — review what is already linked.\n5. `unlink_code_entity` — remove a link that no longer applies, by its link `_id`.\n\n## Further reading\n\n- How to connect Vaiz to MCP: https://vaiz.com/help/tutorials/how-to-connect-vaiz-to-mcp\n- Vaiz: https://vaiz.com\n"
}SHA-256 of public snapshot: 329d0d55fa009c1ed3ec48545fef9bc4bc4685cc0fe9f098ac9dedcebc3380d2