docs: add agent-ready NemoClaw maintainer workflow policies

.agents/skills/nemoclaw-maintainer-policies/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: nemoclaw-maintainer-policies
+description: Read-only maintainer policy reference for NemoClaw agents, engineers, and maintainers. Use when answering NemoClaw project-management workflow questions, including GitHub Issue Type, labels, Project fields, daily release labels, triage, duplicates, blocked items, and maintainer workflow decisions. Trigger keywords - maintainer policy, workflow policy, project workflow, issue type, labels, label taxonomy, needs labels, project status, blocked issue, duplicate issue, daily release label, release train, triage policy.
+user_invocable: true
+---
+
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# NemoClaw Maintainer Policies
+
+This is a policy-only skill package. `SKILL.md` is only the manifest and index.
+
+## References
+
+- **Broad overview:** When a new engineer asks how NemoClaw uses GitHub or how the maintainer workflow works, load [references/workflow-policy.md](references/workflow-policy.md), then [references/project-workflow.md](references/project-workflow.md), then [references/daily-flow.md](references/daily-flow.md). Use [references/release-train.md](references/release-train.md) only when release labels, cutoff, carry-forward, release history, or label pruning are involved.
+- **Agent implementation:** When building or updating an agent or app that applies or recommends workflow metadata, load [references/workflow-policy.md](references/workflow-policy.md), [references/triage-instructions.md](references/triage-instructions.md), [references/label-taxonomy.json](references/label-taxonomy.json), and [references/examples.md](references/examples.md), in that order.
+- **Load [references/workflow-policy.md](references/workflow-policy.md)** when answering source-of-truth, authorization, Issue Type, label boundary, or agent-owned label questions.
+- **Load [references/triage-instructions.md](references/triage-instructions.md)** when answering how to evaluate issues or PRs, when to ask for information, how to use `needs:*`, how to set confidence, or what suggestion payload shape to emit.
+- **Load [references/label-taxonomy.md](references/label-taxonomy.md)** when answering human-facing label meaning, label selection, label compatibility, unknown-label, `agt: *`, or release-label taxonomy questions.
+- **Load [references/label-taxonomy.json](references/label-taxonomy.json)** when validating machine-readable Issue Type, Project field, label, signal, compatibility, or write-policy values.
+- **Load [references/project-workflow.md](references/project-workflow.md)** when answering Project Status, Project fields, duplicate, blocked, backlog, review, QA, issue-template, or lifecycle workflow questions.
+- **Load [references/daily-flow.md](references/daily-flow.md)** when answering daily slate, priority lane, standup, assignment, execution, QA handoff, or daily operating-loop questions.
+- **Load [references/release-train.md](references/release-train.md)** when answering daily version-label, release inclusion, carry-forward, cutoff, release history, or label-pruning questions.
+- **Load [references/examples.md](references/examples.md)** when examples or anti-examples are needed for triage, PR review, daily release activation, competing PRs, stale/rebase cases, or agent-owned labels.
+
+## Answering Workflow Questions
+
+Before answering or applying policy, read the most relevant reference file. Answer in plain maintainer-facing language and distinguish native GitHub Issue Type, PR type labels, `needs:*` action labels, Project fields, GitHub close reasons, and daily version labels. Do not invent labels, statuses, fields, release labels, or workflow states.
+
+For agent implementation questions, treat `triage-instructions.md` as the recommendation payload contract and `label-taxonomy.json` as the allowed-value and validation source.
+
+Workflow answers must remain reference-backed. Do not encode alternate policy in this manifest.

.agents/skills/nemoclaw-maintainer-policies/references/daily-flow.md

@@ -0,0 +1,72 @@
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# NemoClaw Daily Maintainer Flow
+
+This file defines NemoClaw's daily operating runbook. It tells maintainers, TPMs, and agents how to turn QA results, GitHub issues, PRs, Project fields, and daily release labels into a daily slate of assigned work and a release handoff. It does not define label taxonomy or durable Project field meanings; those live in the companion reference files.
+
+Daily labels are coordination signals, not readiness claims. PR labels own release inclusion. Issue labels may be used for daily attention, regression tracking, or "needs PR for this daily release" signals.
+
+## Morning Inputs
+
+Agents preparing a daily recommendation should synthesize:
+
+- QA evidence for the Last release tag: blockers, regressions, release risks, and known issue or bug mappings.
+- Sprint and GitHub evidence: accepted scope, open PRs, open issues, linked work, current WIP, and Project fields.
+- Capacity signals: owner availability, recent throughput, readiness, risk, blockers, and review load.
+
+## Daily Flow
+
+The daily flow is an outline, not a rigid ceremony.
+
+| Step | Phase | Purpose |
+|---:|---|---|
+| 1 | QA Evidence | Capture validation results from the Last release tag and identify blockers, regressions, risks, and unmapped findings. |
+| 2 | Intake | Reconcile QA, GitHub, sprint, release-label, and WIP evidence into a candidate inventory. |
+| 3 | Capacity | Estimate what can realistically move today based on readiness, ownership, review load, and risk. |
+| 4 | Recommend | Publish a daily standup slate grouped by priority lane with suggested owners, next actions, and decision gaps. |
+| 5 | Assign | Maintainers convert the recommendation into assignments, deferrals, or follow-up questions. |
+| 6 | Execute | Engineers drive the assigned slate toward merge, fix, unblock, PR creation, or explicit deferral. |
+| 7 | Release | The daily release is cut from merged PRs carrying the daily version label. |
+| 8 | Handoff | Summarize what shipped, what slipped, what QA should focus on, and what should seed the next cycle. |
+
+## Priority Order
+
+Highest applicable lane wins. A ready PR that fixes a QA TEST Blocker belongs in Lane 1, not Lane 4.
+
+| Rank | Lane | Meaning |
+|---:|---|---|
+| 1 | QA TEST Blockers | Items blocking QA from completing validation. |
+| 2 | QA bugs | Regressions or new bugs found against the Last release tag. |
+| 3 | Sprint impact | Accepted sprint work tied to current exit criteria or high-impact goals. |
+| 4 | Ready PRs | Low-risk PRs close to merge-ready that should not linger. |
+| 5 | Existing WIP | Active owned work that affects capacity or assignment planning. |
+
+## Daily Recommendation
+
+A daily recommendation should make the next decision easy. Include:
+
+- Item number and kind.
+- Priority lane.
+- Current Project Status.
+- Suggested owner or owner gap.
+- Next action.
+- End-of-day exit signal.
+- PR state: missing, open, blocked, reviewable, merge-ready, or merged.
+- Issue state when the PR is linked to an issue or an issue needs a PR.
+- Daily label state on the PR, issue, or both.
+- Decision gaps or questions for maintainers.
+
+## Write Boundary
+
+Daily-flow reports are read-only by default.
+
+Agents may recommend labels, assignments, Project field changes, comments, merges, releases, and follow-up questions. They may perform writes only inside an explicit authorization context for that write class, such as accepted triage suggestions, maintainer-directed work, or named release automation.
+
+## Release Boundary
+
+- A PR daily version label activates daily release work; it is not a readiness claim.
+- Release inclusion requires a PR to be both merged and carrying the relevant daily version label at release cutoff.
+- Issue daily version labels are tracking or coordination signals only.
+- Open PRs with daily version labels carry forward until the label is removed.
+- Durable release history belongs in releases, release notes, or manifests, not in long-lived labels.