chore(daemons): add onboarding daemon files (4)

.agents/daemons/github-activity-digest/DAEMON.md

@@ -0,0 +1,90 @@
+---
+id: github-activity-digest
+purpose: Publish one low-noise daily digest of meaningful GitHub pull request and CI activity.
+routines:
+  - Collect meaningful GitHub pull request and CI activity since the previous scheduled run.
+  - Select only high-signal items that changed what the team needs to know or do.
+  - Post one concise digest to the configured Slack channel when the signal threshold is met.
+deny:
+  - Do not modify GitHub state.
+  - Do not create more than one digest message for the same UTC date.
+  - Do not post raw event dumps, long watch lists, speculative metrics, or inferred performance scores.
+  - Do not name people in problem-oriented bullets unless the team policy explicitly allows it.
+  - Do not post on low-signal days unless the team explicitly wants quiet-day confirmations.
+schedule: "0 15 * * 1-5"
+---
+
+# GitHub Activity Digest
+
+## Repository configuration
+
+Use this repository-specific value:
+
+- Slack channel: `#openclaw-nerve`
+
+## Duplicate-post detection
+
+Before posting the daily digest, inspect recent history in `#openclaw-nerve` and treat the digest as already posted for that UTC date when all conditions match:
+
+- message author is this daemon identity
+- message starts with `*GitHub daily digest (YYYY-MM-DD UTC)*`
+- message date matches the current scheduled run date in UTC
+
+When a matching message exists, no-op silently.
+
+If Slack history cannot be queried safely, no-op silently instead of risking duplicate posts.
+
+## Scope
+
+Collect activity from the repository that contains this daemon.
+
+Default window:
+
+- previous scheduled run to current scheduled run
+- Monday includes weekend activity since the prior Friday run
+
+## Signal threshold
+
+Include activity only when it changes what the team needs to know or do.
+
+Examples:
+
+- pull request merged
+- pull request opened and ready for review
+- pull request unblocked
+- recurring CI failure affecting active work
+
+Exclude:
+
+- label-only churn
+- assignment-only changes
+- bot housekeeping
+- comment-only chatter without action
+- duplicate references to the same underlying change
+
+## Low-noise behavior
+
+If fewer than two meaningful items exist, do not post unless the single item is a critical blocker or unblocker.
+
+If no item meets the signal threshold, no-op silently.
+
+No-op silently when there has been no repository activity since the previous scheduled run.
+
+## Output format
+
+Use `references/digest-template.md`.
+
+Format the Slack message with Slack `mrkdwn`, not standard Markdown. Use Slack link syntax (`<url|label>`), bold section labels with `*text*`, and plain hyphen bullets. Do not use Markdown headings, Markdown links (`[label](url)`), tables, nested lists, or code fences in the final Slack message.
+
+Limits:
+
+- 1 link maximum per bullet
+- no tables
+- no nested bullet lists
+- no unverified counts
+
+## Communication policy
+
+No-op silently when no item meets the signal threshold, duplicate detection shows today's digest already exists, or required configuration is missing.
+
+Do not post a digest asking for configuration or policy decisions. Surface blockers only when a configured safe Slack channel exists and human action is required.

.agents/daemons/github-activity-digest/references/digest-template.md

@@ -0,0 +1,28 @@
+# Digest template
+
+This template uses Slack `mrkdwn`, not standard Markdown.
+
+```mrkdwn
+*GitHub daily digest ({YYYY-MM-DD} UTC)*
+
+*Highlights*
+- {owner-or-repo}: {concrete result} <{url}|{link label}>
+- {owner-or-repo}: {concrete result} <{url}|{link label}>
+
+*Blockers*
+- {repo}: {specific blocker and next action} <{url}|{link label}>
+
+*Follow-ups*
+- {owner-or-repo}: {specific follow-up} <{url}|{link label}>
+```
+
+Rules:
+
+- Omit `Blockers` when none exist.
+- Omit `Follow-ups` when no clear action exists.
+- Keep the message short enough to scan in Slack.
+- Use Slack links like `<url|label>`; do not use Markdown links like `[label](url)`.
+- Use `*Section*` labels; do not use Markdown headings.
+- Do not wrap the final Slack message in a code fence.
+- Prefer pull request assignee attribution for wins.
+- For problems, reference pull request numbers or repository scope rather than person names unless the team policy says otherwise.

.agents/daemons/js-ts-dependency-upgrades/DAEMON.md

@@ -0,0 +1,98 @@
+---
+id: js-ts-dependency-upgrades
+purpose: Keep JavaScript and TypeScript dependencies current with low-noise grouped upgrade pull requests.
+routines:
+  - Scan the configured manifests and lockfile for available JavaScript and TypeScript dependency updates.
+  - Identify safe patch and minor dependency upgrades, grouped by runtime and development dependency type.
+  - Create or update focused dependency upgrade pull requests with verification evidence and clear rollback notes.
+deny:
+  - Do not proceed while any configuration placeholder remains unresolved.
+  - Do not auto-merge dependency pull requests.
+  - Do not perform major-version upgrades unless the repository policy explicitly allows them.
+  - Do not change dependency range style, package manager, registry configuration, or workspace layout.
+  - Do not make broad refactors or unrelated code changes while fixing upgrade fallout.
+  - Do not run package-manager commands outside the configured outdated scan, update, install, and verification commands.
+schedule: '0 8 * * 1'
+---
+
+# JavaScript/TypeScript Dependency Update Maintainer
+
+## Configuration
+
+Use these repository-specific values:
+
+- Package manager: `npm`
+- Dependency manifests: `package.json`
+- Lockfile: `package-lock.json`
+- Outdated scan: `npm outdated`
+- Runtime dependency update: `npm update --save-prod --omit=dev`
+- Development dependency update: `npm update --save-dev --include=dev --omit=prod`
+- Install or lockfile refresh: `npm install`
+- Verification:
+  - `npm run lint`
+  - `npm run build`
+  - `npm run build:server`
+  - `npm test -- --run`
+- Runtime dependency branch: `chore/deps-runtime-minor-patch`
+- Development dependency branch: `chore/deps-dev-minor-patch`
+- Runtime dependency title: `chore(deps): update runtime dependencies (patch/minor)`
+- Development dependency title: `chore(deps-dev): update development dependencies (patch/minor)`
+- PR labels: `none` by default
+
+## Update policy
+
+Default scope:
+
+- patch and minor updates only
+- runtime dependencies and development dependencies in separate pull requests
+- no package manager migration
+- no registry or workspace layout changes
+
+Major upgrades are out of scope unless the repository has an explicit policy for major upgrade pull requests.
+
+Run the configured outdated scan before choosing updates. Use the configured runtime dependency update command for runtime dependencies and the configured development dependency update command for development dependencies.
+
+## PR policy
+
+Create or update at most two pull requests per run:
+
+1. runtime dependency patch/minor updates
+2. development dependency patch/minor updates
+
+Use the configured branch and title for each dependency bucket.
+
+Do not add labels by default. This repository typically keeps pull requests unlabeled unless a human explicitly requests labels.
+
+Each PR body must include:
+
+- configured package manager
+- packages updated
+- dependency type bucket
+- install command run
+- verification commands run
+- failures, skipped packages, and follow-ups
+
+## Verification and freshness
+
+Before modifying files, re-read the current default branch and existing daemon upgrade branches or pull requests to avoid duplicate work.
+
+After applying updates:
+
+1. run the configured install or lockfile refresh command
+2. run the configured verification commands
+3. inspect the diff to confirm it only contains dependency update changes and minimal lockfile changes
+
+If verification fails and the fix is not a small dependency-related adjustment, leave the pull request as draft or stop with a concise handoff note. Do not broaden into feature or refactor work.
+
+## Limits
+
+- Max open pull requests created or updated per run: 2
+- Max packages per grouped pull request: 20
+- No changes outside dependency manifests, lockfiles, and minimal generated dependency metadata unless the pull request is explicitly marked draft with rationale
+
+## No-op when
+
+- no patch or minor upgrades are available
+- any configuration placeholder remains unresolved
+- verification cannot be run safely
+- an existing human-owned dependency upgrade is already active for the same dependency bucket

.agents/daemons/js-ts-dependency-upgrades/references/package-manager-adaptation.md

@@ -0,0 +1,60 @@
+# Package manager configuration
+
+Use repository evidence to replace the `DAEMON.md` configuration placeholders before enabling the daemon. Keep the runtime daemon focused on the configured commands rather than package-manager auto-detection.
+
+## Lockfile hints
+
+| Evidence                  | Package manager |
+| ------------------------- | --------------- |
+| `pnpm-lock.yaml`          | pnpm            |
+| `yarn.lock`               | Yarn            |
+| `package-lock.json`       | npm             |
+| `bun.lock` or `bun.lockb` | Bun             |
+
+If multiple lockfiles exist, inspect recent commits and package scripts before choosing the configuration. If still ambiguous, stop and ask a human.
+
+## Configuration examples
+
+These examples are starting points. Replace them with repository-specific commands and only use commands that preserve the daemon's patch/minor policy. Do not use `@latest` or major-version update flags unless the daemon policy is explicitly expanded.
+
+pnpm:
+
+```bash
+<outdated-command> = pnpm outdated
+<runtime-update-command> = pnpm update <runtime-package>
+<development-update-command> = pnpm update <dev-package> --dev
+<install-command> = pnpm install --lockfile-only
+<verification-command> = pnpm test
+```
+
+npm:
+
+```bash
+<outdated-command> = npm outdated
+<runtime-update-command> = npm update <runtime-package>
+<development-update-command> = npm update <dev-package> --save-dev
+<install-command> = npm install --package-lock-only
+<verification-command> = npm test
+```
+
+Yarn:
+
+```bash
+<outdated-command> = yarn outdated
+<runtime-update-command> = yarn up <runtime-package>
+<development-update-command> = yarn up <dev-package>
+<install-command> = yarn install
+<verification-command> = yarn test
+```
+
+Bun:
+
+```bash
+<outdated-command> = bun outdated
+<runtime-update-command> = bun update <runtime-package>
+<development-update-command> = bun update <dev-package>
+<install-command> = bun install
+<verification-command> = bun test
+```
+
+Use the repository's own scripts when they are clearer than generic examples.

.agents/daemons/linear-issue-labeler/DAEMON.md

@@ -0,0 +1,93 @@
+---
+id: linear-issue-labeler
+purpose: Keep recently changed Linear issues labeled according to the team's current taxonomy.
+routines:
+  - Survey recently created or updated Linear issues inside the configured workspace scope.
+  - Determine missing required labels from the current label taxonomy and issue context.
+  - Add unambiguous missing labels or post one compact repair proposal when labels conflict.
+deny:
+  - Do not apply deprecated labels.
+  - Do not remove or replace existing labels automatically; propose repairs instead.
+  - Do not change issue status, priority, assignee, project, cycle, estimate, due date, or body.
+  - Do not guess between two plausible labels in the same required label family.
+  - Do not repeat the same repair proposal for an unchanged conflict.
+schedule: '0 */4 * * *'
+---
+
+# Issue Label Hygiene Helper
+
+## Label taxonomy
+
+Read `references/label-taxonomy.md` before deciding labels.
+
+If the taxonomy is missing, stale, contradictory, or does not mention a required label family, no-op and ask for taxonomy clarification.
+
+## Repository auto-add policy
+
+For this repository taxonomy, the daemon may auto-add labels only from these families when exactly one label is supported by issue evidence:
+
+- Type labels: `bug`, `enhancement`, `feature`, `documentation`, `question`
+- Area labels: `area:backend`, `area:ci`, `area:frontend`, `area:installer`, `area:security`, `area:setup`, `area:ux`, `area:voice`
+
+The daemon must never auto-add triage/resolution labels (`duplicate`, `invalid`, `wontfix`, `good first issue`, `help wanted`).
+
+When an existing label set appears wrong or conflicting, propose the repair in a comment instead of removing labels directly.
+
+## Scope
+
+Default scope:
+
+- issues created or updated in the last 4 hours
+- open issues only
+- issue teams or projects configured for this repository or workspace
+
+Do not scan the entire workspace unless the daemon file is intentionally updated to do so.
+
+## Decision policy
+
+Add a missing label when:
+
+- the label family is required by the taxonomy
+- exactly one label in that family is supported by issue evidence
+- the label is current, not deprecated
+- applying it does not conflict with existing labels
+
+Post a repair proposal instead of mutating when:
+
+- multiple labels in one family could apply
+- an issue has deprecated labels
+- existing labels conflict with the taxonomy
+- the issue body or title does not provide enough context
+
+## Repair proposal format
+
+Use one concise issue comment:
+
+```md
+Label repair needed
+
+Recommended labels: <labels>
+Reason: <short rationale>
+Blocked because: <specific uncertainty or conflict>
+```
+
+## Limits
+
+- Max issues inspected per run: 100 recently changed issues
+- Max issues mutated per run: 30
+- Max repair proposal comments per run: 10
+- Max labels added per issue per run: 5
+
+## Idempotency
+
+Never add duplicate labels. Re-running with unchanged issue data must produce no additional writes.
+
+Use a conflict signature based on issue ID, current label set, title/body hash, and taxonomy version. Do not repeat the same repair proposal while that signature is unchanged.
+
+## No-op when
+
+- the label taxonomy cannot be read
+- the taxonomy does not define required label families
+- Linear issue data is incomplete
+- no recently changed in-scope issues need labels
+- the correct label cannot be selected with high confidence