In Process Skills

Agent skills for building In Process — the engineering process, not the product. One install teaches your agent how user feedback becomes a high-signal GitHub tracking issue, and how that issue gets delivered documentation-first and test-first across the in_process submodules.

Install

Claude Code / agents marketplace

/plugin marketplace add sweetmantech/in_process_skills
/plugin install inprocess-skills@inprocess

npx (any harness)

npx skills add sweetmantech/in_process_skills

As a submodule of the monorepo

in_process_mono carries this repo at skills/:

git submodule update --init skills

Manual

The repo root is the plugin, with every skill under skills/:

git clone https://github.com/sweetmantech/in_process_skills.git

Skills

Skill	What it does
inprocess-dev	The dev loop, two modes. Write: high-signal GitHub tracking issues — anatomy, the PRs matrix, the Open→Done lifecycle, evidence and linking rules. Ship: deliver a tracked issue docs-first then test-first across web / api / database / docs / indexer, verified on the live Vercel preview, closed out with a submodule-pointer bump.

Routing lives in RESOLVER.md.

Running the loop (start here)

You don't invoke this by name. Say what you want in plain language and the skill fires:

You say	What happens
"here's the latest feedback from the Telegram group: …"	Researches it against origin/main, verifies against production, files a tracking issue in sweetmantech/in_process
"write a tracking issue for X"	Same, without the triage step
"ship issue #1474"	Docs → database → api → web, TDD, preview-verified, PRs opened in merge order
"update the issue, we merged the api PR"	Moves the item to ## Done with a closure note and a Verified clause

Three rules the loop will hold you to, because each has already cost a day:

1. origin/main is the codebase, not the checked-out tree. The monorepo's submodule pins run weeks to months behind. Fetch first — the runbook is in skills/inprocess-dev/references/repos.md.
2. Every issue is filed in sweetmantech/in_process, whatever repo the diff lands in.
3. An issue isn't done until the mono's submodule pointers are bumped. Merging in a submodule leaves the workspace pointing at the old commit.

What the skill assumes

The five In Process repos, wired as submodules of in_process_mono:

Submodule	Repo	Layer
web	in_process	Next.js app
api	In-Process-API	Next.js API-only backend
database	in_process_database	Supabase migrations + RPCs
docs	docs	Mintlify + OpenAPI (the contract)
indexer	Coins-Beneficiaries-Indexer	Envio indexer

Two rules the skill is built around:

• Every issue is filed in sweetmantech/in_process, whatever repo the diff lands in. One home repo means one place to find open work.
• Merge order is docs → database → indexer → api → web, then bump the mono's submodule pointers. The contract lands first; hard dependencies win inside that order.

Creating a skill

skills/
└── inprocess-my-skill/
    ├── SKILL.md              ← required — instructions + YAML frontmatter
    ├── references/           ← optional — docs loaded on-demand
    ├── scripts/              ← optional — executable code
    ├── templates/            ← optional — scaffold files
    └── fixtures/             ← optional — sample / golden data

Every skill needs a SKILL.md with name + description frontmatter, a description that tells the agent when to fire, and a route in RESOLVER.md — CI fails on unreachable skills. See contributing.md and AGENTS.md.

Validation

python3 scripts/portability_lint.py     # every skill is cross-harness portable
python3 scripts/validate_manifests.py   # manifests valid + marketplace parity
python3 scripts/check_resolvable.py     # every skill reachable from RESOLVER.md

All three run in CI on every push and pull request.

License

MIT — see LICENSE.