If you've adopted an OpenSpec-style workflow in your IDE, you already know the appeal: instead of vague tickets, an AI agent writes a proposal, you approve it, the agent implements it, and the change gets archived into a specs folder once it's done. It feels like a huge upgrade over "build this" prompts scattered across Slack threads. But look closely at what's actually happening, and you'll notice it's still just a local file ritual — propose, apply, archive, repeat — scoped to one repo, one branch, one person's editor. That's a real improvement over no spec discipline at all. It's not, however, a system for how teams actually ship software together.
The Local Skills Ceiling
Local IDE skills give an agent a folder convention and a few slash commands. A propose step drops a markdown file into a changes/ directory. An apply step checks off tasks. An archive step moves files around and merges them into a canonical spec tree. It's clever, but it's fundamentally client-only: there's no backend, no shared database, no notion of "who else is touching this." The moment two people work on related changes, or a reviewer wants to weigh in before code exists, the file-folder metaphor runs out of road. Git history becomes your only source of truth, and coordination happens the old-fashioned way — in chat, in your head, or not at all. And because it's scoped to a single repo, anything that spans multiple services or codebases has to be coordinated by hand across separate folders that don't know about each other.
Real Collaboration, Not Just Local Files
Intent treats a spec as a living, shared object, not a file you email around:
- Comments and @mentions live directly on the changeset, with real-time notifications when someone tags you.
- Specs are versioned artifacts, editable in place, with full diff history — so "editing a change" means creating a new version, never silently overwriting the past.
- Multiple people can work the same changeset at once, with updates — comments, status moves, new PRs — streamed live to everyone's open tab via a real-time sync layer, no manual refresh required.
- Planning is a first-class, shared step. A dedicated planning mode lets the team draft and agree on a structured implementation plan before a single line of code is written — turning "let's just start coding and see" into an actual conversation.
- A pre-flight team-readiness check runs automatically the moment someone clicks "Start Work": it checks for formal blockers, AI-surfaced scope overlaps with other in-progress work, and any open todos that are true prerequisites — flagging risk before branches and PRs even exist.
None of that is possible when the "system" is a folder in your working tree.
Multi-Repo, Natively
Real features rarely live in one repository. A single changeset in Intent can link multiple repositories at once, and the implementation plan is structured per repo, so everyone agrees upfront on what changes where. When work starts, Intent opens a branch and a draft PR in each linked repo automatically, keeps specs synced to all of them as the plan evolves, and only marks the changeset complete once every linked PR across every repo has merged. Local, file-based skills treat cross-repo work as a manual side quest; Intent treats it as the default case.
Real Delivery Management, Not Just Task Lists
Local skills track whether tasks are checked off. Intent tracks whether delivery is on track:
- Changesets carry real statuses (draft, backlog, next, in progress, completed, cancelled), effort estimates, and formal blocker relationships.
- Throughput-based forecasts compute realistic delivery dates per team, chaining queued work automatically as priorities shift.
- Changesets auto-complete when their linked PRs merge (and open todos are resolved) — no one has to remember to close the ticket, even when "the PRs" span several repos.
Specs That Stay Current, Not Just Synced-On-Demand
Rather than waiting for someone to run an "apply" or "archive" command, Intent keeps specs current in the background: automatic semantic re-versioning finds the right spec lineage to update as work evolves, scheduled sync jobs push edited specs back into every open branch within minutes, and overlap checks run org-wide — across all your repos, not just files sitting in one local working tree.
The IDE Plugin Still Matters — As a Bridge
None of this makes the IDE irrelevant. Intent's IDE plugin is genuinely useful — it brings changeset context, status, and verification right into your editor. But it's a bridge to a live backend, not the whole system: it fetches real data, delegates spec edits back to the server so versioning and structure rules stay centralized, and leaves persistence, orchestration, and team-wide state where they belong.
Conclusion
Local skills solved a real problem: giving agents structure instead of vibes. But structure without a shared, living backend is still just a better-organized filing cabinet — one that assumes a single repo, a single branch, a single person. Intent keeps that structure, then adds what teams actually need: collaboration, native multi-repo delivery, and specs that stay true — so the plan you agreed on together is the one that ships, wherever the code actually lives.