An open-source pack of methods, prompts, and templates for teams that want AI to be a daily part of how they work. Built to be copied into your team's repo, adapted to your domain, and run on Claude Code or GitHub Copilot.
The cost of producing a draft has collapsed.
For most of the last fifty years, knowledge workers produced things in much the same way: documents, decisions, plans, code, meeting minutes, strategy papers were drafted by a person sitting at a tool, working from what they knew and what they had captured. The cost of producing a first draft was an hour or two of focused work. The cost of producing it well was years of accumulated judgement.
That has changed. Language models can now draft an email, a spec, a paper, a code change in thirty seconds. The first draft is often good enough to ship. Sometimes it is wrong in ways that look right.
This is not a productivity story. It is a structural change in the work itself. The scarce resource has shifted from drafting to judging. Producing has become cheap; specifying what good looks like, and verifying that the draft meets it, has become the work. There is a discipline to doing this well: teams that capture context once, draft against it, review against named criteria, and ship when the loop closes produce more high-quality output. Teams that bolt AI onto unchanged processes produce more output overall, but more of it is plausible-looking failure that is harder to catch.
Two recent public examples illustrate that this is happening across roles, not just in engineering.
Tobias Lütke, CEO of Shopify, sent a memo to executives stating that effective use of AI is now a requirement for every employee, not only developers and analysts. He framed it as a cultural change, not an IT decision. Performance evaluations and product practices were being aligned around the requirement.
Vivian Balakrishnan, Singapore's Foreign Minister, posted a public account of building his own AI-augmented working setup, a "second brain for a diplomat", running on a Raspberry Pi at home, compounding context from speeches and articles he encounters, drafting daily updates, condensing meeting material. He closed with: "The diplomat who learns to work with AI will have a meaningful edge. I think that edge is now."
A CEO and a diplomat, neither of them an engineer, have arrived at the same conclusion: the structural shift demands new working patterns at the role level, not just a new tool to plug in.
The pattern is not "use ChatGPT to draft an email faster". It is closer to: build a shared operating system around AI as a daily working partner, then let it compound.
In a single artefact, the loop is simple:
- The team has a known artefact to produce, a document, a decision, a piece of code, a meeting minute, a specification.
- The artefact has known consumers and a known quality bar.
- AI drafts the artefact from context the team has captured ahead of time.
- A reviewer, a person, another AI agent, or both, checks the draft against the quality bar.
- The artefact ships when the review passes.
Doing this once is easy. The hard part is consistency: running this loop on every artefact a team produces, every week, for a year, with shared context and shared quality bars across the team. That consistency is what this pack supplies.
A pack of working materials small teams adopt to do this work systematically. It ships as:
- Method documents. Five numbered stages and three thematic principles. Stage 1 maps what the team already produces; Stage 5 closes the feedback loop. The method is the framing.
- Generator prompts. Ready-made prompts that produce specific artefacts (artefact maps, skill candidates, decision logs, gap reports, post-mortems). A prompt is a structured way to ask AI to produce one kind of artefact, with the team's context already wired in.
- Reviewer prompts. Paired prompts that check generator output against named criteria. A generator without a reviewer is half a tool.
- Templates. Skeletons for artefacts the team will fill in (frontmatter conventions, daily logs, archive headers, plan folders, instance declarations).
- Adapters. Runtime-specific wrappers for Claude Code and GitHub Copilot so the same pack runs on whichever tool your team uses.
- A worked example. A fictional asset-management team called Perivale that shows the method end-to-end on a plausible scenario. The Perivale files are illustrative only; you do not copy them into your team's instance.
This is a pack, not a product. There is nothing to install and nothing to host. You clone or fork the repo and the pack lives inside your team's own repository.
Two readerships, in mind from the first line of every document.
If you are a senior engineer or architect (the type that designs systems, not buildings) — comfortable in repos, already using Claude Code or Copilot — you can read this pack as a working operating system you fork into your own team's repo. Many of the disciplines (single-source-of-truth, archive-not-delete, frontmatter conventions, INDEX drill-down) will look familiar from your own engineering practice. The pack saves the effort of re-deriving them and adds the AI-specific layers (generator-reviewer pairing, the Koine Loop, the eleven knowledge disciplines).
If you are a product owner, teacher, architect (the type that designs buildings, not systems), researcher, or any non-engineer knowledge worker — comfortable in markdown, less comfortable in terminals — you can read this pack to understand whether AI augmentation as a team practice is something your team should adopt. You will need an engineering collaborator to wire the runtime adapters in, but the decision of whether to adopt the method is yours, not theirs.
You will not find this pack a fit if:
- You are looking for a ChatGPT-shaped product. There is no UI here, there is no installer.
- You are looking for a methodology with certifications and trainers. The pack is unsupported public material, copy-and-own.
- Your team produces low volumes of structured artefacts. The discipline overhead requires real volume to pay back.
- You want to add AI on top of an existing process without changing how you work. This pack assumes the work itself changes.
- Not a product or a platform. There is nothing to host and nothing to install.
- Not a prescriptive framework. The method is opinionated where it has evidence and silent everywhere else.
- Not a training course.
- Not a complete methodology. The pack covers team operating disciplines for AI-assisted knowledge work, and is silent on functional craft (how to write good code, good copy, good policy).
- Not evangelism. If you already have a working way of running your team, do not adopt this just because it exists.
- Make your own copy of this repository. Clone it locally, or fork it to your own GitHub account if you would rather have a connected copy. Either way, the supported model is ownership of a copy, not a dependency on this upstream.
- Read method/00-overview.md, the at-a-glance map of the five stages and the cross-cutting principles.
- Read the worked example at worked-example/perivale-asset-management/ end to end. The example is for understanding only, do not copy its files into your own instance. After you understand it, fork the pack and run the bootstrap interview against your own team.
- Run the bootstrap interview prompt at prompts/bootstrap-interview.md. An AI assistant interviews the team lead about every recurring thing the team makes, and produces a map (the artefact map) that feeds every later stage.
- Pick one method discipline to try first. Artefact archaeology (Stage 1) or the minimum viable OS (Stage 3) are the usual entry points. Do not adopt every discipline at once.
- If you find a real defect, open an issue. See CONTRIBUTING.md.
The author has found it useful to think about AI agents and humans sharing work through twelve role archetypes with Greek names, see method/agent-archetypes.md for the list and what each one does. The Perivale worked example does not use these names, it uses real human first names so the example reads as a working team rather than a mythology lesson. Either pattern is valid in your fork. The pack does not impose a vocabulary; it offers one.
Koine (Κοινή, "common") was the shared Greek of the Hellenistic world after Alexander. It was the everyday register that carried contracts, letters, and the New Testament across the eastern Mediterranean for centuries. It is still the liturgical language of the Greek Orthodox Church today. The name was chosen because the pack is a shared working register for teams doing expert work with AI, and because a shared working language that has carried meaning across centuries is the right ancestor for a team OS.
The repository is small. Each major directory carries an INDEX.md (a one-page map of its contents) that lists its files with a one-line description.
- method/, the method documents, five numbered stages and three thematic principles. Start with method/00-overview.md. Full list and recommended reading order in method/INDEX.md.
- prompts/, runtime-neutral generator prompts. The entry point for a fresh adoption is prompts/bootstrap-interview.md. Full list in prompts/INDEX.md.
- prompts/reviewers/, six Tier 1 reviewers (the gates that must pass on every adoption) plus four optional-primitive reviewers (the gates a pack opts into based on its audience). See prompts/reviewers/INDEX.md.
- templates/, artefact templates referenced by the method and the prompts: frontmatter, daily log, archive header, plan folder convention, instance declaration shape, plus the skill-template and registers-scaffold subfolders. See templates/INDEX.md.
- adapters/claude-code/ and adapters/copilot/, runtime-specific wiring. Start with each adapter's
README.md. - worked-example/perivale-asset-management/, the worked example demonstrating every method stage end to end. For reading only, not adoption.
MIT. See LICENSE.