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
- synaptiai/agent-capability-standardtheir own version, first seen Nov 1, 2026
- BANKSapi/claude-plugintheir own version, first seen Nov 1, 2026
- masseater/skillstheir own version, first seen Oct 25, 2026
- modeled-information-format/mnemonictheir own version, first seen Oct 13, 2026
- VoTruongDanh/Skills-Agenttheir own version, first seen Oct 13, 2026
- ykeezy/skillstheir own version, first seen Oct 9, 2026
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.
anombyte93Skilldiscover
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
BlockSkillplan
Draft a TDD, PRD, or lightweight plan in the conversation without committing it.
Also in 4 projects that use this
OpenAISkillaudit
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
SentrySkillreview
Fixture review skill.
Also in 3 projects that use this
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- suboss87/FDEOps★ 940same name
- yha9806/academic-writing-toolkit★ 54same name
- Dan-Cleary/fdestack★ 40same name
- dfrysinger/qrspi-plus★ 37same name
- modeled-information-format/mnemonic★ 23same name
- synaptiai/agent-capability-standard★ 6same name
- VoTruongDanh/Skills-Agent★ 4same name
- masseater/skills★ 2same name
- BANKSapi/claude-plugin★ 1same name
- ykeezy/skills★ 1same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- adversarial-reviewSkill
- architect-fastSkill
- architect-researchSkill
- architectSkill
- codebase-designSkill
- final-reviewSkill
- frozen-checksSkill
- tddSkill
- to-issuesSkill
- to-specSkill
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
- Distinctive: line 30
RUN item for the run must still be green after the resolution.
- Distinctive: line 32
Do not implement new slice behavior.
- Distinctive: line 39
Before changing any state, collect command evidence for:
- Distinctive: line 42
run and tracking-issue identifiers plus the change-context digest, from your dispatch block.
- Distinctive: line 48
Every claim in your report must be backed by a command result.
- Distinctive: line 66
If a conflict appears during this ship stage, resolve the smallest correct integration, then record conflicted paths, resolution summary, …
- Distinctive: line 68
After each merge and after any conflict resolution, run postflight.
- Distinctive: line 69
Before returning, run the full closing verification: validator plus every graded RUN item for the run.
- Distinctive: line 72
If any merge, postflight, validator, or graded RUN item stays red, stop and return a BLOCKED digest DRAFT with the raw evidence.
- Distinctive: line 79
ensure the branch is pushed.
- Distinctive: line 87
leave the branch ready;
- Distinctive: line 98
Use the codebase-design glossary exactly: module, interface, implementation, depth, seam, adapter, leverage, locality.
- Distinctive: line 103
Do not substitute component, service, boundary, or API for module or interface.
- Distinctive: line 104
Do not say task or ticket for issue.
“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.
Files
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
- Confirm you are on the factory branch for the run.
- Merge remaining green job branches one at a time.
- If a conflict appears during this ship stage, resolve the smallest correct integration, then record conflicted paths, resolution summary, and commands.
- After each merge and after any conflict resolution, run postflight.
- 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.
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
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.

