5
runtime hooks
Session state, safe sync, command policy, output trimming, and a test-change gate.
Public starter kitCopilot CLI · v0.4.0
Make the playbook executable.
This is the repository behind the AI-driven project playbook: a small, inspectable starting point for teams that want agents to follow a workflow, respect guardrails, and know where work belongs.
What you get
Enough structure to start. Small enough to understand.
It is deliberately not a framework. Every artifact is short, documented beside its rationale, and designed to be replaced when your team learns something better.
5
focused skills
Production readiness, feature flags, grilling, post-merge cleanup, and a bounded loop.
2
specialist agents
A mechanical release gate and a read-only weekly retrospective.
3
scoped MCP servers
Azure work items, repositories, and pipelines without loading every tool.
The operating model
Four layers, one clear boundary.
Reuse the workflow. Own the enforcement. Route work explicitly. Keep operations boring. That boundary is the main design decision in the kit.
Why these leversWorkflow
Install the maintained planning, ticketing, TDD, implementation, and review skills.
Enforcement
Add tested runtime hooks for the rules a model must not merely remember.
Routing
Give every task an explicit repository, owner, Azure identity, and validation command.
Operations
Gate releases, use default-off flags, clean merged work, and loop only where a check can refuse.
Quick start
From clone to useful in four steps.
- 01
Install the workflow
Use Matt Pocock's maintained skills for specification, decomposition, TDD, implementation, and review.
pnpm dlx skills@latest add mattpocock/skills - 02
Install the enforcement companion
Copilot loads the hooks, focused skills, custom agents, and scoped Azure DevOps MCP configuration.
copilot plugin install thekeyvan/ai-driven-starter - 03
Create your workspace contract
Copy the templates, then replace every repository, ownership, command, and Azure placeholder with your own.
cp templates/repo-map.yaml ./repo-map.yaml cp templates/issue-tracker-azure-devops.md docs/agents/issue-tracker.md - 04
Prove the guardrails
Run the negative cases before trusting a hook or the loop. Both suites cover valid work and actions that must be refused.
./scripts/hooks/test-hooks.sh ./scripts/ralph/test-loop.sh
Bring your own opinions
Copy the structure, not the assumptions.
The example encodes one team's environment: NestJS, React, Azure Boards, LaunchDarkly, WSO2, and Kubernetes. If your stack differs, change the skills, release checks, MCP configuration, and repository map before you trust them.
- Replace every repo-map placeholder
- Keep only MCP domains you use
- Rewrite stack-specific skill rules
- Add a negative case for every guardrail
Inspect it before you install it
The repository is the product—and the documentation.
Every decision has an ADR, every short instruction has its rationale beside it, and every hook has refusal cases. Fork it, challenge it, and delete what does not earn its keep.