Spec-Driven Planning Workflow (Inspired by Kiro)

[aligit]

First off, huge thanks for building and maintaining CodeCompanion.nvim – it's hands-down the best AI coding experience in Neovim. The agentic workflows, tools, slash commands, and rules make it incredibly powerful and fun to use!

I wanted to suggest a new optional workflow inspired by Amazon's new Kiro IDE, which emphasizes structured planning before coding. Kiro generates specs (requirements, design, tasks) in a dedicated directory, then lets users "start" individual tasks with agents.

It would be amazing if CodeCompanion could add something similar:

• A new command, e.g. :CodeCompanionSpecInit (or via actions palette)
• Prompts the user for a feature description
• Uses the LLM (ideally Claude, since it's great at structured output) to generate three markdown files in a project-local directory like .codecompanion_spec/ (or configurable):
  • requirements.md
  • design.md
  • tasks.md (with checkbox tasks, dependencies noted)

Then, in any chat:

• Auto-load these files as context if present
• Add slash commands like /spec-task 3 to focus the chat on implementing a specific task (pre-populating the prompt with the task description, design, and requirements)

This would fit perfectly with existing agentic workflows – users could approve diffs per task, keeping everything structured without leaving Neovim.

Here are short examples of what the generated files could look like for a simple feature ("Add dark mode toggle to a Lua config"):

requirements.md

# Requirements

## User Story
As a Neovim user, I want a dark mode toggle so I can switch themes easily.

## Acceptance Criteria
- Toggle command works in normal mode
- Persists across sessions
- No impact on performance

--- 

design.md

# Design

## Approach
- Use Neovim's built-in background option
- Create a Lua function to toggle between 'dark' and 'light'
- Add a keymap for the toggle
- Store preference in a simple file

## Components
- toggle.lua module
- Keybinding in init.lua

---

tasks.md

# Tasks

- [ ] Create toggle function
- [ ] Add keymap <leader>td
- [ ] Implement persistence with vim.fn.stdpath
- [ ] Test in light/dark environments

---

requirements.md

# Requirements Document

## Introduction

Smart Search enables users to describe their property search in natural Persian language instead of following the rigid multi-stage filter flow. The system parses free-form text to extract transaction type (rent/sell), location, area range, and price range, then executes the search directly. This MVP focuses on the most common search patterns in the Iranian real estate market.

## Glossary

- **Smart_Search_Parser**: The component that extracts structured filters from natural language Persian text
- **Transaction_Type**: Either 'sell' (فروش/خرید) or 'rent' (اجاره/رهن)
- **Location**: Neighbourhood, district, city, or village name in Persian
- **Area_Range**: Property size in square meters (متر)
- **Price_Range**: Property price in Toman/Rial, typically expressed in میلیون (million) or میلیارد (billion)
- **Parsed_Filters**: The structured output from Smart_Search_Parser containing extracted search criteria
- **Feedback_Display**: UI element showing users what the system understood from their query

## Requirements

### Requirement 1: Transaction Type Detection

**User Story:** As a user, I want to search for rental properties by typing "اجاره" in my query, so that I don't have to manually toggle the sell/rent switch.

#### Acceptance Criteria

1. WHEN a user query contains rent keywords (اجاره، رهن، کرایه، ماهیانه، ودیعه) THEN the Smart_Search_Parser SHALL set transaction_type to 'rent'
2. WHEN a user query contains sell keywords (خرید، فروش، فروشی) THEN the Smart_Search_Parser SHALL set transaction_type to 'sell'
3. WHEN a user query contains no transaction keywords THEN the Smart_Search_Parser SHALL default transaction_type to 'sell'
4. WHEN both rent and sell keywords appear in query THEN the Smart_Search_Parser SHALL use the first detected keyword to determine transaction_type

[pixlmint]

I think a lot of this could be implemented without requiring changes to be made to CodeCompanion. But what I think would really make this feel first-party is if there were good ways to reference back to previously implemented/ worked on features. So maybe something changes about a requirement. If I could select the chat where that was implemented, and just tell it "there were changes, make sure the updated requirement is met", that'd be great.

There might also be interesting additional features if using memories, like say it's implementing a task that's tangentially related to a different task, it could then easily look up the memories created by the instance that worked on that