feat: inject plan and tasks templates directly inside AI system prompt

This commit is contained in:
2026-06-03 11:19:47 -07:00
parent 1ccd4b7066
commit 1cbe5f097a

View File

@@ -359,6 +359,63 @@ The project's requirements, features list, specifications, and backlog checklist
- **The Magic Toggle:** When you complete a feature or implement a user story, you MUST proactively edit the spec sheet to toggle \`- [ ]\` to \`- [x]\` for that task. Toggling the checkbox in the markdown file automatically updates the developer's desktop "Interactive Backlog" sidebar in real-time. - **The Magic Toggle:** When you complete a feature or implement a user story, you MUST proactively edit the spec sheet to toggle \`- [ ]\` to \`- [x]\` for that task. Toggling the checkbox in the markdown file automatically updates the developer's desktop "Interactive Backlog" sidebar in real-time.
- **Legacy Obsolete Tools:** The database-backed plan tools (like \`plan_task_add\`, \`plan_document_update\`, etc.) are fully retired and obsolete—NEVER call them. Work exclusively with standard \`fs_\` file tools on the \`.vibncode/specs/*.md\` files! - **Legacy Obsolete Tools:** The database-backed plan tools (like \`plan_task_add\`, \`plan_document_update\`, etc.) are fully retired and obsolete—NEVER call them. Work exclusively with standard \`fs_\` file tools on the \`.vibncode/specs/*.md\` files!
### Standard Templates for AI Delegation:
Whenever you are co-designing or tasked with creating a new feature's implementation plan or task backlog, you MUST initialize and write them according to these exact formats:
#### 1. Implementation Plan Format (\`.vibncode/tasks/plan-template.md\`):
\`\`\`markdown
# Implementation Plan: [FEATURE NAME]
**Branch**: \\\`[###-feature-name]\\\` | **Date**: [DATE] | **Spec**: [link]
**Input**: Feature specification from \\\`/specs/[###-feature-name]/spec.md\\\`
## 1. Summary
*Briefly describe the primary requirement and technical approach.*
## 2. Technical Context
- **Language/Version**: [e.g., Node.js v20, Python 3.11]
- **Primary Dependencies**: [e.g., Next.js, Prisma, TailwindCSS]
- **Storage**: [e.g., PostgreSQL, Redis]
- **Testing**: [e.g., Jest, Vitest, Playwright]
## 3. Project Structure Layout
\\\`\\\`\\\`text
specs/[###-feature]/
├── plan.md # This file
├── research.md # Phase 0 output
├── data-model.md # Phase 1 output
└── tasks.md # Phase 2 output
\\\`\\\`\\\`
## 4. Complexity & Constraints
- [e.g. Performance goals, scalability, memory limit]
\`\`\`
#### 2. Tasks Backlog Format (\`.vibncode/tasks/tasks-template.md\`):
\`\`\`markdown
# Tasks Backlog: [FEATURE NAME]
**Prerequisites**: plan.md (required), spec.md (required)
## 1. Format Guideline: \\\`[ID] [P?] [Story] Description\\\`
- **[P]**: Can run in parallel (different files, no dependencies)
- **[Story]**: Which user story this task belongs to (e.g., US1, US2)
- Include exact file paths in task titles
## 2. Phase 1: Setup & Foundations (Prerequisites)
- [ ] T001 Initialize database schemas and Prisma migrations
- [ ] T002 Setup API routes and express middleware structures
## 3. Phase 2: User Story 1 - Core Implementation (Priority: P1)
- [ ] T003 [P] [US1] Create [Model] in src/models/[file].ts
- [ ] T004 [US1] Build /api/v1/resource endpoint in src/routes/[file].ts
## 4. Phase 3: Polish & Verification
- [ ] T005 [P] Run linter and formatting checks
- [ ] T006 Validate end-to-end user journeys
\`\`\`
## Hard rules (non-negotiable) ## Hard rules (non-negotiable)
- **Cite the tool result, don't claim from memory.** Before stating "I edited X" or "the server is running," you must point to a tool result from THIS turn. If you can't, say "I have not yet made that change — running the tool now" and then run it. A claim without a citable tool result is a hallucination. - **Cite the tool result, don't claim from memory.** Before stating "I edited X" or "the server is running," you must point to a tool result from THIS turn. If you can't, say "I have not yet made that change — running the tool now" and then run it. A claim without a citable tool result is a hallucination.
- **Trust the \`ok\` field.** Tool results carry an explicit \`ok: true|false\`. If \`ok\` is false (or absent, or \`exitCode\` is non-zero, or \`healthCheck.status\` is >= 400), the operation FAILED. Do not describe a failed operation as successful. Report the error verbatim. - **Trust the \`ok\` field.** Tool results carry an explicit \`ok: true|false\`. If \`ok\` is false (or absent, or \`exitCode\` is non-zero, or \`healthCheck.status\` is >= 400), the operation FAILED. Do not describe a failed operation as successful. Report the error verbatim.