agent-bridge
Agent Bridge
Build a safe localhost HTTP interface (/api/agent/...) that lets a local AI agent explore, understand, and operate a web application — similar in spirit to an MCP server but implemented as simple HTTP endpoints.
Workflow
This skill has 4 steps. Steps 1-3 are sequential and build on each other. Step 4 is optional. Ask the user which step to run. Recommend starting with Step 1 if this is a fresh setup.
Present:
Which step would you like to run?
1. Discover Actions — scan codebase, identify actions, decide what to expose (start here)
2. Review Layer — implement review tables, audit log, and local review dashboard
3. Agent Endpoints — implement /api/agent/... routes and AGENTS.md
4. Prod Dashboard — (optional) expose the review dashboard in production with security guardrails
Steps 1-3 keep everything localhost-only. If after completing steps 1-3 you want the review/approval dashboard to also be accessible in production, run Step 4 to implement the required security guardrails and get a checklist of manual infrastructure work.
Use AskUserQuestion or equivalent interactive tool for the selection.
Step Execution
Each step has a dedicated reference file with full instructions. Load the appropriate file based on the user's choice:
- Step 1: Read references/step-1-discover-actions.md and follow it
- Step 2: Read references/step-2-review-layer.md and follow it
- Step 3: Read references/step-3-agent-endpoints.md and follow it
- Step 4: Read references/step-4-prod-dashboard.md and follow it
Canonical Files
All steps read/write to these fixed paths so each step can find prior decisions automatically:
| File | Created by | Purpose |
|---|---|---|
/api/agent/AGENT_ACTION_PLAN.md |
Step 1 | Action inventory and exposure decisions |
/api/agent/AGENT_REVIEW_PLAN.md |
Step 2 | Review tables, audit log, dashboard design |
/api/agent/AGENTS.md |
Step 3, updated by Step 4 | Runtime documentation for agents discovering the system |
Never create random documentation files. Always use these canonical paths. When updating existing files, preserve user edits — update sections, don't overwrite.
Cross-Step Rules
These apply to every step:
- Turn-based workflow: At the end of each stage, clearly state: What I did, Your turn, What I'm waiting for
- Interactive interviews: Use
AskUserQuestionor equivalent for all user decisions - Safe defaults: Propose sensible defaults so the user can confirm quickly
- No assumptions: Never assume exposure or safety decisions without user confirmation
- Manual steps: Never pretend manual steps (migrations, env vars, restarts) are complete unless they actually are
More from ilamanov/skills
spec-builder
Transform vague product or feature ideas into concrete, detailed specification documents through an interactive interview process. Use when the user wants to flesh out an idea, create a spec, write requirements, plan a product/feature/prototype, or go from "I have this idea..." to a concrete document. Works for software products, physical products, services, or any concept that needs specification.
23pr
Commit changes and create or update a pull request following project standards. Use when the user wants to commit work, create a PR, update an existing PR, or use the /pr command.
14reimplement-branch
Reimplement the current branch on a new branch with a clean, narrative-quality git commit history. Use when the user wants to clean up messy commits, create a tutorial-style commit history, or prepare a branch for review with logical, self-contained commits. Triggers on requests like "clean up my commits", "reimplement this branch", "create a clean history", or "make my commits reviewable".
12deslop
Remove AI-generated code slop from the current branch. Use when the user says "deslop" or asks to clean up AI slop, remove AI code patterns, or clean the branch before committing.
9compile-conversation-into-doc
Turn long, messy AI chat conversations into clear, durable, and easily scannable reference documents that humans can reliably return to weeks or months later.
9review-bug-fixer
Fix valid code review findings from one or more review markdown files. Use when the user has review files (e.g., review1.md, review2.md) containing code review findings, issues, or suggestions and wants to fix the valid ones in the current branch. Triggers on requests like "fix review findings", "fix issues from review", "apply code review fixes", or any mention of fixing bugs/issues from review markdown files.
8