agent-toolkit

agent-toolkit

A collection of generic agentic tools for common engineering tasks, designed to work with any AI agent on any kind of software project. The philosophy behind the toolkit — five pillars and a litmus test for every new artifact — is captured in docs/core-philosophy.md.

Skills

Agentic skills for everyday software engineering — solo or in a team, not bound to any specific language or framework.

Skill & doc authoring

Tools to create and continuously improve the skills and docs your agents rely on, following this approach to agentic skills.

• compact-docs-writer — write docs with maximum token economy.
• compact-skill-creator — create or edit skills, keeping them lean and efficient.
• self-improve — capture a lesson into the skill, doc or check that governs it, so mistakes aren't repeated and agents keep getting better at the project.

Context & memory hygiene

Maintenance to run from time to time, keeping your setup tidy and your context sharp.

• agentify-project — make a project agent-ready by converging it toward a canonical agent-neutral structure (a lean AGENTS.md index with progressive disclosure, shared skills, gitignore hygiene). Re-runnable, and doubles as an audit.
• context-checkup — audit what auto-loads into a session's context and spot what can be trimmed to reduce startup tokens. Why this is important.
• memory-doctor — drain the memory your agents keep auto-accumulating, block by block, moving each entry to the right place or archiving it. More about memory-doctor.

Task workflow

A daily routine for any programming task, following the RPAC workflow: fetch a ticket, refine it, harden it, plan it, harden it again, split the plan into small tasks, then let a fresh session execute them one at a time and consolidate the changes.

• fetch-ticket — download a ticket from any tracker (e.g. GitHub, Jira, Azure DevOps) and save it as a self-contained markdown file.
• attach-to-ticket — save a pasted screenshot, a file or a URL beside a fetched ticket and reference it from the ticket file, e.g. to fill an attachment the fetch could not download.
• grill-me — get interviewed relentlessly about a plan, design or idea, one question at a time, each with a recommended answer, until every branch of the decision tree is resolved; ends with a paste-ready list of the settled decisions. Adapted from Matt Pocock's grill-me (MIT, copyright 2026 Matt Pocock).
• refine-ticket — define the "what" of a task: validate the ticket — or a raw idea you want to brainstorm — against the codebase, settle open decisions together, and save a self-contained requirements doc a fresh session can pick up. Takes a fetched ticket file, or a ticket URL a subagent fetches first.
• create-implementation-plan — define the "how" of a task: turn the requirements into an implementation plan, settling the technical decisions together, then save it for a fresh session to execute.
• harden-artifact — harden a requirements doc or a plan before the next phase picks it up: a fresh-context reviewer tests every deviation from the ticket and every claim against the code and related tickets, the session challenges each finding, and proven mistakes get fixed in the document (say autoaccept to skip the asks for those). Findings that reveal a durable lesson end in an offer to run self-improve, when installed.
• split-plan-tasks — break a plan into individually reviewable tasks grouped into PR-sized batches, appended to the plan file for a fresh session to execute one at a time. Why not execute the full plan at once.
• execute-plan-tasks — execute one task of that breakdown at a time: implement it, verify it, tick it off in the plan, and hand it back for review before the next; when a group is done, hand it to self-review (if installed) before the next group starts.
• create-manual-test-instructions — derive manual test steps from a ticket or requirements file, or from a code change (branch, PR, commit range, diff), useful for the developer or QA.
• handover — package a finished change for its reviewers: what it does and why, the decisions and plan deviations worth knowing, and a review guide — paste-ready as the PR description. More about handover.
• prepare-prompt — write the prompt that hands this session's work to a fresh session — what exists, what is open, what to do and in what form, the facts it cannot derive — as short as the next session allows.

Review assistants

Review helpers that check the codebase while assisting with code or ticket reviews.

• fetch-pr-review — collect the comments left by other reviewers on your PR and save them into a markdown doc, pinned to the PR head, ready to address (or push back on), for example via refine-pr-review.
• refine-pr-review — go through a fetched PR review together, comment by comment — address, partial, or push back — drafting the replies, turning the accepted changes into a requirements doc, and recording the durable lessons, which self-improve persists when installed. Takes the fetched file, or a PR URL a subagent fetches first.
• extract-pr-review-rules — mine the conventions your reviewers actually enforce out of every PR review comment in a repo, saved as a per-reviewer rules doc indexed from your agent entry file so the review skills run it as a checklist; later runs resume from a checkpoint and read only the new comments.
• review-code-assistant — prepare a review of a PR or branch with you: the diff the platform shows, the project's conventions run as a checklist, and candidate comments in diff order, read-only and never posted.
• maintainer-review — review someone else's PR as the maintainer deciding whether it merges: every prior comment walked, every claim verified, then comment, approve or fix the contributor's branch on your go-ahead. How open source projects can cope with AI slop.
• review-ticket — triage a ticket or ticket set before anyone picks it up, saving a review with a feature walkthrough and the questions worth raising with the team.
• verify-understanding — explain the feature back in your own words before building it: a teach-back conversation over its ticket review that probes and corrects until you are ready to implement.
• check-ticket-implementation — check how much of a ticket is already implemented in the code, saving a per-requirement status report (done, partial, not done, or not verifiable).
• fresh-eyes-review — let an agent with a fresh perspective review a changeset and report its findings back to the main session. Read more about fresh-eyes-review.
• self-review — get your changeset merge-ready before requesting review: a fresh-context reviewer checks it as a maintainer would, you answer every finding (or say autoaccept to let the agent decide), and a compact report for the PR proves the review happened. Findings that reveal a durable lesson end in an offer to run self-improve, when installed. Projects can tune the review via an optional .agents/docs/self-review-rules.md.

Talking to humans

Wording for what the agent writes to people, whether the user in the session or other humans.

• explain-in-simple-language — word explanations, recaps, questions to the user, and documents humans read so they are understood on the first read, without dumbing them down or hiding that an agent wrote them.
• use-conversational-language — the voice for text that should read as if a person typed it, used by the review skills for comments and replies and by rules for texts other people read and code comments.

Code checks

• run-nx-checks — run format, lint, typecheck, test, and build on the affected projects of an Nx workspace and fix unambiguous failures, reporting every edit it made.

How to install the skills

Install all skills in one command:

git clone https://github.com/eai-org/agent-toolkit.git && cd agent-toolkit && ./install.sh

Update in one command:

cd agent-toolkit && git pull && ./install.sh

On Claude Code the install also registers a hook that runs that update for you once a day; an install made before it needs the command above once to pick it up (docs/auto-update.md).

Every skill is installed by default. To leave one out, name it once and the choice sticks, daily update included:

./install.sh --exclude use-conversational-language

--include <name> puts it back. Both are repeatable.

On Windows the skills link through junctions, so the update command above works as-is, though an install predating them needs one ./install.sh --force to convert. The rules are copied instead and need --force every time (see Windows).

How the symlink install works and the other install methods — hand-picking skills, other agents, skills.sh, the Claude Code plugin marketplace — are covered in docs/install-skills.md.

Rules

A set of generic, project-agnostic, opinionated rules that apply to any codebase. They are opt-in, installed separately from the skills.

• compact-governing-docs — run the matching compaction skill before writing or editing a governing doc, so it stays compact.
• git-read-only-by-default — never commit, push, merge, or otherwise write to git without an explicit instruction.
• no-ai-attribution — no AI co-author trailers on commits and no "Generated with" footers on PRs.