Update daily-* and weekly-* agentic workflows to use create-discussion instead of create-issue

TODO.md

@@ -0,0 +1,50 @@
+# TODO: Create GitHub Discussion Categories
+
+The agentic workflows have been updated to use GitHub Discussions instead of Issues. Before these workflows can be used, the following discussion categories need to be created in the repository:
+
+## Required Discussion Categories
+
+### 1. Announcements
+- **Slug**: `announcements`
+- **Description**: Important updates and status reports for the project
+- **Used by workflows**:
+  - daily-plan.md
+  - daily-team-status.md
+  - daily-dependency-updates.md
+
+### 2. Ideas
+- **Slug**: `ideas`
+- **Description**: Feature requests, research findings, and improvement proposals
+- **Used by workflows**:
+  - weekly-research.md
+  - daily-test-improver.md
+  - daily-progress.md
+  - daily-perf-improver.md
+  - daily-backlog-burner.md
+
+### 3. Q&A
+- **Slug**: `q-a`
+- **Description**: Questions and quality assurance findings
+- **Used by workflows**:
+  - daily-qa.md
+  - daily-accessibility-review.md
+
+## How to Create Discussion Categories
+
+1. Go to your repository on GitHub
+2. Navigate to the "Discussions" tab
+3. If Discussions are not enabled:
+   - Go to Settings → Features
+   - Enable "Discussions"
+4. Click on the "Categories" section in Discussions
+5. Create the following categories with the exact slugs specified above:
+   - **Announcements** (slug: `announcements`)
+   - **Ideas** (slug: `ideas`)
+   - **Q&A** (slug: `q-a`)
+
+## Notes
+
+- The category slugs must match exactly as specified (e.g., `q-a` not `qa` or `q_a`)
+- GitHub may provide default categories when you first enable Discussions - you can keep those or customize as needed
+- The workflows reference these categories in their `safe-outputs` configuration
+- After creating the categories, compile the workflows using `gh aw compile` to ensure they work correctly

workflows/daily-accessibility-review.md

@@ -11,8 +11,9 @@ permissions: read-all
 network: defaults
 
 safe-outputs:
-  create-issue:
+  create-discussion:
     title-prefix: "${{ github.workflow }}"
+    category: "q-a"
     max: 5
   add-comment:
     max: 5
@@ -54,8 +55,8 @@ Steps:
 If the section "Build and run app in background" already contains actual commands, then go to the next step. If it 
 still contains a placeholder, then:  
    a. Work how to replace it with the actual commands to set up the runtime, install dependencies, build the project and run it in the background, e.g., using `&` at the end of the command.
-   b. Don't actually make the changes (since you're not allowed to make changes under .github/workflows), but rather create an issue showing the exact changes that are needed to the workflow file. Do this by using a markdown codeblock to copy-and-paste into the file, plus a deep link to GitHub to the range of the file to replace.
-   c. In the issue body mention that the user must (1) make these changes manually and (2) then run "gh aw compile" to compile the workflow file using GitHub Agentic Workflows (https://github.com/githubnext/gh-aw).
+   b. Don't actually make the changes (since you're not allowed to make changes under .github/workflows), but rather create a discussion showing the exact changes that are needed to the workflow file. Do this by using a markdown codeblock to copy-and-paste into the file, plus a deep link to GitHub to the range of the file to replace.
+   c. In the discussion body mention that the user must (1) make these changes manually and (2) then run "gh aw compile" to compile the workflow file using GitHub Agentic Workflows (https://github.com/githubnext/gh-aw).
    d. Also instruct them to remove this section from the markdown. 
    e. Exit the workflow with a message saying that the workflow file needs to be updated.
 
@@ -64,7 +65,7 @@ still contains a placeholder, then:
 
 2. Review the source code of the application to look for accessibility issues in the code.  Use the Grep, LS, Read, etc. tools.
 
-3. Use the GitHub MCP tool to create issues for any accessibility problems you find.  Each issue should include:
+3. Use the GitHub MCP tool to create discussions for any accessibility problems you find.  Each discussion should include:
    - A clear description of the problem
    - References to the appropriate section(s) of WCAG 2.2 that are violated
    - Any relevant code snippets that illustrate the issue

workflows/daily-backlog-burner.md

@@ -11,8 +11,9 @@ timeout_minutes: 30
 network: defaults
 
 safe-outputs:
-  create-issue:
+  create-discussion:
     title-prefix: "${{ github.workflow }}"
+    category: "ideas"
     max: 3
   add-comment:
     target: "*" # all issues and PRs
@@ -36,7 +37,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
 
 1. Backlog research (if not done before).
 
-   1a. Check carefully if an open issue with label "daily-backlog-burner-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
+   1a. Check carefully if an open discussion with title starting with "${{ github.workflow }}" exists using `search_discussions`. If it does, read the discussion and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the discussion doesn't exist, follow the steps below to create it:
 
    1b. Do some deep research into the backlog in this repo.
     - Read existing documentation, open issues, open pull requests, project files, dev guides in the repository.
@@ -49,17 +50,17 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
     - Identify any patterns or common themes among the issues, such as recurring bugs, feature requests, or areas of improvement.
     - Look for any issues that may be duplicates or closely related to each other, and consider whether they can be consolidated or linked together.
 
-   1c. Use this research to create an issue with title "${{ github.workflow }} - Research, Roadmap and Plan" and label "daily-backlog-burner-plan". This issue should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
+   1c. Use this research to create a discussion with title "${{ github.workflow }} - Research, Roadmap and Plan". This discussion should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
 
 2. Goal selection: build an understanding of what to work on and select a part of the roadmap to pursue.
 
    2a. You can now assume the repository is in a state where the steps in `.github/actions/daily-progress/build-steps/action.yml` have been run and is ready for you to work on features.
 
-   2b. Read the plan in the issue mentioned earlier, along with comments.
+   2b. Read the plan in the discussion mentioned earlier, along with comments.
 
    2c. Check any existing open pull requests especially any opened by you starting with title "${{ github.workflow }}".
 
-   2d. If you think the plan is inadequate, and needs a refresh, update the planning issue by rewriting the actual body of the issue, ensuring you take into account any comments from maintainers. Add one single comment to the issue saying nothing but the plan has been updated with a one sentence explanation about why. Do not add comments to the issue, just update the body. Then continue to step 3e.
+   2d. If you think the plan is inadequate and needs a refresh, add a comment to the planning discussion with an updated plan, ensuring you take into account any comments from maintainers. Explain in the comment why the plan has been updated. Then continue to step 3e.
 
    2e. Select a goal to pursue from the plan. Ensure that you have a good understanding of the code and the issues before proceeding. Don't work on areas that overlap with any open pull requests you identified.
 
@@ -83,10 +84,10 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
 
    4c. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
 
-5. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
+5. At the end of your work, add a very, very brief comment (at most two-sentences) to the discussion from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
 
 6. If you encounter any unexpected failures or have questions, add 
-comments to the pull request or issue to seek clarification or assistance.
+comments to the pull request or discussion to seek clarification or assistance.
 
 <!-- You can customize prompting and tools in .github/workflows/agentics/daily-progress.config -->
 {{#import? agentics/daily-progress.config.md}}

workflows/daily-dependency-updates.md

@@ -13,8 +13,9 @@ network: defaults
 safe-outputs:
   create-pull-request:
     draft: true
-  create-issue:
+  create-discussion:
     title-prefix: "${{ github.workflow }}"
+    category: "announcements"
 
 # Configure bash build commands here, or in .github/workflows/agentics/daily-dependency-updates.config.md
 #
@@ -37,7 +38,7 @@ Your name is "${{ github.workflow }}". Your job is to act as an agentic coder fo
 
 2. Create a new PR with title "${{ github.workflow }}". Try to bundle as many dependency updates as possible into one PR. Test the changes to ensure they work correctly, if the tests don't pass then work with a smaller number of updates until things are OK. 
 
-> NOTE: If you didn't make progress on particular dependency updates, create one overall issue saying what you've tried, ask for clarification if necessary, and add a link to a new branch containing any investigations you tried.
+> NOTE: If you didn't make progress on particular dependency updates, create one overall discussion saying what you've tried, ask for clarification if necessary, and add a link to a new branch containing any investigations you tried.
 
 <!-- You can customize prompting and tools in .github/workflows/agentics/daily-dependency-updates.config -->
 {{#import? agentics/daily-dependency-updates.config.md}}

workflows/daily-perf-improver.md

@@ -13,8 +13,9 @@ permissions: read-all
 network: defaults
 
 safe-outputs:
-  create-issue:
+  create-discussion:
     title-prefix: "${{ github.workflow }}"
+    category: "ideas"
     max: 5
   add-comment:
     target: "*" # can add a comment to any one single issue or pull request
@@ -59,7 +60,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
 
 1. Performance research (if not done before).
 
-   1a. Check if an open issue with label "daily-perf-improver-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
+   1a. Check if an open discussion with title starting with "${{ github.workflow }}" exists using `search_discussions`. If it does, read the discussion and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the discussion doesn't exist, follow the steps below to create it:
 
    1b. Do some deep research into performance matters in this repo.
      - How is performance testing is done in the repo?
@@ -87,7 +88,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
      Consider perf engineering fundamentals:
      - You want to get to a zone where the engineers can run commands to get numbers towards some performance goal - with commands running reliably within 1min or so - and it can "see" the code paths associated with that. If you can achieve that, your engineers will be very good at finding low-hanging fruit to work towards the performance goals.
 
-     1b. Use this research to create an issue with title "${{ github.workflow }} - Research and Plan" and label "daily-perf-improver-plan", then exit this entire workflow.
+     1b. Use this research to create a discussion with title "${{ github.workflow }} - Research and Plan", then exit this entire workflow.
 
 2. Build steps inference and configuration (if not done before)
 
@@ -107,11 +108,11 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
 
    3a. You can now assume the repository is in a state where the steps in `.github/actions/daily-perf-improver/build-steps/action.yml` have been run and is ready for performance testing, running micro-benchmarks etc. Read this file to understand what has been done. Read any output files such as `build-steps.log` to understand what has been done. If the build steps failed, work out what needs to be fixed in `.github/actions/daily-perf-improver/build-steps/action.yml` and make a pull request for those fixes and exit the entire workflow.
 
-   3b. Read the plan in the issue mentioned earlier, along with comments.
+   3b. Read the plan in the discussion mentioned earlier, along with comments.
 
    3c. Check for existing open pull requests that are related to performance improvements especially any opened by you starting with title "${{ github.workflow }}". Don't repeat work from any open pull requests.
 
-   3d. If you think the plan is inadequate, and needs a refresh, update the planning issue by rewriting the actual body of the issue, ensuring you take into account any comments from maintainers. Add one single comment to the issue saying nothing but the plan has been updated with a one sentence explanation about why. Do not add comments to the issue, just update the body. Then continue to step 3e.
+   3d. If you think the plan is inadequate and needs a refresh, add a comment to the planning discussion with an updated plan, ensuring you take into account any comments from maintainers. Explain in the comment why the plan has been updated. Then continue to step 3e.
 
    3e. Select a performance improvement goal to pursue from the plan. Ensure that you have a good understanding of the code and the performance issues before proceeding.
 
@@ -170,7 +171,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
 
    5d. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
 
-6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
+6. At the end of your work, add a very, very brief comment (at most two-sentences) to the discussion from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
 
 <!-- You can customize prompting and tools in .github/workflows/agentics/daily-perf-improver.config -->
 {{#import? agentics/daily-perf-improver.config.md}}

workflows/daily-plan.md

@@ -13,11 +13,9 @@ permissions: read-all
 network: defaults
 
 safe-outputs:
-  create-issue: # needed to create the project plan issue
+  create-discussion: # needed to create the project plan discussion
     title-prefix: "${{ github.workflow }}"
-  update-issue: # needed to update the project plan issue if it already exists
-    target: "*" # can update one single issue
-    body: # can update the issue body only
+    category: "announcements"
 
 tools:
   web-fetch:
@@ -34,21 +32,21 @@ Your job is to act as a planner for the GitHub repository ${{ github.repository
 
 1. First study the state of the repository including, open issues, pull requests, completed issues.
 
-   1a. As part of this, look for the open issue labelled "project-plan", which is the existing project plan. Read the plan, and any comments on the plan. If no issue is labelled "project-plan" ignore this step.
+   1a. As part of this, look for the open discussion with title starting with "${{ github.workflow }}", which is the existing project plan. Read the plan, and any comments on the plan. If no such discussion exists, ignore this step.
 
    1b. You can read code, search the web and use other tools to help you understand the project and its requirements.
 
 2. Formulate a plan for the remaining work to achieve the objectives of the project.
 
    2a. The project plan should be a clear, concise, succinct summary of the current state of the project, including the issues that need to be completed, their priority, and any dependencies between them.
 
-   2b. The project plan should be written into the issue body itself, not as a comment. If comments have been added to the project plan, take them into account and note this in the project plan. Never add comments to the project plan issue.
+   2b. The project plan should be written into the discussion body itself, not as a comment. If comments have been added to the project plan, take them into account and note this in the project plan. Never add comments to the project plan discussion.
 
    2c. In the plan, list suggested issues to create to match the proposed updated plan. Don't create any issues, just list the suggestions. Do this by showing `gh` commands to create the issues with labels and complete bodies, but don't actually create them. Don't include suggestions for issues that already exist, only new things required as part of the plan!
 
-3. You will either create or update the planning issue so it contains a project plan in its body. 
+3. Create a new planning discussion with the project plan in its body. 
 
-   3a. If in step (1a) you found a "project plan" issue, update its body with the project plan. If in step (1a) you didn't find a "project issue", create one with an appropriate title starting with "${{ github.workflow }}", using the project plan as the body, and ensure the issue is labelled with "project-plan".
+   3a. Create a discussion with an appropriate title starting with "${{ github.workflow }}" and the current date (e.g., "Daily Plan - 2025-10-10"), using the project plan as the body.
 
 
 <!-- You can customize prompting and tools in .github/workflows/agentics/daily-plan.config -->