N8n:spec Driven Development Agent Skill
Keeps implementation and specs in sync. Use when working on a feature that has a spec in .agents/specs/, when the user says /spec, or when starting implementation of a documented feature. Also use when the user asks to verify implementation against a spec or update a spec after changes.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/n8n-io/n8n --skill n8n:spec-driven-developmentThe instruction itself
7 sections, as written by the authorSpec-Driven Development
Specs live in .agents/specs/. They are the source of truth for architectural
decisions, API contracts, and implementation scope. Implementation and specs
must stay in sync — neither leads exclusively.
Core Loop
Read spec → Implement → Verify alignment → Update spec or code → Repeat
Before Starting Work
- Find the spec. Search
.agents/specs/for files matching the feature:
ls .agents/specs/
- Read the full spec. Understand scope, decisions, API contracts, and
open questions before writing code.
- If no spec exists and the task is non-trivial (new module, new API,
architectural change), ask the user whether to create one first.
During Implementation
- Reference spec decisions — don't re-decide what the spec already settled.
- When you diverge from the spec (better approach found, user requested
change, constraint discovered), update the spec immediately in the same
session. Don't leave spec and code out of sync.
- Tick off TODO checkboxes (
- [ ]→- [x]) as items are completed. - Strike through or annotate items that were deliberately skipped or
replaced, with a brief reason:
- [x] ~~OpenRouter proxy~~ → Direct execution: nodes call OpenRouter directly
After Completing Work
Run a spec verification pass:
- Re-read the spec alongside the implementation.
- Check each section:
- Do API endpoints in spec match the controller?
- Do config/env vars in spec match the config class?
- Does the module structure in spec match the actual file tree?
- Do type definitions in spec match
@n8n/api-types? - Are all TODO items correctly checked/unchecked?
- Update the spec for any drift found. Common drift:
- New files added that aren't listed in the structure section
- API response shapes changed during implementation
- Config defaults adjusted
- Architectural decisions refined
- Flag unresolved gaps to the user — things the spec promises but
implementation doesn't deliver yet (acceptable for MVP, but should be noted).
Spec File Conventions
- One or more markdown files per feature in
.agents/specs/. - Keep specs concise. Use tables for mappings, code blocks for shapes.
- Use
## Implementation TODOwith checkboxes to track progress. - Split into multiple files when it helps (e.g. separate backend/frontend),
but don't enforce a rigid naming scheme.
When the User Asks to "Self-Review" or "Verify Against Spec"
- Read all relevant specs.
- Read all implementation files.
- Produce a structured comparison:
- Aligned: items where spec and code match
- Drift: items where they diverge (fix immediately)
- Gaps: spec items not yet implemented (note as future work)
- Fix drift, update specs, report gaps to the user.
Other skills for the same job
different authors, same section of the catalogue
This skill should be used when the user asks about "plugin settings", "store plugin configuration", "user-configurable plugin", ".local.md files", "plugin state files", "read YAML frontmatter", "per-project plugin settings", or wants to make plugin behavior configurable. Documents the .claude/plugin-name.local.md pattern for storing plugin-specific configuration with YAML frontmatter and markdown content.
-Automatically convert documentation websites, GitHub repositories, and PDFs into Claude AI skills in minutes.
This skill should be used when the user asks about "plugin settings", "store plugin configuration", "user-configurable plugin", ".local.md files", "plugin state files", "read YAML frontmatter", "per-project plugin settings", or wants to make plugin behavior configurable. Documents the .claude/plugin-name.local.md pattern for storing plugin-specific configuration with YAML frontmatter and markdown content.
Standardize how an AI-collaboration project turns work into reusable knowledge. Use when initializing or retrofitting Project Cairn in a project, recording progress after meaningful work, maintaining AGENTS/CLAUDE/cairn docs, auditing project knowledge for drift or missing records, pulling and citing external knowledge, or graduating validated project experience into a reusable knowledge base.
Persistent memory and context management for AI agents using OpenContext. Keep context across sessions/repos/dates, store conclusions, and provide document search workflows.
> PARA method knowledge management for Obsidian vaults. Use this skill whenever the user wants to organize notes using PARA (Projects, Areas, Resources, Archive), classify a note into a PARA category, route a note to the right vault folder, normalize frontmatter fields, run a PARA hygiene review, suggest archiving, audit vault structure, or process new knowledge inputs into an existing PARA-based vault. Also trigger when the user mentions inbox processing, vault cleanup, note classification, PARA review, or asks "where does this note belong?". Works with existing Obsidian skills (obsidian-markdown, obsidian-cli) — never replaces them.
Build and query AI-powered knowledge bases from claude-mem observations. Use when users want to create focused "brains" from their observation history, ask questions about past work patterns, or compile expertise on specific topics.
(builtin) Initialize hierarchical AGENTS.md knowledge base
How to use it
Take n8n-io/n8n:spec-driven-development from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.