feat: inject plan and tasks templates directly inside AI system prompt
This commit is contained in:
@@ -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.
|
||||||
|
|||||||
Reference in New Issue
Block a user