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 or doc 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, and 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 — clean up the memory your agents keep auto-accumulating, moving the relevant parts to the right place. More about memory-doctor.

Task workflow

A daily routine for any programming task, following the RPAC workflow: fetch a ticket, refine it, plan it, 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.
• 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.
• 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.
• 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.
• 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.
• create-manual-test-instructions — derive manual test steps from a ticket or requirements file, 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, 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.
• review-code-assistant — assist you in reviewing a PR or branch.
• 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.
• review-ticket — triage a ticket or ticket set before anyone picks it up, saving a review with a feature walkthrough and the decisions to raise with the team.
• verify-understanding — explain the feature back in your own words before building it: a teach-back conversation over a saved 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, marking each requirement as done, partial, or not done in a human-readable status report.
• 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. 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, and questions to the user 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, test, and build on the affected projects of an Nx workspace and fix unambiguous failures.

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.
• no-nonsense-comments — write only code comments that still make sense to a future reader with zero context, prefer no comment over a low-value one, and voice them via use-conversational-language.
• plans-directory — save plans and similar documents under the project's planning directory, following a certain structure.
• read-other-repos-governing-docs — before editing another repo's files, read and follow that repo's governing docs — they don't auto-load.
• self-contained-docs — keep planning and design docs, and prompts for another session, concise and executable by a fresh session with no prior context, writing the prompts via prepare-prompt.
• self-improve-on-correction — when the user corrects something a skill or doc governs, offer to persist the lesson via self-improve.
• write-realistic-texts — make text other people will read sound natural, and get the user's go-ahead on the wording before publishing the texts it names.
• write-simple-explanations — word questions, explanations, and recaps to the user via explain-in-simple-language.

One more rule for non-English speakers ships as a copy-paste snippet rather than a file, since it needs the language filled in — use-my-mothertongue makes
your agent talk to you in your language while everything it writes into the project stays English.

How to install the rules

Because rules are always-on, they are never installed implicitly with the skills. To opt in:

./install-opinionated-rules.sh

Auto-loaded rules are mostly a Claude Code feature — how they work, which agents support them, the script's options, and linking individual rules by hand are covered in docs/install-rules.md.

Install with agentwheel