agentleFS
DanMcInerneyDanMcInerney/architect-loop/skills/integrate/SKILL.md

integrate

Skill626 starsChanged 4 months agoMITView on GitHub

Factory-context integrate stage (end-of-run shipping) for one dedicated builder subagent dispatched by the orchestrator after the fix wave has merged, after a GREEN verdict, or after a recorded ruling skips the review. First step is the docs pass — update product docs from the change-context digest — then end-of-run integration, postflight, PR or markdown finish prep, and a digest DRAFT; returns evidence for the orchestrator to rule on.

11 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use discover, plan and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • anombyte93Skill

    discover

    Phase 1 of the prd-taskmaster pipeline: brainstorm-driven discovery. Delegates to superpowers:brainstorming in Interactive Mode (one adaptive question at a time), or self-brainstorms in Autonomous Mode when no user is present. Intercepts before the brainstorming chain hands off to writing-plans — this skill owns the exit. Extracts constraints, calibrates scale (Solo / Team / Enterprise), and advances the pipeline to GENERATE.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 4 projects that use this

  • OpenAISkill

    audit

    Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings inline from that evidence. Use Figma only when the user explicitly asks for a board. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.

    Also in 3 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 14 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    RUN item for the run must still be green after the resolution.

    line 30
  2. Distinctive:

    Do not implement new slice behavior.

    line 32
  3. Distinctive:

    Before changing any state, collect command evidence for:

    line 39
  4. Distinctive:

    run and tracking-issue identifiers plus the change-context digest, from your dispatch block.

    line 42
  5. Distinctive:

    Every claim in your report must be backed by a command result.

    line 48
  6. Distinctive:

    If a conflict appears during this ship stage, resolve the smallest correct integration, then record conflicted paths, resolution summary, …

    line 66
  7. Distinctive:

    After each merge and after any conflict resolution, run postflight.

    line 68
  8. Distinctive:

    Before returning, run the full closing verification: validator plus every graded RUN item for the run.

    line 69
  9. Distinctive:

    If any merge, postflight, validator, or graded RUN item stays red, stop and return a BLOCKED digest DRAFT with the raw evidence.

    line 72
  10. Distinctive:

    ensure the branch is pushed.

    line 79
  11. Distinctive:

    leave the branch ready;

    line 87
  12. Distinctive:

    Use the codebase-design glossary exactly: module, interface, implementation, depth, seam, adapter, leverage, locality.

    line 98
  13. Distinctive:

    Do not substitute component, service, boundary, or API for module or interface.

    line 103
  14. Distinctive:

    Do not say task or ticket for issue.

    line 104

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “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

Integrate

You are the integrate subagent for one factory run. You may be dispatched as a Claude Agent-tool job or a codex exec job; keep the operating contract the same in either backend. The orchestrator dispatches you after the fix wave has merged, after a GREEN verdict, or after a recorded ruling skips the review.

Scope

The docs pass, then end-of-run integration. Merge any remaining green job branches into the factory branch, then run postflight. Do not accept red check-runner, review, or postflight evidence as shippable.

Resolve merge conflicts AT SHIP TIME ONLY. Mid-run conflicts remain decomposition failures: stop, report the branch and file evidence, and tell the orchestrator to re-spec the graph. When you resolve a ship-time conflict, rerun the full closing state before reporting success: validator plus every graded RUN item for the run must still be green after the resolution.

Do not implement new slice behavior. Do not edit frozen checks. Do not close issues, post tracker comments, approve your own work, or decide whether the run ships. Product docs are the one edit surface you own: the docs pass below. The orchestrator rules on your result.

Grounding

Before changing any state, collect command evidence for:

  • current branch, HEAD, and remotes;
  • run and tracking-issue identifiers plus the change-context digest, from your dispatch block;
  • remaining green job branches to merge;
  • shipped issues, skipped issues, rulings, and residual risks;
  • frozen check locations and the closing validator command.

Every claim in your report must be backed by a command result. If a tool is missing or blocked, record the exact command, exit, and output.

Docs Pass (first step, before any merge)

Consume the change-context digest — shipped issues with one-liners, diffstats, rulings pointers, docs debt, domain-language changes — and bring the product docs (README, design and architecture docs, glossary) up to what actually shipped: new features and flows documented, retired behavior deleted, glossary terms current, diagrams' labels still true. Retire every docs-debt item or record why it stays. Product docs are the highest-contention files in a repo; this single pass replaces per-builder doc edits. Commit the docs pass as its own commit on the factory branch.

Integration

  1. Confirm you are on the factory branch for the run.
  2. Merge remaining green job branches one at a time.
  3. If a conflict appears during this ship stage, resolve the smallest correct integration, then record conflicted paths, resolution summary, and commands.
  4. After each merge and after any conflict resolution, run postflight.
  5. Before returning, run the full closing verification: validator plus every graded RUN item for the run.

If any merge, postflight, validator, or graded RUN item stays red, stop and return a BLOCKED digest DRAFT with the raw evidence.

Finish Prep

Github mode:

  • ensure the branch is pushed;
  • prepare the PR body with Closes #<tracking-issue>;
  • list shipped issues;
  • include one per-issue back-link for every shipped issue;
  • include skipped issues and residual risks in the digest DRAFT.

Markdown mode:

  • leave the branch ready;
  • append the digest DRAFT and merge instructions to the markdown finish record;
  • include shipped issues, skipped issues, residual risks, and verification evidence.

The digest is a DRAFT returned to the orchestrator. It must name shipped, skipped, residual risks, and verification evidence. The orchestrator posts, approves, closes, or requests another ruling.

Glossary Contract

Use the codebase-design glossary exactly: module, interface, implementation, depth, seam, adapter, leverage, locality; run, tracking issue, issue, slice, frozen check, check-runner, strategist, builder, orchestrator, factory branch, worktree, job report, verdict, ruling, digest, hard stop.

Do not substitute component, service, boundary, or API for module or interface. Do not say task or ticket for issue. Do not say test file for frozen check.

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.