agentsclimarketplace

Agent memory blueprint

Skill yystudio-cyber/agent-memory-blueprint

Agent Memory Blueprint: public-safe templates, validators, and skill packaging for machine-first long-running agent memory.

Install
npx -y skills add yystudio-cyber/agent-memory-blueprint

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Design, scaffold, validate, analyze, package, and publish machine-first memory blueprints for long-running AI agents. Use when Codex needs to create or improve a canonical multi-project memory YAML file, split execute/history/update read modes, define project skill cards and detail sections, maintain append-only event ledgers, validate strict-public safety, or prepare a public GitHub Agent Skill/template without leaking private content.

SKILL.md

5.5 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Agent Memory Blueprint

Treat agent memory as a bootable knowledge system, not as notes.

When to use this skill

Use this skill to:

  • design a machine-first YAML memory blueprint for agents
  • scaffold a new synthetic or private memory file
  • validate structure and public-safety boundaries
  • analyze an existing memory shape without printing detail contents
  • prepare a public GitHub Skill package from a private architecture
  • explain or maintain the four-layer memory model

When not to use this skill

Do not use this skill to:

  • store or publish real private data
  • publish real candidate, customer, resume, email, phone, profile URL, or recruiting data
  • replace a database, CRM, ATS, RPA, crawler, scraper, or SaaS product
  • bypass privacy review or treat --strict-public as a perfect leak detector

Operating model

Build four layers:

  • Boot and routing: agent_boot, read_profiles, project_skill_cards, project_index
  • Execution cards: compact project cards with current_state, next_action, paths, and do-not rules
  • Detail sections: SOP, constraints, validation state, commands, and deeper project context
  • History ledgers: append-only calendar_events_YYYY_MM sections for reports and retrospectives

Use multi-document YAML only when helpful. Top-level keys must be unique within and across documents.

Workflow

1. Analyze shape first

Run:

python scripts/analyze_memory_shape.py /path/to/memory.yaml --json

Use the report for structural facts only: top-level keys, read profiles, project cards, detail links, calendar sections, duplicate top-level keys, and public-risk marker counts. Do not copy live project content into public templates.

2. Choose a reference

  • Use references/architecture.md for the four-layer model.
  • Use references/schema.md and schemas/memory.schema.json for field contracts.
  • Use references/update-protocol.md when editing a live private memory file.
  • Use references/publication.md before preparing public GitHub content.

3. Scaffold

Run:

python scripts/scaffold_memory.py --output /path/to/memory.yaml --owner OWNER_NAME

The scaffold is synthetic. Replace it with real project cards only in private files outside the public repository.

4. Validate

Run:

python scripts/validate_memory.py /path/to/memory.yaml

Before publishing:

python scripts/validate_memory.py /path/to/memory.yaml --strict-public
python scripts/release_check.py

Strict-public fails likely emails, phone-like content, recruiting/profile URLs, secret-like assignments, and non-placeholder local paths such as C:\Users\real-user\..., D:\Projects\..., /Users/real-user/..., /home/real-user/..., /mnt/data/..., /workspace/..., /var/secrets/..., /opt/internal/..., or ~/private/....

Allowed placeholder path patterns include /path/to/..., /example/..., obvious values containing OWNER_NAME, PROJECT_ID, example, demo, or placeholder, and /tmp/... for tooling convenience.

5. Package

Run:

python scripts/package_skill.py --output dist/agent-memory-blueprint.zip

The package check must reject caches, .git, .env, private memory files, private/, backups/, .pyc, and nested dist/ output.

Design rules

  • Keep one canonical private memory file per actual user/workspace.
  • Let read_profiles choose execution, history, or update-memory mode.
  • Keep project_skill_cards short enough for every execution.
  • Put deep context in named detail sections.
  • Keep calendar history outside default execution reads.
  • Use supersedes or deprecation notes for correction instead of silent deletion.
  • Every meaningful update should leave a concise human-readable event.
  • Validation status must be truthful: passed, partial, blocked, or not_run.

Before publishing

  • Run every YAML intended for publication through --strict-public.
  • Run python scripts/release_check.py or make release-check.
  • Inspect examples manually and confirm they are synthetic.
  • Inspect dist/agent-memory-blueprint.zip.
  • Do not publish live private memories, backups, real project logs, credentials, profile links, resumes, or personal data.
  • Do not weaken strict-public to make unsafe content pass.

Resources

  • assets/memory-template.yaml: public starter template
  • examples/: synthetic public examples for productivity, software, and research workflows
  • schemas/memory.schema.json: baseline JSON Schema for core structure
  • scripts/analyze_memory_shape.py: private-safe structural analyzer
  • scripts/package_skill.py: public-safe zip packager
  • scripts/release_check.py: one-command release verification
  • scripts/scaffold_memory.py: deterministic template generator
  • scripts/validate_memory.py: structural and strict-public validator
  • tests/: regression tests for validators, examples, and private-safe analysis
  • references/architecture.md: architecture model
  • references/schema.md: field contracts and naming rules
  • references/update-protocol.md: live-memory editing procedure
  • references/publication.md: GitHub/public-release boundary

Gives 0 of the 12 instructions most memory context skills give in ~1.1k tokens

Counted across 674 of the 847 authors here whose files we hold, read 2026-08-06

  • inform the user when setup is completein 21 of 674, across 6 files
  • confirm the draft with the user before writingin 21 of 674, across 6 files
  • update the agent skills block in place if it existsin 21 of 674, across 6 files
  • present findings to the userin 20 of 674, across 5 files
  • write the three docs files from seed templatesin 20 of 674, across 5 files
  • ask the user about each decision one at a timein 19 of 674, across 4 files
  • edit CLAUDE.md if it existsin 18 of 674, across 3 files
  • explore current repo statein 18 of 674, across 3 files
  • do not overwrite user edits to surrounding sectionsin 18 of 674, across 3 files
  • back up the original file before overwritingin 16 of 674, across 8 files
  • keep the memory index under 200 linesin 15 of 674
  • Provide actionable steps and verificationin 13 of 674, across 2 files

Said here and by no other author read

  • keep top-level keys unique within and across documents
  • analyze the memory shape before editing
  • use references and schemas for field contracts
  • replace synthetic scaffolds only in private files
  • validate memory before publishing
  • run strict-public validation before publication

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.