G-Code for DevOps

Before you install

1. What it does

G-Code for DevOps is a work item chat panel for Azure Boards. It reads the open work item — and, where your admin enables it, the related source code — and proposes field edits and child-work-item decompositions that follow your organisation's own curated skills library, which it only ever reads and never writes to. Nothing reaches Azure DevOps until you have reviewed and approved it.

2. You self-host the invocation component

The product ships as infrastructure your own platform team deploys into your own Azure subscription. There is no vendor-hosted instance, no vendor-run endpoint, and no vendor tenant anywhere in the path.

3. You supply your own inference capacity

Point the proxy at either your own Microsoft Foundry deployment, or an Anthropic API key. Both are first-class, supported choices for different situations — neither is a fallback, a degraded mode, or a lesser version of the other.

Which model answers — a current Claude Sonnet model, and which one is yours to choose. On the Anthropic-direct path, a current Claude Sonnet model answers unless whoever deploys the proxy names a different one; that default travels inside the proxy image, so it moves forward as new images ship rather than being fixed for the life of the product. On the Foundry path, the model is the deployment they point the proxy at. Either way it is a deployment input, set once by whoever deploys the proxy — not a per-user setting, not something the extension picks per request, and changing it later means a redeploy rather than a toggle in the panel. It is also the largest single lever anyone in your organisation holds over the inference bill described below. This listing names no version deliberately: you get the model generation that is current when you deploy, and a version printed here would go stale on a calendar this product does not own.

And on the Foundry path, that deployment does not have to be a Claude model. The proxy speaks two provider APIs — Anthropic's Messages API, and the OpenAI chat-completions API that Azure fronts most non-Claude Foundry deployments with — and the endpoint your platform team declares at deploy time is what selects which of the two it uses. So an organisation whose Azure estate already runs a GPT deployment on its own Foundry resource can point the proxy at that one and never obtain Claude capacity at all; both of the endpoint styles Azure serves chat-completions on are supported, so it does not matter which of them your resource hands you. That path is not theoretical: it has been driven end to end against a real GPT deployment on a real Foundry resource — health checks, streamed invocations, tool calls returning complete child-work-item decomposition proposals, and your organisation's own curated skills being selected automatically.

What that support covers, and what it does not. The product's guarantees are enforced in the proxy rather than in the model, so they hold whichever API answers: nothing reaches Azure DevOps without your review, and a malformed reply is re-asked once and then fails honestly instead of quietly. Output quality is the part that does not carry across. The curated-skills library, the tool descriptions and the product's own prompt were written and tuned against Claude, and the vendor has not assessed how another model's proposals read — whether they are useful for the work item in front of you, whether it splits work at a sensible size, whether it honours what a curated skill actually asks for. On a non-Claude deployment that judgement is yours. It is also why this listing does not tell you that every Foundry model works: a model that does not speak this API is not supported at all, and for one that does, what the vendor stands behind today is that the mechanism works, not how good the writing is.

4. On the Foundry path, content never leaves your tenant

This is true for the default configuration: your own Foundry deployment, inside your own Azure tenant and existing cloud agreement. It is a property of which path you configure, not an unconditional property of the product. A second path exists for organisations with no Foundry presence — see Two ways to supply inference capacity below for what changes if you choose it instead.

Two ways to supply inference capacity

The anthropic alternative, stated in full.

Neither path is a fallback, a degraded mode, a workaround, or equivalent to the other. A customer with no Azure AI estate choosing the Anthropic-direct path has made a sound architectural choice for their situation, exactly as a customer choosing the Foundry path has for theirs.

The consequence, stated exactly rather than softened:

Claim A never bends, on either path. There is no vendor infrastructure anywhere in this product's runtime path, on either provider path — the vendor is not a data processor regardless of which one you choose. What changes is claim B, not claim A.

Full detail on choosing between the two — including the Foundry-only third choice of credential mode (workload identity vs. a stored key) and what each obligates you to — is in the credential-mode decision guide that ships with the deployment templates. A companion security and compliance reference, written for your security reviewer, covers retention terms, processing region, and what re-opens as an approval conversation on the Anthropic-direct path.

What shapes the answer: your own curated skills library, and the code beside it

The curated skills library

A skill is your organisation's house style, written down once and applied to everyone's output. It is a file with a name, a description and the instruction itself: how we break an epic down here, what a work item description has to contain before anyone will pick it up, which fields we always set and which we never touch. Each skill is marked by its author as one you pick yourself or one the assistant may choose for you — and when it chooses, it chooses by reading those descriptions. Either way, the skill that shaped a response is named alongside it. A skill is never applied invisibly.

This is the difference between a generic assistant and this one. Something that drafts a plausible work item is a commodity; something that breaks an epic down the way your organisation breaks epics down — because a team lead wrote that down once, and everyone's output changed with it — is not.

Where the library lives, and who owns it. Skills are files in a git repository your organisation controls: by default an Azure Repos repository in your own Azure DevOps organisation, created and seeded once by the install your own platform engineer runs, and yours from that moment on. Curators change a skill the way your organisation changes any other file — a branch, a pull request, a reviewer, a merge — which is where the useful properties come from, and why the design is this way round: every change is attributable to a named person, review happens before a change takes effect, and a change that turns out wrong is reverted rather than argued about. A merged change is in effect for everyone within fifteen minutes, or immediately if someone asks the panel to re-read the library. No redeployment of anything.

The product reads that library. It never writes to it. There is no "save this conversation as a skill" button, no skill editor, and no authoring surface of any kind anywhere in the product — by design, not by omission. Authoring is your repository's job, under your review, outside this product entirely.

It works on the first day, before anyone has curated anything. The extension ships with seeded skills covering breaking down an epic and drafting a work item, and the install seeds a starter library into your own repository so your curators edit something real rather than start from a blank page. If your library is ever unreachable, unconfigured, or not readable by a particular consumer, the panel keeps working on the seeded skills and says so — nobody is left mistaking generic output for house style. One malformed skill file is named so a curator can fix it, and the rest of the library loads normally.

What a skill can and cannot do. Exactly one skill applies to a response; skills do not chain or compose. A skill can narrow what may be proposed — a curator can write one that only ever proposes field edits — but nothing a skill says can widen what the product is allowed to do: it cannot raise a limit, write a field the product does not write, or cause anything to be saved without your confirmation. The library is instruction, never permission. And where the assistant is choosing a skill for you and cannot settle on one, the turn fails and tells you, rather than quietly answering without the house style it just promised you.

What it asks of you, and what it never sends anywhere. The library is yours to curate, and its quality is your output's quality: a skill that is wrong is wrong for everybody using it until somebody changes it, which is why attribution, review, and the named skill on every response carry more weight here than they look. None of it reaches the vendor — the vendor never hosts, reads or sees any customer's skills library, on either provider path.

One limit, and it is the same one stated above. Reading your library, choosing a skill and naming it on the response are the product's own mechanism, and that mechanism runs whichever provider API answers. Whether a model's proposals actually honour what one of your skills asks for is a different question, and the vendor has assessed it against Claude only — as What that support covers, and what it does not says above, on a non-Claude Foundry deployment that judgement is yours. Nothing in this section should be read as the vendor having made it for you.

The source code beside it — off unless your admin turns it on

One use, and a narrow one: so that a proposed breakdown names modules you actually have, instead of plausible ones it invented.

This is deliberately not "give the assistant your repositories". There is no index, no search across repositories, and no retrieval loop the model drives. You choose one repository and branch explicitly; a bounded set of files is read — the shipped default stops at 15 files and 250 KB per invocation, enforced before anything is sent — and the exact list of files, with the repository and branch, is shown to you with the response. If the ceiling was reached, you are told the answer is based on a partial view. A confidently wrong answer is something you can check, rather than something you have to trust.

Files are read under your own Azure DevOps permissions, from repositories you can already open yourself; nothing here widens anyone's access, and nothing here writes to source control under any circumstance. Files whose names mark them as credential-bearing are removed before selection even when code context is on, and your organisation can add its own patterns to that list — a name-based rule is a floor rather than a guarantee, and it is offered as one. If retrieval fails or runs out of time, the invocation proceeds without code context and says so, rather than failing the whole interaction.

Whether this exists at all is your admin's decision, and the shipped default is off. Turned off, no repository is read under any circumstance, the repository picker is absent, and everything else in the product — including everything in the section above — works unchanged.

What self-hosting commits you to — read before you evaluate further

Adopting this product means your organisation operates a component, not merely installs one. Four things, stated plainly rather than left to be discovered after purchase:

1. You operate this component. The vendor cannot. There is no vendor-hosted version of this product, and none is planned. The proxy runs in your own Azure subscription, deployed by your own platform engineer, from the shipped infrastructure templates. The vendor has no credential, no role and no network path into your deployment — which means the vendor also has no visibility into whether it is healthy. Under self-hosting, "who fixes it at 9am" is answered entirely by your own organisation.
2. It is a single point of failure for every feature of the product. There is no degraded mode in which the panel works without the proxy reachable. A restart, a bad deployment, an expired certificate or an exhausted provider quota takes down the assistant for every consumer in your organisation at once, not a subset. An expired licence reaches exactly as far and belongs on that list, with one difference worth stating plainly: nothing has failed. Every invocation is refused across the whole organisation, deliberately, by a deployment that is otherwise running and whose health, version and diagnostic surfaces keep answering normally throughout — it clears by applying a replacement licence to the running deployment, not by diagnosing an outage.
3. It costs money to run, on an ongoing basis, separate from any licence fee and separate from inference spend. The shipped default is sized for 10 to 30 people in one Azure DevOps organisation, up to 10 concurrent invocations, and up to 200 invocations on a working day. Recurring infrastructure cost at that sizing: roughly $33–$90/month, list price, UK South, priced against the Azure Retail Prices API. This is an order-of-magnitude estimate, not a quote — your own region, Azure agreement and pricing tier will move it, and the full breakdown, the meters it is priced from, and how to reprice it for your own situation ship with the deployment templates. What drives the range is replica time, not invocation count: two replicas bill around the clock as an idle floor, and the range mostly reflects how much of the time the deployment spends above that floor under load — even the full ceiling of 200 invocations a day moves the total by only a few dollars over an idle one. Inference capacity is a separate line again, on your own agreement: your existing Azure billing on the Foundry path, or a separate Anthropic account and invoice on the Anthropic-direct path — and is likely to be the larger of the two costs.
4. The availability you get is the availability you build. The vendor does not commit to an uptime figure for this component, because the vendor does not run it. What the product ships instead is the health and diagnostic surface that lets your own platform team meet whatever figure they choose.

Stating this before purchase rather than after is what separates a customer from a refund. Your platform engineer's itemised, step-by-step prerequisites checklist — everything that must exist before an install can begin, and how to check each one now — ships with the deployment templates, alongside the credential-mode decision guide and the security and compliance reference named above.

What it reads, what it writes, and under whose identity

Under whose identity — stated first, because it governs everything below. Every read and every write happens under your own Azure DevOps identity — the same one you are already signed into Azure DevOps with. There is no separate sign-in step, no identity-provider registration of any kind, and no shared service account: the extension forwards the access token your browser already holds, and the proxy verifies it against your Azure DevOps organisation before doing anything. Attribution follows from this: every action is traceable to the person who took it.

What it reads:

• The open work item's fields, description and any unsaved edits already in the form you have open — read in-frame, from the page you are already looking at.
• Your process template's field display names and backlog configuration, so it knows what a valid child work item type is beneath the one you are viewing.
• Where your admin has enabled source-code context: a repository's directory listing and selected file content, read-only. Nothing in this product ever writes to source control.

What it writes — and only on your explicit action, never automatically:

• A child work item you have reviewed and approved, with a parent link, a title and a description, tagged with a provenance marker so anyone can later identify which work items had AI assistance.
• A field edit you have reviewed and approved, to the work item you already have open.

Nothing saves itself and nothing is created without you looking at it first and confirming it.

The extension requests exactly two Azure DevOps scopes, and nothing else. Work items (read and write) — reads your process template's field names and backlog configuration, and creates the child work item you have reviewed and approved, under your own identity, with its provenance tag; Azure DevOps has no narrower scope that covers work item creation, which is why read and write are requested together. Code (read-only) — retrieves a repository's directory listing and selected file content when your admin has enabled source-code context; the write equivalent of this scope is never requested, because nothing in this product commits, pushes, or otherwise modifies a repository. A line-by-line justification for every permission the extension requests, including the handful of capabilities that need no OAuth scope at all, ships with the deployment templates for a reviewer who wants the complete table.

Support model and version support window

Support model: best-effort email/ticket support. No committed response time. Version window: proxy versions released within the previous twelve months.

For support: https://geekitmea.com/support, or email support@geekitmea.com. For pricing and licensing: email geekitsales@geekitmea.com.

Licensing, term and expiry — what "Paid" means here

Paid, bring-your-own-licence (BYOL). Pricing is flat, per Entra tenant, billed annually and invoiced directly by GeekIt — no seats counted, no per-user metering, no usage-based component. One annual licence covers every Azure DevOps organisation under that tenant. This is a Marketplace-billed-as-Paid listing with the actual commercial agreement conducted entirely outside Marketplace commerce: there is no Marketplace-run trial, no Marketplace commerce, and no per-seat Marketplace entitlement check.

The product enforces its own licence — and it does so without ever contacting us. The deployment verifies its own licence entirely inside your tenant: no request to any endpoint outside your deployment's own tenant, and no request to a licensing authority of any kind, at install, at every invocation, or when you renew. This is not a separate promise from the tenant boundary described above — it is the same boundary, applied to licensing rather than to inference, and it is verifiable the same way: a network inspection at install, in normal operation, or during renewal finds nothing to see.

What happens if a licence lapses. An expired licence stops the product for everyone in the organisation — every invocation is refused. There is no reduced mode, no throttled mode and no read-only mode to fall back to. Recovering is a configuration change, not an outage: applying a replacement licence takes effect without a redeploy, a restart, or any interaction with us.

No trial period is run by the Marketplace, and none expires. There is no countdown, no feature gating, and no mode the product falls into when something lapses other than the refusal described above. If you want to evaluate before committing, ask — the install runs entirely in your own tenant and is removed with a single resource-group deletion.

Image signing — every published proxy image is signed by the vendor

Every proxy image the vendor publishes is signed at release time, with a fixed key held in the vendor's own Azure Key Vault. The signing key's fingerprint — SubjectPublicKeyInfo, SHA-256, EC P-256, sourced from the public key file that ships with the deployment bundle — is:

08955ea902bf466ab3ad99d874ac886c0395427e64c0f125ef47c9a6a5b6f1f6

The same fingerprint, together with the key file and the verification command, is printed in the prerequisites documentation that ships with the deployment templates — reached by a route independent of this listing, so the two can be checked against each other rather than either taken on faith alone. Verifying is a capability offered to any customer who wants it, never a step a customer is asked, expected, or required to take — a customer who never runs it has completed a correct, supported install.