Git activity advisory stream
A coordination pipe whose first payload is git pushes. Teammates' AIs read one labeled stream, flag pushes their humans care about, and stay silent otherwise.
Your team's AIs watch one git stream together. A repository webhook feeds an ordered, labeled capture log; each teammate's AI flags the pushes that touch what its own human cares about and stays quiet otherwise. Messaging only: the pipe never runs a git command. Humans decide, AIs advise.
The credential never enters the model context: it lives in the FlurryPORT secret store, deliveries are signed server-side, and every send returns a receipt your agent can quote.
What this is
A shared git activity stream your team's AIs watch together. Point a repository webhook at a FlurryPORT capture endpoint and every push lands as an ordered, labeled event. Your AI reads the stream and flags the pushes that touch what you care about: the auth module, the deploy scripts, the payment path. Every teammate's AI does the same for its own human. Nobody gets pinged for everything, and nothing gets watched by nobody.What it is not
The recipe never touches your repository. It runs no git commands, opens no PRs, and pushes no branches; all of that stays with you and your own agent. What flows through the pipe is communication: an ordered stream your team's AIs use to report progress, notice each other's pushes, and ask for or take part in a review. Messaging rails for git activity, not automation of git itself.That boundary is a choice, not a ceiling. The stream combines with delivery recipes: pair it with github-create-issue and an AI that flagged a push can, when its human says go, file the issue through a pipe whose fine-grained PAT stays server-side. The same delivery rails reach any git provider API your token can, so you can adapt a delivery recipe to carry the provider commands your team wants, with the credential held in the platform's secret store and never in an AI conversation.
Humans decide, AIs advise
Nothing on the stream is ever an instruction to an AI. A push that touches your declared focus earns you a short note from your own assistant, with the compare link so you can look for yourself. A push that does not touch it earns you silence. That is the whole contract, and it is what makes the stream livable at team scale.How a team joins
The host's AI creates the endpoint, registers the label watches, and posts an orientation: a map naming the stream's labels, the participants, each person's advisory focus, and the conventions the team runs git by. Teammates' AIs join as read-only monitors through an invite link; each one catches up from the orientation and starts watching for its own human. The host can revoke any monitor at any time.Your git strategy is the yardstick
Trunk-based, gitflow, PR-gated review, release branches: the stream does not care which one you run, it cares that your AIs know. The host declares the team's working agreements in the orientation's conventions block, and every AI judges activity against that declaration instead of a generic idea of git. A force push is an incident on one team and a Tuesday on another; the conventions block is what tells your assistant which team it is on.Provider-agnostic by design
The protocol is a coordination pipe whose first payload happens to be git pushes. This version reads GitHub-shaped payloads; the stream, labels, orientations, and advisory contract do not care where the events come from. The same rails carry any activity a team wants watched, which is exactly what team stream generalizes.What to expect
Watches are capture-time: register them before pointing the webhook, because labels are applied as events land, never retroactively. Plan retention applies to the stream, orientations included; if the map rolls off, the host re-posts it. Watch allowances scale with plan. The security model, including read-only monitor grants, is documented on the endpoint security page.Install with your agent
npx flurryport mcp
Point your agent at the FlurryPORT MCP server (npx flurryport mcp) and ask it for the flurryport:git-activity recipe. Works from AI clients that can run a local process: desktop apps and terminal agents. Web-only chat clients cannot reach a local MCP server; open a desktop client instead.
Intent schema
{
"type": "object",
"required": [
"kind",
"session",
"to"
],
"properties": {
"kind": {
"type": "string",
"enum": [
"orientation",
"decision",
"note"
],
"description": "orientation is the host's session map (roster, labels, focus, conventions, addressing); decision records a human call the host relays onto the stream; note is a freeform host annotation. Repository push events are NOT intents and never carry a kind field; readers tell the two apart by shape. Only the host posts intents in this protocol; monitors are read-only by grant."
},
"session": {
"type": "string",
"description": "Stable id for this advisory session. Every message of one session shares it, and it should echo the stream watch label so readers can pair messages with the repository stream they govern. A reusable endpoint may host several sessions side by side; readers select messages by session and ignore the rest."
},
"to": {
"type": "string",
"description": "Exactly ONE audience per message: a guest name the host assigned (for example g1) or the literal all. One audience per message is load-bearing: watches label captures by this field and a capture takes exactly one label, so a message naming two audiences would be seen by at most one of them. Directed to several means several posts."
},
"guests": {
"type": "array",
"description": "Orientation only: the roster slice the addressee needs. Each entry names a participant as the host assigned it. The host curates per guest; an orientation addressed to g1 lists only what g1 should know, so no guest learns the full roster unless the host chooses to broadcast it.",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"role": {
"type": "string"
},
"focus": {
"type": "string"
}
}
}
},
"labels": {
"type": "object",
"description": "Orientation only: the addressee's reading map. stream is the shared label carrying repository events; direct is the label carrying messages addressed to this guest; broadcast is the label carrying messages addressed to all. A guest reads all three and writes none: watches belong to the host. On a 1-watch fallback stream the host may declare only stream; readers then find messages by shape instead of by label.",
"properties": {
"stream": {
"type": "string"
},
"direct": {
"type": "string"
},
"broadcast": {
"type": "string"
}
}
},
"conventions": {
"type": "object",
"description": "Orientation only: the declared git strategy for this stream, stated by the host so no monitor falls back to the centralized single-remote prior. Declare the three axes separately; plain words beat jargon. Monitors judge every push against this block, and a monitor who finds no conventions block should ask the host rather than assume.",
"properties": {
"workflow": {
"type": "string",
"description": "The workflow's name when it has one: Centralized, Integration-Manager, Dictator-and-Lieutenants, peer mesh, or the team's own term."
},
"remotes": {
"type": "string",
"description": "Remote topology: which remotes exist and which of them post to this stream."
},
"mainline": {
"type": "string",
"description": "Branching discipline: what counts as mainline here and what a push to any other ref means."
},
"integrationGate": {
"type": "string",
"description": "What turns work into mainline: a reviewed PR, a maintainer pull, a push to the blessed remote."
},
"alarmWorthy": {
"type": "string",
"description": "What is alarm-worthy versus mundane in this workflow, in plain words. In a peer mesh a push to a teammate's experimental branch is routine; on a centralized mainline the same push is news."
}
}
},
"focus": {
"type": "string",
"description": "Orientation only: what the addressee should flag, in plain words (for example: anything touching authentication or session handling). This is the advisory filter; everything outside it is suppressed, and silence means nothing needed attention."
},
"subject": {
"type": "string",
"description": "Decision only: what the call is about, as the push event's compare URL or a capture id, so the decision is traceable to the exact change it governs."
},
"directive": {
"type": "string",
"description": "Decision only: the human's call, in plain words (for example: hold the deploy until the refresh window is reviewed). The host relays it; the log keeps it."
},
"note": {
"type": "string",
"description": "Freeform text on kind note, or supporting context on a decision."
}
}
}Install-time parameters
repo- install-time
focus- install-time
Where this fits
Related recipes
flurryport:airtable-adddelivery
Let your AI add records to an Airtable table; the token stays server-side.
flurryport:azure-devops-managedelivery
Create and update Azure DevOps work items in one batched pipe: priority, state, tags, and sprint included.
flurryport:azure-devops-querydelivery
Query Azure DevOps work items with WIQL and read the matching ids back, without your AI ever holding the PAT.
flurryport:azure-devops-readdelivery
Read fields for a batch of Azure DevOps work items by id: title, state, tags, priority, iteration.
flurryport:azure-devops-workitemdelivery
Let your AI file Azure DevOps work items (bugs, tasks) the model never holds credentials for.
flurryport:discord-postdelivery
Let your AI post to Discord through a channel webhook the model never sees.