Project Feedback Awareness

Purpose

This steering file ensures Kiro is always aware of project-specific feedback and improvement items stored in category-based feedback files.

Feedback System

Location

Project feedback is stored in .ai/projects/{category}/feedback.md with one file per category:

  • .ai/projects/infrastructure/feedback.md - Feedback for infrastructure projects
  • .ai/projects/domain-apis/feedback.md - Feedback for domain API projects
  • .ai/projects/eda/feedback.md - Feedback for EDA projects
  • .ai/projects/market-making/feedback.md - Feedback for market making projects
  • .ai/projects/ai-dev/feedback.md - Feedback for AI dev projects

Format

Each feedback file contains:

  • Current Issues & Improvements Needed: Active problems that need addressing
  • Future Enhancements: Ideas for future improvements
  • Notes: Additional context and observations

Usage Instructions for Kiro

  1. Always check relevant feedback files when working on a project in a specific category
  2. Consider feedback items when making recommendations or changes
  3. Update feedback files when issues are resolved or new ones are discovered
  4. Reference feedback items when they’re relevant to current work

Usage Instructions for Users

  1. Add new feedback by editing the appropriate category feedback file
  2. Update status of existing items as they progress
  3. Move completed items to a “Completed” section or remove them
  4. Use clear, actionable descriptions for better AI understanding

Integration with Specs

When feedback items become substantial enough to warrant formal specification:

  1. Create or update a spec in .ai/projects/{category}/{project-name}/
  2. Reference the spec in the feedback file
  3. Move detailed requirements to the spec document
  4. Keep high-level tracking in the feedback file until it is subsumed by a spec

Example Workflow

  1. User notices an issue: “N8N operator specs should be consolidated”
  2. User adds to .ai/projects/infrastructure/feedback.md
  3. Kiro sees this when working on infrastructure projects and considers it in recommendations
  4. When ready to address, reviews the specs in the infrastructure category for an appropriate spec or proposes a new spec
  5. Update feedback file to reference the new spec
  6. Work through the spec workflow (requirements → design → tasks → implementation)
  7. Once requirements, design and tasks have captured and recorded the feedback, remove it from the feedback file