archive

Overview of archive skill

What archive does well

The archive skill is for teams and solo builders who want to turn one-off session knowledge into reusable project memory. Instead of leaving fixes buried in chat history, it stores debugging resolutions, deployment notes, and process learnings in .archive/YYYY-MM-DD/ as structured markdown, then keeps a lightweight index in .archive/MEMORY.md.

Who should install archive

This archive skill is best for people who repeatedly revisit the same infrastructure, CI, release, or debugging problems and want faster future recovery. It is especially useful if your work spans multiple sessions, multiple agents, or multiple contributors who need a shared “what happened last time?” record.

The real job-to-be-done

Users do not need another note-taking habit. They need a reliable way to capture high-value technical context right after a meaningful task finishes, then surface that context before the next similar task starts. archive is designed around that workflow, not around generic documentation.

Why archive is different from a normal prompt

A normal prompt can tell an AI to “summarize what we did.” The archive skill adds a repeatable storage pattern, a required memory index update, and a session-start hook that loads .archive/MEMORY.md automatically when present. That makes archive for Knowledge Bases practical: the archive becomes part of future working context, not just a forgotten markdown file.

Key tradeoffs before you install

archive is intentionally simple. It does not provide a database, vector search, or automated categorization pipeline. Its value comes from disciplined file structure, searchable tags, and a memory index. If your team will not maintain .archive/MEMORY.md, the archive skill loses much of its advantage.

How to Use archive skill

archive install and repository files to read first

A practical archive install path is:

1. Add the skill from the ReScienceLab/opc-skills repository in your skills system.
2. Read skills/archive/SKILL.md first for the workflow.
3. Read skills/archive/references/TEMPLATE.md for the required archive shape.
4. Read skills/archive/hooks/hooks.json and skills/archive/hooks/load-memory.py if you care about startup context loading.
5. Check skills/archive/.factory-plugin/plugin.json to confirm the intended behavior.

If you only skim one support file, make it references/TEMPLATE.md; it tells you what “good archive output” looks like.

What the archive skill needs as input

The archive skill works best when you give it:

• the completed task or incident
• the main outcome
• the key steps taken
• the critical commands, config changes, or code decisions
• the failure points and final fixes
• the category and likely tags
• any related older archive entries

Without those inputs, the archive will be too vague to help later.

When to trigger archive usage

Use archive after:

• a successful deployment
• a tricky debugging session
• a migration or infrastructure change
• a major feature completion
• any user instruction like “archive this”

Do not use it for every minor edit. The skill is meant for durable learnings, not noisy activity logs.

How archive usage works in practice

The intended workflow is:

1. Check .archive/MEMORY.md for related past work.
2. Create or reuse .archive/YYYY-MM-DD/.
3. Write a markdown archive using the template structure and YAML frontmatter.
4. Add a one-line index entry to .archive/MEMORY.md.
5. Link related entries with the related field.

That index update is not optional busywork. It is what makes future lookup fast.

A stronger prompt for archive skill

Weak prompt:

• “Archive this session.”

Better prompt:

• “Use the archive skill to document today’s ECS deploy issue. Include the IAM permission error, the CloudWatch clue, the exact fix, final deploy status, tags for ecs, iam, deploy, category infrastructure, and add a one-line entry to .archive/MEMORY.md. If a related archive exists, link it.”

The stronger version gives the model enough structure to produce something you can actually reuse.

How to turn a rough goal into a complete archive request

If your raw goal is “save what we learned,” expand it into:

• what happened
• why it mattered
• what failed
• what fixed it
• what should be checked first next time
• where this belongs in categories
• how someone should find it later via tags

This skill rewards retrieval-oriented writing, not narrative writing.

The archive template fields that matter most

From references/TEMPLATE.md, the most important fields are:

• tags: for grep-based retrieval
• category: for index organization
• related: for connecting incidents over time

In the body, the most valuable sections are usually:

• Summary
• Issues Encountered & Solutions
• Key Changes

If you skip the concrete fix details, the archive becomes much less useful.

How the session-start memory hook changes usage

The hook loads .archive/MEMORY.md into session context at startup when the file exists. That means the archive skill is not just for writing; it improves future recall automatically. In adoption terms, this is one of the strongest reasons to install the skill rather than using an ad hoc note file.

archive for Knowledge Bases and team memory

For archive for Knowledge Bases, think of .archive/MEMORY.md as the table of contents and each dated markdown file as the incident or task record. This works well for:

• recurring operational issues
• release checklists with gotchas
• environment-specific fixes
• design decisions with consequences

It is less suitable for broad product documentation or user-facing manuals.

Practical search and lookup workflow

The skill explicitly supports lightweight search:

• review .archive/MEMORY.md
• use grep -ri "keyword" .archive/

That is enough for many engineering teams because the stored content is narrow, technical, and structured. Use tags people will actually search for later: service names, error strings, platform names, and component names.

archive skill FAQ

Is archive worth installing if I already write notes?

Yes, if your current notes are hard to find or never re-enter agent context. The archive skill is useful because it standardizes location, structure, indexing, and session-start memory loading.

Is this archive skill beginner-friendly?

Yes, mostly. The workflow is simple markdown plus one index file. The main beginner risk is writing summaries that are too abstract. The skill is easiest to use if you copy the template and fill in specific fixes, commands, and lessons.

When should I not use archive?

Do not use archive for:

• trivial edits
• temporary brainstorming
• long-form docs
• knowledge that belongs in permanent repo documentation like README.md or runbooks

If the information should guide all contributors all the time, it may belong in standard docs, not only in .archive/.

How is archive different from regular project docs?

Regular docs describe the intended system. Archive usage captures what actually happened during a task or incident: the failed paths, the exact fix, and the context that usually gets lost. It is a historical operational memory layer, not a replacement for canonical docs.

Does archive require special tooling?

Not much. The core format is markdown files plus .archive/MEMORY.md. The repo also includes a hook that loads memory at session start, but even without that, the archive skill still works as a disciplined storage pattern.

What are the boundaries of this archive guide

This archive guide reflects what the repository supports: file-based archives, indexed memory, simple categories, related links, and hook-based recall. It does not promise automated summarization pipelines, semantic search, or external knowledge base syncing.

How to Improve archive skill

Write archive entries for retrieval, not for storytelling

The best archive output is easy to scan later. Put the problem, fix, and critical commands where a future reader can find them fast. A polished narrative is less valuable than a blunt, searchable record.

Use tags people will actually search

Good tags:

• service or tool names
• exact subsystem names
• deployment platform names
• error keywords
• affected environment names

Bad tags:

• vague words like issue, work, or update

This is one of the highest-leverage improvements for archive usage quality.

Make MEMORY.md useful, not ceremonial

A weak index entry says:

• “Fixed deployment issue”

A strong one says:

• “ECS deploy failed due to missing IAM permission for secret access; resolved by updating task role policy”

The index should help someone decide which archive to open next.

Capture failed attempts when they change future decisions

If the team tried two wrong fixes before the right one, include them when they help prevent repeated waste. This is where the archive skill often beats standard docs: it preserves the dead ends that matter.

Provide better inputs to get better archive output

Before asking the skill to archive, gather:

• exact error text
• relevant commands
• changed files or settings
• final verified state
• why the final fix worked

These details materially improve future reuse and searchability.

Common failure modes in archive skill usage

Typical problems include:

• missing .archive/MEMORY.md update
• tags that are too generic
• no clear category
• summary without operational detail
• archive entries with no relation to prior incidents

Most poor archive results come from incomplete input, not from the template itself.

Iterate after the first archive draft

After the first draft, check:

• Can someone find this with likely search terms?
• Does the summary say outcome and cause?
• Are the key commands or config changes included?
• Would a future agent know what to try first?
• Should it link to an older related entry?

A short second pass usually raises archive quality a lot.

Use archive alongside, not instead of, permanent docs

If the session revealed a permanent rule, update the canonical doc too. The archive skill should preserve event-level knowledge; it should not become the only place where critical team guidance lives.

Improve archive adoption with a clear team trigger

Teams get better results when they define explicit triggers such as:

• every production deploy with surprises
• every incident with a non-obvious fix
• every migration
• every user request to “save this for next time”

That keeps the archive valuable without filling it with noise.