--- title: "Platform Engineering with GitHub: Build Your IDP with Copilot, IssueOps, and Golden-Path Repos" description: "Stop building Backstage. GitHub IS the platform. Build your IDP with Copilot extensions, IssueOps workflows, hookflows, and golden-path starter repos." date: 2026-05-19 tags: ["Platform Engineering", "GitHub Copilot", "DevOps", "Developer Experience", "Agentic Development"] canonical: https://htek.dev/articles/platform-engineering-with-github --- Every enterprise team I talk to is drowning in the same problem: **toolchain sprawl**. Backstage instances nobody maintains. ServiceNow tickets that take 3 days to provision a repo. Confluence pages with onboarding steps from 2022. Developers spending 40% of their time fighting infrastructure instead of shipping product. Platform engineering promises to fix this — and the industry agrees. [Gartner predicts](https://www.gartner.com/en/articles/what-is-platform-engineering) that by 2026, 80% of software engineering organizations will establish platform teams. But here's what most teams get wrong: **they think they need to build another tool.** They don't. GitHub already is the platform. > **Want the complete implementation?** This article covers the architecture overview. Newsletter subscribers get the real configs, full code, and step-by-step implementation details. [Subscribe to the htek.dev newsletter →](https://htek.dev/newsletter) ## The Problem with "Build Your Own IDP" I've seen it play out the same way at every Fortune 500 company I've worked with. A platform team spins up a Backstage instance, spends 6 months building plugins, and ends up with a portal that developers still don't want to use — because it's *another tab*. Another login. Another thing to maintain. Meanwhile, every developer on the team already lives in GitHub 8 hours a day. The insight that changed everything for me: **the best platform is invisible**. It meets developers where they already are — in their IDE, in their pull requests, in their issues. You don't need a separate portal. You need GitHub, used correctly. ## The Golden Path Pattern A **golden path** isn't a locked-down template. It's an opinionated default that accelerates developers without restricting them. Think of it like Rails conventions — you *can* deviate, but the default path is so good that most people don't need to. In the GitHub ecosystem, golden paths are **starter repos + Copilot context**: - **[copilot-instructions-starter](https://github.com/htekdev/copilot-instructions-starter)** — Drop-in `.github/copilot-instructions.md` templates that give Copilot the context to understand your org's conventions from day one. - **[copilot-agent-starter](https://github.com/htekdev/copilot-agent-starter)** — Scaffold custom Copilot CLI agents with proper extension architecture, hooks, and skill files. - **[copilot-life-os-starters](https://github.com/htekdev/copilot-life-os-starters)** — Full starter kits for building agentic systems on top of Copilot CLI. When a new developer joins the team and creates a repo from your golden-path template, they inherit the right CI/CD pipelines, the right Copilot context, the right linting rules, and the right security policies. **Onboarding drops from days to minutes.** ## IssueOps: Eliminate the Ticketing Layer Why send developers to ServiceNow when they can just open a GitHub Issue? **IssueOps** turns GitHub Issues into the interface for platform operations. Need a new environment? Open an issue with a specific label. Need a database provisioned? Issue template with the right inputs. GitHub Actions picks it up, runs the automation, and comments back with the result. The [gh-aw-overview](https://github.com/htekdev/gh-aw-overview) repo demonstrates this pattern — using GitHub's native primitives (Issues, Actions, labels, comments) as the control plane for platform operations. Developers never leave GitHub. No context switching. No ticket queue. ## Hookflows: Governance Without Friction The hardest part of platform engineering isn't building the golden path — it's keeping people on it without becoming a bottleneck. This is where [hookflows](https://github.com/htekdev/gh-hookflow) change the game. Hookflows intercept actions at the agent layer — validating commits, enforcing branch naming, checking policy compliance — *before* they hit the repo. They're governance guardrails that run automatically. Combined with [copilot-hooks-starter](https://github.com/htekdev/copilot-hooks-starter), you get a pre-built framework for intercepting and validating agent operations. The [copilot-ci-pipeline](https://github.com/htekdev/copilot-ci-pipeline) repo extends this into CI — giving you a full feedback loop from commit to deployment. I wrote more about this pattern in [my article on governing AI agents in git](/articles/hookflows-governed-git-for-ai-agents) — the principles apply equally to human and AI-driven workflows. > **Newsletter subscribers get the real configs.** The full hookflow definitions, the IssueOps action templates, and the architecture diagrams that connect all 7 repos into a cohesive platform. [Get the implementation details →](https://htek.dev/newsletter) ## The 7-Repo Stack Here's the full stack, all open source and production-tested: | Repo | Purpose | |------|---------| | [copilot-instructions-starter](https://github.com/htekdev/copilot-instructions-starter) | Org-wide Copilot context templates | | [copilot-agent-starter](https://github.com/htekdev/copilot-agent-starter) | Custom Copilot CLI agent scaffolding | | [copilot-hooks-starter](https://github.com/htekdev/copilot-hooks-starter) | Agent-layer governance hooks | | [copilot-ci-pipeline](https://github.com/htekdev/copilot-ci-pipeline) | CI feedback loop for AI-assisted dev | | [gh-hookflow](https://github.com/htekdev/gh-hookflow) | Governed git operations framework | | [gh-aw-overview](https://github.com/htekdev/gh-aw-overview) | IssueOps platform operations pattern | | [copilot-life-os-starters](https://github.com/htekdev/copilot-life-os-starters) | Full agentic system starter kits | These aren't demos. I built and validated this stack while running a DevOps enablement platform at a Fortune 500 energy company — supporting hundreds of repos and dozens of development teams. The patterns scale. ## Why GitHub IS the Platform The realization that unlocked all of this: **you don't need a separate platform layer.** GitHub already has: - **Identity & access** (Teams, CODEOWNERS, branch protection) - **Service catalog** (repo topics, README conventions, `copilot-instructions.md`) - **Self-service provisioning** (IssueOps + Actions) - **Compliance & governance** (hookflows, required checks, audit logs) - **Developer AI** (GitHub Copilot with full repo context) - **Deployment** (Actions + environments + OIDC) Every piece of Backstage functionality has a native GitHub equivalent — and developers already know how to use it. Your platform team's job isn't to build a portal. It's to **configure GitHub as a platform** and encode golden paths that make the right thing the easy thing. ## Go Deeper If you're building (or rebuilding) an internal developer platform, I wrote a full implementation guide as part of [The Agentic Development Blueprint](https://htek.dev/blueprints/the-agentic-development-blueprint) — including architecture diagrams, configuration files, and the decision framework for what goes in golden paths versus what stays flexible. For related patterns, check out [my guide to Copilot CLI extensions](/articles/github-copilot-cli-extensions-complete-guide) and [how hookflows enforce governed git for AI agents](/articles/hookflows-governed-git-for-ai-agents). --- **This was the architecture overview.** The newsletter issue has the step-by-step implementation — exact configs, IssueOps templates, hookflow definitions, and the full wiring diagram connecting all 7 repos into one cohesive IDP. [Subscribe to the htek.dev newsletter →](https://htek.dev/newsletter)