feat: add project management instructions and update Kanban prompts for task handling

LLM_PROJECT_RULES.md

@@ -0,0 +1,56 @@
+# 🤖 LLM Project Management Instructions
+
+> **Notice to the AI Assistant:** This repository uses a simulated Kanban project board driven entirely by **GitHub Issues, Labels, and Milestones** via standard GitHub MCP tools. Read this document to understand the workflow rules before creating, updating, or listing tasks.
+
+---
+
+## 🏷️ 1. Kanban Board Columns (Labels)
+We use `status:` labels to act as our Kanban columns. When "moving" a task across the board, **always remove the old status label** and apply the new one. 
+
+*   `status: backlog` — Ideas, long-term roadmaps, or unprioritized bugs.
+*   `status: todo` — Selected for immediate next steps.
+*   `status: in-progress` — What I am actively working on right now.
+*   `status: blocked` — Stuck waiting on something else.
+*   `status: in-review` — Code written, waiting for self-review or PR merge.
+*   `status: done` — Fully completed. *(Note: Issues with this label should also be Closed).*
+
+### Optional Metadata Labels
+*   **Priority:** `priority: high`, `priority: medium`, `priority: low`
+*   **Type:** `type: feature`, `type: bug`, `type: refactor`, `type: chore`
+
+---
+
+## 🗓️ 2. Milestones (Sprints / Epics)
+*   Group issues into **Milestones** for major feature sets or time-boxed sprints (e.g., `v1.0-mvp`, `Sprint 3`).
+*   Always check for an existing milestone before assigning it. If a requested milestone doesn't exist, create it.
+
+---
+
+## 🛠️ 3. AI Execution Protocols
+
+### Protocol A: Generating the "Board View"
+When asked to "show the board," "give a status update," or asked "what's next?", you must:
+1. List or search all open issues in the repository.
+2. Group the discovered issues by their `status:` label.
+3. Print a clean, text-based Kanban overview for the user. 
+4. Highlight any items marked `priority: high` or `status: blocked`.
+
+### Protocol B: Task Creation
+When the user asks you to create a task or log a bug:
+1. Write a clear, concise issue title and a markdown description (with acceptance criteria if applicable).
+2. Apply `status: todo` (or `status: backlog` if specified).
+3. Apply relevant priority and type labels based on the context of the conversation.
+
+### Protocol C: Moving Tasks
+When the user says a task is active, done, or blocked:
+1. Find the target issue.
+2. Strip the old `status:` label.
+3. Apply the new accurate `status:` label.
+4. If the new status is `status: done`, close the issue.
+
+---
+
+## 📝 4. Quick-Start Prompts for the User
+*   *"Read LLM_PROJECT_RULES.md and print out our current Kanban board overview."*
+*   *"Based on our conversation about the database migration bug, create a new high-priority issue for it."*
+*   *"I just finished implementing the auth middleware. Update its issue to 'done' and show me what's left in my 'todo' column."*

prompts/kanban-finalize-issue.prompt.md

@@ -0,0 +1,11 @@
+---
+description: Finalize an issue, update the board, and celebrate the win.
+---
+I have successfully merged the code for my active task into the main branch. 
+
+Please use the GitHub MCP tools to:
+1. Find the issue we just completed.
+2. Remove the `status: in-review` or `status: in-progress` label.
+3. Add the `status: done` label.
+4. Formally **Close** the issue.
+5. List the remaining items left in the `status: in-progress` and `status: todo` columns so I know exactly where the project stands.

prompts/kanban-move-to-backlog.prompt.md

@@ -0,0 +1,11 @@
+---
+description: Rapidly log an unexpected bug or chore to the backlog.
+---
+I encountered a bug/chore while working on something else, and I need to log it so I don't forget. 
+
+Please ask me for a quick, messy description of the problem. 
+
+Once I provide it, clean it up into a professional GitHub Issue:
+1. Give it a clear, searchable title prefixed with the component name (e.g., `[Auth] Fix token expiration loop`).
+2. Populate the description with a "Steps to Reproduce" or "Problem Statement" section.
+3. Automatically apply the `status: backlog` and `type: bug` (or `type: chore`) labels using the MCP tools.

prompts/kanban-move-to-current.prompt.md

@@ -0,0 +1,12 @@
+---
+description: Move an issue to In-Progress and prepare the development environment.
+---
+I am ready to start working on a task. Please ask me for the Issue ID or title.
+
+Once identified, use the GitHub MCP tools to:
+1. Locate the issue and read its description to sync your context.
+2. Remove its current status label (e.g., `status: todo` or `status: backlog`).
+3. Add the `status: in-progress` label.
+4. Check the repository's existing branches to see if a feature branch already exists for this task. If not, suggest a clean git branch naming convention based on the issue (e.g., `feature/issue-12-auth-fix`).
+
+Summarize the task's acceptance criteria for me so I can begin coding with a clear goal.

prompts/kanban-review-changes-for-PR.prompt.md

@@ -0,0 +1,12 @@
+---
+description: Perform a self-review of local changes and prepare a PR description.
+---
+Initialize context by reading `LLM_PROJECT_RULES.md`. I have completed the coding phase for the current `status: in-progress` issue.
+
+Please use your repository/git tools to review my current diff or recent commits on this branch. Provide a comprehensive code review focusing on:
+1. **Edge Cases:** Any potential bugs, missing error handling, or security vulnerabilities.
+2. **Refactoring:** Opportunities for code optimization or readability improvements.
+
+If the code looks solid, draft a clean Pull Request description for me that summarizes the changes and explicitly includes the phrase "Closes #XX" (replacing XX with the active Issue ID). 
+
+Finally, use the MCP tools to update the issue's label from `status: in-progress` to `status: in-review`.