本文へ移動
cccskills
無料GitHub で公開日本語紹介

add-memory-kind

業務用の新しいメモリ種別を追加する際、Markdown・SQLite・LanceDBの保存先や形式を選び、スキーマ、リポジトリ、書き込み処理を組み立てます。

原文原文の説明を見る

Add a new business memory kind end-to-end. Pick the storage combination (Markdown / SQLite / LanceDB), pick the markdown strategy (daily-log / skill-named / single-file), then wire up the schema(s), repo(s), and writer(s).

EverMind-AI/EverOSスター 13,704(GitHub 13,704 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 新しい業務メモリ種別を追加したいとき
  • 保存先の組み合わせを設計したいとき
  • Markdownと検索用インデックスを連携したいとき

日本語での紹介

できること

業務データを新しいメモリ種別として保存するために、必要な保存先と実装箇所を選び、構成を追加する手順を案内します。人が読める原本としてのMarkdown、構造化データを扱うSQLite、ベクトル検索などに使うLanceDBから、用途に合う組み合わせを決めます。Markdownを使う場合は、日付ごとに追記する形式、名前付きファイルを上書きする形式、単一ファイルを書き換える形式を選びます。そのうえでスキーマ、書き込み処理、必要に応じてテーブルやリポジトリを追加し、公開用の再エクスポートも整えます。

こんなときに便利

EpisodeやCaseなど、新しい業務記録を永続化したい開発者に向いています。検索、構造化状態の管理、人が編集できる原本のどれが必要かを整理し、複数の保存層へ一貫して配線したいときに役立ちます。

使い方の例

  • 「新しい業務メモリ種別を追加する保存構成を決めて」
  • 「日次MarkdownログとSQLiteのテーブルを追加して」
  • 「検索用のLanceDBインデックスまで配線して」

注意点

日次ログ形式は具体的な手順が示されています。名前付きファイル形式と単一ファイル形式はレシピが概略段階で、基底Writerが整うまではMarkdownWriterを使う薄いラッパーが必要です。SQLiteやLanceDBは必要な場合だけ追加します。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

資料チェック

SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。

安全面送信・削除・コマンド実行などの扱いが明示されているか
A良好ファイル上書き方式を明記し、SQLiteやLanceDBは任意の追加です。
導入のしやすさ必要なツールや API キーが少ないか、書かれているか
B一部不足Markdown、SQLite、LanceDBの選択肢は示す一方、導入手順はありません。

点数には入れていません。 2026年10月29日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。

評価が違うと思ったら、見直しを依頼する

どの項目が、なぜ違うと思うかを書いてください。ログインは不要です。内容を SKILL.md と照らし合わせて評価を作り直し、この欄に反映します。

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

含まれるファイル(1)

  • SKILL.md11.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

/add-memory-kind — Add a new business memory kind

When to invoke

Adding a new persisted business entity (Episode, Case, Skill, AtomicFact, Foresight, Profile, or something custom). Multiple storage layers may be involved; this skill walks the decision then the wiring.

1. Decide the storage combination

A memory kind does not have to use all three layers. Pick by what the kind actually needs:

NeedMarkdownSQLiteLanceDB
Human-readable / agent-editable source-of-truth text✅
Structured state, ACID transactions, joins, predicates✅
Vector / BM25 / hybrid retrieval✅

Common combinations seen in EverOS:

ComboExampleRationale
md onlyscratch notes / dump binstext-of-truth, no index needed
md + lancedbepisode / memcell / casetext-of-truth + semantic retrieval
md + sqliteprofile / playbook / soul.md statetext-of-truth + structured state to query
md + sqlite + lancedbfull-blown business recordswhen you need both transactional state AND retrieval
sqlite onlyaudit log / task queue / LSN watermarksystem state, never user-facing
lancedb onlyrare; usually you still want mdderived embeddings without text-of-truth

Rule of thumb: markdown is the truth; sqlite and lancedb are derived indexes that can be rebuilt from md. Drop md only when the kind has no human-readable form (pure system state).

2. Pick the markdown storage strategy (if md is in your combo)

Three strategies — declared in the EverOS Markdown First spec:

StrategyFilenameMutationExamples
Daily-log append<prefix>-YYYY-MM-DD.mdappend entriesmemcell / episode / case / atomic_fact / foresight
Skill-named in-placeskill_<name>.mdoverwrite the fileskills (procedural memory)
Single-file rewriteuser.md / agent.md / soul.md / behaviors.md / tools.mdoverwrite the fileprofiles / playbooks

This skill currently has a complete recipe for daily-log append. Skill-named and single-file recipes are sketched at the bottom — their base writers (BaseSkillWriter / BaseProfileWriter) land later in the project; until then build a thin wrapper over MarkdownWriter directly.


3. Markdown daily-log: 4 steps

3.1 Frontmatter schema — infra/persistence/markdown/mds/<name>.py

"""Episode daily-log frontmatter."""

from __future__ import annotations

import datetime as _dt
from typing import ClassVar, Literal

from everos.core.persistence.markdown import UserScopedFrontmatter


class UserEpisodeDailyFrontmatter(UserScopedFrontmatter):
    """``users/<u>/episodes/episode-<YYYY-MM-DD>.md``."""

    ENTRY_ID_PREFIX: ClassVar[str] = "ep"
    DIR_NAME: ClassVar[str] = "episodes"
    FILE_PREFIX: ClassVar[str] = "episode"

    type: Literal["user_episode_daily"] = "user_episode_daily"
    date: _dt.date
    entry_count: int = 0
    last_appended_at: _dt.datetime | None = None

For agent-track kinds subclass AgentScopedFrontmatter instead. If user-track and agent-track share a kind name (e.g. memcell), give each a distinct ENTRY_ID_PREFIX (e.g. umc vs amc) so reverse lookup is unambiguous.

3.2 Re-export — mds/__init__.py

from .episode import UserEpisodeDailyFrontmatter as UserEpisodeDailyFrontmatter

3.3 Business writer — infra/persistence/markdown/writers/<name>.py

"""Episode appender."""

from __future__ import annotations

from pathlib import Path

from everos.core.persistence import MarkdownReader

from ..mds import UserEpisodeDailyFrontmatter
from .base import BaseDailyWriter


class UserEpisodeAppender(BaseDailyWriter):
    schema = UserEpisodeDailyFrontmatter

    # OPTIONAL: override the count strategy. Default is len(entries);
    # override to trust the frontmatter field instead.
    def _current_count(self, path: Path) -> int:
        if not path.exists():
            return 0
        return MarkdownReader.read(path).frontmatter.get("entry_count", 0)

3.4 Re-export — writers/__init__.py

from .episode import UserEpisodeAppender as UserEpisodeAppender

Done — usage

from everos.infra.persistence.markdown.writers import UserEpisodeAppender

appender = UserEpisodeAppender(memory_root)
eid = appender.append("u_jason", "I went to the doctor today.")
# → users/u_jason/episodes/episode-<today>.md
# → entry markers carry an auto-generated EntryId (e.g. ep_20260507_001)

4. (Optional) SQLite table — 4 steps

Skip this section if the kind doesn't need structured state beyond markdown.

4.1 Schema — infra/persistence/sqlite/tables/<name>.py

from everos.core.persistence.sqlite import BaseTable, Field


class EpisodeState(BaseTable, table=True):
    __tablename__ = "episode_state"  # type: ignore[assignment]

    id: int | None = Field(default=None, primary_key=True)
    entry_id: str = Field(index=True, unique=True)
    cluster_id: str | None = Field(default=None, index=True)
    status: str = Field(default="active")

BaseTable already provides created_at / updated_at (auto-bumped).

4.2 Re-export — tables/__init__.py

from .episode import EpisodeState as EpisodeState

4.3 Repo — infra/persistence/sqlite/repos/<name>.py

from sqlalchemy.ext.asyncio import AsyncSession, async_sessionmaker

from everos.core.persistence.sqlite import RepoBase

from ..sqlite_manager import get_session_factory
from ..tables import EpisodeState


class _EpisodeStateRepo(RepoBase[EpisodeState]):
    model = EpisodeState

    def _factory_lookup(self) -> async_sessionmaker[AsyncSession]:
        return get_session_factory()


episode_state_repo = _EpisodeStateRepo()

4.4 Re-export — repos/__init__.py

from .episode import episode_state_repo as episode_state_repo

5. (Optional) Derived index — 4 steps

Skip this section if the kind doesn't need vector / BM25 / hybrid retrieval.

5.1 Record declaration — infra/persistence/records/<name>.py

from typing import ClassVar

from everos.core.persistence.lancedb import BaseLanceTable, Vector


class EpisodeIndex(BaseLanceTable):
    TABLE_NAME: ClassVar[str] = "episode_index"
    PRIMARY_KEY: ClassVar[tuple[str, ...]] = ("app_id", "project_id", "id")

    id: str
    app_id: str = "default"
    project_id: str = "default"
    entry_id: str
    text: str
    tags: list[str]
    vector: Vector(1024) | None = None  # type: ignore[valid-type]

TABLE_NAME / BM25_FIELDS / PRIMARY_KEY are the backend-neutral declarations every index backend reads (IndexRecordMeta). PRIMARY_KEY has no default: check_primary_keys refuses to start, and LanceDB upsert refuses to write, a table that does not declare one. id is unique only within (app_id, project_id), so every business table declares the three-column key — LanceDB merges on it, Milvus keys the collection on a composed __pk and rejects key components containing /. Vector(N) must match your embedding dimension.

5.2 Re-export — records/__init__.py

from .episode import EpisodeIndex as EpisodeIndex

5.3 Repo — infra/persistence/lancedb/repos/<name>.py

from lancedb import AsyncTable

from everos.core.persistence.lancedb import LanceRepoBase
from everos.infra.persistence.records import EpisodeIndex

from ..lancedb_manager import get_table


class _EpisodeIndexRepo(LanceRepoBase[EpisodeIndex]):
    schema = EpisodeIndex

    async def _table_lookup(self) -> AsyncTable:
        return await get_table(self.schema.TABLE_NAME, self.schema)


episode_index_repo = _EpisodeIndexRepo()

Business code writes through the everos.infra.persistence.index facade: upsert(records) merges on the declared key and is the only write; look a row up with find_one_where(primary_key(app_id, project_id, row_id)).

5.4 Re-export — repos/__init__.py

from .episode import episode_index_repo as episode_index_repo

6. (Future) Skill-named & single-file markdown strategies

When the new memory kind needs:

  • skill-named files (one file per named skill, in-place rewrite) — wait for BaseSkillWriter, or use MarkdownWriter.write_markdown directly with a thin wrapper.
  • single-file rewrite (one fixed file like user.md) — wait for BaseProfileWriter, same fallback.

These strategies do not use entry markers; their frontmatter schema does not need ENTRY_ID_PREFIX (only id / type / schema_version plus the scope mixin fields).


7. Verification checklist

  • make lint — ruff + import-linter clean
  • make test — existing manager / lifespan / writer tests still pass
  • When the kind crosses multiple layers:
    • markdown entry id is the join key for the sqlite / lancedb rows
    • business code reads only via the repo singleton (no raw engine access in service / memory)
    • cascade daemon (when it lands) can rebuild sqlite / lancedb from md alone — keep md as the truth

Tests by layer:

Tests forLocation
Markdown frontmatter schematests/unit/test_infra/test_markdown/test_mds/
Markdown business appendertests/unit/test_infra/test_markdown/test_writers/
SQLite RepoBase logictests/unit/test_core/test_persistence/test_sqlite/
SQLite manager / lifespantests/unit/test_infra/test_sqlite/
LanceDB LanceRepoBase logictests/unit/test_core/test_persistence/test_lancedb/
LanceDB manager / lifespantests/unit/test_infra/test_lancedb/

8. Common pitfalls

MistakeSymptomFix
Forgot ENTRY_ID_PREFIX / DIR_NAME / FILE_PREFIX on a daily-log schemaBaseDailyWriter.__init__ raises TypeErrorAdd all three ClassVars
Same ENTRY_ID_PREFIX on user + agent variantsMemoryLayout.locate_for_entry collision errorUse distinct prefixes (e.g. umc vs amc)
Imported RepoBase from infra.persistence.sqliteImportErrorLives in core.persistence.sqlite (moved earlier)
Skipped one of the four files (schema / writer / table / repo)One side silently absentRe-export both/all from each __init__.py
Vector(N) mismatched with embedding dimLanceDB raises on insertMake N exactly match the model output
Imported MemoryLayout from a writer (infra)import-linter fails (infra → memory reverse dep)Use MemoryRoot (in core) and let the schema's ClassVars drive paths
Hand-rolling datetime.now() instead of today_with_timezone()Day-boundary drift across timezonesAlways go through everos.component.utils.datetime

Background

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

commit

無料概要あり

変更内容と最近の履歴を確認し、Conventional Commits形式のメッセージを作ってコミットします。無関係な変更を分け、フックの失敗にも対処します。

  • 変更を確認してコミットしたいとき
  • 差分から関連ファイルだけを選びたいとき
  • 規約に沿ったコミット文を作りたいとき
EverMind-AI/EverOS1.4万2026年10月29日 更新

new-branch

無料概要あり

変更内容に合った接頭辞と短い名前を決め、mainを最新にして用途を絞ったGitHub作業ブランチを作成するスキルです。

  • 機能追加用のブランチを作りたいとき
  • バグ修正用のブランチを切りたいとき
  • ドキュメント更新を始めたいとき
EverMind-AI/EverOS1.4万2026年10月29日 更新

pr

無料概要あり

変更内容や確認結果をリポジトリのPRテンプレートに沿って整理し、mainを対象にGitHubでプルリクエストを作成するスキルです。

  • 完了した変更のPRを作りたいとき
  • PRテンプレートの各欄を記入したいとき
  • CIや手動確認の結果を記録したいとき
EverMind-AI/EverOS1.4万2026年10月29日 更新

release

無料概要あり

everosのバージョンを更新し、タグを使った自動処理でPyPIへ公開するリリース手順を進めます。変更履歴やGitHub Releaseの下書きも整えます。

  • パッチ・マイナー版を公開したいとき
  • プレリリースを配布したいとき
  • 変更履歴から公開ページを整えたいとき
EverMind-AI/EverOS1.4万2026年10月29日 更新

EverMind-AI のスキルをすべて見る

このスキルの問題を報告する