default branch

Author: dsyme

workflows/agentic-wiki-writer.md

@@ -94,7 +94,7 @@ You are a wiki generator for this repository. Your job is to produce high-qualit
 - **Allowed bash commands:** Only `find`, `tree`, `wc`, and read-only commands (`cat`, `ls`, `head`) work. All other bash commands (`git`, `echo >`, `touch`, `cp`, `tee`, `node`, `python`, `install`, `mkdir`) will be denied.
 - **Creating files:** Use the `write` tool. The `.github/agentic-wiki/` directory is pre-created before your session starts. Do NOT try to mkdir any path.
 - **Wiki page output:** Do NOT write wiki pages to disk. Do NOT create output directories. Construct all page content as strings and pass them to the `push-wiki` safe-output as JSON. See Step 3f.
-- **Repo info for source links:** Do NOT use `git` commands. Read `.git/config` with `cat` to find the remote URL. The default branch is `main`.
+- **Repo info for source links:** Do NOT use `git` commands. Read `.git/config` with `cat` to find the remote URL and default branch.
 - **Repo memory path:** Do NOT hardcode the repo-memory path. Discover it by running `ls /tmp/gh-aw/repo-memory/` to find the directory name, then use that path. It is typically `/tmp/gh-aw/repo-memory/default/`. All memory files must be flat (no subdirectories) — you cannot mkdir inside repo-memory.
 - Always use **relative paths** for repo files (e.g., `.github/agentic-wiki/PAGES.md`), never absolute paths.
 
@@ -545,7 +545,7 @@ You may link to directories: `[components/](https://github.com/OWNER/REPO/tree/B
 
 NEVER use bare relative paths like `src/lib/foo.ts` as links — those will 404 on the wiki.
 
-Determine the correct `OWNER/REPO` by reading `.git/config` with `cat` (do NOT use `git` commands — they are blocked). The default branch is `main`.
+Determine the correct `OWNER/REPO` and default branch by reading `.git/config` with `cat` (do NOT use `git` commands — they are blocked).
 
 **Wiki cross-references** — Use wiki link syntax: `[[Page Name]]` or `[[Display Text|Page-Slug#section-slug]]`.
 

workflows/daily-perf-improver.md

@@ -152,7 +152,7 @@ Always do Task 7 (Update Monthly Activity Summary Issue) every run. In all comme
 3. Check for existing performance PRs (especially yours with "[Perf Improver]" prefix). Avoid duplicate work.
 4. For the selected goal:
 
-   a. Create a fresh branch off `main`: `perf-assist/<desc>`.
+   a. Create a fresh branch off the default branch: `perf-assist/<desc>`.
 
    b. **Before implementing**: Establish baseline measurements using appropriate methods:
       - Synthetic benchmarks for algorithm changes

workflows/daily-repo-chronicle.md

@@ -73,7 +73,7 @@ Collect data for the past 30 days (or available data) using GitHub API:
    - Count of PRs closed per day
 
 3. **Commit Activity Data**:
-   - Count of commits per day on main branches
+   - Count of commits per day on the default branch
    - Number of contributors per day
 
 **Phase 2: Data Preparation**
@@ -211,7 +211,7 @@ Transform the last 24 hours of repository activity into a compelling narrative t
 1. Query GitHub for activity in the last 24 hours:
    - Pull requests (opened, merged, closed, updated)
    - Issues (opened, closed, comments)
-   - Commits to main branches
+   - Commits to the default branch
 
 2. **For bot activity, identify human actors:**
    - Check PR/issue assignees to find who initiated the work

workflows/daily-test-improver.md

@@ -155,7 +155,7 @@ Always do Task 7 (Update Monthly Activity Summary Issue) every run. In all comme
 4. **Check for existing coverage pipeline**: Before generating coverage reports yourself, check if the repository has an existing coverage pipeline (CI jobs, coverage services like Codecov/Coveralls, or documented coverage commands). Use the existing pipeline when available - maintainers may rely on it for consistency.
 5. For the selected goal:
 
-   a. Create a fresh branch off `main`: `test-assist/<desc>`.
+   a. Create a fresh branch off the default branch: `test-assist/<desc>`.
 
    b. **Analyze complexity before testing**: Before writing any tests, thoroughly read and understand the implementation. Evaluate function complexity - is this trivial code or complex logic? See "What NOT to Test" in Guidelines. Exception: only test trivial code if the repo has an explicit policy requiring very high coverage.
 

workflows/repo-assist.md

@@ -112,9 +112,9 @@ steps:
       }
 
       weights = {
-          1:  1   + unlabelled,
+          1:  1   + 3 * unlabelled,
           2:  3   + 1 * open_issues,
-          3:  3   + 0.6 * open_issues,
+          3:  3   + 0.7 * open_issues,
           4:  5   + 0.2 * open_issues,
           5:  5   + 0.1 * open_issues,
           6:  float(repo_assist_prs),

workflows/update-docs.md

@@ -53,7 +53,7 @@ Documentation‑as‑Code, transparency, single source of truth, continuous impr
 
 1. **Analyze Repository Changes**
 
-   - On every push to main branch, examine the diff to identify changed/added/removed entities
+   - On every push to the default branch, examine the diff to identify changed/added/removed entities
    - Look for new APIs, functions, classes, configuration files, or significant code changes
    - Check existing documentation for accuracy and completeness
    - Identify documentation gaps like failing tests: a "red build" until fixed
@@ -118,7 +118,7 @@ Documentation‑as‑Code, transparency, single source of truth, continuous impr
 - Exit if no code changes require documentation updates
 - Exit if all documentation is already up-to-date and comprehensive
 
-> NOTE: Never make direct pushes to the main branch. Always create a pull request for documentation changes.
+> NOTE: Never make direct pushes to the default branch. Always create a pull request for documentation changes.
 
 > NOTE: Treat documentation gaps like failing tests.