Research log

Skill Axect/skills/research-log

Reusable skills for AI coding agents (Claude Code, Codex, Forge) covering paper review, commit triage, GPU rentals, reference search, research logs, image-prompt composition, and more.

Install

npx -y skills add Axect/skills --skill research-log

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

3 stars3 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

Maintain a research log that acts as an advisor, not just a diary. Registers projects; records decisions with generalizable lesson extraction; saves session state; recalls cross-project lessons and prior solutions when stuck; checks proposed approaches against promoted anti-pattern rules; runs weekly review with lesson promotion and dashboard refresh. Use when the user asks to initialize a research-log project, record an experiment or decision, save session state, recall past lessons or how a blocker was solved before, check a planned approach against past mistakes, or review all projects.

SKILL.md

3.6 KB, as published. Nobody here has run it

Research Log

This skill maintains a unified research-log workspace in ~/.research/ and uses it to actively improve research, not merely to record it. The data model and all file schemas are defined in references/conventions.md — read it first whenever you touch the store.

The skill earns its keep at three moments:

M1 — decision-time guardrail. Surface relevant anti-patterns before the user commits to an approach. See "Decision guardrail" below — this fires from conversation, not only on command.
M3 — recall when stuck. Search across all projects for prior lessons and solutions.
M4 — real-time drift. Flag work that has drifted from the current Compass focus.

Decision guardrail (M1) — always active

Whenever the user proposes a research approach — an architecture, model, loss function, methodology, experimental design, or "let's do X" choice — before agreeing, elaborating, or helping execute it:

Read ~/.research/rules.md (small, promoted-rules-only; cheap to load).
Check whether any Rule's trigger/Check matches the proposed action.
If a Rule matches, surface it first: "You are about to {X}; this bit you in {projects} — {Check}." Include the evidence. Let the user decide; do not block.
If nothing matches, say nothing about rules and proceed normally.

This is a behavioral directive, not a hook. It applies in any registered project's working directory. Keep it lightweight — only promoted Rules are checked, and only when an actual approach choice is on the table (not for routine edits or questions).

Workflow router

Read the matching workflow reference for the user's request:

Project registration or onboarding → references/initialize.md
Recording an experiment, debugging result, or design choice → references/record.md
Saving current session context → references/save-state.md
Recalling past lessons / how a blocker was solved before (M3) → references/recall.md
Explicitly checking a planned approach against past mistakes (M1) → references/check.md
Weekly review, dashboard refresh, lesson promotion, archive scan → references/review.md

Working rules

Match the current working directory against the Project Registry in ~/.research/dashboard.md before acting on an existing project.
Follow the file schemas defined in references/conventions.md exactly.
Acquire the per-project lock (~/.research/.locks/{slug}.lock) before writing project state.
Compass ← current focus is the anchor for drift detection; keep exactly one.
When recording a decision, always attempt lesson extraction; when a lesson recurs across ≥ 2 projects, propose promoting it to a Rule and regenerate rules.md.
Treat dashboard updates as review-time derived data unless a workflow says otherwise.
When a workflow requires user approval before writing, draft first and wait for approval.
Never write to a legacy ~/.research-log/ backup; it is read-only.