agent-integration
- Repo stars 4,389
- Author updated Live
- Author repo cli
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @entireio · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: agent-integration
description: > Run all three phases of agent integration in a single session. Parameters are collected once a…
category: ai
runtime: no special runtime
---
# agent-integration output preview
## PART A: Task fit
- Use case: > Run all three phases of agent integration in a single session. Parameters are collected once and reused across all phases. Collect these before starting (ask the user if not provided): runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Parameters / Architecture References / Scope” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Run all three phases of agent integration in a single session. Parameters are collected once and reused across all phases. Collect these before starting (ask the user if not provided): runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Parameters / Architecture References / Scope” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/e2e`, `/commit`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Parameters / Architecture References / Scope”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: agent-integration
description: > Run all three phases of agent integration in a single session. Parameters are collected once a…
category: ai
source: entireio/cli
---
# agent-integration
## When to use
- > Run all three phases of agent integration in a single session. Parameters are collected once and reused across all p…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Parameters / Architecture References / Scope” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "agent-integration" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Parameters / Architecture References / Scope
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Agent Integration — Full Pipeline
Run all three phases of agent integration in a single session. Parameters are collected once and reused across all phases.
Parameters
Collect these before starting (ask the user if not provided):
| Parameter | Description | How to derive |
|---|---|---|
AGENT_NAME |
Human-readable name (e.g., "Gemini CLI") | User provides |
AGENT_PACKAGE |
Go package dir name — no hyphens | Lowercase, remove hyphens/spaces |
AGENT_KEY |
Registry key for agent.Register() and entire enable |
Check existing patterns in cmd/entire/cli/agent/registry.go |
AGENT_SLUG |
Filesystem/URL-safe slug (kebab-case) used in E2E runner filenames and script names | Kebab-case of agent name; align with existing entries in e2e/agents/ |
AGENT_BIN |
CLI binary name | command -v <binary> |
LIVE_COMMAND |
Full command to launch agent | User provides |
EVENTS_OR_UNKNOWN |
Known hook event names, or "unknown" | From agent docs or "unknown" |
Note: These identifiers can differ. Run grep -r 'AgentName\|func.*Name()' cmd/entire/cli/agent/*/ and e2e/agents/ to see how existing agents handle the split.
Architecture References
These documents define the agent integration contract:
- Implementation guide:
docs/architecture/agent-guide.md— Step-by-step code templates, event mapping, testing patterns - Integration checklist:
docs/architecture/agent-integration-checklist.md— Design principles and validation criteria
Scope
This skill targets hook-capable agents — those that support lifecycle hooks
(implementing HookSupport from agent.go). Agents that use file-based detection
(implementing FileWatcher) require a different integration approach not covered here.
Check agent.go for the current interface definitions.
Core Rule: E2E-First TDD
This skill enforces strict E2E-first test-driven development. The rules:
- E2E tests are the spec. The existing
ForEachAgenttest scenarios define what "working" means. The agent runner makes those tests runnable for the new agent. - Run E2E tests at every step. Each implementation tier starts by running the E2E test and watching it fail. You implement until it passes. No exceptions.
- Unit tests are written last. After all E2E tiers pass (Step 14), you write unit tests using real data collected from E2E runs as golden fixtures.
- If you didn't watch it fail, you don't know if it tests the right thing. Never write a test you haven't seen fail first.
- Minimum viable fix. At each E2E failure, implement only the code needed to fix that failure. Don't anticipate future tiers.
/e2e:debugis your debugger. When an E2E test fails, use the artifact directory with/e2e:debugbefore guessing at fixes.
Pipeline
Run these three phases in order. Each phase builds on the previous phase's output.
Phase 1: Research
Discover the agent's hook mechanism, transcript format, and configuration through binary probing and documentation research. Produces an implementation one-pager at cmd/entire/cli/agent/$AGENT_PACKAGE/AGENT.md that the other phases use as their single source of agent-specific information.
Read and follow the research procedure from .claude/skills/agent-integration/researcher.md.
Expected output: Implementation one-pager at cmd/entire/cli/agent/$AGENT_PACKAGE/AGENT.md and a test script at scripts/test-$AGENT_SLUG-agent-integration.sh.
Commit: After the research phase completes, use /commit to commit all files.
Gate: If the verdict is INCOMPATIBLE, stop and discuss with the user before proceeding.
Phase 2: Write E2E Runner
Create the E2E agent runner so existing test scenarios can exercise the new agent. No unit tests are written in this phase — no new test scenarios either (existing ForEachAgent tests are the spec).
Read and follow the procedure from .claude/skills/agent-integration/test-writer.md.
Expected output: E2E agent runner at e2e/agents/$AGENT_SLUG.go that compiles and registers with the test framework.
Commit: After the E2E runner compiles and registers, use /commit to commit all files.
Phase 3: Implement (E2E-First, Unit Tests Last)
Build the Go agent package using strict E2E-first TDD. E2E tests drive development at every step — run each tier, watch it fail, implement the minimum fix, repeat. Unit tests are written only after all E2E tiers pass, using real data from E2E runs as golden fixtures.
Read and follow the implement procedure from .claude/skills/agent-integration/implementer.md.
Expected output: Complete agent package at cmd/entire/cli/agent/$AGENT_PACKAGE/ with all E2E tiers passing and unit tests locking in behavior.
Note: AGENT.md is a living document — Phases 2 and 3 update it when they discover new information during testing or implementation.
Final Validation
After all three phases, run the complete validation:
mise run fmt # Format
mise run lint # Lint
mise run test:ci # All tests (unit + integration)
Summarize:
- Compatibility verdict from Phase 1
- Files created in Phases 2 and 3
- Test coverage
- Any remaining TODOs or gaps
Decide Fit First
Design Intent
How To Use It
Boundaries And Review