research-harness-work
Skill42 starsChanged 6 days agoMITView on GitHub
RES: Execute approved analysis tasks from analysis_plan.md. Writes scripts, runs them, saves logs and outputs, updates task status. Trigger: run analysis, execute task, run regression, produce table, produce figure. Do NOT load for: planning, review, release, setup, audit, cleaning.
In this repository32 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-browserSkill
- authSkill
- ciSkill
- crudSkill
- deploySkill
- harness-acceptSkill
- harness-loopSkill
- harness-plan-briefSkill
- harness-planSkill
- harness-progressSkill
- harness-releaseSkill
- harness-reviewSkill
- harness-setupSkill
- harness-syncSkill
- harness-workSkill
- maintenanceSkill
- memorySkill
- principlesSkill
- research-harness-auditSkill
- research-harness-cleanSkill
- research-harness-planSkill
- research-harness-releaseSkill
- research-harness-reviewSkill
- research-harness-setupSkill
- session-controlSkill
- session-initSkill
- session-memorySkill
- sessionSkill
- session-stateSkill
- uiSkill
- workflow-guideSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 15 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈15
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Default behavior with no argument: ask the user which task or stage to run.
- Distinctive: line 38
Before executing any task:
- Very specific: line 40
Read analysis_plan.md. If it does not exist, stop and tell the user to run /research-harness-plan first.
- Very specific: line 43
If the task has cc:blocked status: report the blocking reason and stop.
- Distinctive: line 59
If the task has unresolved questions: stop and list them.
- Distinctive: line 65
Write the script at the path specified in the task definition.
- Distinctive: line 112
Do not hard-code numerical results into the script.
- Distinctive: line 116
Run the script. Capture the exit code and the full log output.
- Distinctive: line 123
Do not continue to the next step if the script did not exit with code 0.
- Distinctive: line 127
After a successful run, verify:
- Very specific: line 133
If any verification fails: do not mark the task cc:done.
- Very specific: line 137
Add an evidence row to the Evidence Ledger in analysis_plan.md:
- Distinctive: line 164
Do not paraphrase or interpret the results.
- Distinctive: line 168
Do not report any number that is not present in the log file
- Very specific: line 169
Do not mark a task cc:done unless the log file and output file both exist
- Distinctive: line 170
Do not continue after a script failure without documenting the error
- Very specific: line 171
Do not change analysis_plan.md task scope without recording the change under the task
- Distinctive: line 172
Do not use absolute file paths in scripts
- Very specific: line 173
Do not execute a task that is cc:blocked without user instruction
- Very specific: line 174
Do not run tasks that were not in the approved analysis_plan.md without user instruction
- Distinctive: line 198
If a task fails after 3 attempts:
- Very specific: line 200
Write to analysis_plan.md under the task:
- Distinctive: line 207
Do not invent output, use estimated values, or continue as if the task completed.
- Distinctive: line 211
After all approved tasks are complete:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Research Harness Work
Execute approved analysis tasks from analysis_plan.md. For each task, write a reproducible script, run it, verify the log exists, and update the evidence ledger.
This skill runs after /research-harness-plan (human-approved) and before /research-harness-review.
Quick Reference
| Input | Action |
/research-harness-work 1.1 | Execute task 1.1 from analysis_plan.md |
/research-harness-work 2 | Execute all tasks in stage 2 sequentially |
/research-harness-work all | Execute all cc:todo tasks sequentially |
/research-harness-work --no-commit | Execute without committing; leave outputs for review |
Default behavior with no argument: ask the user which task or stage to run. Do not auto-select.
Pre-flight Checks
Before executing any task:
- Read
analysis_plan.md. If it does not exist, stop and tell the user to run/research-harness-planfirst. - Confirm the task ID exists in
analysis_plan.mdand its status iscc:todoorcc:wip. Do not re-executecc:donetasks without explicit user instruction. - Confirm the analysis-ready dataset specified in
analysis_plan.mdexists underdata/processed/. - If the task has
cc:blockedstatus: report the blocking reason and stop. Do not work around a blocked task.
Procedure
Step 1 — Read the task definition
From analysis_plan.md, read for the specified task:
- Script path
- Log path
- Output path
- DoD (definition of done)
- Assumptions
- Unresolved questions
- Identification strength label
If the task has unresolved questions: stop and list them. Ask the user to resolve them before the task runs.
Mark the task cc:wip in analysis_plan.md.
Step 2 — Write the analysis script
Write the script at the path specified in the task definition.
Script requirements:
- Language: use whichever language the study uses (R, Stata, Python). If not specified, use R.
- Header comment: study name, task ID, date, analyst (Claude Code), identification strategy from
study_spec.md§2 - Project-relative paths only
- Set random seed if any random operation is used
- Open log file at the start; close at the end
- Log: task ID, date, dataset loaded, N rows loaded, any sample restrictions applied with N dropped and N remaining, all model results including coefficients and standard errors, N in estimation sample
R template for regression task:
# Study: <study name>
# Task: <task-id> — <task description>
# Identification: <tag from study_spec.md>
# Date: YYYY-MM-DD
# Analyst: Claude Code
library(here)
log_file <- here("analysis", "<stage>", "logs", "<task>.log")
sink(log_file, append = FALSE, split = TRUE)
cat("Task:", "<task-id>", "\n")
cat("Started:", format(Sys.time()), "\n\n")
# Load
df <- read.csv(here("data", "processed", "analysis_ready.csv"))
cat("Loaded:", nrow(df), "rows\n")
# Sample restriction (if task-specific)
n_before <- nrow(df)
df <- df[<restriction>, ]
cat("After restriction:", nrow(df), "rows (dropped:", n_before - nrow(df), ")\n")
# Model
fit <- lm(<formula>, data = df)
cat("\n=== Results ===\n")
print(summary(fit))
# Save output
write.csv(broom::tidy(fit), here("output", "tables", "<task>.csv"), row.names = FALSE)
cat("\nOutput written to: output/tables/<task>.csv\n")
cat("Finished:", format(Sys.time()), "\n")
sink()Do not hard-code numerical results into the script. The script computes them; the log records them.
Step 3 — Run the script
Run the script. Capture the exit code and the full log output.
- Exit code 0: proceed to Step 4
- Exit code non-zero (attempt 1): read the log, identify the error, fix the script, re-run
- Exit code non-zero (attempt 2): read the log again, fix the specific error, re-run
- Exit code non-zero (attempt 3): stop. Do not invent output. Write the error to
analysis_plan.mdunder the task. Mark the taskcc:blocked. Tell the user what failed and why.
Do not continue to the next step if the script did not exit with code 0.
Step 4 — Verify evidence
After a successful run, verify:
- Log file exists at the path specified in the task definition
- Output file (table or figure) exists at the path specified
- The log contains the numerical results that will be reported (coefficients, standard errors, sample size)
If any verification fails: do not mark the task cc:done. Report what is missing.
Step 5 — Update analysis_plan.md
Add an evidence row to the Evidence Ledger in analysis_plan.md:
| Task | Script | Log | Output | Verified | Date |
| 1.1 | analysis/descriptive/scripts/table1.R | analysis/descriptive/logs/table1.log | output/tables/table1.csv | YES | YYYY-MM-DD |
Mark the task status cc:done.
Step 6 — Report completion
Print a task completion summary:
Task 1.1 — Complete
Script: analysis/descriptive/scripts/table1.R
Log: analysis/descriptive/logs/table1.log [exists: YES]
Output: output/tables/table1.csv [exists: YES]
Status: cc:done
Key results from log:
N = <value from log>
[other key stats from log]
Next task: 1.2 or run /research-harness-work 1.2Do not paraphrase or interpret the results. Quote them from the log.
Forbidden Actions
- Do not report any number that is not present in the log file
- Do not mark a task
cc:doneunless the log file and output file both exist - Do not continue after a script failure without documenting the error
- Do not change
analysis_plan.mdtask scope without recording the change under the task - Do not use absolute file paths in scripts
- Do not execute a task that is
cc:blockedwithout user instruction - Do not run tasks that were not in the approved
analysis_plan.mdwithout user instruction
Evidence Requirements
- Script file exists at the documented path
- Log file exists at the documented path
- Output file exists at the documented path
- Evidence row added to
analysis_plan.md - Task status updated to
cc:doneinanalysis_plan.md
Completion Criteria (per task)
- Task definition read from approved
analysis_plan.md - No unresolved questions blocking the task
- Script written with header comment, project-relative paths, log file
- Script ran with exit code 0
- Log file exists
- Output file exists
- Key results visible in log
- Evidence row added to
analysis_plan.md - Task status:
cc:done
Escalation (task failure)
If a task fails after 3 attempts:
- Write to
analysis_plan.mdunder the task:- What error occurred (quoted from log)
- What was tried
- What is needed to resolve it
- Mark task
cc:blocked - Tell the user: the data or design may not support this task. They must decide whether to revise the plan.
Do not invent output, use estimated values, or continue as if the task completed.
Handoff to Stage 6
After all approved tasks are complete:
All requested tasks are done. Review
analysis_plan.mdto confirm all expected tasks arecc:done.When ready, run
/research-harness-reviewto check identification, numerical accuracy, and causal claims before release.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

