feat: nemoclaw maintainer community response skill

.agents/skills/nemoclaw-maintainer-community-response/DEVLOG.md

@@ -0,0 +1,40 @@
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# NemoClaw Community Response Skill — Development Log
+
+A living record of decisions, changes, and context for this skill.
+Auto-maintained via [claude-devlog-skill](https://github.com/code-katz/claude-devlog-skill). Entries are reverse-chronological.
+
+---
+
+## [2026-04-13] NemoClaw community response skill and project workflow established
+
+**Category:** `milestone`
+**Tags:** `community`, `maintainer-tooling`, `github-projects`, `skill`, `workflow`
+**Risk Level:** `low`
+**Breaking Change:** `no`
+
+### Summary
+Built a complete community response workflow for NemoClaw maintainers, including this agent skill, updated maintainer guide docs, a project workflow reference, and a feature request parking system using the existing label structure.
+
+### Detail
+- Created `SKILL.md` — drafts community-facing responses to GitHub issues and PRs. For each item it recommends an action (comment, close, request changes, escalate), a project board status, and suggested labels. Reads `docs/maintainer-guide-snippet.md` and `docs/project-workflow.md` at runtime so it never works from stale memory.
+- Added `docs/maintainer-guide.md` and `docs/maintainer-guide-snippet.md` (previously untracked local files) — covers 9 response situations: won't-fix, superseded PR, poorly designed PR, duplicates, feature requests, Discussion redirects, triage acknowledgment, needs-info (label + close), and response time norms.
+- Added `docs/project-workflow.md` — defines project board status semantics, the three-tier label structure (Type + Sub-type + Dimension), board setup instructions for Enhancement Parking and Platform/Integration views, and the promotion flow from `No Status` → `Backlog` → `In Progress`.
+- Approved responses are logged to `~/development/daily-rhythm/activity/nemoclaw-community-responses.md` for long-term record keeping (persisted via GitLab through the daily-rhythm repo).
+- 44+ issues closed in the first session using the skill.
+
+### Decisions Made
+- **Log location:** Response log moved from `.nemoclaw-maintainer/community-responses.md` (gitignored, local to NemoClaw repo) to `daily-rhythm/activity/nemoclaw-community-responses.md` so it persists to GitLab and is available for long-term reporting and activity summaries.
+- **Feature request status:** New feature requests get `No Status` (unreviewed) not `Backlog`. Only a maintainer who has explicitly reviewed and approved an item sets `Backlog`. This prevents the false signal of "added to backlog" in community responses.
+- **Label structure over custom Project field:** Used the existing three-tier label system (`enhancement` + `enhancement: *` sub-labels + `Platform/Integration/Provider: *` dimension labels) for categorization instead of adding a custom field to the GitHub Project. No new infrastructure needed.
+- **Skill reads live docs:** The skill reads guide files at runtime rather than encoding templates in the skill itself. Updating the guide updates skill behavior without touching the skill file.
+- **Tone:** Community first, firm and friendly — lead with acknowledgment, hold the line when needed, never dismissive.
+
+### Related
+- Skill: [SKILL.md](SKILL.md)
+- Guide: [docs/maintainer-guide.md](../../../docs/maintainer-guide.md)
+- Workflow: [docs/project-workflow.md](../../../docs/project-workflow.md)
+- Response log: `~/development/daily-rhythm/activity/nemoclaw-community-responses.md`
+- Branch: `feat/community-response-skill` (based on `cv/maintainer-skills`)

.agents/skills/nemoclaw-maintainer-community-response/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: nemoclaw-maintainer-community-response
+description: Drafts community-facing responses to GitHub issues and PRs for NemoClaw maintainers. For each item, recommends an action (comment, close, close+comment, request changes, escalate) and drafts the response text. Handles won't-fix closures, out-of-scope closures, superseded PRs, poorly designed PR rejections, security acknowledgments, duplicate issues, feature request routing, needs-info labeling, and general triage. Logs approved responses to ~/development/daily-rhythm/activity/nemoclaw-community-responses.md. Tone: community first, firm and friendly. Trigger keywords - respond to issue, close issue, respond to PR, community response, won't fix, out of scope, reject PR, triage response, draft response, what should I say, needs info, duplicate issue, feature request.
+user_invocable: true
+---
+
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# NemoClaw Maintainer — Community Response
+
+Draft a response to a GitHub issue or PR, recommend an action, and log the approved response.
+
+**Tone:** Community first, firm and friendly. Lead with acknowledgment. Hold the line when needed. Never dismissive.
+
+## Step 1: Read the Guides
+
+Before drafting, read both reference docs:
+
+```bash
+cat docs/maintainer-guide-snippet.md
+cat docs/project-workflow.md
+```
+
+Do not draft from memory. The guides may have been updated. `maintainer-guide-snippet.md` has the response templates. `project-workflow.md` has the status semantics and full label structure.
+
+## Step 2: Gather Context
+
+Ask the user (or infer from context) for:
+
+- Issue or PR number and title
+- Body text (or summary if long)
+- Any existing comments relevant to the response
+- Whether this is an issue or a PR
+
+If the user provides a URL or number only, ask for the body text — don't assume.
+
+## Step 3: Identify the Situation
+
+Map the item to one of the situations in the guide:
+
+| Situation | When |
+|---|---|
+| Won't fix / out of scope / needs design | Valid item, but won't be addressed or is outside scope |
+| Superseded PR | Another PR was merged that covers the same ground |
+| Security acknowledgment | Contributor reported or fixed a vulnerability |
+| Poorly designed PR | PR cannot merge as-is; needs specific changes |
+| Duplicate | Same issue or PR already exists |
+| Feature request | Valid suggestion, not a bug — route to parking |
+| Redirect to Discussions | Open-ended question or design topic, not actionable |
+| Triage acknowledgment | Valid open issue, confirmed, no timeline yet |
+| Needs info (first contact) | Can't investigate without more information from contributor |
+| Needs info (close) | Already labeled `status: needs-info`, 7+ days, no response |
+
+If the situation is ambiguous, ask: "Is this a closure, a needs-info, a routing decision, or something else?"
+
+## Step 4: Recommend an Action and Project Status
+
+State the recommended action and **project status** clearly before drafting. The project status field must be set on every item — do not leave it as "Done" by default.
+
+**Actions:**
+
+| Action | When |
+|---|---|
+| `comment` | Post a reply, leave open (triage ack, needs-info first contact, redirect to Discussions) |
+| `close` | Close with comment |
+| `request changes` | PR needs revision — post comment, leave open |
+| `comment + label` | Post comment AND apply a label (e.g., rebase nudge → apply `status: rebase`) |
+| `escalate` | Security report that should go through PSIRT — do not respond publicly |
+| `rebase nudge` | PR has merge conflicts or is significantly out of date — post comment asking author to rebase, apply `status: rebase` |
+
+**Project status mapping (NemoClaw Development Tracker):**
+
+| Situation | Project Status |
+|---|---|
+| Won't fix | `Won't Fix` |
+| Out of scope / needs design | `Won't Fix` |
+| Duplicate / superseded PR | `Duplicate` |
+| Feature request (new, unreviewed) | `No Status` |
+| Feature request (approved for future) | `Backlog` — only set this if maintainer has explicitly approved |
+| Needs review / poorly designed PR | `Needs Review` |
+| Triage acknowledgment (confirmed, backlogged) | `Backlog` |
+| Needs info (first contact or close) | `No Status` |
+| Completed / merged | `Done` |
+| NVQA-tracked item | `NVQA` |
+
+**For feature requests — also suggest labels** (read label structure from `project-workflow.md`):
+1. Always suggest `enhancement` as the base label
+2. Suggest the most specific Tier 2 sub-label that fits (e.g., `enhancement: inference`, `enhancement: ui`)
+3. Suggest Tier 3 dimension label(s) if platform-, integration-, or provider-specific (e.g., `Integration: Slack`, `Platform: MacOS`)
+
+Present as: **Action:** `comment` · **Project status:** `No Status` · **Suggested labels:** `enhancement`, `enhancement: inference`
+
+For closures, use the project status from the mapping table above — `Won't Fix`, `Duplicate`, or `No Status` depending on the situation.
+
+## Step 5: Draft the Response
+
+Write the response following the template from the guide. Apply these rules:
+
+- **Always explain why** when closing — never close silently.
+- **Acknowledge contributors** when their work informed a solution, even if it didn't land.
+- **Be specific** — name the exact reason, the exact information needed, the exact problem with the PR.
+- **One sentence on why.** Not a paragraph. Not a list.
+- Write in second person, direct address to the contributor.
+- Warm but specific — generic phrases without substance read as dismissive.
+- Never reference internal systems, roadmap items, or org decisions that shouldn't be public.
+- **PRs requiring rebase:** After posting the comment, always apply `status: rebase` via:
+  ```bash
+  gh pr edit <number> --repo NVIDIA/NemoClaw --add-label "status: rebase"
+  ```
+  This keeps rebase-blocked PRs distinct from needs-info PRs and surfaces them for follow-up separately.
+- **Same contributor on multiple PRs needing rebase:** If the contributor who owns this PR also has another open PR that needs a rebase, note it in the comment — suggest a joint rebase on both at once. Example addition: "Note this is from the same contributor as #[N] — a joint rebase on both would be ideal." Apply `status: rebase` to both PRs. Check for contributor overlap before sending any rebase nudge.
+
+## Step 6: Present for Approval
+
+Show the user:
+
+1. **Recommended action and project status** (e.g., `close` · project status: `Won't Fix`)
+2. **Draft response** (ready to paste into GitHub)
+3. Any follow-up note (e.g., "add the label before closing")
+
+Ask: "Want me to adjust the tone or any specific wording?"
+
+## Step 7: Log the Approved Response
+
+When the user approves, append to `~/development/daily-rhythm/activity/nemoclaw-community-responses.md`.
+
+Use the absolute path — this file lives in the daily-rhythm activity folder so it is persisted to GitLab over time, not in the NemoClaw repo.
+
+```
+## [ISSUE|PR] NVIDIA/NemoClaw#<number> — <title>
+**Date:** YYYY-MM-DD
+**Action:** comment | close | request changes | escalate
+**Project status:** <status>
+**Labels:** <suggested or applied labels>
+
+**Response:**
+<approved response text>
+
+---
+```
+
+Create the file if it doesn't exist. Never stage or commit this file to the NemoClaw repo.
+
+## Response Time Check
+
+If the user asks whether a response window is at risk, check against:
+
+| Situation | Target |
+|---|---|
+| New issue | First response ≤ 5 business days |
+| Open PR, no review | First comment ≤ 7 business days |
+| Contributor asks for update | Reply ≤ 3 business days |
+| `status: needs-info` labeled | Close if no response after 7 days |
+
+A window is "at risk" when 80% of the target has elapsed. Surface as a flag, not an alarm.

docs/maintainer-guide-snippet.md

@@ -0,0 +1,125 @@
+---
+orphan: true
+title: "NemoClaw Community Engagement Quick Reference"
+description: "Quick reference card for NemoClaw maintainers — closing, merging, rejecting, duplicates, feature requests, triage, and needs-info flows."
+keywords: maintainer, community, triage, quick reference
+topics: [maintainer, community]
+tags: [maintainer, community]
+content_type: reference
+difficulty: beginner
+audience: maintainers
+status: active
+---
+
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# NemoClaw — Community Engagement Quick Reference
+
+> - **Always explain why** when closing — never close silently.
+> - **Acknowledge contributors** when their work informs a merged solution, even if their PR didn't land.
+> - **Security reporters get credit** — even when the fix goes through PSIRT, not GitHub.
+> - **Be specific when declining** — vague feedback wastes everyone's time and damages trust.
+> - **Route, don't reject** feature requests — backlog or Discussions, never silence.
+> - **Name what you need** when asking for info — and give the contributor 7 days to respond.
+
+---
+
+## Closing Won't Fix / Out of Scope
+
+| Reason | Label |
+|---|---|
+| Valid issue, won't address | `status: won't-fix` |
+| Outside project design/scope | `status: out-of-scope` |
+| Good idea, needs a proposal first | `status: needs-design` |
+
+> Thanks for raising this. After review, we're closing as **[label]** because [one sentence]. See [CONTRIBUTING.md](https://github.com/NVIDIA/NemoClaw/blob/main/CONTRIBUTING.md) for scope guidance. We appreciate you taking the time.
+
+---
+
+## When Your Merge Supersedes Another PR
+
+Comment on the closed PR before you merge:
+
+> Closing in favor of #[N], which was merged and covers the same ground. Your [approach / test cases / edge case] helped shape the solution that landed — thanks for working on this.
+
+**Security PRs:** Always acknowledge the finding explicitly, even when the fix went through PSIRT:
+
+> Thanks for identifying this. The fix followed our [coordinated disclosure process](https://github.com/NVIDIA/NemoClaw/blob/main/SECURITY.md), but your report is a real contribution and we want to recognize it.
+
+---
+
+## Rejecting a Poorly Designed PR
+
+1. **Acknowledge intent** — one sentence on what they were solving
+2. **Name the specific problem** — don't say "not quite right," say why
+3. **Give a path forward** — what would need to change, or ask them to start in an issue first
+
+> Thanks for tackling [X] — it's a real gap. The approach here [specific problem]. Before we could accept this, we'd need [specific ask]. Happy to discuss the right approach in the issue first.
+
+---
+
+## Closing Duplicates
+
+> Thanks for the report. This is a duplicate of #[N] — all discussion is happening there. Closing in favor of the original thread. Feel free to add context or subscribe to #[N] to follow along.
+
+**Label:** `status: duplicate`
+
+---
+
+## Feature Requests
+
+> Thanks for the suggestion. We've noted this and will review it — we'll update this issue if it moves forward. We don't have a timeline to share yet.
+
+**Project status:** `No Status` (do NOT say "added to backlog" — that implies approval)
+
+**Labels:** Always apply `enhancement` + the most specific sub-label (`enhancement: inference`, `enhancement: ui`, etc.) + any Tier 3 dimension labels (`Integration: Slack`, `Platform: MacOS`, `Provider: NVIDIA`, etc.)
+
+*Full label reference: [docs/project-workflow.md](project-workflow.md)*
+
+---
+
+## Redirecting to Discussions
+
+> This looks like a great topic for an open conversation rather than a bug or feature request. I've moved this to Discussions here: [link]. Closing the issue to keep the tracker focused on actionable items.
+
+---
+
+## Triage Acknowledgment
+
+> Thanks for the detailed report — we've confirmed this and added it to our backlog. We don't have a timeline to share yet, but we've got it on our radar. We'll update this issue when work begins.
+
+---
+
+## Needs Info
+
+**First contact** — label `status: needs-info`, leave open:
+
+> Thanks for the report. To move forward, we need: [specific ask]. We'll keep this open for 7 days — if we don't hear back, we'll close it to keep the tracker tidy.
+
+**7+ days, no response** — close + comment:
+
+> Closing due to no response. If this is still happening, please open a new issue and include [repeat the specific ask]. Happy to take another look.
+
+---
+
+## Response Time Commitments
+
+| Situation | Target |
+|---|---|
+| New issue | First response ≤ 5 business days |
+| Open PR, no review | First comment ≤ 7 business days |
+| Contributor asks for update | Reply ≤ 3 business days |
+
+If you'll miss a window — post an update before it lapses.
+
+---
+
+*Full guide: [docs/maintainer-guide.md](maintainer-guide.md) · Scope: [CONTRIBUTING.md](https://github.com/NVIDIA/NemoClaw/blob/main/CONTRIBUTING.md) · Security: [SECURITY.md](https://github.com/NVIDIA/NemoClaw/blob/main/SECURITY.md)*
+
+---
+
+## Next Steps
+
+- [Maintainer Guide](maintainer-guide.md) — full workflows, decision trees, and templates
+- [Project Workflow](project-workflow.md) — board status semantics and label taxonomy