Memory Sync Protocol

Synchronize durable behavior or preference changes across TOOLS.md, MEMORY.md, AGENTS.md, and memory/YYYY-MM-DD.md with one consistent workflow. Use when use...

Security Scan

The skill's instructions match its stated purpose (syncing memory/tool/governance files) and it does not request unexpected credentials or installs, but it does assume filesystem and git access and can change global agent files so you should review changes before committing.

Purpose & Capability

The name/description (synchronizing TOOLS.md, MEMORY.md, AGENTS.md, daily memory logs) matches the SKILL.md actions. It does not request unrelated env vars, binaries, or config paths. One implicit requirement: the agent must have read/write access to the repository files and git available to follow the 'Git discipline' steps.

Instruction Scope

The SKILL.md is narrowly focused on classifying changes, editing the specified files, appending a daily log, and committing. It does not instruct reading unrelated system files or sending data externally. However, it gives the agent authority to modify repository files that govern agent/tool behavior (AGENTS.md, TOOLS.md), and it relies on the agent to avoid storing secrets (a guardrail but not an enforcement).

Install Mechanism

Instruction-only skill with no install spec and no code files; nothing will be downloaded or written at install time by the skill itself.

Credentials

The skill requests no environment variables or credentials. That is proportional. Caveat: the guardrail 'Do not store sensitive secrets...' depends on the agent following instructions—if users ask the skill to sync content that includes secrets, those secrets could be written into the repo files unless the user or agent blocks it.

Persistence & Privilege

The skill is not 'always: true' and doesn't request elevated platform privileges, but it is designed to edit global governance and tooling files (AGENTS.md, TOOLS.md). Those edits can change future agent behavior—this is consistent with its purpose but creates a meaningful persistence/privilege surface that the user should control (e.g., review commits).

Assessment

This skill is coherent for its stated job, but it assumes the agent can write repository files and run git. Before enabling or invoking it: (1) make sure the files it edits are in a repository you control and that you have backups; (2) require a human review step for diffs/commits (don't allow blind pushes); (3) do not request the skill to sync content that contains secrets or credentials; (4) confirm the environment has git and that file permissions are intentionally granted; (5) consider testing in a sandbox repo first so you can observe the exact edits and commit messages it produces.

When this skill is triggered, execute the following sequence strictly.

1) Classify the change

• Execution detail (tool/profile/path/routing trigger) → TOOLS.md
• Long-term stable preference (high-level) → MEMORY.md
• Governance/process rule (how to maintain) → AGENTS.md
• Event log / audit trail (what changed today) → memory/YYYY-MM-DD.md

2) Update files with minimal duplication

• Write detailed routing/trigger logic in TOOLS.md.
• Write only high-level summary in MEMORY.md.
• Avoid copying large sections between files.
• If adding a new policy, also add short maintenance note in AGENTS.md.

3) Append daily log

• In memory/YYYY-MM-DD.md, record:
  • what changed,
  • why,
  • affected files.

4) Git discipline

• Before major rewrites: create a backup commit.
• After updates: commit with semantic message, e.g.
  • docs(routing): ...
  • docs(memory): ...
  • chore(memory): ...

5) Reply format

Return a concise sync report:

• Updated files
• Key rules added/changed
• Commit hash/message

Guardrails

• Do not store sensitive secrets in MEMORY/TOOLS unless user explicitly asks.
• Do not bloat MEMORY with skill inventories or transient logs.
• Prefer TOOLS for concrete calling rules; MEMORY for durable preference only.