lividgreen/research
Research records for a coding agent, changed through transitions and held together by a check: ideas, questions, tasks and findings as typed Markdown records, a reference library that refuses an unread citation, a dashboard over both, and the method a session works by.
One read-only browser dashboard over the flow's records, the reference library's cards and any other component installed beside it and bound in the project — every page the component's own command-line answer, rendered. Use when the owner wants to browse the records or the cards, when asked to start or stop the dashboard, and when writing a new component that should add its pages to it. Reads no record or card file itself and writes nothing.
Root-cause debugging discipline — use when encountering any bug, failing test or check, unexpected behavior, or build failure, BEFORE proposing fixes; and again before claiming anything is fixed. Especially when a "quick obvious fix" is tempting or previous fixes didn't stick.
Design pass for any new mechanism, tool, check, document section, or formal target — run BEFORE implementing. Use whenever the user proposes building or changing something ("let's add X", "can we do Y", "should we…", "what about…"), picks up a recorded open question or decision, or asks for a feature.
The typed flow of research work — ideas, tasks, questions with kill criteria and findings whose evidence a machine resolves, one Markdown record each, transitions through the flow CLI, a validator, a generated index with a ranked next list, and a cold-start bundle. Use when reading a project's records to pick up work, when capturing an idea, minting or drawing a task, closing one with its resolution, framing or answering a question, recording a checkable result, ranking the next list, or restructuring the records. The project's own instructions bind the directory, the prefixes and the gates through flow.toml; this skill names none of them.
The reference library — one card per referred work (a paper, a book, a preprint, a software library or tool, a dataset, a report handed in, a page) holding its fields, how it was read, our notes and what it says at a place, written and searched through the library CLI. Use when registering a work, recording how it was read, looking for a work or for what one states, finding related works or where one is cited, and before any sentence cites a work. For any project that refers to things, scientific or not. The project's own instructions bind the directory and the gates through library.toml; this skill names none of them.
Method rules for a project that writes documents and makes claims — how to review, what counts as evidence, what to check before pricing a piece of work, how to change a target honestly when a wall is hit, and, where the project keeps a machine-checked library, how a formal target is picked and scoped and what a wall is. Use before a design round, a list refresh, a review pass or the pricing of a formal target. The rules come from one research programme, and the incidents that earned them are not part of the kit.
Sets a project up for the research plugin — the flow, the reference library, the instructions paragraphs and the pre-commit hooks — and checks an existing setup. Use as /research:research-init, or when asked to set up research-kit, the flow, the library or the records in a project, or to check what the setup is missing, or to bring a project's existing notes, plans and bibliography into the records and the cards. Probes the project and the machine with scripts/setup.py probe, proposes what is missing and installs it only on the person's word, writes what the probe says is absent and nothing that exists, and reports what was written, installed and declined. The project's own instructions bind the names afterwards; this skill writes them once.