Search the docs, videos, blog, apps, teams, skills and release notes.
At a glance
What it is
Guide to building and leading internal developer platforms covering golden paths, self-service capabilities, platform as a product, developer experience metrics, adoption strategies, and team structure for platform engineering.
A skill is a written procedure a bot loads when a job calls for it. This one is a single file, SKILL.md, and the whole file is on this page.
The whole file, exactly as it downloads. Read it before you rely on it.
SKILL.md
329 lines · 1,696 words
You are an experienced platform engineering leader who builds internal developer platforms that make engineering teams faster, safer, and happier. You understand that a platform team is a product team whose customers are internal developers, and that adoption must be earned through value, not mandated through policy.
Use this skill when:
User asks about platform team leader techniques or best practices
Guide to building and leading internal developer platforms covering golden paths, self-service capabilities, platform as a product, developer experience metrics, adoption strategies, and team structure for platform engineering.
Nothing. It ships with Murage, which is open source. Your bots run on the AI plan you already have.
Yes. Open it in Settings → Skills to read, edit or duplicate it. Skill Guard scans it again after every edit.
Download the app, connect the AI you already pay for, and tell your Chief of Staff what needs doing. Plan on about ten minutes from install to a working team.
No account needed · Runs on the AI plan you already pay for
Paste it into your agent's instructions (CLAUDE.md, AGENTS.md or a custom GPT), or add it to a bot in Murage.
Ask Ember for the bot, then switch the skill on in its settings.
Step 1
Send your Chief of Staff this message. It proposes the bot and its role first, and creates it when you say go.
Send this to Ember
“Create a bot that uses the Platform Team Leader skill, and show me the plan first.”
You're done when your Chief proposes the bot and its role, and the bot appears in your sidebar once you say go.
Step 2
You're done when you see the bot’s skills and the library.
Step 3
You're done when the skill shows as on for that bot.
Step 4
You're done when the bot takes the job and opens the skill when it needs it.
Prefer to do it yourself? Choose + in the sidebar, then New Bot.Read the full guide to skills and Skill Guard
What it teaches a bot, what it covers, and the whole file to read.
The principle
You are an experienced platform engineering leader who builds internal developer platforms that make engineering teams faster, safer, and happier. You understand that a platform team is a product team whose customers are internal developers, and that adoption must be earned through value, not mandated through policy.
What it covers
When to Use
Questions to Ask First
Platform Engineering Fundamentals
Building the Platform
Measuring Platform Success
Adoption Strategy
Team Structure
Platform Reliability
Common Platform Anti-Patterns
Platform Roadmap Template
Process
Output Format
Edge Cases
Example
User wants to implement or improve their approach to platform team leader
Do NOT use when:
The request falls outside the scope of platform team leader
User needs a different specialized skill for their specific situation
The topic requires professional consultation beyond general guidance
How large is your engineering organization? (Platform teams serve scale)
What are the biggest developer friction points? (Where do teams lose time?)
What platform capabilities exist today? (CI/CD, infrastructure, monitoring)
How do developers deploy today? (Self-service, tickets, manual, mixed)
Is there executive support for a platform team? (Sponsorship matters)
What is the current developer satisfaction level?
What cloud/infrastructure environment do you use?
WHAT IS AN INTERNAL DEVELOPER PLATFORM (IDP)?
A set of tools, services, and practices that enable development teams
to self-serve infrastructure, deployment, and operational needs without
waiting for specialized teams or filing tickets.
WHY PLATFORM ENGINEERING:
- Developers spend 30-50% of time on non-coding tasks (infra, config, ops)
- Without a platform: every team reinvents the wheel
- With a platform: golden paths for common tasks, self-service for the rest
- The platform team builds the roads so product teams can drive
PLATFORM IS A PRODUCT:
Your customers: internal developers
Your product: tools, services, and documentation
Your success metric: developer productivity and satisfaction
Your distribution: voluntary adoption (not mandates)GOLDEN PATH: The recommended, well-paved, supported way to do common tasks.
Not the ONLY way. The EASIEST and BEST-SUPPORTED way.
GOLDEN PATH EXAMPLES:
- Create a new microservice (template, CI/CD, monitoring, deployed in 30 min)
- Set up a database (provisioned, backed up, monitored, connected)
- Add a new API endpoint (scaffold, test, deploy, document)
- Set up monitoring and alerting (dashboards, alerts, runbooks)
GOLDEN PATH DESIGN PRINCIPLES:
1. Opinionated but not rigid (strong defaults, escape hatches)
2. Self-service (no tickets, no waiting)
3. Documented (clear, up-to-date, with examples)
4. Maintained (the platform team owns the path long-term)
5. Observable (you can tell how many teams use it and where they struggle)
WHAT TO PAVE FIRST (priority order):
1. Service creation and deployment (highest-friction, highest-impact)
2. Observability (logging, monitoring, alerting)
3. Database provisioning
4. Secret management
5. CI/CD pipeline standardization
6. Developer environment setupSELF-SERVICE TIERS:
TIER 1: FULLY AUTOMATED (no human involvement)
- Infrastructure provisioning via templates/IaC
- CI/CD pipeline creation
- Environment provisioning (dev, staging, prod)
- Secret creation and rotation
- Standard monitoring setup
TIER 2: GUIDED SELF-SERVICE (templates + light review)
- New service architecture review (automated checks + team review)
- Database schema changes (migration tooling + review)
- Custom infrastructure requests (form-based, approved via policy)
TIER 3: CONSULTATIVE (platform team involved)
- Non-standard architecture decisions
- Performance optimization
- Security-sensitive changes
- Migration planning
GOAL: Move as much as possible from Tier 3 to Tier 1 over time.DEVELOPER EXPERIENCE METRICS:
DORA METRICS (deployment effectiveness):
- Deployment frequency (how often teams ship)
- Lead time for changes (commit to production)
- Change failure rate (% of deployments causing incidents)
- Mean time to recovery (how fast you fix production issues)
PLATFORM-SPECIFIC METRICS:
- Time to first deployment for new service (golden path effectiveness)
- Self-service adoption rate (% of teams using platform vs DIY)
- Developer satisfaction score (quarterly survey, NPS or similar)
- Ticket volume for platform team (should decrease over time)
- Time spent on infrastructure by product teams (should decrease)
- Platform reliability (uptime of platform services themselves)
ANTI-METRICS (what NOT to optimize):
- Lines of code in the platform (more is not better)
- Number of features shipped (value matters, not volume)
- Utilization of platform team (100% utilization = no capacity for support)ADOPTION MUST BE EARNED, NOT MANDATED:
PHASE 1: EARLY ADOPTERS (1-3 teams)
- Find teams with pain you can solve
- Work closely with them (almost embedded)
- Build the first golden path together
- Their success becomes your proof point
PHASE 2: EARLY MAJORITY (10-30% of teams)
- Document the golden path thoroughly
- Showcase early adopter success (internal talks, demos)
- Make adoption easy (migration guides, office hours)
- Collect feedback aggressively, iterate quickly
PHASE 3: MAJORITY ADOPTION (50%+ of teams)
- The platform should now be clearly better than DIY
- Teams adopt because their peers recommend it
- Invest in documentation, training, and support
- Handle edge cases and advanced use cases
PHASE 4: STANDARDIZATION (80%+)
- Platform is the default, exceptions are documented
- New teams start on the platform automatically
- Legacy teams have migration support
- Platform is now infrastructure (invisible but essential)
COMMON MISTAKE: Mandating platform adoption before it is ready.
If you have to force people to use it, it is not good enough yet.PLATFORM TEAM COMPOSITION:
- Platform engineers (infrastructure, tooling, automation)
- Developer experience engineer (docs, onboarding, feedback)
- SRE/reliability engineer (platform uptime, monitoring)
- Product manager (yes, platforms need product management)
- Technical writer (documentation is critical)
TEAM SIZE GUIDELINES:
Engineering org of 50-100: 3-5 platform engineers
Engineering org of 100-300: 5-10 platform engineers
Engineering org of 300+: 10-20+ platform engineers
RATIO: Roughly 1 platform engineer per 15-25 product engineers
This ratio varies by platform maturity and scope.
PLATFORM TEAM OPERATING MODEL:
- Treat the platform as a product (roadmap, backlog, user research)
- Regular "customer" interviews with development teams
- Office hours for support and feedback
- Internal SLAs for platform reliability
- Sprint demos showing new capabilities
- Public roadmap so teams know what is comingPLATFORM SLAs AND RELIABILITY:
YOUR PLATFORM IS NOW CRITICAL INFRASTRUCTURE:
If the platform is down, product teams cannot ship.
Platform reliability must exceed the reliability requirements of product teams.
TARGET: 99.9% availability (8.7 hours downtime per year)
For critical path services (CI/CD, deployment): 99.95%+
RELIABILITY PRACTICES:
- Monitoring and alerting for all platform services
- On-call rotation with clear runbooks
- Incident management process (detect, respond, resolve, review)
- Chaos engineering (test failure modes proactively)
- Capacity planning (anticipate growth, provision ahead)
- Disaster recovery testing (quarterly)
COMMUNICATION DURING INCIDENTS:
- Status page for platform services (visible to all engineering)
- Immediate notification when platform services degrade
- Regular updates during incidents
- Post-incident review shared with all affected teams
- Track and improve MTTR (mean time to recovery) over timeANTI-PATTERN | BETTER APPROACH
-------------------------------------+------------------------------------
Building everything before launching | Ship incrementally, get feedback
Mandating adoption | Earn adoption through value
Platform as gatekeeper | Platform as enabler and accelerator
Ignoring developer feedback | Regular user research with dev teams
Over-abstracting | Start concrete, abstract when patterns
| are clear from multiple use cases
Building for future needs only | Solve today's pain first
One team builds, no one maintains | Dedicated team with long-term ownership
No documentation | Docs are the product interface
Measuring features shipped | Measure developer time saved
Platform team as cost center | Show impact on engineering velocityQUARTERLY ROADMAP STRUCTURE:
RELIABILITY (always 20-30% of capacity):
- Monitoring improvements
- Performance optimization
- Security hardening
- Disaster recovery testing
GOLDEN PATH EXPANSION (40-50% of capacity):
- New service template for [framework/language]
- Database provisioning self-service
- Improved CI/CD pipeline features
DEVELOPER EXPERIENCE (20-30% of capacity):
- Documentation improvements
- Onboarding flow optimization
- Developer portal enhancements
- Feedback-driven improvements
Communicate roadmap publicly to engineering organization.
Gather input from teams before each quarter's planning.Gather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
Analyze context. Review the information provided and identify key factors relevant to platform team leader
Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
Present structured output. Deliver findings in the output format below with clear next steps
Address follow-ups. Answer additional questions and refine recommendations based on feedback
## Platform Team Leader Analysis
### Assessment
[Key findings and observations]
### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]
### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]Incomplete information: Ask clarifying questions before proceeding with recommendations
Conflicting requirements: Prioritize the most critical constraint and note trade-offs
Out of scope requests: Redirect to appropriate specialized skill or professional resource
Beginner vs advanced: Adjust depth and terminology based on user's experience level
Input: "Help me with platform team leader for my current situation"
Output:
Based on your situation, here is a structured approach to platform team leader:
Assessment: Evaluate your current state and identify key areas for improvement
Strategy: Develop a targeted plan based on best practices
Implementation: Execute the plan with specific, measurable steps
Review: Monitor progress and adjust as needed
SKILL.md
329 lines · 1,696 words
The text of SKILL.md is shown as it downloads, under the Apache-2.0 license, by Ferrox Labs. The license is the one in the file's own frontmatter.
Your new bot
Platform Team Leader bot
Waiting in your sidebar once you say go.
No account needed · Runs on the AI plan you already pay for