Linked-Intent Development plugin
Claude Code plugins for design-first work: designs, EARS requirements, tests, then code, plus spec-to-code tracking
- 118 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- The plugin creates documents in docs/ and appends directives to the project's CLAUDE.md
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add plugins/linked-intent-developmentDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The plugin creates documents in docs/ and appends directives to the project's CLAUDE.md
This is third-party code. Review the repository files before installing.
What it does
Linked-Intent Development, or LID, is a design-before-code methodology for agents. The `linked-intent-dev` plugin drives work in order: an overall design, detailed component designs, EARS requirements with IDs such as `AUTH-UI-001`, tests, then code. At each step the agent asks questions, offers two or three trade-off options and waits for approval. Tests and code cite the IDs through `@spec` annotations, so alignment with the intent can be checked mechanically. The second plugin, `arrow-maintenance`, keeps an index in `docs/arrows/` and watches that requirements and code do not drift in projects too large for one context. The optional `lid-experimental` adds a `bidirectional-differential` skill: two fresh Claude sessions reconstruct code from the requirements and requirements from stripped code to surface unstated intent. The `/linked-intent-dev` command creates `docs/high-level-design.md` and a `docs/intent/` directory and appends LID directives to `CLAUDE.md`. For Cursor, Windsurf, Codex and other agents there is a rule file pointing at `AGENTS.md`.
Who it is for. Teams that maintain a product with agents for years and want design documents to stay the source of truth rather than a draft.
Good fit when
- A new project starts with an overall design and components, and code comes only after requirements and tests
- A large repository does not fit in context and needs an index tying requirements to code
- In an existing project you want to recover intent documents from code and close gaps gradually
- You want to verify code does exactly what the EARS requirements state through `@spec` references
Not a fit when
- You need a quick weekend prototype: the method demands discipline and careful design review before code
- You need specialised agents, security reviews and CI guards: LID is deliberately simpler, two plugins and templates
- The task is small and mechanical, such as a rename: a six-phase cycle is overkill
Example request
Run /linked-intent-dev, then propose 2 to 3 options for an overall design of a notification service.Limitations
The method demands discipline: designs are reviewed carefully, intent gaps are closed step by step and design phases are not skipped. The author contrasts LID with other spec-driven systems and says documents here stay the source of truth for the life of the project, while code and tests are regenerated from them. That means a continuing time cost in review. The experimental plugin is separate and may be retired or promoted. For other tools support comes through a rule file, not the automatic gates of Claude Code.
How to disable. Remove the plugins through /plugin. The docs/high-level-design.md, docs/intent and docs/arrows directories and the LID directives in CLAUDE.md stay in the project, so delete them by hand if no longer needed.
FAQ
How do I install LID in Claude Code?
Run `/plugin marketplace add jszmajda/lid`, then `/plugin install linked-intent-dev@jszmajda-lid` and `/plugin install arrow-maintenance@jszmajda-lid`. The "project" scope shares it with a team. After installing run `/linked-intent-dev`.
What is EARS?
A requirements format where each one is testable and carries an ID such as `AUTH-UI-001`. Tests and code cite the ID with an `@spec` annotation so any behavior traces back to a requirement.
How is LID different from other spec-driven systems?
Most optimise for the next change, while LID optimises for the project over time: documents stay the source of truth and the spec wins on disagreement. It has two plugins and a few templates instead of specialised agents.
What does arrow-maintenance do?
Keeps a `docs/arrows/` index and checks that requirements and code stay coherent in projects too large for one context. It suits large repositories that need a map of correspondences.
Can I use LID in Cursor or Codex?
Yes. Drop a small rule file into the project that points the agent at `AGENTS.md`. Snippets for Cursor, Windsurf, Copilot, Aider, Continue, Junie, Codex and Zed are in the project docs.
Discussion
No questions or reviews yet.
Related
PluginsThe AI-SDLC plugin for Claude Code carries a task from spec to PR: a readiness gate, a developer agent and several reviewers.
Nine plugins for Claude Code with 51 skills and 2 agents: a single workflow from a rough idea to a reviewed pull request.
A Claude Code plugin that generates and maintains CLAUDE.md: a 0 to 100 quality score, a 150-line cap and stale reference checks
ADLC Harness takes a task from intent to PR with one command, and the human approves only four key gates.
Skill and plugin for Codex and Claude Code: the agent drives a project through a plan-to-maintain loop with human gates.
ADLC is a set of dependency-free CLIs and agent plugins: gates at each development phase against typical model failure modes.
README in short
The README explains the method: agree on what to build before how. It then contrasts LID with other spec-driven systems, lists two core plugins and one experimental one, gives Claude Code installation, scenarios for new and existing projects, six work phases and an example project that uses LID on itself.