diff --git a/.agents/skills/nemoclaw-maintainer-policies/SKILL.md b/.agents/skills/nemoclaw-maintainer-policies/SKILL.md new file mode 100644 index 00000000000..280f37a0f38 --- /dev/null +++ b/.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 +--- + + + + +# 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. diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/daily-flow.md b/.agents/skills/nemoclaw-maintainer-policies/references/daily-flow.md new file mode 100644 index 00000000000..e5c6ffbc11d --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/daily-flow.md @@ -0,0 +1,72 @@ + + + +# 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. diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/examples.md b/.agents/skills/nemoclaw-maintainer-policies/references/examples.md new file mode 100644 index 00000000000..36c8c416a53 --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/examples.md @@ -0,0 +1,407 @@ + + + +# NemoClaw Maintainer Examples + +These examples show the expected shape of agent recommendations. They are examples, not extra taxonomy; use `workflow-policy.md`, `triage-instructions.md`, `label-taxonomy.md`, `project-workflow.md`, `daily-flow.md`, and `release-train.md` as the source of truth. + +## Issue Triage Examples + +### Bug Report With Missing Environment + +Evidence: + +- User reports `nemoclaw onboard` fails on macOS. +- The failure appears macOS-specific, not merely tested on macOS. +- Reproduction steps are present. +- Docker and NemoClaw versions are missing. + +Dry run: + +```json +{ + "item_number": 101, + "item_kind": "issue", + "issue_type_to_set": "Bug", + "labels_to_add": ["area: onboarding", "platform: macos", "needs: info"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Priority": "Medium", + "Status": "Backlog" + }, + "recommended_action": "ask_for_info", + "confidence": "high", + "rationale": { + "issue_type_to_set": "The report describes broken onboarding behavior.", + "area: onboarding": "The failure occurs during `nemoclaw onboard`.", + "platform: macos": "The report indicates the failure is specific to macOS.", + "needs: info": "The report lacks NemoClaw and Docker versions." + }, + "questions_for_author": [ + "Which NemoClaw version are you using?", + "Which Docker version are you using?", + "Can you share the full error output from `nemoclaw onboard`?" + ], + "human_review_required": false +} +``` + +Comment: + +> Thanks for the report. Please share your NemoClaw version, Docker version, and the full error output from `nemoclaw onboard` so maintainers can reproduce this. + +### Documentation Report + +Evidence: + +- User reports a broken quickstart link. + +Dry run: + +```json +{ + "item_number": 102, + "item_kind": "issue", + "issue_type_to_set": "Documentation", + "labels_to_add": ["area: docs"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Status": "Backlog" + }, + "recommended_action": "route_to_docs", + "confidence": "high", + "rationale": { + "issue_type_to_set": "The report describes incorrect or broken documentation.", + "area: docs": "The affected surface is documentation." + }, + "questions_for_author": [], + "human_review_required": false +} +``` + +Anti-examples: + +- Do not add `documentation`; set native Issue Type `Documentation`. +- Do not add `status: triage`; use `needs: triage` only if maintainer workflow review is still needed. + +### Feature Request Needing Design + +Evidence: + +- User proposes adding a new local inference provider. +- The request affects provider architecture and user-facing capability. +- Design and compatibility expectations are incomplete. + +Dry run: + +```json +{ + "item_number": 103, + "item_kind": "issue", + "issue_type_to_set": "Enhancement", + "labels_to_add": ["area: providers", "area: local-models", "needs: design"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Priority": "Low", + "Status": "Backlog" + }, + "recommended_action": "request_design_direction", + "confidence": "medium", + "rationale": { + "issue_type_to_set": "The request proposes new user-visible capability.", + "area: providers": "The proposal adds provider behavior.", + "area: local-models": "The proposal concerns local inference.", + "needs: design": "Provider behavior and compatibility expectations need maintainer direction." + }, + "questions_for_author": [ + "Which local provider or runtime should this support?", + "What user workflow should this enable?" + ], + "human_review_required": false +} +``` + +### Daily Issue Tracking + +Evidence: + +- QA reports a regression against the Last release tag. +- No PR exists yet. +- Maintainer wants the issue visible in the daily slate so a PR can be opened or assigned. +- Current daily label is `v0.0.8`. + +Dry run: + +```json +{ + "item_number": 104, + "item_kind": "issue", + "issue_type_to_set": "Bug", + "labels_to_add": ["area: e2e", "v0.0.8"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Priority": "High", + "Status": "Needs Review" + }, + "recommended_action": "assign_or_open_pr_for_daily_release", + "confidence": "high", + "rationale": { + "issue_type_to_set": "The item is a regression found against the Last release tag.", + "area: e2e": "The evidence comes from end-to-end validation.", + "v0.0.8": "The issue needs PR work or regression follow-up for the daily tag; this is not release inclusion." + }, + "questions_for_author": [], + "human_review_required": true +} +``` + +Anti-example: + +- Do not treat an issue `v0.0.x` label as release inclusion. A PR must be merged with the relevant daily version label to enter the release. + +## PR Examples + +### Review-Ready Bug Fix + +Evidence: + +- PR fixes CLI argument parsing. +- Linked issue has native Issue Type `Bug`. +- PR is not draft, has no conflicts, and is awaiting maintainer review. + +Dry run: + +```json +{ + "item_number": 201, + "item_kind": "pull_request", + "issue_type_to_set": null, + "labels_to_add": ["bug-fix", "area: cli"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Status": "Needs Review" + }, + "recommended_action": "request_maintainer_review", + "confidence": "high", + "rationale": { + "bug-fix": "The PR fixes broken CLI behavior.", + "area: cli": "The affected surface is CLI argument parsing." + }, + "questions_for_author": [], + "human_review_required": false +} +``` + +### PR Needs Rebase After Related Work Landed + +Evidence: + +- PR adds provider routing behavior. +- A newer merged PR changed the same routing module and base API. +- This PR now has conflicts or a stale base that blocks meaningful review. +- The PR was previously reviewable. + +Dry run: + +```json +{ + "item_number": 202, + "item_kind": "pull_request", + "issue_type_to_set": null, + "labels_to_add": ["feature", "area: providers", "area: routing", "needs: rebase"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Status": "Blocked" + }, + "recommended_action": "request_rebase", + "confidence": "high", + "rationale": { + "feature": "The PR adds provider routing capability.", + "area: providers": "The PR affects provider behavior.", + "area: routing": "The PR changes routing logic.", + "needs: rebase": "A newer merged PR changed the same module, and this PR needs conflict or stale-base cleanup before review can continue." + }, + "questions_for_author": [ + "Can you rebase this PR against the current default branch and resolve the routing changes from the related merged PR?" + ], + "human_review_required": false +} +``` + +Comment: + +> Thanks for the work here. A related routing change has landed since this PR was opened; please rebase against the current default branch and resolve the routing updates so maintainers can continue review. + +### Competing PRs For The Same Issue + +Evidence: + +- PR #241 and PR #244 both claim to fix issue #99. +- The diffs overlap and cannot both land as-is. +- It is not clear whether one PR should supersede the other or whether the work should be combined. + +Dry run: + +```json +{ + "item_number": 241, + "item_kind": "pull_request", + "issue_type_to_set": null, + "labels_to_add": ["bug-fix", "area: cli", "needs: cleanup-review"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Status": "Blocked" + }, + "recommended_action": "ask_contributors_to_converge", + "confidence": "high", + "rationale": { + "bug-fix": "The PR claims to fix a linked bug.", + "area: cli": "The overlapping changes affect CLI behavior.", + "needs: cleanup-review": "Another open PR appears to solve the same issue, so maintainers need a convergence decision before normal review continues." + }, + "questions_for_author": [ + "Can you compare this PR with PR #244 and confirm whether one PR should be used, one should be withdrawn, or the work should be combined?" + ], + "human_review_required": true +} +``` + +Comment: + +> Thanks for the fix. This appears to overlap with PR #244 for the same issue; please compare approaches and let maintainers know whether one PR should be used, one should be withdrawn, or the work should be combined. + +### Security-Sensitive PR + +Evidence: + +- PR modifies SSRF validation. +- Public labels should route review without confirming exploitability. + +Dry run: + +```json +{ + "item_number": 203, + "item_kind": "pull_request", + "issue_type_to_set": null, + "labels_to_add": ["bug-fix", "area: security", "area: sandbox", "security"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Status": "Needs Review" + }, + "recommended_action": "security_sensitive_review", + "confidence": "high", + "rationale": { + "bug-fix": "The PR fixes unsafe validation behavior.", + "area: security": "The PR changes a security-sensitive path.", + "area: sandbox": "The PR affects sandbox boundary behavior.", + "security": "The PR touches SSRF validation." + }, + "questions_for_author": [], + "human_review_required": true +} +``` + +### Daily Release Activation + +Evidence: + +- Maintainer selects PR #123 for the day queue. +- Current daily label is `v0.0.8`. + +Dry run: + +```json +{ + "item_number": 123, + "item_kind": "pull_request", + "issue_type_to_set": null, + "labels_to_add": ["v0.0.8"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": {}, + "recommended_action": "activate_for_daily_release_work", + "confidence": "high", + "rationale": { + "v0.0.8": "The maintainer selected this open PR for today's work queue. This is not a readiness claim." + }, + "questions_for_author": [], + "human_review_required": false +} +``` + +Anti-examples: + +- Do not treat `v0.0.8` as a readiness claim. +- Do not change the version label just because the day ended. +- Do not delete an old version label while an open PR still depends on it. + +## Agent-Owned Label Examples + +Allowed: + +- `agt: duplicate-candidate` +- `agt: stale-audit` +- `agt: needs-human-check` + +Dry run: + +```json +{ + "item_number": 301, + "item_kind": "issue", + "issue_type_to_set": null, + "labels_to_add": ["agt: duplicate-candidate"], + "labels_to_remove": [], + "labels_to_create": [ + { + "name": "agt: duplicate-candidate", + "reason": "Agent coordination label for a duplicate-candidate audit." + } + ], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": {}, + "recommended_action": "agent_coordination", + "confidence": "high", + "rationale": { + "agt: duplicate-candidate": "The label is inside the agent-owned namespace and does not encode product type, priority, status, sprint, release version, or issue classification." + }, + "questions_for_author": [], + "human_review_required": false +} +``` + +Not allowed: + +- `agt: bug` +- `agt: priority-high` +- `agt: in-progress` +- `agt: sprint-6` +- `agt: v0.0.8` diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/label-taxonomy.json b/.agents/skills/nemoclaw-maintainer-policies/references/label-taxonomy.json new file mode 100644 index 00000000000..501d5bd0a13 --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/label-taxonomy.json @@ -0,0 +1,615 @@ +{ + "schema_version": 1, + "repo": "NVIDIA/NemoClaw", + "status": "canonical maintainer policy", + "issue_type_source_of_truth": { + "field": "GitHub native Issue Type", + "values": ["Bug", "Enhancement", "Task", "Documentation", "Epic", "Initiative"] + }, + "project_fields": { + "project": "NVIDIA organization Project 199", + "fields": { + "Status": { + "data_type": "single_select", + "value_source": "policy", + "values": ["No Status", "Backlog", "In Progress", "Blocked", "Needs Review", "NV QA", "Done", "Won't Fix", "Duplicate"] + }, + "Priority": { + "data_type": "single_select", + "value_source": "policy", + "values": ["Urgent", "High", "Medium", "Low"] + }, + "Sprint": { + "data_type": "iteration", + "value_source": "live_project_iterations", + "values": [], + "write_rule": "Fetch live Project iterations before writing." + }, + "Effort": { + "data_type": "single_select", + "value_source": "policy", + "values": ["High", "Medium", "Low"] + }, + "Start date": { + "data_type": "date", + "value_source": "date", + "format": "YYYY-MM-DD" + }, + "Target date": { + "data_type": "date", + "value_source": "date", + "format": "YYYY-MM-DD" + } + } + }, + "agent_owned_namespace": { + "pattern": "agt: *", + "permissions": ["create", "apply", "remove", "delete"], + "authorization": "Allowed inside an authorized agent-owned workflow.", + "forbidden_meanings": ["product type", "priority", "project status", "sprint", "release version", "issue classification"] + }, + "unknown_label_policy": { + "canonical": false, + "allowed_exceptions": ["agt: *"], + "handling": "Report old or unknown labels in an audit or cleanup dry run. Do not create, apply, or recreate labels that are not listed in this taxonomy." + }, + "canonical_labels": [ + { + "name": "bug-fix", + "family": "pr_type", + "item_kinds": ["pull_request"], + "description": "PR primarily fixes broken behavior.", + "positive_signals": ["regression fix", "failing test fix", "crash fix", "incorrect output fix"], + "negative_signals": ["new capability", "docs only", "tooling only"], + "mutually_exclusive_group": "pr_type" + }, + { + "name": "feature", + "family": "pr_type", + "item_kinds": ["pull_request"], + "description": "PR adds or expands user-visible capability.", + "positive_signals": ["new command", "new provider", "new workflow", "new user-facing behavior"], + "negative_signals": ["bug-only fix", "docs only"], + "mutually_exclusive_group": "pr_type" + }, + { + "name": "refactor", + "family": "pr_type", + "item_kinds": ["pull_request"], + "description": "PR restructures code without intended behavior change.", + "positive_signals": ["cleanup", "decomposition", "architecture simplification"], + "negative_signals": ["intended behavior change"], + "mutually_exclusive_group": "pr_type" + }, + { + "name": "chore", + "family": "pr_type", + "item_kinds": ["pull_request"], + "description": "Docs, CI, dependencies, packaging, policy, or maintenance.", + "positive_signals": ["docs", "CI", "dependency", "skill policy", "automation", "packaging"], + "negative_signals": ["primary product behavior change"], + "mutually_exclusive_group": "pr_type" + }, + { + "name": "security", + "family": "risk", + "item_kinds": ["issue", "pull_request"], + "description": "Potential vulnerability, unsafe behavior, or access risk.", + "positive_signals": ["credentials", "permissions", "authentication", "SSRF", "sandbox escape", "policy bypass", "trusted installer"], + "negative_signals": ["ordinary UX issue without security impact"], + "mutually_exclusive_group": null + }, + { + "name": "needs: triage", + "family": "needs", + "item_kinds": ["issue", "pull_request"], + "description": "New issue or PR needs maintainer review for project workflow assignment, labeling, ownership, or next action.", + "positive_signals": ["new issue", "new PR", "project workflow assignment needed", "labeling needed", "ownership needed", "next action unclear"], + "negative_signals": ["already classified", "project workflow assignment complete", "owner assigned", "next action clear"], + "mutually_exclusive_group": null + }, + { + "name": "needs: info", + "family": "needs", + "item_kinds": ["issue", "pull_request"], + "description": "Waiting on author for missing details.", + "positive_signals": ["missing repro", "missing logs", "missing version", "missing platform", "unclear intent"], + "negative_signals": ["enough context to act", "review-ready PR"], + "mutually_exclusive_group": "primary_blocking_need" + }, + { + "name": "needs: design", + "family": "needs", + "item_kinds": ["issue", "pull_request"], + "description": "Requires product or architecture direction.", + "positive_signals": ["cross-cutting change", "unclear architecture", "product decision needed"], + "negative_signals": ["straightforward implementation"], + "mutually_exclusive_group": null + }, + { + "name": "needs: rebase", + "family": "needs", + "item_kinds": ["pull_request"], + "description": "PR needs rebase or conflict resolution.", + "positive_signals": ["merge conflicts", "dirty merge state", "stale base blocking review"], + "negative_signals": ["clean merge state"], + "mutually_exclusive_group": "primary_blocking_need" + }, + { + "name": "needs: unblock", + "family": "needs", + "item_kinds": ["issue", "pull_request"], + "description": "Blocked item needs dependency or decision resolved.", + "positive_signals": ["blocked dependency", "decision needed", "external unblock required"], + "negative_signals": ["work can proceed"], + "mutually_exclusive_group": null + }, + { + "name": "needs: cleanup-review", + "family": "needs", + "item_kinds": ["issue", "pull_request"], + "description": "Stale, superseded, competing, convergence-needed, or closure-candidate item needs maintainer judgment.", + "positive_signals": ["stale", "superseded candidate", "competing PR", "overlapping work", "convergence decision needed", "closure candidate"], + "negative_signals": ["active work", "clear close decision already made"], + "mutually_exclusive_group": null + }, + { + "name": "good first issue", + "family": "community", + "item_kinds": ["issue"], + "description": "Small, clear, safe task for new contributors with tiny blast radius and no permission, secret, security, release, or policy risk.", + "positive_signals": ["tiny blast radius", "clear scope", "enough context", "starter task", "no permissions risk", "no secrets risk"], + "negative_signals": ["security", "urgent", "needs design", "large refactor", "permissions", "secrets", "release risk", "policy risk"], + "mutually_exclusive_group": null + }, + { + "name": "help wanted", + "family": "community", + "item_kinds": ["issue"], + "description": "Accepted work where maintainers welcome external contribution.", + "positive_signals": ["accepted scope", "external contribution useful"], + "negative_signals": ["private security work", "unclear direction"], + "mutually_exclusive_group": null + } + ], + "label_families": { + "area": { + "item_kinds": ["issue", "pull_request"], + "prefix": "area:", + "selection_guidance": [ + "Use area labels for the affected product or code surface, not for every concept mentioned in the report.", + "For install/onboarding/packaging overlap: use area: install for prerequisites or setup mechanics, area: onboarding for first-run flow and onboarding state, and area: packaging for shipped artifacts, images, registries, or distribution.", + "For inference/providers/routing/local-models overlap: use area: inference for model execution or output behavior, area: providers for provider integration/configuration/selection work, area: routing for dispatch/fallback/model-selection logic, and area: local-models for local runtime, download, launch, or connectivity.", + "For integrations/messaging overlap: use area: integrations for external app or bridge behavior, area: messaging when message delivery/channel lifecycle is the affected subsystem, and add a specific integration:* label when one listed integration is involved." + ], + "values": [ + "area: architecture", + "area: ci", + "area: cli", + "area: docs", + "area: e2e", + "area: inference", + "area: install", + "area: integrations", + "area: local-models", + "area: messaging", + "area: networking", + "area: observability", + "area: onboarding", + "area: packaging", + "area: performance", + "area: policy", + "area: project-management", + "area: providers", + "area: routing", + "area: sandbox", + "area: security", + "area: skills", + "area: ui" + ], + "entries": [ + { + "name": "area: architecture", + "description": "Architecture, design debt, major refactors, or maintainability.", + "positive_signals": ["architecture proposal", "design debt", "major refactor", "maintainability", "cross-cutting structure"], + "negative_signals": ["small local bug", "docs-only change", "single command UX issue"] + }, + { + "name": "area: ci", + "description": "CI workflows, checks, release automation, or GitHub Actions.", + "positive_signals": ["GitHub Actions", "workflow failure", "CI check", "release automation", "test runner infrastructure"], + "negative_signals": ["runtime bug found by CI but not caused by CI", "manual test failure"] + }, + { + "name": "area: cli", + "description": "Command line interface, flags, terminal UX, or output.", + "positive_signals": ["command", "flag", "terminal output", "CLI error", "argument parsing"], + "negative_signals": ["web UI issue", "backend behavior with no CLI-specific surface"] + }, + { + "name": "area: docs", + "description": "Documentation, examples, guides, generated docs, or docs build.", + "positive_signals": ["docs page", "guide", "example", "README", "broken link", "generated docs"], + "negative_signals": ["code behavior bug", "feature request without documentation scope"] + }, + { + "name": "area: e2e", + "description": "End-to-end tests, nightly failures, or validation infrastructure.", + "positive_signals": ["end-to-end test", "nightly failure", "validation run", "QA regression", "release validation"], + "negative_signals": ["unit test only", "single component failure outside e2e flow"] + }, + { + "name": "area: inference", + "description": "Inference routing, serving, model selection, or generated outputs.", + "positive_signals": ["model output", "inference request", "serving path", "model selection", "generated response"], + "negative_signals": ["provider setup only", "UI-only presentation issue"] + }, + { + "name": "area: install", + "description": "Install, setup, prerequisites, or uninstall flow.", + "positive_signals": ["installer", "setup", "dependency", "prerequisite", "uninstall", "first install"], + "negative_signals": ["post-install runtime behavior", "ordinary command usage after setup"] + }, + { + "name": "area: integrations", + "description": "External app, tool, channel, or OpenClaw integration behavior.", + "positive_signals": ["external app", "bridge", "channel", "integration setup", "third-party tool"], + "negative_signals": ["core product behavior with no external integration"] + }, + { + "name": "area: local-models", + "description": "Local model providers, downloads, launch, or connectivity.", + "positive_signals": ["local model", "model download", "local runtime", "Ollama", "vLLM", "local serving"], + "negative_signals": ["hosted provider only", "generic inference issue without local runtime evidence"] + }, + { + "name": "area: messaging", + "description": "Messaging channels, bridges, manifests, or channel lifecycle.", + "positive_signals": ["message delivery", "channel lifecycle", "manifest", "bridge message", "chat channel"], + "negative_signals": ["general UI text", "notification unrelated to messaging bridge"] + }, + { + "name": "area: networking", + "description": "DNS, proxy, TLS, ports, host aliases, or connectivity.", + "positive_signals": ["DNS", "proxy", "TLS", "port", "connection refused", "host alias", "network timeout"], + "negative_signals": ["provider outage with no local networking evidence", "generic install failure"] + }, + { + "name": "area: observability", + "description": "Logging, metrics, tracing, diagnostics, or debug output.", + "positive_signals": ["logs", "metrics", "trace", "diagnostics", "debug output", "observability"], + "negative_signals": ["logs only included as evidence for a different issue"] + }, + { + "name": "area: onboarding", + "description": "First-run, onboarding FSM, provider setup, or sandbox launch.", + "positive_signals": ["first run", "onboard command", "onboarding state", "provider setup wizard", "initial sandbox launch"], + "negative_signals": ["ongoing usage after onboarding", "general install prerequisite"] + }, + { + "name": "area: packaging", + "description": "Packages, images, registries, installers, or distribution.", + "positive_signals": ["package", "image", "registry", "installer artifact", "distribution", "release package"], + "negative_signals": ["runtime code bug unrelated to packaging"] + }, + { + "name": "area: performance", + "description": "Latency, throughput, resource use, benchmarks, or scaling.", + "positive_signals": ["slow", "latency", "throughput", "CPU", "memory", "benchmark", "scaling"], + "negative_signals": ["functional failure without performance impact"] + }, + { + "name": "area: policy", + "description": "Network policy, egress rules, presets, or sandbox policy.", + "positive_signals": ["policy", "egress rule", "preset", "allowlist", "denylist", "sandbox rule"], + "negative_signals": ["maintainer workflow policy", "label policy", "documentation policy"] + }, + { + "name": "area: project-management", + "description": "Taxonomy, triage, workflow, roadmap, or project process.", + "positive_signals": ["label taxonomy", "triage workflow", "project field", "roadmap", "maintainer process"], + "negative_signals": ["product feature request", "code behavior bug"] + }, + { + "name": "area: providers", + "description": "Inference provider integration, configuration, or selection work.", + "positive_signals": ["provider integration", "provider configuration", "provider selection", "new provider", "provider adapter behavior"], + "negative_signals": ["generic model output issue", "routing-only issue with no provider configuration or adapter behavior"], + "companion_label_guidance": "Add provider:* when a listed provider is specifically involved. Use area: providers without provider:* for unknown, proposed, or non-canonical providers." + }, + { + "name": "area: routing", + "description": "Request routing, policy routing, model selection, or fallback logic.", + "positive_signals": ["routing", "fallback", "request dispatch", "model selection", "provider selection logic"], + "negative_signals": ["single provider failure with no routing behavior"] + }, + { + "name": "area: sandbox", + "description": "OpenShell sandbox lifecycle, runtime, configuration, or recovery.", + "positive_signals": ["sandbox", "OpenShell", "sandbox launch", "runtime boundary", "sandbox recovery"], + "negative_signals": ["general container issue not tied to sandbox behavior"] + }, + { + "name": "area: security", + "description": "Security controls, permissions, secrets, or hardening.", + "positive_signals": ["permission", "secret", "credential", "hardening", "access control", "security control"], + "negative_signals": ["ordinary bug without security-sensitive path"] + }, + { + "name": "area: skills", + "description": "Agent skills, prompts, behaviors, or skill packaging.", + "positive_signals": ["skill", "prompt", "agent behavior", "skill package", "agent instruction"], + "negative_signals": ["ordinary user workflow without agent or skill behavior"] + }, + { + "name": "area: ui", + "description": "Web UI, terminal display, visual layout, or UX behavior.", + "positive_signals": ["web UI", "layout", "visual", "terminal display", "UX behavior", "screen text"], + "negative_signals": ["backend behavior with no visible user interface impact"] + } + ], + "positive_signals": ["affected code area", "affected user workflow", "review routing surface"], + "negative_signals": ["weak inference", "not useful for routing"] + }, + "platform": { + "item_kinds": ["issue", "pull_request"], + "prefix": "platform:", + "selection_guidance": [ + "Apply platform labels only when the platform appears causal, routing-relevant, or materially more likely to own the issue.", + "Do not apply a platform label just because the platform appears in the environment template, reproduction setup, or logs.", + "When a more specific platform label applies, prefer it over a broader one unless both are independently routing-relevant." + ], + "values": [ + "platform: arm64", + "platform: brev", + "platform: container", + "platform: dgx-spark", + "platform: dgx-station", + "platform: gb10", + "platform: jetson", + "platform: k3s", + "platform: k8s", + "platform: linux", + "platform: macos", + "platform: ubuntu", + "platform: windows", + "platform: wsl" + ], + "entries": [ + { + "name": "platform: arm64", + "description": "ARM64 or aarch64-specific behavior.", + "positive_signals": ["ARM64-only failure", "aarch64 build failure", "architecture-specific binary or dependency", "reproduction differs between ARM64 and x86_64"], + "negative_signals": ["platform only listed in environment", "same failure on x86_64", "Apple Silicon or Jetson issue better routed by platform: macos or platform: jetson alone"] + }, + { + "name": "platform: brev", + "description": "Brev hosted development environments.", + "positive_signals": ["Brev workspace", "Brev-hosted environment", "Brev-specific setup or runtime"], + "negative_signals": ["cloud development environment without Brev evidence"] + }, + { + "name": "platform: container", + "description": "Docker, containerd, Podman, or image behavior.", + "positive_signals": ["Docker daemon appears causal", "containerd runtime failure", "Podman-specific behavior", "image pull or image build failure", "container networking appears causal"], + "negative_signals": ["Docker only listed in environment", "container is only part of generic setup and not likely causal"] + }, + { + "name": "platform: dgx-spark", + "description": "DGX Spark hardware or workflows.", + "positive_signals": ["DGX Spark", "DGX Spark setup", "DGX Spark-specific workflow"], + "negative_signals": ["NVIDIA hardware mentioned without DGX Spark relevance"] + }, + { + "name": "platform: dgx-station", + "description": "DGX Station hardware or workflows.", + "positive_signals": ["DGX Station", "DGX Station setup", "DGX Station-specific workflow"], + "negative_signals": ["NVIDIA hardware mentioned without DGX Station relevance"] + }, + { + "name": "platform: gb10", + "description": "GB10 GPU environments.", + "positive_signals": ["GB10", "GB10-specific GPU environment", "GB10 hardware behavior"], + "negative_signals": ["generic GPU issue without GB10 evidence"] + }, + { + "name": "platform: jetson", + "description": "Jetson AGX Thor or Orin environments.", + "positive_signals": ["Jetson", "AGX Thor", "Orin", "JetPack", "Jetson-specific install or runtime"], + "negative_signals": ["ARM64 issue without Jetson-specific evidence"] + }, + { + "name": "platform: k3s", + "description": "K3s-specific behavior.", + "positive_signals": ["K3s", "lightweight Kubernetes", "K3s cluster", "K3s-specific deployment"], + "negative_signals": ["generic Kubernetes issue better labeled platform: k8s"] + }, + { + "name": "platform: k8s", + "description": "Kubernetes-specific behavior.", + "positive_signals": ["Kubernetes", "kubectl", "cluster", "pod", "deployment", "service"], + "negative_signals": ["container runtime issue outside Kubernetes"] + }, + { + "name": "platform: linux", + "description": "Linux behavior without Ubuntu specificity.", + "positive_signals": ["Linux-specific path", "systemd", "Linux permissions", "non-Ubuntu Linux distribution"], + "negative_signals": ["Ubuntu-specific behavior", "platform listed only as environment"] + }, + { + "name": "platform: macos", + "description": "macOS, Darwin, Homebrew, or Apple Silicon behavior.", + "positive_signals": ["macOS-specific error", "Darwin", "Homebrew", "Apple Silicon path", "macOS permission behavior"], + "negative_signals": ["macOS only listed as tested environment", "Docker only listed in environment", "same issue reproduced on Linux or Windows"] + }, + { + "name": "platform: ubuntu", + "description": "Ubuntu-specific behavior.", + "positive_signals": ["Ubuntu version", "apt package", "Ubuntu-specific dependency", "Ubuntu-specific install path"], + "negative_signals": ["generic Linux behavior", "Ubuntu only listed as environment"] + }, + { + "name": "platform: windows", + "description": "Native Windows or PowerShell behavior.", + "positive_signals": ["Windows-specific error", "PowerShell", "Windows path", "native Windows install", "Windows permissions"], + "negative_signals": ["WSL-specific issue", "Windows host only listed in environment"] + }, + { + "name": "platform: wsl", + "description": "Windows Subsystem for Linux behavior.", + "positive_signals": ["WSL", "WSL2", "Windows Subsystem for Linux", "WSL networking", "WSL filesystem path"], + "negative_signals": ["native Windows issue", "generic Linux issue without WSL-specific evidence"] + } + ], + "positive_signals": ["platform-specific error", "platform-specific code path", "platform-specific install behavior", "platform-specific runtime behavior", "repeated evidence from same platform", "platform seems routing-relevant or likely causal"], + "negative_signals": ["platform-agnostic", "all platforms", "reproduction setup only", "logs mention platform without platform-specific behavior", "guessed from generic failure text"] + }, + "provider": { + "item_kinds": ["issue", "pull_request"], + "prefix": "provider:", + "selection_guidance": [ + "Apply provider labels only when the item is specific to that provider's API, configuration, runtime, endpoint, auth, model behavior, or adapter.", + "When a provider exposes an OpenAI-compatible API but has its own canonical provider label, use the more specific provider label instead of provider: openai.", + "Use area: providers with no provider:* label for unknown, proposed, or non-canonical providers." + ], + "values": [ + "provider: anthropic", + "provider: nvidia", + "provider: ollama", + "provider: openai", + "provider: vllm" + ], + "entries": [ + { + "name": "provider: anthropic", + "description": "Anthropic or Claude provider behavior.", + "positive_signals": ["Anthropic", "Claude", "Anthropic API", "Claude model", "Anthropic provider config"], + "negative_signals": ["generic inference issue", "OpenAI-compatible provider issue"] + }, + { + "name": "provider: nvidia", + "description": "NVIDIA inference endpoint, NIM, or NVIDIA provider behavior.", + "positive_signals": ["NVIDIA endpoint", "NIM", "NVIDIA provider", "NVIDIA API key", "NVIDIA-hosted model"], + "negative_signals": ["NVIDIA hardware only", "non-provider NVIDIA platform issue"] + }, + { + "name": "provider: ollama", + "description": "Ollama local model provider behavior.", + "positive_signals": ["Ollama", "ollama serve", "Ollama model", "local Ollama runtime"], + "negative_signals": ["local model issue not using Ollama"] + }, + { + "name": "provider: openai", + "description": "OpenAI API or OpenAI-compatible provider behavior.", + "positive_signals": ["OpenAI API", "OpenAI-compatible endpoint with no more specific provider label", "Chat Completions", "Responses API", "OpenAI model"], + "negative_signals": ["Anthropic-specific issue", "NVIDIA, Ollama, or vLLM issue with a more specific provider label", "local provider issue"] + }, + { + "name": "provider: vllm", + "description": "vLLM local or hosted provider behavior.", + "positive_signals": ["vLLM", "vllm serve", "OpenAI-compatible vLLM endpoint", "vLLM runtime"], + "negative_signals": ["generic local model issue not tied to vLLM"] + } + ], + "positive_signals": ["specific provider path", "provider configuration", "provider-specific failure"], + "negative_signals": ["generic inference issue", "unknown provider"] + }, + "integration": { + "item_kinds": ["issue", "pull_request"], + "prefix": "integration:", + "selection_guidance": [ + "Apply integration labels only when a listed external app, channel, tool, or agent integration is specifically involved.", + "Use area: integrations for integration subsystem work, and add integration:* when a listed integration is named or clearly implicated.", + "Use area: messaging when delivery, channel lifecycle, manifests, or bridge messages are the affected subsystem; combine it with integration:* when the messaging issue is specific to a listed integration." + ], + "values": [ + "integration: brave", + "integration: discord", + "integration: hermes", + "integration: openclaw", + "integration: slack", + "integration: telegram", + "integration: wechat", + "integration: whatsapp" + ], + "entries": [ + { + "name": "integration: brave", + "description": "Brave integration behavior.", + "positive_signals": ["Brave", "browser integration", "Brave-specific channel or app behavior"], + "negative_signals": ["generic browser issue without Brave evidence"] + }, + { + "name": "integration: discord", + "description": "Discord bridge or channel lifecycle.", + "positive_signals": ["Discord", "Discord bot", "Discord bridge", "Discord channel"], + "negative_signals": ["generic messaging issue without Discord evidence"] + }, + { + "name": "integration: hermes", + "description": "Hermes startup, plugin, or sandbox behavior.", + "positive_signals": ["Hermes", "Hermes plugin", "Hermes startup", "Hermes sandbox"], + "negative_signals": ["generic plugin issue without Hermes evidence"] + }, + { + "name": "integration: openclaw", + "description": "OpenClaw runtime, plugins, configuration, or bridge.", + "positive_signals": ["OpenClaw", "OpenClaw runtime", "OpenClaw plugin", "OpenClaw bridge"], + "negative_signals": ["NemoClaw core behavior without OpenClaw involvement"] + }, + { + "name": "integration: slack", + "description": "Slack bridge, manifest, auth, or delivery behavior.", + "positive_signals": ["Slack", "Slack app", "Slack manifest", "Slack auth", "Slack message delivery"], + "negative_signals": ["generic messaging issue without Slack evidence"] + }, + { + "name": "integration: telegram", + "description": "Telegram bot, bridge, polling, or delivery.", + "positive_signals": ["Telegram", "Telegram bot", "Telegram bridge", "polling", "Telegram delivery"], + "negative_signals": ["generic messaging issue without Telegram evidence"] + }, + { + "name": "integration: wechat", + "description": "WeChat channel or bridge behavior.", + "positive_signals": ["WeChat", "WeChat channel", "WeChat bridge", "WeChat delivery"], + "negative_signals": ["generic messaging issue without WeChat evidence"] + }, + { + "name": "integration: whatsapp", + "description": "WhatsApp channel setup or runtime.", + "positive_signals": ["WhatsApp", "WhatsApp channel", "WhatsApp bridge", "WhatsApp setup"], + "negative_signals": ["generic messaging issue without WhatsApp evidence"] + } + ], + "positive_signals": ["specific app", "specific bridge", "specific agent integration"], + "negative_signals": ["generic integration surface"] + }, + "release": { + "item_kinds": ["issue", "pull_request"], + "pattern": "^v\\d+\\.\\d+\\.\\d+$", + "positive_signals": ["maintainer selected PR for daily work", "open PR activated for day queue", "issue tracked as daily release attention signal", "issue flagged as needing PR work for daily release"], + "negative_signals": ["readiness claim", "automatic bump", "issue treated as release inclusion"] + }, + "agent_owned": { + "item_kinds": ["issue", "pull_request"], + "pattern": "^agt: .+", + "positive_signals": ["agent coordination", "agent audit marker"], + "negative_signals": ["product type", "priority", "project status", "sprint", "release version"] + } + }, + "mutually_exclusive_groups": { + "pr_type": ["bug-fix", "feature", "refactor", "chore"], + "primary_blocking_need": ["needs: info", "needs: rebase"] + }, + "quality_rules": { + "minimal_labeling": true, + "low_confidence_write_allowed": false, + "default_mode": "recommendation_only", + "writes_require_authorization_context": true, + "human_review_required_when_outside_authorization_context": true, + "agent_owned_label_writes_allowed_when_authorized": true, + "release_labels_on_issues_allowed": true, + "release_label_is_readiness_claim": false + } +} diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/label-taxonomy.md b/.agents/skills/nemoclaw-maintainer-policies/references/label-taxonomy.md new file mode 100644 index 00000000000..c382fa57a73 --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/label-taxonomy.md @@ -0,0 +1,187 @@ + + + +# NemoClaw Label Taxonomy + +Status: canonical maintainer policy. + +Labels should exist only when maintainers, agents, dashboards, or reviewers act differently because the label is present. + +## Native Fields Before Labels + +Use native GitHub Issue Type for issue classification: + +- `Bug` +- `Enhancement` +- `Task` +- `Documentation` +- `Epic` +- `Initiative` + +Use GitHub Project fields for: + +- Priority +- Effort +- Start date +- Target date +- Lifecycle status +- Release or project status + +Use labels for: + +- Product or code routing. +- Platform, provider, integration, or reproduction surface. +- Immediate action queues. +- Community contribution signals. +- PR type and PR release activation. +- Agent-owned coordination under `agt: *`. + +## Canonical Label Families + +### PR Type + +Apply exactly one PR type label to a non-draft PR when there is enough evidence. + +| Label | Applies To | Description | Positive Signals | Negative Signals | +|---|---|---|---|---| +| `bug-fix` | PR | PR primarily fixes broken behavior. | Fixes regression, failing test, crash, incorrect output. | Adds unrelated new capability, pure docs, pure tooling. | +| `feature` | PR | PR adds or expands user-visible capability. | New command, provider, workflow, config, or user-facing behavior. | Only fixes existing behavior or docs. | +| `refactor` | PR | PR restructures code without intended behavior change. | Cleanup, decomposition, architecture simplification. | User-visible behavior change. | +| `chore` | PR | Docs, CI, dependencies, packaging, policy, or maintenance. | Docs-only, build, CI, dependency, skill policy, automation. | Product behavior change that needs feature or bug-fix. | + +`security` can be added as a supplemental risk label to any issue or PR when security review is required. + +### Routing Areas + +Area labels apply to issues and PRs when the affected surface is clear. + +Use area labels for the affected product or code surface, not for every concept mentioned in the report. For overlapping areas, prefer the label that best describes the owner of the next action: + +- `area: install` for prerequisites or setup mechanics; `area: onboarding` for first-run flow and onboarding state; `area: packaging` for shipped artifacts, images, registries, or distribution. +- `area: inference` for model execution or output behavior; `area: providers` for provider integration, configuration, or selection work; `area: routing` for dispatch, fallback, or model-selection logic; `area: local-models` for local runtime, download, launch, or connectivity. +- `area: integrations` for external app or bridge behavior; `area: messaging` when message delivery or channel lifecycle is the affected subsystem; add a specific `integration:*` label when one listed integration is involved. + +| Label | Description | +|---|---| +| `area: architecture` | Architecture, design debt, major refactors, or maintainability. | +| `area: ci` | CI workflows, checks, release automation, or GitHub Actions. | +| `area: cli` | Command line interface, flags, terminal UX, or output. | +| `area: docs` | Documentation, examples, guides, generated docs, or docs build. | +| `area: e2e` | End-to-end tests, nightly failures, or validation infrastructure. | +| `area: inference` | Inference routing, serving, model selection, or generated outputs. | +| `area: install` | Install, setup, prerequisites, or uninstall flow. | +| `area: integrations` | External app, tool, channel, or OpenClaw integration behavior. | +| `area: local-models` | Local model providers, downloads, launch, or connectivity. | +| `area: messaging` | Messaging channels, bridges, manifests, or channel lifecycle. | +| `area: networking` | DNS, proxy, TLS, ports, host aliases, or connectivity. | +| `area: observability` | Logging, metrics, tracing, diagnostics, or debug output. | +| `area: onboarding` | First-run, onboarding FSM, provider setup, or sandbox launch. | +| `area: packaging` | Packages, images, registries, installers, or distribution. | +| `area: performance` | Latency, throughput, resource use, benchmarks, or scaling. | +| `area: policy` | Network policy, egress rules, presets, or sandbox policy. | +| `area: project-management` | Taxonomy, triage, workflow, roadmap, or project process. | +| `area: providers` | Inference provider integration, configuration, or selection work. | +| `area: routing` | Request routing, policy routing, model selection, or fallback logic. | +| `area: sandbox` | OpenShell sandbox lifecycle, runtime, configuration, or recovery. | +| `area: security` | Security controls, permissions, secrets, or hardening. | +| `area: skills` | Agent skills, prompts, behaviors, or skill packaging. | +| `area: ui` | Web UI, terminal display, visual layout, or UX behavior. | + +### Platform + +Platform labels apply when the issue or PR is specific to a platform or is more likely relevant to that platform, not merely because the author happened to test there. This is one of the hardest label families to infer. + +Positive signals include platform-specific errors, platform-specific code paths, platform-specific install/runtime behavior, or repeated evidence from the same platform. Weak signals include reproduction setup only, "all platforms" reports, or logs that mention a platform without showing platform-specific behavior. + +When evidence is ambiguous, use the platform label only when the platform seems routing-relevant or likely causal. Otherwise, leave it off and explain what evidence would make it platform-specific. + +When a more specific platform label applies, prefer it over a broader one unless both are independently routing-relevant. Do not add `platform: container`, `platform: arm64`, or an OS label just because the environment template mentions Docker, CPU architecture, or OS. + +| Label | Description | +|---|---| +| `platform: arm64` | ARM64 or aarch64-specific behavior. | +| `platform: brev` | Brev hosted development environments. | +| `platform: container` | Docker, containerd, Podman, or image behavior. | +| `platform: dgx-spark` | DGX Spark hardware or workflows. | +| `platform: dgx-station` | DGX Station hardware or workflows. | +| `platform: gb10` | GB10 GPU environments. | +| `platform: jetson` | Jetson AGX Thor or Orin environments. | +| `platform: k3s` | K3s-specific behavior. | +| `platform: k8s` | Kubernetes-specific behavior. | +| `platform: linux` | Linux behavior without Ubuntu specificity. | +| `platform: macos` | macOS, Darwin, Homebrew, or Apple Silicon behavior. | +| `platform: ubuntu` | Ubuntu-specific behavior. | +| `platform: windows` | Native Windows or PowerShell behavior. | +| `platform: wsl` | Windows Subsystem for Linux behavior. | + +Do not create or apply `platform: all`. + +### Provider + +Provider labels apply when the issue or PR is specific to a recurring inference provider. + +Use `area: providers` for provider integration work, and add `provider:*` when a listed provider is specifically involved. When a provider exposes an OpenAI-compatible API but has its own provider label, use the more specific provider label instead of `provider: openai`. For unknown or proposed providers, use `area: providers` and name the provider in the rationale. + +| Label | Description | +|---|---| +| `provider: anthropic` | Anthropic or Claude provider behavior. | +| `provider: nvidia` | NVIDIA inference endpoint, NIM, or NVIDIA provider behavior. | +| `provider: ollama` | Ollama local model provider behavior. | +| `provider: openai` | OpenAI API or OpenAI-compatible provider behavior. | +| `provider: vllm` | vLLM local or hosted provider behavior. | + +### Integration + +Integration labels apply when a recurring external app, channel, tool, or agent integration is specifically involved. + +Use `area: integrations` for integration subsystem work, and add `integration:*` when a listed integration is named or clearly implicated. Use `area: messaging` when delivery, channel lifecycle, manifests, or bridge messages are the affected subsystem; combine it with `integration:*` when the messaging issue is specific to a listed integration. + +| Label | Description | +|---|---| +| `integration: brave` | Brave integration behavior. | +| `integration: discord` | Discord bridge or channel lifecycle. | +| `integration: hermes` | Hermes startup, plugin, or sandbox behavior. | +| `integration: openclaw` | OpenClaw runtime, plugins, configuration, or bridge. | +| `integration: slack` | Slack bridge, manifest, auth, or delivery behavior. | +| `integration: telegram` | Telegram bot, bridge, polling, or delivery. | +| `integration: wechat` | WeChat channel or bridge behavior. | +| `integration: whatsapp` | WhatsApp channel setup or runtime. | + +### Needs + +`needs:*` labels are action queues. Remove them when the action is complete. `Needs Review` is a Project Status value, not a label. + +| Label | Applies To | Description | +|---|---|---| +| `needs: cleanup-review` | Issue, PR | Stale, superseded, competing, convergence-needed, or closure-candidate item needs maintainer judgment. | +| `needs: design` | Issue, PR | Product or architecture direction is unclear or cross-cutting. | +| `needs: info` | Issue, PR | Missing repro, logs, version, platform, answer, or PR context. | +| `needs: rebase` | PR | Merge conflicts, dirty merge state, or rebase requested. | +| `needs: triage` | Issue, PR | New issue or PR needs maintainer review for project workflow assignment, labeling, ownership, or next action. | +| `needs: unblock` | Issue, PR | Blocked item needs a dependency or decision resolved. | + +Do not combine: + +- `needs: info` with `needs: rebase`. +- `good first issue` with `security`, urgent priority, or `needs: design`. + +### Community + +| Label | Applies To | Description | +|---|---|---| +| `good first issue` | Issue | Small, clear, safe task for new contributors with tiny blast radius and no permission, secret, security, release, or policy risk. | +| `help wanted` | Issue | Accepted work where maintainers welcome external contribution. | + +### Release Train + +Daily `v0.0.x` labels activate PRs for daily release work. Issues may use a daily label as a tracking or attention signal, but issue labels do not determine release inclusion. See `release-train.md`. + +### Agent-Owned + +`agt: *` labels are agent-owned coordination labels. Agents may create, apply, remove, and delete them inside an authorized agent-owned workflow. They must not encode product type, priority, project status, sprint, or release version. + +## Unknown Labels + +Labels not listed in this taxonomy are not canonical and must not be created, applied, or recreated by agents or maintainers. The only exception is the agent-owned `agt: *` namespace described above. + +If an old or unknown label is found on an existing item, report it in an audit or cleanup dry run. Do not use it as permission to apply the same label elsewhere. diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/project-workflow.md b/.agents/skills/nemoclaw-maintainer-policies/references/project-workflow.md new file mode 100644 index 00000000000..4c5b3fdcd71 --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/project-workflow.md @@ -0,0 +1,108 @@ + + + +# NemoClaw Project Workflow + +This workflow explains how GitHub Project fields support NemoClaw's daily operating flow. The timeboxed daily cadence, priority lanes, and release handoff live in `daily-flow.md`. + +## Fields + +| Concept | Source Of Truth | +|---|---| +| Issue classification | Native GitHub Issue Type | +| PR classification | PR type labels | +| Priority | GitHub Project Priority field | +| Effort | GitHub Project Effort field | +| Start date | GitHub Project Start date field | +| Target date | GitHub Project Target date field | +| Lifecycle | GitHub Project Status field | +| Resolution | GitHub close reason, linked issue/PR, maintainer comment, and logs | +| Release activation | Daily `v0.0.x` labels on PRs | +| Release tracking | Daily `v0.0.x` labels on issues when used as attention or "needs PR" signals | + +## Project Status + +Use the Project Status field for durable workflow state: + +| Status | Meaning | +|---|---| +| `No Status` | Item is not yet placed in the project workflow. | +| `Backlog` | Accepted or tracked work that is not currently active. | +| `In Progress` | Work has an owner and active implementation, investigation, or coordination is happening. | +| `Blocked` | Work cannot proceed until a dependency, decision, access issue, or external input is resolved. | +| `Needs Review` | Work needs maintainer review, PR review, or assignment review before it can move forward. | +| `NV QA` | Work is ready for, under, or awaiting NVIDIA QA validation. | +| `Done` | Work is complete for the project workflow. | +| `Won't Fix` | Maintainer decision is not to pursue the work. | +| `Duplicate` | Item is represented by another canonical issue or PR. | + +Status is not a label. `needs:*` labels may create action queues, but the Project Status field owns lifecycle state. + +## Daily Slate Workflow + +The daily slate starts from the priority lanes in `daily-flow.md`: + +1. QA TEST Blockers. +2. QA regressions or new bugs from the Last release tag. +3. High-impact accepted sprint work. +4. Ready PRs. +5. Existing WIP. + +For each recommended daily item, agents should report: + +- Item number and kind. +- Priority lane. +- Current Project Status. +- Suggested owner or owner gap. +- Next action. +- End-of-day exit signal. +- Whether a PR exists, is needed, or is already merged. +- Whether a daily `v0.0.x` label is present on the PR, issue, or both. + +Standup converts the recommendation into assignments. Every recommended item should leave standup either assigned with a next action and exit signal, or explicitly deferred with rationale. + +## Release Labels In Project Context + +Daily `v0.0.x` labels have different meanings by item kind: + +- On PRs, the label activates the PR for daily release work. Merged PRs carrying the daily label are candidates for the daily release cutoff. +- On issues, the label is an attention, regression-tracking, or "needs PR for this daily release" signal. It does not include the issue in the release by itself. + +Open labeled PRs carry forward until the label is removed. Open issues may keep or lose daily labels according to maintainer judgment and the current daily slate. + +## Issue Templates + +Issue forms must set native `type`. + +- Bug forms set `type: Bug`. +- Feature request forms set `type: Enhancement`. +- Documentation issue forms set `type: Documentation`. +- Internal maintainer work should use `type: Task`. + +New issue forms should default `labels: ["needs: triage"]` so maintainers can review project workflow assignment, labeling, ownership, and next action. + +Issue forms must not default deprecated labels such as `bug`, `enhancement`, `documentation`, or `status: triage`. + +## Labels + +Labels are for routing, reproduction surfaces, immediate action queues, community contribution signals, PR type, PR release activation, and issue release tracking. + +Do not use labels for: + +- Issue type. +- Priority. +- Effort. +- Dates. +- Lifecycle. +- Resolution. +- Sprint. + +## Agent Writes + +Agents should emit a dry-run plan containing labels, field changes, comments, and rationale unless they are already operating inside an explicit authorization context for the proposed write class. + +When writes are authorized: + +1. Apply field updates first. +2. Add canonical labels. +3. Post comments only when the authorization context covers the exact comment text or intent. diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/release-train.md b/.agents/skills/nemoclaw-maintainer-policies/references/release-train.md new file mode 100644 index 00000000000..5ca51c17741 --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/release-train.md @@ -0,0 +1,51 @@ + + + +# NemoClaw Release Train + +Daily release labels coordinate release work. They do not classify issues and they do not promise readiness. + +## Rules + +- PRs own the release-inclusion meaning of daily version labels. +- Engineers and agents may add the current `v0.0.x` label to open PRs to activate them for day work. +- Issues may also carry daily version labels when they need a PR, fix, or regression follow-up for the daily tag. +- Applying a daily version label is not a readiness claim. +- Release includes PRs that both carry the daily version label and are merged by cutoff. +- Issue version labels are tracking signals only; an issue label does not include work in the release without a merged labeled PR. +- Open PRs with version labels carry forward automatically. +- A PR leaves the cycle only when the version label is removed. +- Version labels are pruned after seven days only after durable release history is preserved and no open PR still carries or depends on the old label. + +## Cutoff + +The daily cutoff is the maintainer-defined point where the release tag is prepared. + +At cutoff: + +1. List merged PRs carrying the target version label. +2. Confirm each is intended for the release. +3. List open PRs still carrying daily version labels as carry-forward work. +4. Generate QA handoff from merged PRs. +5. Cut the release tag only with explicit maintainer confirmation. + +## Carry Forward + +Open PRs with version labels remain active carry-forward work by default. Do not change the version label just because the day ended. Keep the label while the PR is still intended for the daily release flow, and remove it when the PR should leave that flow. + +Maintainers may: + +- Add the current version label when they want the PR visible in the current day queue. +- Remove an old version label when the PR is deferred, superseded, closed, or no longer part of the daily cycle. +- Keep an old version label until release history and dashboards no longer need it. + +## Pruning + +Old version labels may be deleted only when all conditions are true: + +1. The label is older than seven days. +2. Durable release history has been preserved in tags, release notes, Agent Feed artifacts, or equivalent reports. +3. No open PR still carries or depends on the old label. +4. The current authorization context explicitly allows label pruning. + +Pruning is a cleanup operation, not part of ordinary daily triage. diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/triage-instructions.md b/.agents/skills/nemoclaw-maintainer-policies/references/triage-instructions.md new file mode 100644 index 00000000000..a4bdd3ac0cc --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/triage-instructions.md @@ -0,0 +1,193 @@ + + + +# NemoClaw Triage Instructions + +These instructions are for agents and skills that evaluate NemoClaw issues and PRs before recommending Type, labels, project fields, comments, or follow-up questions. + +## Core Rules + +- Read `label-taxonomy.md` and `label-taxonomy.json` before suggesting labels. +- Triage from evidence in the item title, body, linked issue, files changed, CI state, and maintainer comments. +- Prefer no label over a guessed label. +- Do not use labels for native issue type, priority, effort, lifecycle status, sprint, or resolution. Daily version labels on issues are tracking and coordination signals only. +- Present dry-run recommendations first unless the agent is already operating inside an explicit authorization context for the proposed write class. +- Keep changes minimal: only add labels or fields that change routing, actionability, or reporting. +- Project Status is a Project field, not a label. Valid values include `No Status`, `Backlog`, `In Progress`, `Blocked`, `Needs Review`, `NV QA`, `Done`, `Won't Fix`, and `Duplicate`. +- Set `human_review_required: true` when the proposed write is outside the current authorization context, has elevated risk, or needs maintainer judgment before execution. + +## Issue Flow + +1. Classify the issue using native GitHub Issue Type: `Bug`, `Enhancement`, `Task`, `Documentation`, `Epic`, or `Initiative`. +2. Add area labels only when the affected surface is clear. +3. Add platform, provider, or integration labels only with explicit evidence. +4. Add `needs:*` only when an immediate action queue is needed. +5. Recommend Project Priority from impact evidence, not user urgency language. +6. Recommend Project Status separately from labels. +7. Ask for missing information when the report is not actionable. +8. Recommend a daily `v0.0.x` label for an issue only when it is useful for daily tracking, regression attention, or "needs PR" coordination. + +## PR Flow + +1. Identify whether the PR is draft, conflicted, stale, blocked, or review-ready. +2. Apply exactly one PR type label only when enough evidence exists: `bug-fix`, `feature`, `refactor`, or `chore`. +3. Add `security` when the PR touches credentials, permissions, SSRF, sandbox escape risk, policy enforcement, or trusted installer paths. +4. Add area/platform/provider/integration labels based on files changed and PR intent when useful for review routing. +5. Recommend Project Status `Needs Review` for non-draft, conflict-free PRs that are awaiting maintainer review. +6. Add `needs: rebase` when conflicts or rebase state blocks review. +7. Add `needs: info` when contributor intent or required context is missing. +8. Daily `v0.0.x` labels activate PRs for daily release work; adding one is not a readiness claim. + +## Minimal Labeling + +Use the smallest label set that makes the item actionable. + +For issues, a high-quality dry run often includes: + +- Native Issue Type. +- Zero to two area labels. +- Optional platform/provider/integration labels when directly evidenced. +- Optional `needs:*`. +- Project Priority and Status recommendations. +- Optional daily release label only when the issue needs daily tracking, regression attention, or "needs PR" coordination. + +For PRs, a high-quality dry run often includes: + +- One PR type label. +- Area labels for review routing. +- Optional `security`. +- Optional `needs:*`. +- Project Status recommendation. +- Optional daily release label only when the maintainer workflow activates the PR. + +## Confidence Thresholds + +Use `confidence` in dry-run output: + +| Confidence | Meaning | Write Guidance | +|---|---|---| +| `high` | 80%+ confidence; direct evidence supports the recommendation. | Eligible inside an authorization context. | +| `medium` | 70-79% confidence; evidence is plausible but incomplete. | Eligible inside an authorization context with rationale. | +| `low` | Below 70% confidence; evidence is weak or inferred. | Do not write; ask for info or leave unlabeled. | + +Never apply a label from a low-confidence inference. + +## When To Ask For Info + +Use `needs: info` and ask targeted questions when: + +- A bug report lacks reproduction steps, expected behavior, actual behavior, version, environment, or logs. +- A platform-specific claim lacks platform details. +- A provider or integration issue lacks provider/integration configuration. +- A PR does not explain intent, scope, or linked issue and the diff could be interpreted multiple ways. +- A security report lacks enough detail to route safely. + +Ask for exact missing fields. Do not ask broad questions like "Can you provide more details?" when specific missing data is known. + +## When To Use Needs Labels + +- `needs: triage`: Newly created issue or PR needs maintainer review for project workflow assignment, labeling, ownership, or next action. +- `needs: info`: Author action is required before work can proceed. +- `needs: design`: Product or architecture decision is required. +- `needs: rebase`: PR cannot proceed because of conflicts or stale base. +- `needs: unblock`: Blocked item needs a decision or dependency resolved. +- `needs: cleanup-review`: Stale, superseded, competing, convergence-needed, or closure-candidate item needs maintainer judgment. + +`needs:*` labels are not lifecycle status. Remove them after the requested action is complete. + +## Security Handling + +- Add `security` when credentials, permissions, authentication, sandbox escape, SSRF, policy bypass, trusted installers, or vulnerability language is present. +- Mark human review required. +- Use neutral language. Do not confirm exploitability in public comments. +- Recommend private disclosure routing when the item appears to describe an undisclosed vulnerability. + +## Dry-Run Output + +Use this JSON-compatible shape: + +```json +{ + "item_number": 123, + "item_kind": "issue", + "issue_type_to_set": "Bug", + "labels_to_add": ["area: install", "platform: macos", "needs: info"], + "labels_to_remove": [], + "labels_to_create": [], + "labels_to_delete": [], + "issue_fields_to_set": {}, + "project_fields_to_set": { + "Priority": "Medium", + "Status": "Backlog" + }, + "recommended_action": "ask_for_info", + "confidence": "medium", + "human_review_required": true, + "rationale": { + "issue_type_to_set": "The report describes broken install behavior.", + "area: install": "The failure occurs during setup.", + "platform: macos": "The failure appears macOS-specific.", + "needs: info": "The report lacks NemoClaw and Docker versions." + }, + "questions_for_author": [ + "Which NemoClaw version are you using?", + "Which Docker version are you using?", + "Can you share the full command and error output?" + ] +} +``` + +`labels_to_create` and `labels_to_delete` are only for authorized `agt: *` label operations unless a non-agent label operation is explicitly authorized by the current workflow. + +## Comment Guidance + +- Keep comments to one or two sentences. +- Explain the immediate action or missing information. +- Thank contributors and assume good intent. +- When useful, address the author by GitHub login and reference the specific behavior, PR, or report. +- Be friendly, specific, and direct; do not use generic filler, sarcasm, or frustration. +- Link to existing docs or prior issues when they answer the question better than repeating guidance inline. +- For `needs: info`, ask for exact missing details. +- For security, avoid exploit confirmation. +- For duplicate recommendations, include the canonical item and recommend Project Status or close reason `Duplicate`. +- For superseded or competing-work recommendations, include the canonical or related item if known. +- Use response-specific maintainer guidance for longer community replies, stale handling, closure decisions, or reusable templates. + +## Examples + +### Bug With Missing Environment + +Recommendation: + +- Native Issue Type: `Bug` +- Labels: `area: install`, `platform: macos`, `needs: info` +- Priority: `Medium` +- Status: `Backlog` + +Comment: + +> Thanks for the report. Please share the NemoClaw version, Docker version, macOS version, and the full install error so maintainers can reproduce it. + +### Docs Issue + +Recommendation: + +- Native Issue Type: `Documentation` +- Labels: `area: docs` +- No `documentation` label + +### Review-Ready PR + +Recommendation: + +- Labels: `bug-fix`, `area: cli` +- Project Status: `Needs Review` +- Do not add a daily version label unless the maintainer day workflow activates it. + +### Anti-Examples + +- Do not add `bug` to a new issue. Set native Issue Type `Bug`. +- Do not add `status: triage`; use `needs: triage` only if an action queue is still needed. +- Do not add `priority: high`; recommend Project Priority instead. +- Do not treat an issue `v0.0.x` label as release inclusion; PR labels own daily release activation. +- Do not add `needs: review`; use Project Status `Needs Review` for review-ready PRs. diff --git a/.agents/skills/nemoclaw-maintainer-policies/references/workflow-policy.md b/.agents/skills/nemoclaw-maintainer-policies/references/workflow-policy.md new file mode 100644 index 00000000000..6ebf573197d --- /dev/null +++ b/.agents/skills/nemoclaw-maintainer-policies/references/workflow-policy.md @@ -0,0 +1,57 @@ + + + +# NemoClaw Maintainer Workflow Policy + +This package is the canonical maintainer-policy source for NemoClaw agent workflows. + +## Source Of Truth Hierarchy + +1. Native GitHub Issue Type classifies issues as `Bug`, `Enhancement`, `Task`, `Documentation`, `Epic`, or `Initiative`. +2. `triage-instructions.md` defines how agents evaluate issues and PRs, including confidence, minimal-labeling rules, and when to ask for more information. +3. `label-taxonomy.md` and `label-taxonomy.json` define the approved label taxonomy and machine-readable validation rules. +4. GitHub Project fields own lifecycle, priority, effort, dates, and release/project status. Project Status values include `Needs Review`. +5. Labels own routing, reproduction surfaces, immediate action queues, community contribution signals, PR release activation, and issue release tracking. + +## Policy Boundaries + +- Do not duplicate policy in individual maintainer or contributor skills. Those skills should point here and keep only workflow-specific mechanics. +- Do not use labels as a second source of truth for issue type, priority, effort, lifecycle status, sprint, or resolution. +- Default mode is recommendation-only. Agents may write only inside an explicit authorization context. +- `human_review_required` means the proposed write is outside the current authorization context, has elevated risk, or needs maintainer judgment before execution. + +An authorization context can be: + +- A maintainer request that asks an agent to perform a specific class of writes. +- A repo automation configured to apply a known class of writes. +- A triage UI user accepting a suggested write set. +- A release workflow running under a named release automation. +- An authorized agent-owned workflow operating only in the `agt: *` label namespace. + +Canonical labels, Issue Type, Project fields, public comments, release labels, closes, merges, and non-agent label deletion require an authorization context that explicitly allows that operation. Security-sensitive, destructive, release, merge, and public-comment writes require stricter authorization than ordinary triage labels. + +## Issue Classification + +Native GitHub Issue Type is the canonical issue-kind field: + +| Issue Type | Use For | +|---|---| +| `Bug` | Confirmed or suspected broken behavior, regression, crash, incorrect result, or security-sensitive malfunction. | +| `Enhancement` | User-visible improvement or new capability that is not a regression. | +| `Task` | Maintainer work, cleanup, infrastructure, testing, policy, or internal follow-up. | +| `Documentation` | Missing, incorrect, unclear, or broken documentation. | +| `Epic` | Multi-issue delivery group. | +| `Initiative` | Larger product or program objective spanning epics or projects. | + +Labels must not replace native Issue Type. + +## Agent-Owned Labels + +`agt: *` is an agent-owned namespace. + +- Agents may create, apply, remove, and delete `agt: *` labels inside an authorized agent-owned workflow. +- `agt: *` labels are agent automation and coordination signals. +- `agt: *` labels must not encode product type, priority, project status, sprint, release version, or issue classification. +- Human-maintained taxonomy files should not depend on an `agt: *` label being durable. + +Consumers must use this package for canonical write policy. diff --git a/.agents/skills/nemoclaw-skills-guide/SKILL.md b/.agents/skills/nemoclaw-skills-guide/SKILL.md index 5e0f6e92874..ea338fe7e58 100644 --- a/.agents/skills/nemoclaw-skills-guide/SKILL.md +++ b/.agents/skills/nemoclaw-skills-guide/SKILL.md @@ -22,10 +22,10 @@ The prefix in each skill name indicates who it is for. For end users operating a NemoClaw sandbox. Covers installation, inference configuration, network policy management, monitoring, remote deployment, security configuration, workspace management, and reference material. -### `nemoclaw-maintainer-*` (12 skills) +### `nemoclaw-maintainer-*` (13 skills) For project maintainers. -Covers the daily maintainer cadence (morning standup, daytime loop, evening handoff), cutting releases, drafting release notes, finding PRs to review, comparing PRs, cross-issue sweeps, triage, normalizing issue and PR title tags, performing security code reviews, and verifying whether stale bug reports still reproduce on the latest release. +Covers the daily maintainer cadence (morning standup, daytime loop, evening handoff), workflow policy reference, cutting releases, drafting release notes, finding PRs to review, comparing PRs, cross-issue sweeps, triage, normalizing issue and PR title tags, performing security code reviews, and verifying whether stale bug reports still reproduce on the latest release. ### `nemoclaw-contributor-*` (2 skills) @@ -57,6 +57,7 @@ Covers creating pull requests that follow the project template and drafting docu |-------|---------| | `nemoclaw-maintainer-morning` | Morning standup: triage the backlog, determine the day's target version, label selected items, surface stragglers, and output the daily plan. | | `nemoclaw-maintainer-triage` | Suggest and optionally apply labels for issues and PRs using the live NemoClaw triage instructions. | +| `nemoclaw-maintainer-policies` | Read-only maintainer workflow policy reference for Issue Type, labels, Project fields, daily release labels, triage, duplicates, blocked items, and workflow decisions. | | `nemoclaw-maintainer-cross-issue-sweep` | Scan open issues for adjacent fixes or contradiction risks when reviewing a PR. | | `nemoclaw-maintainer-day` | Daytime loop: pick the highest-value version-targeted item and execute the right workflow (merge gate, salvage, security sweep, test gaps, hotspot cooling, or sequencing). Designed for `/loop`. | | `nemoclaw-maintainer-evening` | End-of-day handoff: check version progress, bump stragglers to the next patch, generate a QA handoff summary, and cut the release tag. | @@ -89,6 +90,6 @@ Skills are cumulative. Each role includes the skills from the roles above it: |------|----------------|-------|------------| | User | `nemoclaw-user-*` | 10 | `nemoclaw-user-get-started` | | Contributor | `nemoclaw-user-*` + `nemoclaw-contributor-*` | 12 | `nemoclaw-user-overview` | -| Maintainer | All skills | 24 | `nemoclaw-maintainer-morning` | +| Maintainer | All skills | 25 | `nemoclaw-maintainer-morning` | After identifying the role, present the applicable skills from the Skill Catalog above and recommend the starting skill. diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index 023e295948a..f7dc02fd6ae 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -1,6 +1,7 @@ name: Bug Report -description: Report a bug you confirmed and could not fix. -labels: ["bug", "status: triage"] +description: Report a bug you encountered and can reproduce. +type: Bug +labels: ["needs: triage"] body: - type: textarea id: description @@ -28,7 +29,8 @@ body: label: Environment description: OS, Node.js version, Docker version, NemoClaw version, and any other relevant details. placeholder: | - - OS: macOS 15.2 / Ubuntu 24.04 / Windows 11 + WSL2 + - OS: Ubuntu 24.04 / Windows 11 + WSL2 / macOS 15.2 + - Hardware: DGX Spark / DGX Station / N1X / Jetson / x86_64 workstation / other - Node.js: v20.x - Docker: Docker Desktop 4.x / Docker Engine 27.x - NemoClaw: v0.x.x (output of `nemoclaw --version`) diff --git a/.github/ISSUE_TEMPLATE/doc_issue.yml b/.github/ISSUE_TEMPLATE/doc_issue.yml index acb00f03d60..47b25a5487b 100644 --- a/.github/ISSUE_TEMPLATE/doc_issue.yml +++ b/.github/ISSUE_TEMPLATE/doc_issue.yml @@ -1,6 +1,7 @@ name: Documentation Issue description: Report incorrect, missing, or unclear documentation. -labels: ["documentation", "status: triage"] +type: Documentation +labels: ["needs: triage"] body: - type: textarea id: description diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml index c2bdfae94c7..d587041b507 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.yml +++ b/.github/ISSUE_TEMPLATE/feature_request.yml @@ -1,6 +1,7 @@ name: Feature Request description: Propose a feature with a design. Not a "please build this" request. -labels: ["enhancement", "status: triage"] +type: Enhancement +labels: ["needs: triage"] body: - type: textarea id: problem @@ -33,10 +34,10 @@ body: attributes: label: Category options: - - "enhancement: feature" - - "enhancement: provider" - - "enhancement: platform" - - "enhancement: testing" + - "Feature" + - "Provider" + - "Platform" + - "Testing" validations: required: true