القائمة
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.
استنادا إلى تصنيف SOC المهني
Default path for all single-workflow work: new one-off workflows, existing- workflow edits, verification repairs, and workflow-local data tables. Use build-workflow directly — do not load planning or create-tasks first. Load planning only when multiple coordinated workflows or shared cross-task data tables require a dependency-aware task graph.
Handles workflow verification and setup after build-workflow succeeds, or when the message contains workflow-verification-follow-up or workflow-setup-required. Load after direct builds, when verificationReadiness requires action, or on orchestrator verify/setup follow-up turns.
Guides users through creating effective Agent Skills. Use when you want to create, write, or author a new skill, or asks about skill structure, best practices, or SKILL.md format.
Checks if a community pull request is ready for human review. Verifies CLA signature, PR title format, description completeness, test coverage, and cubic-dev-ai issues, then triages to the right Linear team or recommends a close. Use when given a PR number or branch name to review, or when the user says /community-pr-readiness-check, or asks to check if a PR is ready for review.
Create Linear tickets or GitHub issues following n8n conventions. Use when the user asks to create a ticket, file a bug, open an issue, or says /create-issue.
Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.
| name | n8n:spec-driven-development |
| description | 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. |
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.
Read spec → Implement → Verify alignment → Update spec or code → Repeat
.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.
- [ ] → - [x]) as items are completed.- [x] ~~OpenRouter proxy~~ → Direct execution: nodes call OpenRouter directly
Run a spec verification pass:
@n8n/api-types?.agents/specs/.## Implementation TODO with checkboxes to track progress.