What's next: your roadmap

From backlog to roadmap

One choice closes the course: the next quarter, picked deliberately - a published roadmap of three to five builds, each with a builder, a reviewer, and a date. You have a backlog of chores and a team that can build. The last move of the course is choosing the quarter deliberately instead of grabbing whatever is loudest. Score every backlog entry on two axes: hours returned per month, and confidence it can be built with the rungs of the Ladder you already climb - skill, connection, schedule, verification.

1. Score the backlog as a team - thirty minutes, in the weekly meeting slot.
2. Pick three to five for the quarter. High return, high confidence first - momentum is a feature, and a shipped medium win beats a stalled big one.
3. Assign each a builder and a reviewer from the ownership map, with a target ship-and-share date.
4. Anything scored high-return but low-confidence goes on the second list: the build-vs-bring-us-in decision below.
5. Re-score quarterly. The backlog is alive; the roadmap is just its current top slice.

Build in-house or bring us in

The honest heuristic, the same one we give clients:

• Install it - check the library first. When the chore is generic (a PDF filler, a CSV cleaner, a commit-message writer), someone has probably already built the skill: SkillsMP (skillsmp.com) indexes 3,000,000+ open-source skills as of September 2026, Anthropic's anthropics/skills repo carries the document skills, and the official and community plugin marketplaces carry bundles. An index that size is mostly noise. Read the full SKILL.md and any scripts before installing - it is code you didn't write, and it will sit next to your API keys - then adapt it to your conventions and ship it through your team marketplace. An afternoon, not a roadmap slot.
• Build in-house when it looks like the course: a skill plus a connection plus a schedule, the patterns you have shipped five times, failure means a missed report rather than a damaged relationship.
• Bring in help when it is multi-system orchestration with many failure modes, customer-facing output at scale where errors compound, real engineering surface (databases, queues, custom integrations beyond API-call territory), or simply worth more shipped this month than next quarter.
• The middle path is usually best value: we build the hard core into your repo, your team owns and extends it - which works precisely because your team now speaks the system. Everything we ship lands in your repo, in the same files-and-skills architecture you have been working in for twelve weeks. You own it either way.

The exit inventory: what you own now

Before looking forward, take stock of what exists - because all of it is yours, in your repos, in open formats, with no dependency on us or on any single vendor's UI surviving:

• A workspace and company brain that any agent - and any new hire - can navigate.
• A skills library: your SOPs, encoded, versioned, owned, and reviewed.
• Scheduled automations with logs, guardrails, and known per-run costs.
• Governance as configuration: managed settings, deny rules, sandbox, audit habits.
• A team where building automations is a normal Tuesday activity, with a cadence that keeps it so.

Staying current without chasing every release

Claude Code ships fast. This course was written in June 2026 and refreshed in September 2026; between those dates the default model changed on every plan, auto mode became the starting mode, and a promised billing change was paused the day it was due. Parts of it will age again. The team needs a current-awareness habit, not a panic habit:

• One person (rotating is fine) skims the release notes monthly and brings anything relevant to ship-and-share. One sentence per item is plenty.
• When a new feature might replace something you built, test it in one project before migrating everything. Your assets are files in git; migration is an edit, not a rewrite.
• Keep auto-updates on (the native installer's default) so security fixes and improvements arrive without ceremony - your managed version floor from week eleven backstops the laggards.
• When the default model changes, run /doctor prompt-audit: it audits CLAUDE.md, skills, and agents for prompting written for older models. Then re-run each pinned skill's cost check, because a new model can write very different token counts.
• Watch retirement dates on anything you pinned. Haiku 4.5 is the only current Haiku and its floor is "not sooner than October 15, 2026". Aliases move with the lineup; hardcoded model IDs break.

And that is the course. You came in twelve weeks ago to learn a tool. You are leaving with a system: a brain, a skills library, scheduled automations, governance, a cadence, and a team that ships. Keep the meeting alive, keep the logs honest, and keep building.

Do this now

Sources and further reading

• SkillsMP - the install-it option, 3,000,000+ open-source skills (Sept 2026)
• Anthropic skills repo
• Agent Skills - the open standard
• Claude Code documentation
• Monitoring usage and costs