Independent tooling experiments for AI-assisted development and developer experience.

Agent Engineering Tools

Deterministic AI-Agent Developer Tools

These tooling projects explore how engineering teams can make AI-assisted development more reliable. The work stays intentionally small and focused on specific workflow problems instead of pretending to automate the entire development lifecycle.

Independent / Ongoing
  • TypeScript
  • CLI
  • GitHub Actions
  • AI Agents
  • Supply-chain safety

Context

The projects emerged from practical friction points: weak agent instructions, risky agent settings committed to repositories, agent-written pull requests too large to review evenly, and teams adopting AI-assisted workflows before their conventions were ready for it. Each tool focuses on one gap and keeps the scope explicit.

Problem

AI-assisted development breaks down quickly when the repository context is vague, the review feedback is generic, or the workflow assumptions are unstable. Small tools can make those failure modes easier to detect before they become team habits.

My role

  • Designed and implemented three TypeScript CLIs, the GitHub Action, and MCP, skill, and plugin integrations, with release and verification documentation.
  • Defined the product scope and boundaries for each tool so the claims stayed smaller than the problem.
  • Used the projects to explore developer experience as a product surface with explicit inputs and outputs.

What I built

  • agent-context-doctor, because most bad agent output traces back to weak instructions rather than a weak model, and nobody was checking the instructions. It now also audits committed Claude Code and MCP settings, where a single bypassPermissions default or remote-script hook runs on every contributor's machine.
  • agent-pr-reviewer-lite, because agent-written pull requests touch many files and reviewers need to know which ones matter. It flags auth, billing, migration, CI, secret, and agent-permission changes from fixed rules, and names each file's CODEOWNERS from the base branch.
  • agent-readiness-kit, because a repository without clear conventions, boundaries, or validation paths will amplify agent mistakes instead of catching them. It scores 13 categories and scaffolds the missing files, including least-privilege Claude Code settings.
  • agent-readiness-action, so the readiness score and the instruction audit run on every pull request, with both engines bundled at pinned commits instead of installed from a registry.
  • Agent Readiness integrations: a published MCP server, a portable skill, and Claude Code and Cursor plugins that share the same read-only, offline scanner. Host clients may send reports and files they read to their model provider.

Diagram

Where each tool checks an AI-assisted workflow

Select a step to see what happens there.

Step 1 of 6

Repo readiness

agent-readiness-kit checks for the conventions, boundaries, and validation paths that keep agent mistakes from being amplified.

Each tool targets one gap in the workflow, and the final decision stays with a human reviewer.

Technical decisions

Decision

Keep the tools focused on deterministic checks and explicit heuristics instead of over-claiming broad autonomous intelligence.

Why

The goal was to make failure modes visible and actionable, not to replace engineering judgment with a black box.

Trade-off

A smaller scope means the tools solve narrower problems and require more human interpretation.

Result

The projects stay clearer about what they evaluate, what they report, and what still requires human review.

Decision

Treat CLI output, configuration, and documentation as part of the product instead of as afterthoughts.

Why

Developer tooling only helps when the feedback is understandable and easy to integrate into existing workflows.

Trade-off

Improving DX details takes time that could otherwise go into more features.

Result

The tools demonstrate a product-minded approach to developer experience instead of a script-only mindset.

Decision

Treat the repository under audit as untrusted input, because on a pull request it is written by whoever opened it.

Why

These tools run in CI with a token in the environment. An early version of the action ran npx agent-readiness-kit, and that npm name belongs to an unrelated author, so every run downloaded and executed someone else's code.

Trade-off

Bundling engines at pinned commits, reading config and CODEOWNERS from the base branch, and refusing to follow symlinks adds build and release work.

Result

Nothing is downloaded at run time, a pull request cannot change the rules that review it, and file names cannot inject workflow commands or redirect report writes.

Diagram

Broad autonomous claims vs deterministic checks

Broad autonomous tooling

  • Generic AI review comments that get ignored
  • Unclear about what was evaluated and what was not
  • Implies review and readiness decisions are automated
  • Output treated as an afterthought to the analysis

Small deterministic tools

  • Deterministic checks and explicit heuristics
  • Findings with severity, file, and evidence
  • Clear about what is reported and what still needs human review
  • CLI output, configuration, and documentation treated as product
Narrow, explicit checks make failure modes visible instead of hiding engineering judgment inside a black box.

UX and detail decisions

  • Every finding carries a severity, the file, and the evidence, and the same input always produces the same output, so results are easier to trust than a generic AI summary.
  • Reports go where reviewers already look: terminal, Markdown, SARIF for code scanning, and inline pull-request annotations.
  • Kept repository readiness and context quality visible as explicit engineering inputs.
  • Avoided language that implies the tools fully automate review or readiness decisions when they are really evaluation aids.

Outcome

  • Shipped v1.0 of all four projects in September 2026: three CLIs installable from GitHub release tags and a GitHub Action referenced as alipajand/agent-readiness-action@v1.
  • Released Action v1.2.0 and integrations v0.1.2 in October 2026. The MCP package is published on npm and in the official MCP Registry; the skill and Claude Code plugin install from GitHub. The local Cursor plugin passed acceptance tests, while directory submissions remain under review in the October 14 record.
  • Kept architecture, security, validation, and final decisions under human engineering review.

What I would improve

  • Continue refining repository-specific evaluation rules so the tools produce more useful feedback in real teams.
  • Add more examples and integration paths that show how the tools fit into broader engineering workflows.