# anything

Published: 2026-11-08

By [Ron Edgecomb](/about/index.md)

Tags: AI, AI agents

![The anything wordmark, with a period and an asterisk beside the word, in black on a light gray background.](https://ronedgecomb.dev/_astro/anything.DLY3gjHu_oNIzR.webp)

I built [anything](https://github.com/ronedgecomb/anything) as a small collection of opinionated agent skills for software, research, writing, planning, and other work. A skill is a set of written instructions an AI agent can load when a task calls for it. These capture the guidance I kept repeating: ask useful questions, keep the process proportional, and leave behind work that's clear and maintainable.

## Try one skill

Start with `interview` if you have a loose idea you want to work through. With pnpm installed, run this from your project using the [skills CLI](https://github.com/vercel-labs/skills):

```sh
pnpm dlx skills add ronedgecomb/anything --skill interview
```

Choose your agent when prompted. In a session with the skill available, try:

```text
Use the interview skill to help me turn these rough notes into a project
write-up. Read the existing draft first, then ask about what's missing.
```

Each skill works on its own, and setup is optional. The [installation guide](https://github.com/ronedgecomb/anything/blob/main/docs/installation.md) also covers native Claude Code, Codex, and Pi installations, plus individual skills for OpenCode.

## Why I made it

Before building anything, I was regularly using [Addy Osmani's agent-skills](https://github.com/addyosmani/agent-skills) and [Superpowers](https://github.com/obra/superpowers). As those collections grew, I found that their workflows were moving further from the way I wanted to work. I kept guiding agents back toward the same preferences, and eventually wanted a smaller collection that reflected those preferences from the start.

One recurring frustration was the tests agents added while changing simple scripts. They would check that a particular variable name or package was no longer present, even when there wasn't a requirement to keep it out. The same pattern showed up in documentation, with statements about removed features or scripts taking space that could explain how the project currently worked. It added material to maintain and made builds take longer than they needed to.

## What a useful change looks like

The `no-tombstones` skill addresses that residue: material kept around mainly to describe or forbid a previous implementation, without an ongoing reason for it.

Consider a small task: simplify a date-formatting script while preserving its output. A test that only checks an old helper's name is gone might look like this:

```js
expect(source).not.toContain("oldFormatter");
```

That test can pass even if the script returns the wrong date. A useful check would protect the output people depend on:

```js
expect(formatDate("2026-11-08")).toBe("November 8, 2026");
```

The documentation can make the same shift. "Removed the old formatter" records a change. "Accepts a date in `YYYY-MM-DD` form and returns a US long date, such as `November 8, 2026`" gives the next reader a contract they can use. The implementation history belongs in the change summary when it helps explain the work.

That's the judgment I want the skill to encourage. A temporary search can confirm that an old name is gone. Lasting tests and documentation should protect current requirements. Regression coverage, migration guidance, and checks that enforce a real restriction still have a clear purpose.

To try this skill, replace `interview` with `no-tombstones` in the install command above.

## Across the rest of the work

The same approach applies to research, writing, and planning. For a research-backed article, `interview` can help establish the audience and question. `orchestrate` can organize research and drafting, and `fresh-review` can examine the argument and evidence before publication.

The collection also covers carrying decisions between sessions, recording project preferences, and maintaining a repository. You can [browse the current skills on GitHub](https://github.com/ronedgecomb/anything#skills) and choose the ones that address the work in front of you.

The skills themselves are written instructions with no runtime dependencies. A small task should still get a small process, and each extra question, plan, review, or test should have a reason to be there.