01. The plugin that already existed
The ask was simple: a narrow plugin for web, Angular and Nx, reusing the skills and agents other developers publish on GitHub where they are good, and a better spec-to-code pipeline. Before searching anywhere I listed what was already on the machine, and the first finding was embarrassing. The narrow plugin mostly existed. tether-nx had six agents, nine skills, rule ids and five eval cases, extracted from a production workspace. That workspace did not use it. It ran eight local copies of the agents instead, tuned to its tracker and its review bar, and the plugin had never been exercised on its own source repository.
The second finding was that Nx was already covered. The official nx plugin from the Nx team
ships seven skills, workspace exploration, generators, task running, CI monitoring, and was installed at
project scope. Any plugin of mine that described Nx in prose would be duplicating a maintained one.
The third was that the Angular layer was a mix of three sources nobody had written down: Google's
angular-developer skill with forty-one reference files, a SignalStore and a PrimeNG rule set
from a community repository that had since been archived, and my own placement and performance skills,
two of them vendored from another developer under MIT.
Before you build the narrow plugin, check whether you are the person who already built it and switched it off.
02. Three plugins, one job each
The decision was a split, not a new name. One marketplace, three plugins, each answering one question.
| Plugin | Question it answers | Ships |
|---|---|---|
tether | What may the agent never do? | Hooks: a git guard, an MCP write guard, untrusted-input reminders, report and word caps, telemetry, an eval runner. |
tether-nx | How is Angular code written here? | Rules only: library layers, providers, signals, components, SignalStore, PrimeNG, performance, accessibility. Stable rule ids a project overrides in one file. |
tether-web | How does a ticket become a merged pull request? | Ten agents and nine process skills, from investigator to pr-creator, driven by a rules file that names the tracker, the PR host, the preview URL and the verify command. |
tether-web declares tether-nx and the official nx plugin as
dependencies in its manifest, and its agents preload the rules skills by their plugin name. Installing it
pulls the other two in. The rules plugin lost its agents and became a library of conventions; the workflow
plugin became the only place an agent is defined.
The agents got model tiers at the same time. The investigator, spec-writer and planner inherit the session model, so planning runs on whatever the person chose. The two implementers and the correctness reviewer run on Opus. The plan validator, the conventions reviewer, the UI checker and the PR creator run on Sonnet, because checking a table against a list of ids is not where the expensive model earns its price.
03. What we borrowed, and under which licence
A background agent spent nine minutes and a hundred tool calls on GitHub, angular.dev, nx.dev and the Claude Code docs, with one rule: primary sources only, a URL per claim, and the licence of every repository named before it is recommended. The result sorted into three piles.
- Reuse as-is. The official Nx plugin, as a dependency. Google's
angular-developer, linked rather than copied, because its licence is only stated in a frontmatter line. Anthropic'sfrontend-designunder Apache-2.0, for a screen with no design frame. Microsoft'splaywright-cli, Apache-2.0, to drive a browser from a reviewer instead of leaving a click-through under deferred. - Fork and trim. The archived SignalStore and PrimeNG rule tables, now carried as
ng-signalstoreandng-primengwith their MIT notice and our async shape appended. A Playwright best-practices skill, keeping locators, assertions, fixtures and flakiness and dropping the rest. One idea from each of the spec-driven tools, below. - Write ourselves. A Jest and Spectator recipe, because no public skill has real content for that pair. A Tailwind 3 token skill, because every public Tailwind skill targets v4. The Jira and Azure DevOps stages. The verify script.
The Angular CLI's MCP server reads angular.json, which an Nx workspace does not have. A well-known agent collection has breadth and no Angular. Anthropic's web-testing skill is Python. The spec-driven development tools, seven of them, all do what the pipeline here already does, with GitHub where we have Jira and Azure DevOps.
That last line is the useful one. None of spec-kit, superpowers, Pimzino, ccpm, BMAD, agent-os or OpenSpec was worth adopting as a tool. Four of their ideas were worth adopting as changes.
04. Five changes to the workflow
Each change answers a line that appears in our last four run reports, the documents every branch ends with. The reports carry a rulings list and a ledger per agent, so the frictions were already written down; nobody had read them as a to-do list.
| What the run reports said | Change | Borrowed from |
|---|---|---|
| The fix-round cap of two was reached; review found defects the plan already implied. | A read-only plan validator between the planner and the first implementer: every spec decision has a task, every task cites real decision ids, the waves follow from the fields. It ends with Verdict: Dispatch or Verdict: Revise. | Pimzino's spec validator |
| Waves were decided by reading prose; a shared barrel was lifted out by hand each time. | Every plan task carries touches, conflicts_with, spec and checks fields. The dispatcher derives the waves and the shared-file commit from them. | ccpm's task fields |
| The review bar was restated in four places. | One constitution skill with stable CON-n ids, preloaded by the planner, the validator and both reviewers. A project overrides an id in its own file, never silently. | spec-kit's constitution |
| A reviewer claim was later refuted; the ledger already had a column for it. | Every review finding carries an evidence cell, a path and line plus the command or spec that shows it. A finding without evidence is refuted by the dispatcher without discussion. | ours |
| The same follow-ups were re-listed across three pull requests. | A dated follow-ups register the docs-syncing step appends to and the investigator reads at the start of the next ticket in the same area. | OpenSpec's living deltas, scaled down |
Adopt the idea, not the tool. Every spec-driven framework we read is a prompt pack plus a tracker we do not use.
05. Built by the agents it describes
The split was built the way the plugin says work should be built: a spec, then five Opus implementers in parallel on disjoint paths of one working tree, each committing from a pathspec, then two more for the docs and the evals. Fourteen commits, all tests green, the marketplace validator passing.
Three of the five first-wave implementers stopped short and reported Blocked: instead of
committing. That was the harness working.
The repository's frontmatter test rejected any agent that preloads a skill from another plugin. The new workflow agents preload the rules plugin's skills by design. Two implementers wrote their files, ran the suite, saw red, and held the commit, as their brief said to.
The fix went into the checker, not the content: a prefix listed in the plugin manifest's dependencies now resolves against that plugin's skills folder, with a test for the case. The same hour, the neutrality scan flagged @playwright and @ngneat as unknown npm scopes and a hex colour as a ticket number. Public scopes joined the allowlist; the colour changed.
The pattern repeated enough to be the lesson of the day. A check that pushes back on a correct change is not an obstacle to route around; it is the place the repository's assumptions are written down. Each time, the implementer reported the failing line with the file and the reason, and the dispatcher decided whether the check or the change was wrong. In four cases the check was.
The one thing the agents could not do was fetch. The sandbox has no outbound network, so vendoring two
skills verbatim with their licence files waits for a human to run two git clone commands. An
agent that summarises a licence through a fetch tool is not a copy.
06. What is still open
- The dogfood run. One small ticket through
tether-web:*on the workspace the rules came from, compared against the local agents, before those copies are retired. Until then both sets are installed side by side. - The two vendored skills and the
playwright-cliinstall, which need the clones above. - A real run of the two new eval cases. They were checked against hand-written good and bad outputs, which is not the same as a model.
- A release tag. The root README already pins it; cutting it is a decision, not a build step.
The research note, the spec and the run report with its token ledger sit beside the code, dated. The plugin is on GitHub with the changelog that lists what moved and what broke.
Rules in one plugin, workflow in another, guards in a third. When one of them is wrong, you know which file to open.