open-scholar-peer: Instructions file for Claude Code

kiacontext — this project's memory. Read this before you start work.

This repository carries a folder called kia-context/. It is a small set of Markdown files holding what a reader of the code cannot see: what is being built right now, what was already decided and why, what was tried and rejected, and what must never change. The layout is a reusable harness called kiacontext; everything inside it is specific to this project.

👉 Start by reading kia-context/INDEX.md.

It is the map of every other file — one minute of reading, and nothing below makes proper sense without it. Read it before your first substantial action in a session, not when you get stuck.

Why this exists. You start every session with no memory of the last one. The code can tell you what the system does; it can never tell you why it is that way, what was already attempted and abandoned, or which awkward-looking part is deliberate and must not be "improved". Without that, settled arguments get re-run, decisions get quietly reversed, and work is redone. These files are the part of the project that survives between sessions.

They are authoritative. Where the code and a spec disagree, that is a finding to raise with the human — not a document to ignore.

You write these files. The human decides what goes in them. Every file under kia-context/ is written by an agent, out of a conversation — nobody maintains them by hand. Your job is to keep them true.

How to use them.

• Before proposing or building anything: specs/MANIFESTO.md for the boundary you may not cross, and the active logs/BRAINSTORM.md to check whether your idea was already considered and rejected.
• Before touching anything structural: specs/ARCHITECTURE.md.
• Every session: logs/PROGRESS.md holds the current milestone, its deliverables and their acceptance criteria — what is being built, and how far it got. How to work through it is written in that file, not here.
• Every file states its own terms. Its frontmatter says how binding it is, who may write to it, whether it is still active, and — in the description — what does not belong in it. Read that before editing; it beats guessing from the filename.
• The body of a file is yours; its frontmatter is not. Every heading, table and section you find in these files is a starting suggestion — reshape any of it to fit the project, and delete what does not apply rather than leaving it empty. The six frontmatter fields are the exception: they are what make a file part of kiacontext, so keep all six on every file and keep their values current.
• Writing back is part of the work, not an afterthought. A session that changes the project and leaves these files untouched has thrown away everything it learned.