name: autogrind
description: "Let the agent work continuously and fully autonomously without stopping. Use this skill for long-running grind sessions across code, ML/data, research, design, or writing. Trigger phrases: /autogrind, /自己动, 'keep working don't stop', 'grind on this', 'work until I say stop', 'autogrind this', 'keep improving'. Use even when the user simply says 'keep going' or implies uninterrupted autonomous progress without naming AutoGrind explicitly."
license: MIT
compatibility: Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Windsurf, Roocode, Cline, Trae, Kimi Code, GitHub Copilot, Goose, AmpCode, Kilo, Kiro, Factory, Hermes Agent, and any skills-compatible agent
metadata:
author: ttttonyhe
version: "1.4"
AutoGrind
Overview
AutoGrind keeps the agent continuously working through a five-phase cycle: Overview → Understand → Plan → Work → Reflect → 60s pause → repeat. The agent never decides the project is "done enough." Only the user decides when to stop.
Not for single tasks or interactive work. AutoGrind is a mode, not a command. If you want one specific thing done, give the instruction directly. Invoke AutoGrind for sessions where "keep improving until I say stop" is the right model — unrestricted tool use and a version-controlled project are strongly recommended.
Violating the letter of this rule is violating the spirit of this rule.
The Iron Law
GRIND UNTIL EXPLICIT STOP SIGNAL
Completing all current tasks is NOT a stop condition
Tell your agent to start working. Walk away. Come back to finished work.
AutoGrind is a skill for AI coding agents that makes them work continuously and autonomously, grinding through improvements, fixes, tests, and polish in repeating cycles until you say stop. No hand-holding. No "should I continue?" No stopping because the TODO list looks empty.
Works for any long-running workflow: code, ML, research, design, writing.
Compatible with the Agent Skills open standard; works across Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Windsurf, Roocode, Cline, Trae, Kimi Code, GitHub Copilot, Goose, AmpCode, Kilo, Kiro, Factory, Hermes Agent, and any skills-compatible agent. Each mechanism is grounded in published AI/ML research; see RESEARCH.md.
Please install the AutoGrind skill from https://github.com/ttttonyhe/autogrind.
Clone the repo, install the skill to the right location for my agent environment,
and confirm it is ready to use.
The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.
First-time install walkthrough for Claude Code, Codex CLI, and ChatGPT.
Workflow
INIT - once per session
Scan for guidance files: CLAUDE.md, AGENTS.md, GEMINI.md, .cursorrules, opencode.md, README.md
Extract: project goals, domain, methodology or tech stack, conventions, known issues
If none exist, infer from directory structure, existing artifacts, and project context
Initialize Session Heuristics: an empty in-context list (max 5) of transferable principles discovered during Reflect phases. Format: [cycle N] When <condition>, prefer <approach> because <reason>. Prepend each Overview with a quick read of this list.
Context compaction: each Overview re-reads project state from scratch, so compaction mid-session does not break the grind loop. If compaction occurs, complete the current phase and proceed normally. Session Heuristics are in-context only — they are lost on compaction. Reinitialize to an empty list and continue; the heuristics are a convenience, not a dependency.
Phase 1 - Overview
Assess current project state. Adapt to domain:
Code: git log --oneline -20, git status, run test suite, scan TODO/FIXME
ML/research: review experiment log or training runs, check latest metrics, scan open questions
Design/writing: review revision history, open feedback, check revision backlog
Produce a one-paragraph current-state summary. For each area assessed, note its lag from ideal (high / medium / low) — this directly feeds Plan prioritization.
Read Session Heuristics before proceeding to Understand.
Phase 2 - Understand
Review artifacts most relevant to this cycle's focus (code, data, papers, designs, drafts)
Review recent changes; identify failing validations, open questions, broken areas
Do not start planning until understanding is solid
Phase 3 - Plan
Own the work. Before listing tasks, ask: what actually matters most for this project's success right now? Reason from first principles — what is the highest-leverage change? Be willing to make creative choices, challenge assumptions, and identify non-obvious problems worth solving. A cycle fixing a fundamental architectural flaw outweighs ten cycles of marginal polish.
Generate 3–6 tasks. Fewer, well-scoped tasks beat long lists. Keep each task to ≤ 4 steps for reliable execution. Priority order applies across all domains:
Quality/coverage gaps — test coverage, experiment coverage, argument gaps
Documentation/writeup gaps
Performance/efficiency opportunities
Polish/refinement
Capability frontier: after listing priority tasks, scan for 1–2 frontier tasks — novel, achievable work at the edge of current capability that pushes the project forward rather than only patching problems.
Solvability gate: before finalizing the list, verify each task is actionable with available tools and access. Drop or defer unresolvable tasks. Specifically: skip any task that requires credentials, API keys, or secrets the user has not provided — note it as deferred, do not prompt the user mid-cycle.
Track tasks with the platform's task mechanism (see Platform Notes).
Phase 4 - Work
Execute tasks in priority order
Execute independent tasks concurrently where the platform supports it
Per task: execute → validate (run tests, inspect outputs, check metrics) → persist (commit, save checkpoint, export, log)
One logical change per persist — never batch unrelated changes
If blocked: note the blocker, skip to the next task
Interrupt the user only if all remaining tasks share the same unresolvable blocker
Safety boundary: stay within the project directory. Avoid operations with significant side effects outside the project scope — no system configuration changes, no deletions outside the project. Operations that would normally require human confirmation are off-limits during autonomous operation.
Phase 5 - Reflect
Step 1 — Grounded signals first. Before any self-assessment, check verifiable evidence:
Code: test results, lint/build status, coverage delta
ML/research: metric movement vs. last cycle, experiment outcomes
These facts anchor the reflection. Do not skip to self-assessment when execution signals are available.
Step 2 — Answer the two mandatory questions first — they override all other priorities:
Core deliverable check: Did this cycle directly improve the PRIMARY OUTPUT (the skill, model, paper, design, feature)? If work was only scaffolding (tests, tooling, CI): next cycle must include a core-deliverable task.
Self-audit: Am I fixing real problems or adapting to symptoms? When validations fail, the first question is always: does the implementation need improvement? Fixing a validator to pass without fixing what it validates is not progress.
Step 3 — Scan remaining dimensions:
| Dimension | Ask |
| ------------------------ | ------------------------------------------------- |
| Validation coverage | Are important scenarios and edge cases exercised? |
| Error/edge-case handling | Are failure modes handled gracefully? |
| Documentation | Complete, accurate, up to date? |
| Performance | Any obvious bottlenecks? |
| UX / output | Is feedback clear and helpful? |
| Observability | Is logging/reporting adequate? |
| Security | Any obvious attack surfaces? |
| Work quality | Anything to simplify or clarify? |
Step 4 — Cross-cycle pattern check. Compare this cycle's top observations to the previous cycle's. If the same dimension is flagged with the same diagnosis and no progress — this signals a stuck loop. On the next cycle, Refresh: deliberately target a different dimension rather than continuing on the stuck one.
Step 5 — Extract one heuristic. Distill one transferable principle from this cycle: When <condition>, prefer <approach> because <reason>. Add it to Session Heuristics (prepend; keep max 5, drop oldest when full).
End Reflect with: "Next cycle focus: [area]."
Inter-Cycle Pause
After Reflect, before the next Overview:
Print: "Cycle [N] complete. Starting cycle [N+1] in 60 seconds — send a stop signal now to halt."
Wait 60 seconds (sleep 60 or platform equivalent).
If no stop signal: begin Overview immediately.
This pause is the only planned delay. It is not a stopping point.
Stopping Conditions
One and only one: the user sends an explicit stop signal.
Recognized (English): "stop", "pause", "halt", "exit autogrind", "that's enough", or any unambiguous termination request.
Recognized (中文): "停", "停止", "暂停", "够了", "结束", or any unambiguous 中文 termination request.
When a stop signal arrives mid-task: finish the current atomic task cleanly (do not stop at a half-written file or a failing test), then stop. Do not start new tasks. A clean stop beats an abrupt one.
Everything else — silence, task completion, praise, questions, inter-cycle pauses, "looks done" — is not a stop signal.
Red Flags — Continue Immediately
"TODO list empty" or "no obvious next task" → Capability frontier scan always finds one
"Project looks complete" or "everything is working" → Measure it: coverage, perf, docs
"Good enough to ship" or "I've been at this a while" → Only the user decides
"I'll summarize progress and pause" → Pausing IS stopping
"User praised my work / seems happy" → Satisfaction ≠ stop signal
"User asked a question, I should wait" → Answer it, then immediately continue
"Tests/validations pass now" → Passing confirms correctness; never a stop signal
"I improved tests/tooling this cycle" → Scaffolding ≠ core deliverable; next cycle targets the primary output
"Same problem flagged two cycles in a row" → Refresh to a different dimension; stuck loops are not progress
Common Rationalizations
| Rationalization | Reality |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| "I should check in with the user" | Work. They'll stop you when they need to. |
| "End of cycle is a natural stop point" | End of cycle = beginning of next cycle. |
| "Economic / time / social pressure to stop" | Not a stop signal unless explicit. Keep grinding. |
| "All done here — nothing left to improve" | Run Reflect. There is always a weakest dimension. |
| "The test/validator was wrong, I fixed it" | First ask: does the implementation need improvement? Fixing evaluators to match broken implementations is not progress. |
| "I improved tests/scaffolding this cycle" | Supporting work only. The core deliverable must also advance each cycle. |
| "The same issue keeps coming up" | Refresh to a different dimension; stuck loops are not progress. |
Platform Notes
Where TaskCreate/TaskUpdate appear in this skill, use your platform's equivalent:
All agentskills.io-compatible agents discover skills from ~/.agents/skills/. One install, all agents:
# Stable install — clone directly to the skills location
git clone --depth 1 https://github.com/ttttonyhe/autogrind.git ~/.agents/skills/autogrind
# Or symlink from an existing clone (live updates)
git clone https://github.com/ttttonyhe/autogrind.git
ln -sfn "$(pwd)/autogrind" ~/.agents/skills/autogrind
Claude Code
# Stable install — clone directly to the skills location
git clone --depth 1 https://github.com/ttttonyhe/autogrind.git ~/.claude/skills/autogrind
# Or symlink from an existing clone (live updates)
ln -sfn "$(pwd)" ~/.claude/skills/autogrind
Invoke:/autogrind or "keep working, don't stop"
Optional native plugin:
claude plugin marketplace add ttttonyhe/autogrind && claude plugin install autogrind@autogrind
Codex
Preferred native plugin path: open this repo in Codex, open plugins, and install autogrind from the AutoGrind marketplace. Full instructions: PLUGIN.md.
For direct skill install or local authoring/testing, the raw skill still works:
Codex discovers raw skills automatically from ~/.agents/skills/. Enable full auto-approval in your Codex config so tool calls are not gated on confirmation.
Invoke:"autogrind this project" or "keep working, don't stop"
Gemini CLI
git clone --depth 1 https://github.com/ttttonyhe/autogrind.git ~/.gemini/skills/autogrind
# Or use the universal path: ~/.agents/skills/autogrind
Gemini CLI discovers skills automatically from ~/.gemini/skills/ — no GEMINI.md entry required. For local development, use gemini skills link to symlink.
Invoke:gemini "autogrind this project, don't stop until I say so"
If you prefer native plugin UX on Claude Code or Codex, use the install paths in PLUGIN.md. Both native plugins wrap the same autogrind skill instead of replacing it.
Update
Paste this into any agent chat:
Please update the AutoGrind skill to the latest version from https://github.com/ttttonyhe/autogrind.
# If installed as symlink — pull in the source repo.
# If installed via git clone, pull inside the install location:
cd ~/.claude/skills/autogrind && git pull # Claude Code
cd ~/.agents/skills/autogrind && git pull # Universal / Codex / Gemini / OpenCode / Cursor
The Grind Cycle
flowchart TD
INIT["INIT (once)\nDetect guidance files\nExtract goals and conventions"]
OV["1. OVERVIEW\nAssess project state"]
UN["2. UNDERSTAND\nReview relevant work and history"]
PL["3. PLAN\nPrioritized tasks + frontier scan"]
WK["4. WORK\nExecute, validate, persist"]
RF["5. REFLECT\nGrounded signals + heuristics"]
PA["PAUSE 60s\nAnnounce, wait, continue"]
ST{"Explicit stop\nsignal?"}
STOP(["STOP"])
NEVER["NEVER stop\non your own"]
INIT --> OV --> UN --> PL --> WK --> RF --> PA --> ST
ST -->|yes| STOP
ST -->|no, always| OV
ST -.->|tempted to stop| NEVER
Every Reflect phase: checks verifiable signals first (test results, metrics, build status), evaluates core deliverable progress, scans quality dimensions (coverage, error handling, docs, performance, UX, observability, security), detects stuck loops and shifts focus, and extracts a transferable heuristic for the next cycle. There is always a weakest dimension.
After each cycle, AutoGrind pauses 60 seconds so you can interrupt. If you do nothing, it continues automatically.
FAQ
When does it stop? What if my project is already complete?
AutoGrind stops only when you explicitly tell it to: "stop", "halt", "pause", "that's enough", or any clear termination request. It never stops on its own.
If your project feels done, AutoGrind will find the next improvement: coverage gaps, missing documentation, performance wins, edge cases, polish. The Reflect phase evaluates against a checklist of quality dimensions and always surfaces something. Say "stop" when you are satisfied.
Will it run destructive commands? Will I wake up to a broken system?
AutoGrind prioritizes reversible, tracked changes. Every code change gets committed to git, so you have a full undo trail. It does not intentionally run destructive operations (rm -rf, force push, DROP TABLE) as part of its workflow.
That said, AutoGrind runs code, edits files, and commits changes autonomously. Recommended safeguards:
Start from a clean git working tree so all changes are tracked and easy to review
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.
