增加新功能 - 討論工時

[kkdai]

當 issue 裡面有 PRD 也有分工的時候，要能夠估計工時。
他會查看有幾個 assignees (如果沒有，就是一個人）
來估計要做多久

@agent-fleet need_prd

[agent-fleet]

PRD (Product Requirements Document)

---

## Product Requirements Document (PRD)

**Product Name:** GitHub PRD Bot - Time Estimation Feature

**Version:** 1.0

**Date:** October 26, 2023

**Author:** [Your Name]

### 1. Introduction

This PRD outlines the requirements for adding a new feature to the existing GitHub PRD Bot. This new feature will enable the bot to estimate the development time required for an issue based on the generated PRD, sub-tasks, and number of assignees. The primary goal is to provide a rough estimate to project managers and developers for better planning and resource allocation.

### 2. Background

Currently, the GitHub PRD Bot automatically generates Product Requirements Documents (PRDs) and suggests sub-tasks for newly created GitHub Issues.  However, there is no built-in mechanism to estimate the effort (in terms of time) required to complete the issue.  This makes it difficult for project managers and developers to plan sprints and allocate resources effectively. The existing bot functionality includes PRD generation and sub-task identification but lacks time estimation.

### 3. Goals

*   Provide a reasonable estimate of the development time required to complete an issue.
*   Offer this estimate based on the generated PRD and identified sub-tasks.
*   Consider the number of assignees when calculating the estimated time.
*   Improve sprint planning and resource allocation efficiency.
*   Minimize manual effort required for time estimation on GitHub Issues.

### 4. User Stories

*   As a **Project Manager**, I want the bot to provide an estimated development time for an issue, so that I can plan sprints and allocate resources effectively.
*   As a **Developer**, I want to see the estimated development time for an issue, so that I can understand the scope of work and plan my tasks accordingly.
*   As a **Product Owner**, I want to have an estimate of the effort involved in delivering a feature, so that I can prioritize features based on cost and value.

### 5. Requirements

#### 5.1 Functional Requirements

*   **Trigger:** The time estimation functionality should be triggered manually via a GitHub Issue comment.  The trigger command should be `@<bot-name> estimate_time`.
*   **PRD Retrieval:** The bot should automatically identify and retrieve the latest PRD within the Issue's comments.  If no PRD exists, an error message should be posted indicating that a PRD must be generated first.
*   **Sub-task Retrieval:** The bot should automatically identify and retrieve the list of sub-tasks generated from the PRD within the Issue's comments. If no sub-tasks exist, an error message should be posted indicating that sub-tasks must be generated first.
*   **Assignee Identification:** The bot should determine the number of assignees for the Issue. If no assignees are assigned, the bot should assume a single developer is working on the issue.
*   **Time Estimation Logic:** The bot should use Google Gemini AI to estimate the time required to complete the issue, considering:
    *   The complexity and scope of the PRD.
    *   The number and complexity of the sub-tasks.
    *   The number of assignees.  (More assignees should, generally, decrease the estimated time, assuming parallel work is possible).
    *   A default time unit (e.g., hours, days). The bot should default to "days" but allow the user to specify a unit with the command (e.g., `@<bot-name> estimate_time in hours`).
    *   The prompt to Gemini AI should include instructions to provide the estimate in a clear and easily understandable format, and include the reasoning behind the estimate.
*   **Output:** The bot should post a new comment in the Issue with the estimated development time, including:
    *   The estimated time (e.g., "Estimated Development Time: 5 days").
    *   A brief explanation of the reasoning behind the estimate.
    *   A disclaimer that the estimate is approximate and may vary based on individual developer skills and unforeseen circumstances.
    *   The number of assignees used in the calculation.
*   **Error Handling:** The bot should handle errors gracefully, such as:
    *   Invalid command format.
    *   Missing PRD or sub-tasks.
    *   Failure to connect to the Google Gemini AI service.
    *   Rate limiting from GitHub or Google Gemini AI.
*   **Configuration:** The bot should have configurable parameters for:
    *   The default time unit (hours, days, weeks).
    *   The default number of hours per day for calculating work estimates.
    *   The prompt sent to the Google Gemini AI model (allowing customization of the estimation logic).
    *   The multiplier applied to the estimated time based on the number of assignees.

#### 5.2 Non-Functional Requirements

*   **Performance:** The time estimation process should be completed within a reasonable timeframe (e.g., less than 30 seconds).
*   **Scalability:** The bot should be able to handle a large number of requests without performance degradation.
*   **Reliability:** The bot should be reliable and available, with minimal downtime.
*   **Security:** The bot should be secure and protect sensitive data, such as the Google Gemini AI API key.
*   **Maintainability:** The code should be well-documented and easy to maintain.
*   **Usability:** The bot's interface should be easy to use and understand.
*   **Integration:** The bot should seamlessly integrate with GitHub.

### 6. Success Metrics

*   **Accuracy of Estimates:** Measure the difference between the estimated development time and the actual development time. Track the average difference across a sample of issues.
*   **Usage of the Feature:** Track the number of times the `estimate_time` command is used.
*   **User Satisfaction:** Gather feedback from users (project managers, developers, product owners) on their satisfaction with the accuracy and usefulness of the time estimation feature. This could be done through surveys or informal feedback sessions.
*   **Improvement in Sprint Planning:** Track the impact of the feature on sprint planning efficiency, such as a reduction in unplanned work or an improvement in sprint completion rates.

### 7. Future Considerations

*   **Automated Time Tracking Integration:** Integrate with time tracking tools (e.g., Jira, Toggl) to automatically track actual development time and improve the accuracy of future estimates.
*   **Learning and Adaptation:** Implement a machine learning model that learns from past estimates and actual development times to improve the accuracy of future estimates.
*   **Integration with other GitHub features:** Explore integration with other GitHub features, such as GitHub Projects and GitHub Actions.
*   **Support for other languages:** Expand support for other languages beyond English.

### 8. Out of Scope

*   Detailed task breakdown and assignment (this is already handled by the sub-task generation).
*   Integration with specific time tracking tools in the initial release.
*   Implementing a sophisticated machine learning model in the initial release.

---

PRD (Traditional Chinese)

## 產品需求文件 (PRD)

**產品名稱:** GitHub PRD 機器人 - 時間估算功能

**版本:** 1.0

**日期:** 2023年10月26日

**作者:** [您的名字]

### 1. 簡介

本PRD概述了為現有GitHub PRD機器人添加新功能的需求。 此新功能將使機器人能夠根據生成的PRD、子任務和分配人數來估算 issue 所需的開發時間。 主要目標是為專案經理和開發人員提供粗略的估算，以便更好地規劃和資源分配。

### 2. 背景

目前，GitHub PRD 機器人會自動生成產品需求文件 (PRD) 並為新創建的 GitHub Issue 建議子任務。 但是，沒有內建機制來估算完成 Issue 所需的工作量（就時間而言）。 這使得專案經理和開發人員難以有效地規劃 sprints 和分配資源。 現有的機器人功能包括 PRD 生成和子任務識別，但缺乏時間估算。

### 3. 目標

*   提供完成 Issue 所需的合理開發時間估算。
*   根據生成的 PRD 和已識別的子任務提供此估算。
*   在計算估算時間時考慮分配人數。
*   提高 sprint 規劃和資源分配效率。
*   最大限度地減少 GitHub Issues 上時間估算所需的手動工作。

### 4. 使用者故事

*   作為一名 **專案經理**，我希望機器人提供 Issue 的估計開發時間，以便我可以有效地規劃 sprints 並分配資源。
*   作為一名 **開發人員**，我希望看到 Issue 的估計開發時間，以便我可以了解工作範圍並相應地規劃我的任務。
*   作為一名 **產品負責人**，我希望獲得交付功能所需工作量的估算，以便我可以根據成本和價值來確定功能的優先順序。

### 5. 需求

#### 5.1 功能性需求

*   **觸發:** 時間估算功能應透過 GitHub Issue 評論手動觸發。 觸發命令應為 `@<bot-name> estimate_time`。
*   **PRD 檢索:** 機器人應自動識別並檢索 Issue 評論中最新的 PRD。 如果不存在 PRD，則應發布錯誤訊息，指示必須先生成 PRD。
*   **子任務檢索:** 機器人應自動識別並檢索 Issue 評論中從 PRD 生成的子任務清單。 如果不存在子任務，則應發布錯誤訊息，指示必須先生成子任務。
*   **分配人員識別:** 機器人應確定 Issue 的分配人員數量。 如果沒有分配人員，則機器人應假設只有一位開發人員正在處理此 Issue。
*   **時間估算邏輯:** 機器人應使用 Google Gemini AI 來估算完成 Issue 所需的時間，考慮因素包括：
    *   PRD 的複雜性和範圍。
    *   子任務的數量和複雜性。
    *   分配人數。 （通常，更多的分配人員應該會減少估算的時間，假設可以進行並行工作）。
    *   預設時間單位（例如，小時、天）。 機器人應預設為“天”，但允許使用者使用命令指定單位（例如，`@<bot-name> estimate_time in hours`）。
    *   向 Gemini AI 發送的提示應包括以清晰易懂的格式提供估算，並包含估算背後的原因的說明。
*   **輸出:** 機器人應在 Issue 中發布一條包含估計開發時間的新評論，包括：
    *   估計時間（例如，“估計開發時間：5 天”）。
    *   對估算背後原因的簡要解釋。
    *   免責聲明，聲明該估算值是近似值，並且可能因個別開發人員的技能和不可預見的情況而異。
    *   計算中使用的分配人員數量。
*   **錯誤處理:** 機器人應優雅地處理錯誤，例如：
    *   無效的命令格式。
    *   缺少 PRD 或子任務。
    *   無法連接到 Google Gemini AI 服務。
    *   來自 GitHub 或 Google Gemini AI 的速率限制。
*   **配置:** 機器人應具有以下可配置參數：
    *   預設時間單位（小時、天、週）。
    *   用於計算工作估算的每日預設小時數。
    *   發送到 Google Gemini AI 模型的提示（允許自訂估算邏輯）。
    *   根據分配人數應用於估算時間的乘數。

#### 5.2 非功能性需求

*   **效能:** 時間估算過程應在合理的時間範圍內完成（例如，少於 30 秒）。
*   **可擴展性:** 機器人應能夠處理大量請求而不會降低效能。
*   **可靠性:** 機器人應可靠且可用，且停機時間最少。
*   **安全性:** 機器人應安全並保護敏感資料，例如 Google Gemini AI API 金鑰。
*   **可維護性:** 程式碼應具有良好的文件記錄且易於維護。
*   **可用性:** 機器人的介面應易於使用和理解。
*   **整合:** 機器人應與 GitHub 無縫整合。

### 6. 成功指標

*   **估算的準確性:** 衡量估計開發時間與實際開發時間之間的差異。 追蹤 issue 樣本的平均差異。
*   **功能的使用情況:** 追蹤 `estimate_time` 命令的使用次數。
*   **使用者滿意度:** 收集使用者（專案經理、開發人員、產品負責人）對時間估算功能的準確性和實用性的滿意度。 這可以透過調查或非正式的回饋會議來完成。
*   **Sprint 規劃的改進:** 追蹤該功能對 sprint 規劃效率的影響，例如減少未規劃的工作或提高 sprint 完成率。

### 7. 未來考量

*   **自動時間追蹤整合:** 與時間追蹤工具（例如 Jira、Toggl）整合，以自動追蹤實際開發時間並提高未來估算的準確性。
*   **學習和適應:** 實施一個機器學習模型，該模型可以從過去的估算和實際開發時間中學習，以提高未來估算的準確性。
*   **與其他 GitHub 功能整合:** 探索與其他 GitHub 功能（例如 GitHub Projects 和 GitHub Actions）的整合。
*   **支援其他語言:** 將支援擴展到英語以外的其他語言。

### 8. 超出範圍

*   詳細的任務分解和分配（這已經由子任務生成處理）。
*   在初始版本中與特定時間追蹤工具整合。
*   在初始版本中實施複雜的機器學習模型。

[kkdai]

@agent-fleet need_sub_task

[agent-fleet]

Generated Sub-tasks

Based on the PRD, here are the suggested sub-tasks:

Here's a breakdown of the PRD into actionable sub-tasks, formatted as a GitHub-flavored Markdown checklist:

• Create a new GitHub repository for the "GitHub PRD Bot - Time Estimation Feature" or identify the existing bot's repository.
• Set up the project's directory structure.
• Configure version control using Git.
• Set up a CI/CD pipeline (e.g., using GitHub Actions, Jenkins).
• Define environment variables and secrets management for API keys (Google Gemini AI).

1. Command Parsing and Triggering

• Implement the command parsing logic to identify the @<bot-name> estimate_time command in Issue comments.
• Extract the time unit (if provided) from the command (e.g., "hours", "days").
• Implement error handling for invalid command formats.

2. PRD and Sub-task Retrieval

• Develop a function to search for and retrieve the latest PRD from the Issue's comments.
• Develop a function to search for and retrieve the list of sub-tasks from the Issue's comments.
• Implement error handling for missing PRD or sub-tasks. Post appropriate error messages as comments.

3. Assignee Identification

• Develop a function to retrieve the number of assignees for the Issue.
• Handle the case where no assignees are assigned (default to a single developer).

4. Google Gemini AI Integration

• Set up the Google Gemini AI API client library in the project.
• Create a function to interact with the Google Gemini AI API.
• Develop a prompt generation module that constructs the prompt to send to Google Gemini AI. The prompt should include the PRD, sub-tasks, and assignees information, and request an estimate in the desired format and unit.
• Implement error handling for Google Gemini AI API connection failures and rate limiting.

5. Time Estimation Logic and Output

• Implement the core time estimation logic, using the Google Gemini AI API to generate the estimate.
• Parse the response from Google Gemini AI to extract the estimated time, reasoning, and any relevant information.
• Format the estimated time and reasoning into a user-friendly message.
• Add a disclaimer to the message stating that the estimate is approximate.
• Include the number of assignees used in the calculation in the output message.
• Post the formatted message as a new comment in the Issue.

6. Configuration

• Implement configurable parameters for:
  • Default time unit (hours, days, weeks).
  • Default number of hours per day for calculating work estimates.
  • The prompt sent to the Google Gemini AI model (allowing customization of the estimation logic).
  • The multiplier applied to the estimated time based on the number of assignees.
• Implement a mechanism for setting these parameters (e.g., environment variables, configuration file).

7. Error Handling and Logging

• Implement robust error handling throughout the bot, including handling:
  • Invalid command format
  • Missing PRD or sub-tasks
  • Failure to connect to the Google Gemini AI service
  • Rate limiting from GitHub or Google Gemini AI
• Implement comprehensive logging to track bot activity, errors, and performance.

8. Testing

• Write unit tests for all core functions (command parsing, PRD retrieval, sub-task retrieval, assignee identification, Google Gemini AI interaction, output formatting).
• Write integration tests to test the bot's end-to-end functionality.
• Perform manual testing to ensure the bot is working as expected in various scenarios.

9. Deployment and Monitoring

• Deploy the bot to a suitable hosting environment (e.g., cloud platform, server).
• Set up monitoring and alerting to track the bot's health, performance, and error rate.

10. Documentation

• Write comprehensive documentation for the bot, including:
  • Installation instructions
  • Configuration options
  • Usage instructions
  • Troubleshooting guide
• Document the code thoroughly.

11. Security

• Implement secure storage for sensitive data, such as the Google Gemini AI API key (e.g., using environment variables or a secrets management system).
• Regularly review the bot's code for security vulnerabilities.

12. Non-Functional Requirements

• Performance: Optimize the bot's code and infrastructure to ensure the time estimation process is completed within 30 seconds.
• Scalability: Design the bot to handle a large number of requests without performance degradation.
• Reliability: Implement measures to ensure the bot is reliable and available, with minimal downtime.
• Usability: Design the bot's interface (comments) to be easy to use and understand.
• Integration: Ensure the bot seamlessly integrates with GitHub.

13. Success Metrics Implementation

• Implement tracking for the number of times the estimate_time command is used.
• Implement mechanism for users to provide feedback on the estimates accuracy and usefulness (e.g., thumbs up/down, survey link).
• Develop a process to measure the difference between estimated and actual development time across a sample of issues.
• (Future Consideration - depends on tools available) Track improvement in sprint planning metrics (e.g., sprint completion rate, unplanned work).

14. (Future Considerations - Stubs for future sprints/iterations)

• Implement a stub function for integrating with time tracking tools (Jira, Toggl).
• Implement a stub function for implementing a machine learning model for improved estimation.
• Implement a stub function for exploring integration with other GitHub features.
• Implement a stub function for supporting languages other than English.

[kkdai]

@agent-fleet implement_feature

[agent-fleet]

I failed to implement the feature for issue #3. Reason: No files to modify. Please specify the files in the issue body using the format Files: file1.go, path/to/file2.go.