diff --git a/.github/workflows/daily-file-diet.lock.yml b/.github/workflows/daily-file-diet.lock.yml index cffcecde1c..0cccb03606 100644 --- a/.github/workflows/daily-file-diet.lock.yml +++ b/.github/workflows/daily-file-diet.lock.yml @@ -713,23 +713,53 @@ jobs: If refactoring is needed (file ≥ 800 lines), create an issue with this structure: - ```markdown - # Refactor Large Go File: [FILE_PATH] + #### Markdown Formatting Guidelines + + **IMPORTANT**: Follow these formatting rules to ensure consistent, readable issue reports: + + 1. **Header Levels**: Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy. The issue title serves as h1, so start section headers at h3. + + 2. **Progressive Disclosure**: Wrap detailed file analysis, code snippets, and lengthy explanations in `
Section Name` tags to improve readability and reduce overwhelm. This keeps the most important information immediately visible while allowing readers to expand sections as needed. + + 3. **Issue Structure**: Follow this pattern for optimal clarity: + - **Brief summary** of the file size issue (always visible) + - **Key metrics** (LOC, complexity, test coverage) (always visible) + - **Detailed file structure analysis** (in `
` tags) + - **Refactoring suggestions** (always visible) - ## Overview + These guidelines build trust through clarity, exceed expectations with helpful context, create delight through progressive disclosure, and maintain consistency with other reporting workflows. + + #### Issue Template + + ```markdown + ### Overview The file `[FILE_PATH]` has grown to [LINE_COUNT] lines, making it difficult to maintain and test. This task involves refactoring it into smaller, focused files with improved test coverage. - ## Current State + ### Current State - **File**: `[FILE_PATH]` - **Size**: [LINE_COUNT] lines - **Test Coverage**: [RATIO or "No test file found"] - **Complexity**: [Brief assessment from Serena analysis] - ## Refactoring Strategy +
+ Full File Analysis + + #### Detailed Breakdown - ### Proposed File Splits + [Provide detailed semantic analysis from Serena here: + - Function count and distribution + - Complexity hotspots + - Duplicate or similar code patterns + - Areas with high coupling + - Specific line number references for complex sections] + +
+ + ### Refactoring Strategy + + #### Proposed File Splits Based on semantic analysis, split the file into the following modules: @@ -748,17 +778,18 @@ jobs: - Responsibility: [description] - Estimated LOC: [count] - ### Shared Utilities + #### Shared Utilities Extract common functionality into: - **`[utility_file].go`**: [description] - ### Interface Abstractions + #### Interface Abstractions Consider introducing interfaces to reduce coupling: - [Interface suggestions] - ## Test Coverage Plan +
+ Test Coverage Plan Add comprehensive tests for each new file: @@ -774,7 +805,9 @@ jobs: - Test cases: [list key scenarios] - Target coverage: >80% - ## Implementation Guidelines +
+ + ### Implementation Guidelines 1. **Preserve Behavior**: Ensure all existing functionality works identically 2. **Maintain Exports**: Keep public API unchanged (exported functions/types) @@ -784,7 +817,7 @@ jobs: 6. **Update Imports**: Ensure all import paths are correct 7. **Document Changes**: Add comments explaining module boundaries - ## Acceptance Criteria + ### Acceptance Criteria - [ ] Original file is split into [N] focused files - [ ] Each new file is under 500 lines @@ -794,16 +827,19 @@ jobs: - [ ] Code passes linting (`make lint`) - [ ] Build succeeds (`make build`) - ## Additional Context +
+ Additional Context - **Repository Guidelines**: Follow patterns in `.github/agents/developer.instructions.agent.md` - **Code Organization**: Prefer many small files grouped by functionality - **Testing**: Match existing test patterns in `pkg/workflow/*_test.go` +
+ --- - **Priority**: Medium - **Effort**: [Estimate: Small/Medium/Large based on complexity] + **Priority**: Medium + **Effort**: [Estimate: Small/Medium/Large based on complexity] **Expected Impact**: Improved maintainability, easier testing, reduced complexity ``` diff --git a/.github/workflows/daily-file-diet.md b/.github/workflows/daily-file-diet.md index a2225d6e69..5ed2c676a5 100644 --- a/.github/workflows/daily-file-diet.md +++ b/.github/workflows/daily-file-diet.md @@ -119,23 +119,53 @@ Calculate: If refactoring is needed (file ≥ 800 lines), create an issue with this structure: -```markdown -# Refactor Large Go File: [FILE_PATH] +#### Markdown Formatting Guidelines + +**IMPORTANT**: Follow these formatting rules to ensure consistent, readable issue reports: + +1. **Header Levels**: Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy. The issue title serves as h1, so start section headers at h3. + +2. **Progressive Disclosure**: Wrap detailed file analysis, code snippets, and lengthy explanations in `
Section Name` tags to improve readability and reduce overwhelm. This keeps the most important information immediately visible while allowing readers to expand sections as needed. + +3. **Issue Structure**: Follow this pattern for optimal clarity: + - **Brief summary** of the file size issue (always visible) + - **Key metrics** (LOC, complexity, test coverage) (always visible) + - **Detailed file structure analysis** (in `
` tags) + - **Refactoring suggestions** (always visible) + +These guidelines build trust through clarity, exceed expectations with helpful context, create delight through progressive disclosure, and maintain consistency with other reporting workflows. + +#### Issue Template -## Overview +```markdown +### Overview The file `[FILE_PATH]` has grown to [LINE_COUNT] lines, making it difficult to maintain and test. This task involves refactoring it into smaller, focused files with improved test coverage. -## Current State +### Current State - **File**: `[FILE_PATH]` - **Size**: [LINE_COUNT] lines - **Test Coverage**: [RATIO or "No test file found"] - **Complexity**: [Brief assessment from Serena analysis] -## Refactoring Strategy +
+Full File Analysis + +#### Detailed Breakdown + +[Provide detailed semantic analysis from Serena here: +- Function count and distribution +- Complexity hotspots +- Duplicate or similar code patterns +- Areas with high coupling +- Specific line number references for complex sections] + +
-### Proposed File Splits +### Refactoring Strategy + +#### Proposed File Splits Based on semantic analysis, split the file into the following modules: @@ -154,17 +184,18 @@ Based on semantic analysis, split the file into the following modules: - Responsibility: [description] - Estimated LOC: [count] -### Shared Utilities +#### Shared Utilities Extract common functionality into: - **`[utility_file].go`**: [description] -### Interface Abstractions +#### Interface Abstractions Consider introducing interfaces to reduce coupling: - [Interface suggestions] -## Test Coverage Plan +
+Test Coverage Plan Add comprehensive tests for each new file: @@ -180,7 +211,9 @@ Add comprehensive tests for each new file: - Test cases: [list key scenarios] - Target coverage: >80% -## Implementation Guidelines +
+ +### Implementation Guidelines 1. **Preserve Behavior**: Ensure all existing functionality works identically 2. **Maintain Exports**: Keep public API unchanged (exported functions/types) @@ -190,7 +223,7 @@ Add comprehensive tests for each new file: 6. **Update Imports**: Ensure all import paths are correct 7. **Document Changes**: Add comments explaining module boundaries -## Acceptance Criteria +### Acceptance Criteria - [ ] Original file is split into [N] focused files - [ ] Each new file is under 500 lines @@ -200,16 +233,19 @@ Add comprehensive tests for each new file: - [ ] Code passes linting (`make lint`) - [ ] Build succeeds (`make build`) -## Additional Context +
+Additional Context - **Repository Guidelines**: Follow patterns in `.github/agents/developer.instructions.agent.md` - **Code Organization**: Prefer many small files grouped by functionality - **Testing**: Match existing test patterns in `pkg/workflow/*_test.go` +
+ --- -**Priority**: Medium -**Effort**: [Estimate: Small/Medium/Large based on complexity] +**Priority**: Medium +**Effort**: [Estimate: Small/Medium/Large based on complexity] **Expected Impact**: Improved maintainability, easier testing, reduced complexity ``` diff --git a/pkg/cli/templates/create-agentic-workflow.md b/pkg/cli/templates/create-agentic-workflow.md index 161444b155..1b31386fde 100644 --- a/pkg/cli/templates/create-agentic-workflow.md +++ b/pkg/cli/templates/create-agentic-workflow.md @@ -181,7 +181,7 @@ DO NOT ask all these questions at once; instead, engage in a back-and-forth conv - 📋 **DO NOT include other fields with good defaults** - Let the compiler use sensible defaults unless customization is needed. - Apply security best practices: - Default to `permissions: read-all` and expand only if necessary. - - Prefer `safe-outputs` (`create-issue`, `add-comment`, `create-pull-request`, `create-pull-request-review-comment`, `update-issue`) over granting write perms. + - Prefer `safe-outputs` (`create-issue`, `add-comment`, `create-pull-request`, `create-pull-request-review-comment`, `update-issue`, `dispatch-workflow`) over granting write perms. - For custom write operations to external services (email, Slack, webhooks), use `safe-outputs.jobs:` to create custom safe output jobs. - Constrain `network:` to the minimum required ecosystems/domains. - Use sanitized expressions (`${{ needs.activation.outputs.text }}`) instead of raw event text. diff --git a/pkg/cli/templates/create-shared-agentic-workflow.md b/pkg/cli/templates/create-shared-agentic-workflow.md index 76e0675728..577bc3660c 100644 --- a/pkg/cli/templates/create-shared-agentic-workflow.md +++ b/pkg/cli/templates/create-shared-agentic-workflow.md @@ -34,7 +34,7 @@ You are a conversational chat agent that interacts with the user to design secur **Move Write Operations to Safe Outputs** - Never grant direct write permissions in shared components - Use `safe-outputs:` configuration for all write operations -- Common safe outputs: `create-issue`, `add-comment`, `create-pull-request`, `update-issue` +- Common safe outputs: `create-issue`, `add-comment`, `create-pull-request`, `update-issue`, `dispatch-workflow` - Let consuming workflows decide which safe outputs to enable **Process Agent Output in Safe Jobs** diff --git a/pkg/cli/templates/github-agentic-workflows.md b/pkg/cli/templates/github-agentic-workflows.md index 0724608609..f350e65b03 100644 --- a/pkg/cli/templates/github-agentic-workflows.md +++ b/pkg/cli/templates/github-agentic-workflows.md @@ -568,6 +568,14 @@ The YAML frontmatter supports these fields: target-repo: "owner/repo" # Optional: cross-repository ``` Publishes workflow artifacts to an orphaned git branch for persistent storage. Default allowed extensions include common non-executable types. Maximum file size is 50MB (51200 KB). + - `dispatch-workflow:` - Trigger other workflows with inputs + ```yaml + safe-outputs: + dispatch-workflow: + workflows: [workflow-name] # Required: list of workflow names to allow + max: 3 # Optional: max dispatches (default: 1, max: 3) + ``` + Triggers other agentic workflows in the same repository using workflow_dispatch. Agent output includes `workflow_name` (without .md extension) and optional `inputs` (key-value pairs). Not supported for cross-repository operations. - `create-code-scanning-alert:` - Generate SARIF security advisories ```yaml safe-outputs: