dev-impl: Скилл для реализации задач и быстрых исправлений

--- name: dev-impl description: This skill should be used when the user asks to "dev-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". Perform test-first implementation with TDD as a guardrail. Supports both normal mode (Plan+task specification) and quick mode (direct instructions). argument-hint: '<plan-name> <task-id> | "<instruction>"' --- # Dev Impl Core workflow of test-first implementation with TDD as a guardrail. Has two execution modes: normal mode based on task files and lightweight quick mode without Plan. ## Prerequisites ### Position within the `dev-*` skill flow ``` dev-context → dev-plan → [dev-impl] → dev-verify ↘ dev-debug (in case of failure) ``` ### Execution modes | Mode | Argument | Purpose | |-------|------|------| | Normal mode | `<plan-name> <task-id>` | Implement one task from the Plan | | Quick mode | `"correction instruction"` | Lightweight correction/adjustment (no Plan required) | ### Priority based on quality Prioritize in the order of **quality > speed > token consumption**. ## Workflow: Normal mode Execute with `/dev-impl <plan-name> <task-id>`. ### Step 1: Context building (minimal) Read only the minimum necessary files with an interface-first approach: ``` Priority: 1. docs/dev/context.md (project overview) 2. Task file (interface definition, test strategy) 3. Relevant type definition files ← only when necessary 4. Relevant existing test files (pattern reference) ← only when necessary 5. Implementation files (only relevant functions) ← only when necessary ``` Start tracking task progress with TodoWrite. ### Step 2: Test case generation (Red) Generate test code based on the Test Strategy in the task file: 1. Match the pattern of existing test files (context.md rules) 2. Write test cases based on the interface definition of the task 3. Execute the test command (obtained from context.md) 4. **Confirm failure** (Red state) If the test passes prematurely, re-examine the requirements and the validity of the test. ### Step 3: Implementation (Green) Generate the minimum implementation to pass the test: 1. Write code that conforms to the interface definition 2. **Add Intent comments** (follow the "Intent Comment Rules" described below) 3. Execute test → **Confirm success** (Green state) 4. If it fails, analyze the error and fix it (maximum 3 cycles) 5. If not resolved in 3 cycles, use `/dev-debug` ### Step 4: Refactoring + Quality check After the test is Green, perform the following: #### 4a. 500-line rule (strictly enforced) Check the line count of all relevant files using Bash (use absolute paths): ```bash wc -l "$(git rev-parse --show-toplevel)/<relative path of the file>" ``` If there are files exceeding 500 lines: - Split by responsibility boundary (Single Responsibility Principle) - Split the test file accordingly - Maintain import/export consistency - Re-execute the test after splitting #### 4b. Security check Verify the implementation code for the following issues: - Injection (SQL, command, XSS) - Missing authentication/authorization checks - Exposure of sensitive information in logs/error messages - Insufficient user input validation #### 4c. Performance check - N+1 problem (DB/API queries in loops) - Memory leaks (unreleased event listeners, closure references) - Inefficient algorithms (sections that can be improved to O(n^2) or higher) #### 4d. Code quality - Eliminate duplicate code - Improve naming - Remove unnecessary comments #### 4e. Coverage check 1. Obtain the Coverage Threshold from the Test Framework section of `docs/dev/context.md` 2. Identify the target packages from the Files section of the task file 3. Measure coverage for each package (execute the Coverage Command for each package) 4. Treat `[no test files]` as 0% 5. **If the threshold is not met**: Add tests and re-measure (maximum 3 cycles) 6. **If not met after 3 cycles**: Report as 🟡 and continue (do not block) Re-execute the test and confirm that it remains successful. ### Step 5: Traffic light report + Completion #### Output confidence report Assign a confidence level to each implemented file and report it to the user: ```markdown ## dev-impl Confidence Report ### Coverage Results | Package | Coverage | Threshold | Result | |-----------|----------|------|------| | internal/handler | 85.2% | 80% | OK | ### 🔵 Front-end instructions (low review priority) - [File name](path) — Complies with existing patterns ### 🟡 Valid assumptions (requires confirmation) - [File name](path) — [Points to be checked] ### 🔴 AI inference completion (human confirmation required) - [File name](path) — [Reason for requiring judgment] ``` #### Completion 1. Update the `status` of the task file to `done` 2. Update TodoWrite ### Step 6: Docker cleanup Check if `docker-compose.yml` or `docker-compose.yaml` exists in the project root. If it exists: 1. Execute `docker compose down` to stop the containers 2. Report to the user if the stop fails (do not block) ## Workflow: Quick mode Execute with `/dev-impl "correction instruction"` (no Plan name). ### Purpose - Minor test case modifications + implementation adjustments - Small bug fixes - Adding cases to existing tests - Lightweight refactoring ### Flow 1. Read `docs/dev/context.md` (if it exists) 2. Use the Explore sub-agent (haiku) to explore relevant files 3. Modify tests → Modify implementation (or vice versa) 4. Verify with test execution 5. Check the 500-line rule 6. Output a concise traffic light report 7. Docker cleanup (same as Step 6) ## Strategy based on complexity Switch the strategy based on the `estimated_complexity` in the task file. See `references/impl-strategies.md` for details. | Complexity | Strategy | Test + Implementation | |-------|------|-----------| | low | Batch generation | Generate tests + implementation in one batch and verify with test execution | | medium | Standard cycle | Test → Confirm Red → Implementation → Confirm Green | | high | Incremental | Add one test at a time → Make one Green at a time | ## Sub-agent strategy | Purpose | Sub-agent type | Model | |------|---------------------|--------| | Related code exploration | Explore | haiku | | Test template generation | general-purpose | haiku | | Standard implementation | Main execution | sonnet | | Complex logic | Main execution | opus | ## Intent Comment Rules Add Intent comments to each public function/method in the generated source code to explain the reason for the design decision. ### Traffic light system (🔵🟡🔴) - 🔵 **Front-end instructions**: Design decisions explicitly instructed in the task file, plan.md, or context.md - 🟡 **Valid assumptions**: Design decisions inferred from the instructions (e.g., based on best practices) - 🔴 **AI inference completion**: Design decisions that the AI inferred and supplemented without a basis in the front-end ### Comment format Write in the comment syntax of the language, before each function/method: ```go // 🔵 Intent: Implement the TodoRepository interface specified in the task file. // Use the INSERT and ID retrieval in a single query with the RETURNING clause. func (r *PostgresTodoRepository) Create(ctx context.Context, todo *model.Todo) error { ``` ```go // 🟡 Intent: Wrap with fmt.Errorf according to the error handling convention in context.md. // Allows the service layer to distinguish errors from the repository layer. func (s *TodoService) GetByID(ctx context.Context, id string) (*model.Todo, error) { ``` ```go // 🔴 Intent: Default value for pagination. Not specified in the front-end. // Adopt limit=20 based on the common convention of Web APIs. const defaultPageSize = 20 ``` ### Attachment rules - Add Intent comments to **all public functions/methods** - Add only when there is a design decision for private functions (omit trivial processing) - Do not add to test code - 1 comment = concise, 1-2 lines. Avoid redundant explanations - If adding to existing code, maintain existing Intent comments ## Rules and Constraints - Write tests first. Do not proceed to the next step until the test passes. - All files must be **under 500 lines**. Refactor to split if exceeded. - Before starting, confirm that all tasks in the `dependencies` of the task file are `done`. - If context.md does not exist, guide to `/dev-context` - If the task file does not exist in normal mode, guide to `/dev-plan` - Obtain the test execution command from context.md - Security and performance issues with 🔴 must be corrected before completion - Use absolute paths for Bash commands (obtain the root using `$(git rev-parse --show-toplevel)`) ## Additional Resources ### Reference files - **`references/impl-strategies.md`** — Implementation strategies based on complexity, details of interface-first reading, criteria for applying batch mode