初步踏入开发工作考虑到ai开发中所需要进行的总结所以设计了一个针对智能体进行一份周工作报告的skill.md这里记录一下。--- name: weekly-report-generator description: Generates weekly work reports and task breakdowns from project codebase. Invoke when user asks to write a work report, weekly summary, or task estimation based on actual project code. --- # Weekly Report Generator This skill generates structured weekly work reports and task breakdowns by deeply analyzing the project codebase, ensuring the report content is grounded in actual code implementation rather than subjective description. ## When to Invoke Invoke this skill when the user asks to: - Write a weekly/daily work report - Generate a project progress summary - Break down completed work into task points with time estimates - Create a development timeline or schedule ## Core Workflow The skill follows a 3-phase process: Codebase Survey → Report Generation → Task Breakdown. ### Phase 1: Codebase Survey Before writing any report, thoroughly investigate the project using search agents. Launch multiple search agents in parallel to cover different dimensions: 1. **Project Architecture Survey** - Directory structure (pages, components, composables, types, server, styles, middleware, plugins, layouts) - Configuration files (nuxt.config.ts / vite.config.ts / package.json / tsconfig.json) - Environment variables (.env files) - Build and deployment setup 2. **Module-by-Module Deep Dive** (one search agent per module) For each business module the user mentions, investigate: - Page files (route structure, page layout, component composition) - Composable files (API methods, data fetching patterns, state management) - Type definitions (interfaces, enums, utility types) - Component files (reusable components, layout components) - Server-side code (API proxy, middleware) - Key implementation logic (data flow, user interaction flow, error handling) 3. **Cross-Cutting Concerns** - Style system (SCSS variables, theme customization, responsive breakpoints) - Authentication mechanism (token management, route guards, login/register flow) - API architecture (proxy pattern, response format, error handling) - Shared components and utilities **Critical**: The survey must be comprehensive enough to describe actual implementation details, not just feature names. For example, instead of saying login function, describe password Base64 encoded via btoa(), submitted as multipart/form-data with request-auth header. ### Phase 2: Report Generation Generate the report with the following 5 sections, each grounded in the codebase survey results: #### Section 1: Project Functionality Understanding - Overall project positioning and business domain - Module inventory with functional scope - Key architectural characteristics (e.g., SSR/SSG mode, frontend/backend separation, auth-driven feature layering) - User-facing feature summary #### Section 2: Frontend Design Philosophy - Design system (color palette, typography, spacing tokens, component library choice) - Layout patterns (page structure, responsive breakpoints, detail page standard structure) - Style engineering (preprocessor setup, global variable injection, CSS scoping strategy, naming conventions) - Reference actual variable values and breakpoint numbers from the codebase #### Section 3: Technical Choices and Implementation Logic per Module For each module, document: - Route paths and page file locations - Feature architecture (what the module does, sub-modules or sub-features) - Technical choices made (data fetching pattern, state management, API calling mode, type system) - Implementation logic flow (data flow diagram in text form) - API integration status (which APIs are connected, which are mock/hardcoded) - Known issues or deviations from project standards #### Section 4: Backend API Design and Implementation - API proxy architecture (how frontend requests reach the backend) - Why specific proxy patterns were chosen (e.g., why not devProxy) - Complete API endpoint inventory in table format (path, method, response format, success code) - Response format compatibility handling (multiple format tolerance) - Authentication mechanism in API calls (token format, header forwarding) #### Section 5: Future Development Preparation - Prioritized list of incomplete features (P0/P1/P2) - Architecture optimization directions - Technical reserves for upcoming work - Known bugs or technical debt ### Phase 3: Task Breakdown Based on the completed work documented in the report, break down into task points: 1. **Merge related tasks**: Tasks that share the same code area or have tight dependencies should be combined (e.g., type definition API composable page development for the same module can be one task point) 2. **Time estimate per task**: 2~4H per task point. Adjust based on actual complexity: - Simple (type definition API wrapper): 2H - Medium (single page with standard patterns): 3H - Complex (multi-feature page or cross-cutting system): 4H 3. **Realistic estimation**: Consider that experienced developers work faster than naive estimates. Dont pad individual sub-tasks and then sum them up — think holistically about how long the combined work actually takes. 4. **Schedule layout**: Distribute task points across available working days, respecting: - Dependencies (infrastructure first, then features) - Daily capacity (6~8H per day) - Deadline constraint ## Output Format ### Report Format Use Word-friendly formatting: - Numbered section headers (一、二、三...) - Tables for structured data (feature lists, API inventories, design tokens) - Bullet points within sections - Avoid Markdown-specific syntax that doesnt paste well into Word (no backtick code blocks, no pipe tables that Word cant parse) - Use Chinese numbering conventions (一、二、三 for major sections, 1. 2. 3. for subsections) ### Task Breakdown Format - Group by module - Each task point: sequence number name hours brief description - Module subtotals - Grand total - Schedule table: date → task points → hours ## Quality Checklist Before delivering the report, verify: - [ ] Every feature description references actual code implementation, not just feature names - [ ] API paths and response formats are accurate (from codebase, not assumed) - [ ] Design token values (colors, breakpoints) match actual SCSS variables - [ ] Implementation logic flows are complete (from user action to API call to UI update) - [ ] Incomplete/mock features are explicitly flagged - [ ] Task breakdown hours are realistic and not inflated - [ ] Related tasks are properly merged, not artificially split技能名称 weekly-report-generator周工作报告生成器核心流程 3 个阶段阶段一代码库调研- 并行启动多个搜索 Agent分别调研项目架构、各业务模块实现细节、跨模块公共机制- 调研粒度必须深入到实际代码实现如密码 Base64 编码 multipart/form-data 提交而非仅停留在功能名称层面阶段二报告生成- 按 5 个固定章节输出项目功能认识 → 前端设计思想 → 各模块技术选用与实现逻辑 → 后端接口设计实现 → 后续开发准备- 每个章节内容必须基于代码库调研结果引用实际的变量值、API 路径、响应格式、实现逻辑流程- 使用 Word 友好格式中文编号、表格、避免 Markdown 特殊语法阶段三任务拆分- 合并关联任务同模块的类型定义API封装页面开发合为一个任务点- 每个任务点 2~4H根据实际复杂度而非简单叠加估算- 按依赖关系和工作日排期尊重截止时间约束关键原则 报告内容必须扎根于代码实际实现而非主观描述任务拆分要务实合并、不人为拆细。
周工作报告生成器的智能体skill配置
初步踏入开发工作考虑到ai开发中所需要进行的总结所以设计了一个针对智能体进行一份周工作报告的skill.md这里记录一下。--- name: weekly-report-generator description: Generates weekly work reports and task breakdowns from project codebase. Invoke when user asks to write a work report, weekly summary, or task estimation based on actual project code. --- # Weekly Report Generator This skill generates structured weekly work reports and task breakdowns by deeply analyzing the project codebase, ensuring the report content is grounded in actual code implementation rather than subjective description. ## When to Invoke Invoke this skill when the user asks to: - Write a weekly/daily work report - Generate a project progress summary - Break down completed work into task points with time estimates - Create a development timeline or schedule ## Core Workflow The skill follows a 3-phase process: Codebase Survey → Report Generation → Task Breakdown. ### Phase 1: Codebase Survey Before writing any report, thoroughly investigate the project using search agents. Launch multiple search agents in parallel to cover different dimensions: 1. **Project Architecture Survey** - Directory structure (pages, components, composables, types, server, styles, middleware, plugins, layouts) - Configuration files (nuxt.config.ts / vite.config.ts / package.json / tsconfig.json) - Environment variables (.env files) - Build and deployment setup 2. **Module-by-Module Deep Dive** (one search agent per module) For each business module the user mentions, investigate: - Page files (route structure, page layout, component composition) - Composable files (API methods, data fetching patterns, state management) - Type definitions (interfaces, enums, utility types) - Component files (reusable components, layout components) - Server-side code (API proxy, middleware) - Key implementation logic (data flow, user interaction flow, error handling) 3. **Cross-Cutting Concerns** - Style system (SCSS variables, theme customization, responsive breakpoints) - Authentication mechanism (token management, route guards, login/register flow) - API architecture (proxy pattern, response format, error handling) - Shared components and utilities **Critical**: The survey must be comprehensive enough to describe actual implementation details, not just feature names. For example, instead of saying login function, describe password Base64 encoded via btoa(), submitted as multipart/form-data with request-auth header. ### Phase 2: Report Generation Generate the report with the following 5 sections, each grounded in the codebase survey results: #### Section 1: Project Functionality Understanding - Overall project positioning and business domain - Module inventory with functional scope - Key architectural characteristics (e.g., SSR/SSG mode, frontend/backend separation, auth-driven feature layering) - User-facing feature summary #### Section 2: Frontend Design Philosophy - Design system (color palette, typography, spacing tokens, component library choice) - Layout patterns (page structure, responsive breakpoints, detail page standard structure) - Style engineering (preprocessor setup, global variable injection, CSS scoping strategy, naming conventions) - Reference actual variable values and breakpoint numbers from the codebase #### Section 3: Technical Choices and Implementation Logic per Module For each module, document: - Route paths and page file locations - Feature architecture (what the module does, sub-modules or sub-features) - Technical choices made (data fetching pattern, state management, API calling mode, type system) - Implementation logic flow (data flow diagram in text form) - API integration status (which APIs are connected, which are mock/hardcoded) - Known issues or deviations from project standards #### Section 4: Backend API Design and Implementation - API proxy architecture (how frontend requests reach the backend) - Why specific proxy patterns were chosen (e.g., why not devProxy) - Complete API endpoint inventory in table format (path, method, response format, success code) - Response format compatibility handling (multiple format tolerance) - Authentication mechanism in API calls (token format, header forwarding) #### Section 5: Future Development Preparation - Prioritized list of incomplete features (P0/P1/P2) - Architecture optimization directions - Technical reserves for upcoming work - Known bugs or technical debt ### Phase 3: Task Breakdown Based on the completed work documented in the report, break down into task points: 1. **Merge related tasks**: Tasks that share the same code area or have tight dependencies should be combined (e.g., type definition API composable page development for the same module can be one task point) 2. **Time estimate per task**: 2~4H per task point. Adjust based on actual complexity: - Simple (type definition API wrapper): 2H - Medium (single page with standard patterns): 3H - Complex (multi-feature page or cross-cutting system): 4H 3. **Realistic estimation**: Consider that experienced developers work faster than naive estimates. Dont pad individual sub-tasks and then sum them up — think holistically about how long the combined work actually takes. 4. **Schedule layout**: Distribute task points across available working days, respecting: - Dependencies (infrastructure first, then features) - Daily capacity (6~8H per day) - Deadline constraint ## Output Format ### Report Format Use Word-friendly formatting: - Numbered section headers (一、二、三...) - Tables for structured data (feature lists, API inventories, design tokens) - Bullet points within sections - Avoid Markdown-specific syntax that doesnt paste well into Word (no backtick code blocks, no pipe tables that Word cant parse) - Use Chinese numbering conventions (一、二、三 for major sections, 1. 2. 3. for subsections) ### Task Breakdown Format - Group by module - Each task point: sequence number name hours brief description - Module subtotals - Grand total - Schedule table: date → task points → hours ## Quality Checklist Before delivering the report, verify: - [ ] Every feature description references actual code implementation, not just feature names - [ ] API paths and response formats are accurate (from codebase, not assumed) - [ ] Design token values (colors, breakpoints) match actual SCSS variables - [ ] Implementation logic flows are complete (from user action to API call to UI update) - [ ] Incomplete/mock features are explicitly flagged - [ ] Task breakdown hours are realistic and not inflated - [ ] Related tasks are properly merged, not artificially split技能名称 weekly-report-generator周工作报告生成器核心流程 3 个阶段阶段一代码库调研- 并行启动多个搜索 Agent分别调研项目架构、各业务模块实现细节、跨模块公共机制- 调研粒度必须深入到实际代码实现如密码 Base64 编码 multipart/form-data 提交而非仅停留在功能名称层面阶段二报告生成- 按 5 个固定章节输出项目功能认识 → 前端设计思想 → 各模块技术选用与实现逻辑 → 后端接口设计实现 → 后续开发准备- 每个章节内容必须基于代码库调研结果引用实际的变量值、API 路径、响应格式、实现逻辑流程- 使用 Word 友好格式中文编号、表格、避免 Markdown 特殊语法阶段三任务拆分- 合并关联任务同模块的类型定义API封装页面开发合为一个任务点- 每个任务点 2~4H根据实际复杂度而非简单叠加估算- 按依赖关系和工作日排期尊重截止时间约束关键原则 报告内容必须扎根于代码实际实现而非主观描述任务拆分要务实合并、不人为拆细。
