Meet the squad who built this app

In my welcome blog, I introduced the idea behind agentic-workflows. This is a sample library I wanted to share because every field and industry that is adopting AI has these types of processes. The AI SDLC is only one agentic workflow.

The project is a public, open-source collection of GitHub Copilot agent definitions, prompt workflows, and planning document templates. The whole thing lives in a .github folder. You copy it into your project and get an AI-driven planning cycle that runs directly through Copilot Chat.

I would also love feedback and for others to contribute! Anyway, here is my breakdown so far. What other users should I add?

	Sarah O. — Solution Owner She is sharp on the business side and a SME on what the app should be. Using @product-owner-agent, she can take a vague idea out of a stakeholder meeting and turn it into a structured feature spec without touching a single line of code. When the agent asks a question she cannot answer, those gaps surface earlier, and she is able to communicate them.
	Ximena D. — Experience Designer She thinks in components, flows, and accessibility states. The designer agent understands modern design patterns and benefits of reusable components, continuity between screens, style, animation, and motion. When she runs design-considerations.md against a feature, she gets a structured UX review that feeds back into the planning docs before engineering starts.
	Quin E. — Quality Engineer He is skeptical by nature. @qe-agent helps him review story files for edge cases and acceptance criteria gaps before anyone writes a line of code. That structured testability checkpoint at the planning stage means he stops finding problems after the fact. Again, these skills can be honed for iOS/Android and Appium, RESTAssured and Java SpringBoot, whatever the stack may be.
	Sammy E. — Software Engineer They use the developer prompts to line the feature up with the app's code and conventions. The agent can adapt to React, Vue, Next.js, or whatever the team is actually building.
	Patrica E. — Platform Engineer She owns the infrastructure questions. platform-engineer can be tuned for AWS, Azure, GCP, or whatever stack the project uses.

The flow is pretty direct. The developer and platform-engineer templates are designed to flex to your stack, so Sammy and Patrica both get prompts that match the way your team actually builds.

flowchart TB
  Idea[Idea]
  PO["Product Owner<br>(@product-owner-agent)"]
  Doc["Draft feature docs<br>FEATURE.md + stories"]
  UX["Experience Designer<br>(@designer-agent)"]
  Arch["Architecture<br>(@architecture-agent)"]
  QE["Quality Engineer<br>(@qe-agent)"]
  Plat["Platform Engineer<br>(@platform-engineer-agent)"]
  PlanReview["Planning review & sign-off"]
  Dev["Developer<br>(@developer-agent)"]
  TeamSignoff["Team sign-off<br>(QE/XD/PE/SO)"]
  Done[Done]

  Idea --> PO
  PO --> Doc
  Doc --> UX
  Doc --> Arch
  Doc --> QE
  Doc --> Plat
  UX --> PlanReview
  Arch --> PlanReview
  QE --> PlanReview
  Plat --> PlanReview
  PlanReview --> Dev
  Dev --> TeamSignoff
  TeamSignoff --> Done

You describe a feature idea in Copilot Chat. The Product Owner agent asks clarifying questions. You answer them. When you confirm, it writes a FEATURE.md file. Then the Stories agent breaks that feature into user stories. You confirm again, story files get written. The Issues agent creates GitHub Issues from those files using the gh CLI. From there, developers work from approved specs.

Nobody opens a feat/* branch until the spec and stories are approved. When Quin is reviewing stories during planning instead of testing a build at the end of a sprint, the whole team moves faster. The QE, XD, and Architecture reviews give the Solution Owner the confidence to sign off before the code lands. The SO still reviews the QE/XD results and makes the final call before merge. Shift-left is the responsibility of all domains, and quality is expected from everyone.

Getting started

Clone the repository into your project:

Following the README, open copilot-instructions.md, and fill in your project details. This is where you provide the stack, team roles, and naming conventions.

Then try this in Copilot Chat:

See what it asks. Answer honestly.

The quality of what you get back is proportional to the quality of what you put in.

If you want agents to have accurate, version-specific docs for your libraries, look into Context7. It's an optional MCP server you can enable in VS Code settings. Include use context7 in any agent prompt and it pulls live documentation instead of relying on whatever the model was trained on. Particularly useful when you're working with fast-moving libraries.

For a concrete example, see the feature doc that built this README in the repo and how the same agent workflow applies to the docs themselves.

Why I built this

I think the thing to remember is everyone on the two-pizza team can use one of these agents.

One thing worth calling out specifically: prompts that write files require you to type a confirmation token. Something like CREATE FEATURE NOW. This is intentional. The dialog phase is supposed to be a conversation. The agent asks. You answer. It does not create files until you tell it to. I added this to ensure the AI assistant is clear on what files it is to generate.

This repo is meant to show one way to make planning more visible and more practical. It is not the only way, and it is not a cure for every team problem. What it does do is give teams an example of how requirements, stories, and quality reviews can be captured before work starts.

It also demonstrates how I have been building and shipping jameskoch.work. The website itself is a working example of how this can work, and GitHub Copilot is just one tool that makes this accomplishable.

The repo is open source, and the part I really want people to help with is the agent examples in .github/agents/examples. If you have a better workflow, a clearer prompt, or a new stack-specific agent, put up a PR and let's build it together.