Phira Project Memory Lookup

Use this skill when historical project context is likely to change what you should recommend, build, or review.

Purpose

• Treat .archive/ as durable project memory maintained by phira-archivist.
• Pull only relevant history into the current task context.
• Avoid re-running known dead ends and avoid violating prior decisions unless explicitly revisiting them.

When to use this skill

Use when one or more are true:

• You are about to change defaults, interfaces, eval criteria, or workflow assumptions.
• The task looks similar to earlier attempts and repeated failures are possible.
• The user asks for status/history/what was already tried or decided.
• You need rationale behind an earlier decision before proposing changes.

Do not use by default for every task. Keep lookups targeted and cheap.

Lookup protocol (read-only)

1. Check whether .archive/ exists.
2. Resolve baseline pointer:
   • Prefer .archive/pointers/branches/<branch_key>.yaml when branch pointer exists.
   • Else use .archive/pointers/HEAD.yaml if it exists.
   • If neither exists, memory is unavailable; continue without archive context.
3. Read last_record from the pointer, then read .archive/records/<last_record>.md.
4. If more context is needed, walk parents lineage with caps:
   • max depth: 8
   • max records total: 12
5. If task-specific context is needed, run keyword search over .archive/records/*.md:
   • use 2-5 focused keywords from user intent
   • read only top matches needed (cap at 10 files)

Output: memory packet

When this skill is used, produce a compact memory packet for the caller/output:

• records: ordered list of relevant record IDs (newest first)
• constraints: active constraints that should affect current work
• decisions: prior decisions and why they were made
• failures: known failure modes/negative results worth avoiding
• open_questions: unresolved issues that may block confidence
• evidence: file paths used (pointer + record files)

Keep the packet short and high-signal.

Usage rules

• Cite record IDs and paths whenever archive history materially influences your answer.
• Treat archive records as strong context, not unquestionable truth.
• If the user explicitly asks to revisit or overturn a prior decision, do so explicitly.
• Never invent record content. If details are missing, say so.

Graceful fallback

• If .archive/ is missing, uninitialized, or inconsistent, proceed normally and note that no archive memory was available.