Ngandu Kasuku, a principal product counsel at GitHub, cut her contract review time in half by building her own drafting tool using GitHub Copilot CLI.
The team behind the tool consists of lawyers, program managers, and business professionals. They are not engineers. Their work involves repetitive tasks like reviewing standard contracts and answering recurring legal questions. Before this, they lacked confidence in how to build the right software to handle these problems.
Using Copilot CLI, they asked for what they wanted in plain language. They plugged into their code repositories and saw real changes within days. The mindset shifted from “I could never code” to “I just built something,” a habit that spread until every member was creating their own utilities.
Why I built an internal drafting style guide
The following is a first-person account from Ngandu Kasuku, Principal Product Counsel.
I am a product attorney, but commercial work remains a sizable part of my practice. Around March or April, I found myself buried in partnership deals involving data, infrastructure, and product integrations. No two deals looked quite alike, so each new matter felt like starting over.
I started using Copilot CLI to manage the surge, which helped, but also had some problems. Then, after seeing what others had built with Copilot, I realized I was not thinking big enough. Instead of using AI for one task at a time, I could build something around the way I work.
So, I created a contract drafting tool using Copilot CLI. I called it terms-ai, which I admit isn’t the most original name. I started by scaffolding the project and storing key documents in a repository. This gave me one place to organize and version the instructions, drafting resources, and workflows that guide the AI. That structure made the results more consistent and reduced the copying and pasting that had slowed me down when I was using a library of prompts.
One of the tool’s main features is an internal drafting style guide. Since my days as a commercial lawyer, I have favoured plain language. I never understood why contracts needed words like “heretofore” and “therewith”. When I discovered that an entire legal drafting movement shared this view, I used its principles as the foundation for my style guide.
I also built a library of agreements I had already completed. Now, when an existing partner sends over an addendum or a new agreement, the tool can draw on that earlier work. These agreements remain in an approved, access-controlled internal environment.
The tool and its general workflow are open source. The agreements and other sensitive information are not part of the open source repository. Since I began using terms-ai, I have cut my review and drafting time roughly in half. My provisions are more consistent across agreements, and the drafts reflect the plain style I prefer.
The tool still has a long way to go. But the biggest lesson was not that AI could help me draft faster. It was that I could use AI to build a tool around my own judgment, experience, and way of working.
How I built legal workflows without writing traditional code
The following is a first-person account from Jesse Geraci, Online Safety Counsel.
I started with a narrow problem. We needed to analyse source code quickly and accurately to evaluate DMCA (Digital Millennium Copyright Act) notices. The original project began as a set of GitHub Copilot instructions for recurring tasks like DMCA triage, comparing code, license checks, and circumvention review. We wanted to turn the messy, one-off prompt work that everyone was doing independently into something repeatable that a legal team could trust to gather the right facts and analyse the data consistently.
I was surprised at how far I could go without engineering support. The core “programming” was plain-language files consisting of workflow instruction sets, policy reference materials, and templates for writing reports. Instead of writing source code, I was able to use my language crafting skills as a lawyer to build structured legal judgment into the workflow itself.
It grew from there. We added different analysis modes for clients and lawyers (with faster outputs and escalation recommendations for clients, and deeper review and both-sides arguments for lawyers) and integrated external data sources. When I handed the workflow off to the team, they started using it right away and asked Copilot to do more.
That foundation has since evolved into a full desktop app for running predefined legal workflows in a clean interface. Building the desktop app required writing some code (a lot of code, actually), but the core instructions used to customise workflows are easily edited and customised in the app using plain language.
The app we created has now expanded well beyond only code analysis for DMCA notices. It includes instructions for many in-house workflows like contract review, NDA triage, risk assessment, compliance checks, and response drafting. Under the hood, it can route work through reusable skills and agents (intake, playbook alignment, risk scoring, evidence verification, escalation routing, report assembly), but the important part is not technical complexity—it is that legal teams can still control behaviour in readable Markdown.
For me, the key lesson was that I do not need to wait for the perfect software vendor—or become a full-time developer myself—to build serious AI tooling. If you can clearly define your methodology, your standards, and your output format, GitHub Copilot makes it easy to operationalise that knowledge.
My legal Copilot is not a replacement for legal judgment, and it should not be treated that way. It is a structured decision-support system designed to keep human review central while making legal analysis more consistent, more transparent, and more scalable.
What it means
The legal team at GitHub demonstrates that non-technical staff can automate repetitive work without becoming professional developers. The shift is from asking an AI to perform a single task to building a system that encodes their specific workflows and standards. Users define their methodology in plain language, such as Markdown, and the tool executes it. This approach keeps human oversight central while improving consistency across a team’s output.
