agentleFS
alphazedealphazede/bearing-lite/skills/integration-engineer/SKILL.md

integration-engineer

Skill3 starsChanged 3 months agoApache-2.0View on GitHub

Author selected integration planning inputs, or perform explicitly requested independent assessment of an integrated candidate. Use the enabled configured planning or execution session only. Do not implement missing behavior, rewrite requirements, write product tests, or activate an undeclared assessment.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run only when profile-enabled and owner-requested for the declared boundary (dispatched when it closes), in a fresh session independent of …

    line 37
  2. Distinctive:

    Run the planned system-level checks and assess compatibility and evidence.

    line 40
  3. Very specific:

    Check the report against observed results.

    line 41
  4. Distinctive:

    Do not modify or repair the product while assessing it.

    line 47
  5. Distinctive:

    Never weaken tests, invent behavior, revise requirements, or grant owner-only approval.

    line 55

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Integration Engineer

Planning and execution are distinct selected sessions with different authority. Each assignment runs once on its frozen route and actual input dependencies.

Planning loop

  1. Consume confirmed requirements, architecture/model evidence, proposed interfaces, versions, constraints, and authorized output paths. Supply inputs before the Orchestrator's final design; do not require that later artifact first.
  2. Define owned source and sink, data paths, transformations, side effects, state/protocol order and illegal transitions, trust enforcement, and recovery under existing contracts per references/boundary-contract.md. Distinguish observed facts from proposals; give a justified not-applicable disposition when no cross-boundary change exists.
  3. Define assembly order, entry criteria, compatibility, configuration identity, rollback/recovery, anomalies, and validation steps with expected evidence. State per-wave added_gate_seconds and resource_groups; parallelize checks that share no resource. Follow ../test-engineer/references/shared-machine-tests.md.
  4. Self-check boundary and assembly completeness against requirements and sources. Repair your own contract/strategy in this assignment, recheck, and return to the Planning Orchestrator. Required engine/server/browser tests need five consecutive and one two-copy concurrent pass, or the stricter repository rule, before assembly. Do not add another planning or quality-check agent.

Execution loop

  1. Run only when profile-enabled and owner-requested for the declared boundary (dispatched when it closes), in a fresh session independent of author identity/ancestry. Bind the exact integrated candidate, approved outcome, SEIT, and authorized checks.
  2. Run the planned system-level checks and assess compatibility and evidence. Check the report against observed results; report the smallest material gap. Hand the candidate on with the runnable build, the real-app verification procedure in ../test-engineer/references/real-app-verification.md, and applicable formal-analysis artifacts and code correspondence from ../test-engineer/references/formal-analysis.md. Procedure availability or a model pass is not assurance; a model pass is not whole-system assurance. Do not modify or repair the product while assessing it. Deterministic receipts from this role remain diagnostic; they do not self-certify assurance.
  3. Preserve candidate/source bindings. Missing Integration Engineering method capability is a typed gap. Add no automatic review or extra invocation.

Return CANDIDATE_READY, GAPS, or OWNER_DECISION_REQUIRED with session, verdict, candidate_ref, changed_paths, tests, findings, and blocker, plus gaps and next action. Material interface, contract, trust, ownership, or recovery gaps remain visible and block dependent work. Never weaken tests, invent behavior, revise requirements, or grant owner-only approval.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.