aictrl

[GitHub Stars] [Skills]

aictrl.dev engineering skills and plugin

Essential, vendor-neutral AI engineering skills for the AI SDLC: turning bug reports and requests into well-defined issues, root-cause analysis, implementing changes, code review and explaining pull requests. Install the skills alone, or install the aictrl.dev plugin to add the same skills plus OAuth-connected workflows that run in the cloud on aictrl.dev, turning backlog work into reviewed pull requests.

aictrl MCP server

The hosted aictrl MCP server gives coding agents access to project context, backlog tasks, code-review findings, and controlled workflow execution. Connect to https://aictrl.dev/mcp using Streamable HTTP and sign in with OAuth. No API key or local server process is required.

You need an aictrl account and membership of an aictrl organization. Repository-backed work also needs a GitHub repository connected through the aictrl GitHub App. Access follows your organization membership; workflow execution follows the published workflow's permissions and approval gates.

GitHub Copilot in VS Code:

1. Open the Command Palette and run MCP: Add Server.
2. Choose HTTP (HTTP or Server-Sent Events) and enter https://aictrl.dev/mcp. Name the server aictrl and choose the configuration destination.
3. Start the server from VS Code's MCP controls and complete the browser sign-in when prompted.

See VS Code's MCP setup guide for configuration destinations and server controls.

In other MCP clients, add the same remote URL and complete OAuth when prompted. The Claude Code and Codex plugins below already include the MCP configuration. See SETUP.md for connection checks and troubleshooting.

Try these prompts after connecting:

• "Check my aictrl account readiness."
• "Which aictrl organizations can I use?"
• "Show the backlog tasks for my organization."
• "List the published workflows I can run."

This public repository contains the skills, client configuration, and registry metadata for the hosted service. The hosted server's source code is private.

Install

Skills only — Codex, Claude Code, OpenCode, and compatible agents

npx skills add aictrl-dev/skills

Claude Code plugin

/plugin marketplace add aictrl-dev/skills/plugin install aictrl@aictrl-public

Codex plugin

codex plugin marketplace add aictrl-dev/skills --ref maincodex plugin add aictrl@aictrl-public

OpenCode — install the skills with npx skills add aictrl-dev/skills, then add the connected-workflow server to opencode.json and sign in:

{ "mcp": { "aictrl": { "type": "remote", "url": "https://aictrl.dev/mcp", "enabled": true } } }

opencode mcp auth aictrl

Cursor / direct OpenCode skills — skills use the cross-tool Agent Skills standard:

git clone https://github.com/aictrl-dev/skills && cd skills./scripts/install.sh cursor       # or: opencode | all

…or copy skills/* into your tool's skills dir (~/.cursor/skills, ~/.config/opencode/skills).

Then ask for the task naturally or invoke a supported slash command, for example /create-issue, /implement-code-change, /code-review, /create-workflow, or /execute-workflow.

The Skills

design-review in action

Input: a SaaS landing page mock.

Value Proposition — WEAK  Hero headline "Workflows made simple" says nothing about what the product does.  Fix: replace with a one-liner that names the user, the problem, and the outcome.
Actionability — BROKEN  Three competing CTAs above the fold (Start free, Book demo, Watch video).  Fix: one primary CTA above the fold; demote the others below.

Every critique names the element. Every fix is concrete. No generic "improve clarity."

ux-testing in action

On an internal work-queue design, novice agent testers asked to start the most important ready work approved a security review instead (v5: 2 of 2). After the fix loop moved the ready work above the approvals, 3 of 3 started the right issue. Simulated users reproduced the same trap (72% clicked Approve), and checks against page state caught a tester who reported success after creating nothing. Write-up: AI usability testing on a backlog design.

Why these exist

These skills are free and standalone. aictrl.dev adds controlled remote execution, approvals, policy, history, integrations, and cost limits. implement-code-change can use an optional connected workflow, and execute-workflow safely operates an existing published workflow; local mode remains available for every launch skill except the connected-only execute-workflow.

The Claude and Codex plugins and the skills.sh install all consume the root skills/ directory directly. There are no vendor-specific copies to repin or hand-edit. Connected execution always uses the aictrl MCP identity at https://aictrl.dev/mcp; OAuth is requested only when a connected workflow is used.

Privacy, terms and support

The skills run locally and send nothing to aictrl.dev. The bundled aictrl MCP server is used only when you connect it with OAuth; what it collects and keeps is described in the privacy policy and terms. Support: aictrl.dev/support or [email protected]. Security reports: security.txt. Setup guidance for the MCP connection is in SETUP.md.

Optional third-party services and keys

Bundled helpers in two skills can send data to a third-party service, only in the steps below and only when you run them. Nothing runs on install. A key is read only for its step, sent only to the service named in that row, and never printed, logged or stored. Each key belongs to the service it is sent to: Google credentials go only to Google, the TypeSafe key only to TypeSafe, and a custom simulator key only to the endpoint you set alongside it. The bundled aictrl MCP server never receives any of them.

Narration is prepared using the user's selected speech tools (for example, ElevenLabs) or supplied as audio plus measured word timestamps. Those tools receive the narration text/audio under their own configuration. The plugin does not include a narration API client or read speech-provider credentials; its splitter processes the prepared files locally.

No other skill sends data to a third-party service; the browser-based skills (ui-polish, ux-testing) load only the app URL you give them.

Without these variables the local demo pipeline still runs with prepared narration; an explicitly requested upload reports missing configuration, and ux-testing continues with agent testers only. UX_VERIFY_TOKEN is a local token between the ux-testing scripts and their own local server; it is never sent off the machine.

Contributing

PRs that add skills are welcome — see CONTRIBUTING.md. Release owners should also follow the public plugin release runbook.