diff --git a/README.md b/README.md index a070bf1..f0a6a37 100644 --- a/README.md +++ b/README.md @@ -48,6 +48,7 @@ You can use the "/plan" agent to turn the reports into actionable issues which c ### Code Improvement Workflows (by making changes, producing pull requests) - [๐Ÿ“– Regular Documentation Update](docs/update-docs.md) - Update documentation automatically +- [๐Ÿ“– Daily Documentation Updater](docs/daily-doc-updater.md) - Automatically update documentation based on recent code changes and merged PRs - [โœจ Code Simplifier](docs/code-simplifier.md) - Automatically simplify recently modified code for improved clarity and maintainability - [โšก Daily Progress](docs/daily-progress.md) - Automated daily feature development following a structured roadmap - [๐Ÿงช Daily Test Coverage Improver](docs/daily-test-improver.md) - Improve test coverage by adding meaningful tests to under-tested areas diff --git a/docs/daily-doc-updater.md b/docs/daily-doc-updater.md new file mode 100644 index 0000000..9961067 --- /dev/null +++ b/docs/daily-doc-updater.md @@ -0,0 +1,92 @@ +# ๐Ÿ“– Daily Documentation Updater + +> For an overview of all available workflows, see the [main README](../README.md). + +The [Daily Documentation Updater workflow](../workflows/daily-doc-updater.md?plain=1) automatically reviews and updates documentation based on recent code changes and merged pull requests. It scans for changes in the last 24 hours and updates documentation to reflect new features, modifications, or deprecations. + +## Installation + +```bash +# Install the 'gh aw' extension +gh extension install github/gh-aw + +# Add the workflow to your repository +gh aw add-wizard githubnext/agentics/daily-doc-updater +``` + +This walks you through adding the workflow to your repository. + +You can start a run of this workflow immediately by running: + +```bash +gh aw run daily-doc-updater +``` + +## Configuration + +This workflow requires no configuration and works out of the box. It automatically: +- Scans for merged PRs from the last 24 hours +- Identifies documentation gaps +- Follows your repository's existing documentation structure and style +- Creates pull requests with documentation updates + +You can edit the workflow to customize: +- The time range for scanning changes +- Which types of changes to document +- The documentation update criteria +- PR title prefix and labels + +After editing, run `gh aw compile` to apply your changes. + +## What it reads from GitHub + +- Merged pull requests from the last 24 hours +- Recent commits and their details +- Pull request descriptions and comments +- Code changes and diffs + +## What it creates + +- Pull requests with documentation updates +- Updated markdown documentation files + +## Human in the loop + +- **Pull Request Review**: All documentation changes are submitted as pull requests for review before merging +- **Manual Approval**: A human reviewer can verify accuracy, completeness, and appropriateness of documentation updates +- **Draft PRs**: Configure `draft: true` in the workflow to require explicit promotion to ready-for-review + +## Use Cases + +1. **Continuous Documentation**: Keep documentation synchronized with code changes automatically +2. **Feature Release Documentation**: Ensure new features are documented when they're merged +3. **API Changes**: Document API modifications, deprecations, and breaking changes +4. **Changelog Maintenance**: Help maintain up-to-date changelogs or release notes +5. **Developer Onboarding**: Ensure new developers always have current documentation + +## Why It's Valuable + +- **Reduces Documentation Debt**: Catches documentation gaps before they accumulate +- **Maintains Documentation Quality**: Keeps docs synchronized with code changes +- **Saves Developer Time**: Automates the tedious task of documentation maintenance +- **Improves User Experience**: Ensures users have access to current, accurate documentation +- **High Success Rate**: With a 96% merge rate in production use, this workflow consistently produces valuable documentation updates + +## Activity Duration + +Typical workflow execution takes 10-20 minutes depending on: +- Number of recent pull requests +- Size of the repository +- Complexity of documentation updates + +## Example Workflow Run + +A typical run might: +1. Scan the last 24 hours and find 3 merged PRs +2. Identify that PR #123 added a new command-line flag +3. Locate the CLI documentation file +4. Add documentation for the new flag with usage examples +5. Create a PR titled "[docs] Update documentation for features from 2026-02-15" +6. Include links to the original PR that added the feature + +The resulting PR would be reviewed and merged, keeping documentation current. diff --git a/docs/daily-repo-status.md b/docs/daily-repo-status.md index 7b42188..89d7f3e 100644 --- a/docs/daily-repo-status.md +++ b/docs/daily-repo-status.md @@ -24,7 +24,7 @@ gh aw run daily-repo-status ## Configuration -This workflow requires no configuration and works out of the box. You can use edit the workflow to customize triage criteria, labeling logic, customize issue categorization, modify automated responses. +This workflow requires no configuration and works out of the box. You can edit the workflow to customize triage criteria, labeling logic, customize issue categorization, modify automated responses. ## What it reads from GitHub diff --git a/docs/update-docs.md b/docs/update-docs.md index 72a96a7..6470366 100644 --- a/docs/update-docs.md +++ b/docs/update-docs.md @@ -2,7 +2,7 @@ > For an overview of all available workflows, see the [main README](../README.md). -The [update documentation workflow](../workflows/update-docs.md?plain=1) will run on each push to main to try to update documentation in the repository. It defaults to using [Astro Starlight] (https://starlight.astro.build) for documentation generation, but you can edit it to use other frameworks if necessary. +The [update documentation workflow](../workflows/update-docs.md?plain=1) will run on each push to main to try to update documentation in the repository. It defaults to using [Astro Starlight](https://starlight.astro.build) for documentation generation, but you can edit it to use other frameworks if necessary. ## Installation diff --git a/workflows/daily-doc-updater.md b/workflows/daily-doc-updater.md new file mode 100644 index 0000000..1599ff6 --- /dev/null +++ b/workflows/daily-doc-updater.md @@ -0,0 +1,181 @@ +--- +name: Daily Documentation Updater +description: Automatically reviews and updates documentation based on recent code changes +on: + schedule: + # Every day at a random time + - cron: daily + workflow_dispatch: + +permissions: + contents: read + issues: read + pull-requests: read + +engine: copilot + +tools: + github: + toolsets: [default] + edit: + bash: true + +timeout-minutes: 30 + +category: maintenance + +safe-outputs: + create-pull-request: + expires: 2d + title-prefix: "[docs] " + labels: [documentation, automation] + draft: false + +--- + +# Daily Documentation Updater + +You are an AI documentation agent that automatically updates project documentation based on recent code changes and merged pull requests. + +## Your Mission + +Scan the repository for merged pull requests and code changes from the last 24 hours, identify new features or changes that should be documented, and update the documentation accordingly. + +## Task Steps + +### 1. Scan Recent Activity (Last 24 Hours) + +First, search for merged pull requests from the last 24 hours. + +Use the GitHub tools to: +- Calculate yesterday's date: `date -u -d "1 day ago" +%Y-%m-%d` +- Search for pull requests merged in the last 24 hours using `search_pull_requests` with a query like: `repo:${{ github.repository }} is:pr is:merged merged:>=YYYY-MM-DD` (replace YYYY-MM-DD with yesterday's date) +- Get details of each merged PR using `pull_request_read` +- Review commits from the last 24 hours using `list_commits` +- Get detailed commit information using `get_commit` for significant changes + +### 2. Analyze Changes + +For each merged PR and commit, analyze: + +- **Features Added**: New functionality, commands, options, tools, or capabilities +- **Features Removed**: Deprecated or removed functionality +- **Features Modified**: Changed behavior, updated APIs, or modified interfaces +- **Breaking Changes**: Any changes that affect existing users + +Create a summary of changes that should be documented. + +### 3. Identify Documentation Location + +Determine where documentation is located in this repository: +- Check for `docs/` directory +- Check for `README.md` files +- Check for `*.md` files in root or subdirectories +- Look for documentation conventions in the repository + +Use bash commands to explore documentation structure: + +```bash +# Find all markdown files +find . -name "*.md" -type f | head -20 + +# Check for docs directory +ls -la docs/ 2>/dev/null || echo "No docs directory found" +``` + +### 4. Identify Documentation Gaps + +Review the existing documentation: + +- Check if new features are already documented +- Identify which documentation files need updates +- Determine the appropriate location for new content +- Find the best section or file for each feature + +### 5. Update Documentation + +For each missing or incomplete feature documentation: + +1. **Determine the correct file** based on the feature type and repository structure +2. **Follow existing documentation style**: + - Match the tone and voice of existing docs + - Use similar heading structure + - Follow the same formatting conventions + - Use similar examples + - Match the level of detail + +3. **Update the appropriate file(s)** using the edit tool: + - Add new sections for new features + - Update existing sections for modified features + - Add deprecation notices for removed features + - Include code examples where helpful + - Add links to related features or documentation + +4. **Maintain consistency** with existing documentation + +### 6. Create Pull Request + +If you made any documentation changes: + +1. **Call the safe-outputs create-pull-request tool** to create a PR +2. **Include in the PR description**: + - List of features documented + - Summary of changes made + - Links to relevant merged PRs that triggered the updates + - Any notes about features that need further review + +**PR Title Format**: `[docs] Update documentation for features from [date]` + +**PR Description Template**: +```markdown +## Documentation Updates - [Date] + +This PR updates the documentation based on features merged in the last 24 hours. + +### Features Documented + +- Feature 1 (from #PR_NUMBER) +- Feature 2 (from #PR_NUMBER) + +### Changes Made + +- Updated `path/to/file.md` to document Feature 1 +- Added new section in `path/to/file.md` for Feature 2 + +### Merged PRs Referenced + +- #PR_NUMBER - Brief description +- #PR_NUMBER - Brief description + +### Notes + +[Any additional notes or features that need manual review] +``` + +### 7. Handle Edge Cases + +- **No recent changes**: If there are no merged PRs in the last 24 hours, exit gracefully without creating a PR +- **Already documented**: If all features are already documented, exit gracefully +- **Unclear features**: If a feature is complex and needs human review, note it in the PR description but include basic documentation +- **No documentation directory**: If there's no obvious documentation location, document in README.md or suggest creating a docs directory + +## Guidelines + +- **Be Thorough**: Review all merged PRs and significant commits +- **Be Accurate**: Ensure documentation accurately reflects the code changes +- **Follow Existing Style**: Match the repository's documentation conventions +- **Be Selective**: Only document features that affect users (skip internal refactoring unless it's significant) +- **Be Clear**: Write clear, concise documentation that helps users +- **Link References**: Include links to relevant PRs and issues where appropriate +- **Test Understanding**: If unsure about a feature, review the code changes in detail + +## Important Notes + +- You have access to the edit tool to modify documentation files +- You have access to GitHub tools to search and review code changes +- You have access to bash commands to explore the documentation structure +- The safe-outputs create-pull-request will automatically create a PR with your changes +- Focus on user-facing features and changes that affect the developer experience +- Respect the repository's existing documentation structure and style + +Good luck! Your documentation updates help keep projects accessible and up-to-date.