One picture of what AI enablement looks like when it is connected to the daily work. The AI enablement hub (the cockpit, or AI command center) knows who you are from the enterprise sign-in. It reads the repositories, API (application programming interface) contracts and Jira, read-only, through MCP servers (Model Context Protocol, an open standard for connecting an AI tool to a system). It drafts the work for people to decide. Click any box for what it is and where it shows up in the running example, pushApprove at Acme Corp.
Inside a developer repository
Underneath the hub, each repository carries its own context. This is what a developer, or a coding agent, finds after checking out one service: the README, the team's instructions, project skills and slash commands, rules, and the two hooks that check the agent's work before and after each step. On the right is what the organization plugs in, so no team rebuilds it.
| Layer | Lives in | Who owns it | What it does |
|---|---|---|---|
| README | README.md | The team | What the service is, how to run it, the owners, and the link to the hub |
| Instructions | CLAUDE.md (or AGENTS.md) | The team | Rules the coding agent reads first: commands, conventions, what to reuse |
| Rules | .claude/rules/*.md | The team, within org rules | Testing (100% coverage of changed code, a negative test per rule), contracts, security |
| Project skills and commands | .claude/skills/, .claude/commands/ | The team | Golden paths such as a contract change; /test-plan drafts tests from the Jira story |
| Organization skills and rules | The org-skills repository, installed in every project | The enablement lead | One story-breakdown skill, one contract-change skill, for everyone |
| PreToolUse hook | .claude/hooks/, wired in settings.json | Team and organization | Runs before each tool call and can block it: secrets, direct OS checks outside the shared module |
| PostToolUse hook | .claude/hooks/, wired in settings.json | Team and organization | Runs after each edit: format, affected tests, changed-line coverage, and tells the agent what failed |
| MCP servers | .mcp.json, from the shared mcp-servers repository | The platform team | Jira, Git, RAG knowledge and catalog access, read-only |
| CI pipeline | .github/workflows/ci.yml, from shared templates | The platform team | The real gate: tests, coverage, contracts and scans block the merge |
The file names are those of one coding agent (Claude Code); other agents have the same layers under other names, see chapter 11. Hooks are controls that help, not proof: a hook nudges and blocks known patterns, and the CI pipeline is what enforces. 100% coverage of changed code is a floor: it shows every line ran in a test, not that the tests check the right thing, so reviewers still read the tests.
The whole ecosystem, not one team's slice
A feature like pushApprove crosses many repositories. The hub connects all of them, so the questions, the drafts and the test cases cover the whole path from the phone to the backend.
| Kind | Repositories in the example | Team |
|---|---|---|
| Login orchestrator | sign-in-methods-service | Identity |
| Backend checks | device-registry-service, sign-in-history-service, sign-in-risk-service | Device, History, Risk |
| Messaging | notification-service | Notification |
| Shared library | device-capability (reused, not rewritten) | Device |
| Shared AI repositories | rag-knowledge, mcp-servers, ai-tools, org-skills, prompt-library | Enablement and platform |
| Clients | ios-app, android-app, web-client | Mobile, Web |
Why a hub: training and work live apart today
In most organizations the training, the documentation and the templates sit in one place and the work sits in another. People switch tools, copy text into a chat, and rebuild the context in their heads each time. That is time, effort and mental load, spent before any real work starts.
| Today | With the hub |
|---|---|
| Training is a course in a separate portal, weeks before the task | The lab or example appears next to the step that needs it |
| Each person pastes context into a chat by hand | The hub already has the context: workflow, contracts, owners |
| Story templates live in a wiki the PO (product owner) must find | The story guide shows the definition of ready while the PO writes |
| Prompts and tips live in personal notes | Skills, slash commands and prompt examples live in the repository, owned and versioned |
| A dependency means a search, a message and a wait | Each dependency's contract, owner and runbook is one link away |
| Nobody sees the whole workflow until the system demo | Every team sees the same picture from day one |
How stories are defined: before AI and with the hub
| Before AI | With the hub | |
|---|---|---|
| How to write it | A story template in a wiki the PO has to find | The story guide (definition of ready) and approved prompts, shown while the PO writes the Jira epic |
| Breaking it down | Refinement meetings split the epic into stories, one team at a time | A story-breakdown skill drafts epic → stories → tasks, with acceptance criteria and test cases, through the Jira MCP server |
| Questions | Each team asks its own, one meeting at a time | Routed to every owner on day one, from the workflow map |
| Context | Each team estimates on its own partial view | Every draft cites the repository, contract and line it came from, with a confidence |
| Learning | A course weeks earlier | The lab on story drafting appears beside the guide, for a first-time PO |
| Decision | Spread across threads | People accept, edit or reject each draft in Jira; the hub never changes a status |
Each role's glossary entry has a short "Stories: before AI and with the hub" section for that role's part. Open Product owner, QA engineer or any role from chapter 6, then its glossary term.
Front door 1: the product owner starts from the epic
The product owner does not learn a new tool first. The Jira epic links to the hub. The hub shows what a ready story needs, asks the open questions of every owner at once, and drafts the requirement, the spec and the per-team items for review.
| Step | What the PO sees | Who decides |
|---|---|---|
| Write | The epic, in the words a stakeholder would use | The PO |
| Guide | The story guide: what is missing for a ready story, with a filled example | The PO |
| Questions | Every open question, routed to its owner on day one | Each owner answers |
| Drafts | Requirement, spec, one item per team with test cases, each with source and confidence | Nobody yet: drafts only |
| Review | Architect, QA (quality assurance), risk and each team lead accept, edit or reject | Each lead, for its own part |
| Ready | Approved stories back in Jira, linked to the spec and decisions | The PO approves the set |
For pushApprove this takes the plan from about 3 sprints of meetings to about 3 days (illustrative). Chapter 8 walks the same plan through every stage.
Front door 2: the developer starts from the repository
The developer starts where the code is. Everything they need travels with the repository, so nothing has to be found, copied or remembered.
| In the repository | What it gives the developer |
|---|---|
| README | What the service does, how to run it, and a link to its page in the hub: its workflow, open items and owners |
| Instructions file | The team's rules, which the coding assistant reads on every task |
| Skills and slash commands | Packaged golden paths, such as a contract change with its contract test |
| Prompt examples | Filled prompts the team already trusts |
| Linked dependencies | Each dependency's contract, owner, runbook and catalog entry, through the hub |
The repository is the front door for engineers, and the hub is the map behind it. Chapter 7 shows how the instructions file, skills and the asset catalog make reuse the default.
Who uses it, and for what
| Role | Comes in through | Gets | Decides |
|---|---|---|---|
| Product owner | The Jira epic | Story guide, routed questions, drafted spec | Approves the plan |
| Developer | The repository README | Team context, skills, linked dependencies | The code, through a reviewed pull request |
| QA engineer | The team's item | Drafted test cases and the end-to-end matrix | Which tests ship |
| Architect | The spec draft | Contract changes and reuse found | The design |
| Risk and security | The plan's risk tier | Controls on every item, early | Whether the controls are enough |
| Enablement lead | The library and metrics | Which skills, prompts and labs are used | What to promote, fix or retire |
The guardrails hold on every path
The hub is itself an AI use case, recorded in the inventory at the medium risk tier: it reads proprietary source, and people review every output. The feature it plans is a separate high-impact change under its own controls, and AI is never in that feature's runtime path.
| Guardrail | How it is enforced |
|---|---|
| Read-only | Its service identity has read scopes only: no merge, no status change, no release |
| No customer data | No production access; a proposal to read production data is blocked at the trust boundary |
| People decide | The author of a draft is never its approver; every decision is saved with its reason |
| Sources and confidence | Every drafted line cites repository, contract and line; below 0.75 it goes to the owner |
| Evaluated | An evaluation set of past features is re-run before any model or prompt change |
How it grows, stage by stage
The hub is not a day-one purchase. It is what the adoption ladder builds toward.
| Stage | What exists | What the hub can do |
|---|---|---|
| 0 Foundations | Inventory, intake, approved tools, enterprise sign-in | Nothing yet: the hub use case goes through intake |
| 1 Personal | People use approved assistants | Nothing shared yet |
| 2 Team context | Instructions files, skills and prompts in each repository; the asset catalog | Answer with team context; the README links start to matter |
| 3 Delegated tasks | Workflow map, repositories and Jira connected through MCP servers | Story guide, routed questions, drafted spec and per-team items |
| 4 Agentic workflow | Approval gates proven at stage 3 | Items to pull requests and contract tests, each behind an approval gate |
| 5 Scale | Shared for every feature | Portfolio view and reuse across features |