// Create structured plan documents and track work items using YAML frontmatter. Use when the user wants to plan a feature, track progress, log bugs/tasks/ideas, or organize project work.
Help the user file a bug report or feature request for Nimbalyst. Activates when the user opens the in-app feedback flow or runs /feedback:bug-report or /feedback:feature-request. Coordinates evidence gathering, anonymization, and posting to GitHub Issues.
Create diagrams and visual drawings using Excalidraw (.excalidraw files). Use when the user wants flowcharts, architecture diagrams, system diagrams, sketches, or any visual diagram. For database schemas and entity relationship diagrams, use the DataModelLM extension instead.
Create git commits using Nimbalyst's interactive commit proposal widget. ONLY use when the user explicitly clicks "Commit with AI" button or asks for "smart commit". For regular commit requests, use standard git commands instead.
Build, install, and hot-reload Nimbalyst extensions using MCP tools. Use when developing, testing, or iterating on Nimbalyst extensions.
Create visual data models for database schemas using Nimbalyst's DataModelLM editor. Use when the user wants to design a data model, database schema, entity relationship diagram, or Prisma schema.
Create visual UX mockups using HTML/CSS files (.mockup.html). Use when the user wants to design UI, wireframes, visual layouts, or plan features visually.
| name | planning |
| description | Create structured plan documents and track work items using YAML frontmatter. Use when the user wants to plan a feature, track progress, log bugs/tasks/ideas, or organize project work. |
Nimbalyst uses structured markdown documents with YAML frontmatter for planning and tracking work.
Plans live in nimbalyst-local/plans/ with YAML frontmatter:
---
planStatus:
planId: plan-[unique-identifier]
title: [Plan Title]
status: draft
planType: feature
priority: medium
owner: [owner-name]
stakeholders: []
tags: []
created: "YYYY-MM-DD"
updated: "YYYY-MM-DDTHH:MM:SS.sssZ"
progress: 0
---
draft: Initial planning phaseready-for-development: Approved and ready to startin-development: Currently being worked onin-review: Implementation complete, pending reviewcompleted: Successfully completedrejected: Plan has been rejectedblocked: Progress blocked by dependenciesfeature: New feature developmentbug-fix: Bug fix or issue resolutionrefactor: Code refactoring/improvementsystem-design: Architecture/design workresearch: Research/investigation taskinitiative: Large multi-feature effortimprovement: Enhancement to existing featureTrack bugs, tasks, ideas, and other items in nimbalyst-local/tracker/:
- [Brief description] #[type][id:[idPrefix]_[ulid] status:[default-status] priority:medium created:YYYY-MM-DD]
Before creating any tracker item, always check .nimbalyst/trackers/*.yaml in the workspace root for custom tracker type definitions. Each YAML file defines a tracker type with:
type: The type name used in #[type][...] syntax (e.g., devblog-post)idPrefix: The prefix for generated IDs (e.g., dev produces dev_abc123)fields: Available fields including status options with custom valuessync: Whether items sync to the team (shared/local/hybrid)Always use the exact type name from the YAML when creating items. Do not substitute a built-in type when a custom type matches the user's intent.
#bug, prefix: bug)#task, prefix: tsk)#idea, prefix: id)#decision, prefix: dec)#plan, prefix: pln)Defined in .nimbalyst/trackers/*.yaml. Examples:
#feature-request, prefix: feat)#tech-debt, prefix: debt)#devblog-post, prefix: dev)nimbalyst-local/plans/[descriptive-name].md (kebab-case)nimbalyst-local/tracker/[type]s.md (pluralize the type name).nimbalyst/trackers/ for custom types before using built-in types