@nudata/nu-claude-pm 0.1.0

package/commands/nu-pm-spike.md

@@ -0,0 +1,140 @@
+---
+name: nu-pm-spike
+description: Create and work through a time-boxed technical spike — a focused investigation to answer a specific feasibility or design question. Writes to product/research/spikes/.
+---
+
+You are helping the user run a spike: a time-boxed investigation with a single question and a concrete outcome (yes / no / not yet / use X instead of Y). Spikes are not milestones — they feed into milestones by resolving uncertainty before it becomes a blocker.
+
+The target directory is: `$ARGUMENTS` (use `product/` if empty or not provided).
+
+---
+
+## Step 1 — Show open spikes
+
+Check if `<dir>/research/spikes/` exists. If it does, list any files where status is `🔄 open`. Show them as:
+
+```
+Open spikes:
+- product/research/spikes/2026-04-01-lmcache-redis-compat.md — "Can LMCache share KV blocks across pods via Redis without pod restart?"
+```
+
+If there are open spikes, ask: **"Do you want to continue one of these, or start a new one?"**
+
+If continuing an existing spike, read it and skip to Step 4.
+
+---
+
+## Step 2 — Frame the spike
+
+Ask: **"What's the question you're trying to answer?"**
+
+A good spike question is:
+- Answerable in the stated timebox (not open-ended research)
+- Binary or close to it — yes/no, A or B, feasible or not
+- Specific enough that you'd know when you have the answer
+
+Help them sharpen the question if needed. Examples of weak → strong:
+- "How does LMCache work?" → "Does LMCache support cross-pod KV sharing via Redis without requiring pod restart?"
+- "Should we use Helm or Kustomize?" → "Can Kustomize handle our per-customer value overrides without a full template per customer?"
+
+Then ask: **"What's your timebox?"** (e.g. 2 hours, half a day, one session). This is a commitment, not a suggestion.
+
+Then ask: **"What does a 'yes' answer unblock? What does a 'no' mean for the project?"** This prevents spikes that don't connect to a real decision.
+
+---
+
+## Step 3 — Create the spike document
+
+Generate a filename: `YYYY-MM-DD-<slug>.md` where slug is 3-5 kebab-case words. Create `<dir>/research/spikes/` if it doesn't exist.
+
+Write the document:
+
+```markdown
+# Spike: <Question as title>
+
+**Status**: 🔄 open
+**Question**: <exact question — the spike is done when this is answered>
+**Timebox**: <duration — treat this as a hard stop>
+**Started**: YYYY-MM-DD
+
+**If yes**: <what this unblocks>
+**If no**: <what this means for the project — pivot, descope, or accept the constraint>
+
+---
+
+## Approach
+
+<How you'll investigate this. List the specific things to try or check, in order. Keep it short — a spike is not a research project.>
+
+1. <First thing to try>
+2. <Second thing to try>
+3. <Fallback / alternative to test if #1 fails>
+
+---
+
+## Log
+
+> Add entries as you go. Timestamp optional but helpful for longer spikes.
+
+- 
+
+---
+
+## Outcome
+
+> Complete this when the spike concludes. Do not leave it blank.
+
+**Answer**: <yes / no / partial — state it directly>
+
+**Evidence**: <what you found that supports the answer — command output, a working example, a specific failure mode>
+
+**Recommendation**: <what the project should do as a result>
+
+**Status**: ✅ concluded / ⚠️ inconclusive / 🚫 abandoned
+```
+
+Tell the user the file is created and the timebox has started.
+
+---
+
+## Step 4 — Work through the spike
+
+Ask: **"Do you want to work through this together, or do you have findings to add?"**
+
+**If working together**: follow the approach list. Help the user interpret results. When something works, capture it in the Log with enough detail to reproduce. When something fails, note the failure mode specifically — "it failed" is not useful; "it fails with `AssertionError` in `wait_for_save` when block size > 3 chunks" is.
+
+Push toward the answer — don't let the spike turn into open-ended exploration. If the timebox is approaching and the answer isn't clear, that is itself a finding.
+
+**If adding findings**: take what they give you, help structure it into Log entries, and push toward the Outcome section.
+
+---
+
+## Step 5 — Conclude the spike
+
+When the question is answered (or the timebox is up):
+
+Fill in the **Outcome** section:
+- State the answer directly — don't hedge if the evidence is clear
+- Include concrete evidence (a working command, a measured number, a specific error)
+- Set status to `✅ concluded`, `⚠️ inconclusive`, or `🚫 abandoned`
+
+**On inconclusive**: if the timebox ran out without a clear answer, write what was learned and what a follow-up spike would need to investigate. Don't extend the timebox — open a new spike with a narrower question.
+
+**On 'no' answers**: a 'no' is a valid and valuable outcome. Help the user think through what it means:
+- Does this block a milestone? → flag it in `milestones.md` as a blocker
+- Does it invalidate a roadmap assumption? → suggest `/nu-pm-roadmap` to review
+- Is there an alternative approach to spike? → suggest a follow-up spike with a new angle
+
+Change **Status** at the top from `🔄 open` to match the outcome status.
+
+---
+
+## Step 6 — Connect back to the project
+
+After concluding, ask: **"Does this outcome change anything in your milestones or roadmap?"**
+
+If yes, help them identify the specific change:
+- A task that's now unblocked → offer to note it in `milestones.md`
+- A task that's now blocked → offer to add a blocker note
+- An assumption in `roadmap.md` that needs updating → suggest `/nu-pm-roadmap`
+- A technology decision that should be recorded → suggest adding it to the roadmap's Key Decisions table

package/commands/nu-pm-status.md

@@ -0,0 +1,52 @@
+---
+name: nu-pm-status
+description: Give a concise, actionable summary of what to work on next. Reads product/how-to/nu-pm-status.md for project-specific context (cluster state, infra prerequisites, etc.).
+---
+
+Give a concise, actionable summary of what to work on next.
+
+The target directory is: `$ARGUMENTS` (use `product/` if empty or not provided).
+
+## Steps
+
+1. Read all of these in parallel:
+   - `<dir>/now.md` — current focus and what was just done
+   - `<dir>/milestones.md` — task checklist across all milestones
+   - `<dir>/roadmap.md` — architecture context (skim only)
+   - The most recent file in `<dir>/reports/` (latest session report)
+
+2. If `<dir>/how-to/nu-pm-status.md` exists, read it now and incorporate any project-specific context gathering (e.g. reading a cluster state file, checking infra status) before assembling the output.
+
+3. From milestones.md: find the active milestone (first one marked `🔄 in progress`). Within it, find:
+   - The first `[~]` task (in progress but not done)
+   - The first `[ ]` task (next to start)
+
+4. If `now.md` contains a `Design doc:` and `Current story:` field, load the relevant story section from the referenced PRD to get its concrete scope and first action.
+
+5. Check for blockers or prerequisites:
+   - Does the next task need infrastructure running? (note it clearly)
+   - Is there an unresolved bug or investigation from the last session report?
+   - Is there a "next session starts at" note in the last report?
+
+6. Output a short, scannable answer:
+
+```
+## What's Next
+
+**Milestone**: <milestone name> (<X/Y stories done>)
+**Active story**: <title>
+
+**Why this story**: <1–2 sentences — what it unblocks or proves>
+
+**Prerequisite check**:
+- Infrastructure: <up / hibernated / unknown>
+- Any blocker: <yes/no — describe if yes>
+
+**Concrete first action**:
+<The exact command to run or file to edit to start this task.>
+
+**After that**:
+<The 2–3 tasks that follow in sequence.>
+```
+
+Keep it tight. No need to summarise every milestone — just tell the user what to do right now and why.

package/commands/nu-pm-update.md

@@ -0,0 +1,49 @@
+---
+name: nu-pm-update
+description: Append a timestamped progress snapshot to today's session report. Does NOT commit, hibernate, or stop work. Reads product/how-to/nu-pm-update.md for project-specific additions.
+---
+
+Append a timestamped progress snapshot to today's session report. Mid-session checkpoint only — does not commit, push, or hibernate.
+
+The target directory is: `$ARGUMENTS` (use `product/` if empty or not provided).
+
+## Steps
+
+1. Read `<dir>/now.md` and `<dir>/milestones.md` to understand current state.
+
+2. Run `git log --oneline -6` and `git status --short` to see what has changed since last commit.
+
+3. Check `<dir>/how-to/nu-pm-update.md` if it exists — read it now and incorporate any project-specific state-gathering steps before writing the report (e.g. checking cluster state, reading infra status files).
+
+4. Determine today's report file path: `<dir>/reports/YYYY-MM-DD.md` (today's date).
+
+5. If the file does not exist, create it with this header:
+```markdown
+# Session Report — YYYY-MM-DD
+```
+
+6. Append a new timestamped section:
+```markdown
+## Update — HH:MM UTC
+
+**Active task**: <first [~] or [ ] task in milestones.md>
+
+### Completed since last update
+- <bullet per completed item>
+
+### In progress
+- <what is currently running or being worked on>
+
+### Key results (if any)
+| Metric | Value |
+|--------|-------|
+
+### Notes / decisions
+- <bugs found, config changes, observations>
+
+---
+```
+
+7. Confirm to the user: "Updated `<dir>/reports/YYYY-MM-DD.md` with a progress snapshot at HH:MM UTC."
+
+Do NOT commit, push, or run any shutdown steps.

package/commands/nu-pm-user-guide.md

@@ -0,0 +1,211 @@
+---
+name: nu-pm-user-guide
+description: Display the full user guide for the nu-pm-* command system — what each command does, when to use it, and how the document stack fits together.
+---
+
+Display the following user guide exactly as written. Do not summarize it or truncate it.
+
+After displaying it, ask: **"Would you like me to save a copy to `product/nu-pm-user-guide.md` so you can view it in your IDE?"** If yes, write the guide content (everything below the `---` separator, starting with `# ds-work User Guide`) to `product/nu-pm-user-guide.md`. If the user provides a different path, use that instead. Confirm the file was written and note they can open it in their editor.
+
+---
+
+# ds-work User Guide
+
+The `nu-pm-*` commands are a set of Claude Code slash commands for managing software projects end-to-end — from initial setup through daily session flow, periodic review, and external communication. They work together as a system.
+
+---
+
+## The Command Map
+
+### Setup commands
+Run these when starting a new project or filling in empty scaffolded docs.
+
+| Command | What it does |
+|---------|-------------|
+| `/nu-pm-scaffold [description]` | Bootstrap a new project — creates the full `product/` directory, placeholder docs, `how-to/` extension templates, and `project-management-principles.md`. Run from the project root. |
+| `/nu-pm-vision [dir]` | Interactively create `vision.md` from scratch (if placeholder/missing) or review and update an existing one against current project state. |
+| `/nu-pm-roadmap [dir]` | Interactively create `roadmap.md` from scratch (if placeholder/missing) or review and update an existing one against what milestones have proven. |
+
+### Session lifecycle commands
+Run these every session, in order.
+
+| Command | When | What it does |
+|---------|------|-------------|
+| `/nu-pm-continue [dir]` | Start of session | Reads `now.md`, `milestones.md`, the latest session report, and the active PRD (if any). Outputs a resume brief with the active story and next action. |
+| `/nu-pm-status [dir]` | After finishing a task | Shorter than continue. Finds the next task, checks infra prerequisites, gives the concrete first action. |
+| `/nu-pm-update [dir]` | Mid-session checkpoint | Appends a timestamped snapshot to today's session report. Does not commit. Use before stepping away or after a significant task. |
+| `/nu-pm-halt [dir]` | End of every session | Full shutdown: updates `milestones.md` + `now.md`, writes the session report, commits and pushes, then runs any project-specific teardown from `how-to/nu-pm-halt.md`. |
+
+### Periodic review commands
+Run these at milestone boundaries or when strategy needs a check.
+
+| Command | What it does |
+|---------|-------------|
+| `/nu-pm-vision [dir]` | Review mode (when vision.md is filled): checks each section for drift against recent milestone completions and session reports. Proposes targeted edits. Appends Decision Log rows. |
+| `/nu-pm-roadmap [dir]` | Review mode (when roadmap.md is filled): checks milestone state, architecture currency, resolved open questions, alignment with vision. Proposes targeted edits. |
+
+### Exploration commands
+Run these for investigations that don't fit neatly into a milestone — research that informs a decision, or a technical question that needs a time-boxed answer before work can continue.
+
+| Command | What it does |
+|---------|-------------|
+| `/nu-pm-research [dir]` | Create a structured research document for market research, competitive analysis, technology evaluation, or domain deep-dives. Guides you through framing the question, scoping the investigation, and writing findings + recommendation. Shows open research at the start. Writes to `product/research/` or `product/market-research/` depending on type. |
+| `/nu-pm-spike [dir]` | Run a time-boxed technical spike — a focused investigation with a single yes/no/A-vs-B question and a hard timebox. Shows open spikes at the start so nothing gets forgotten. Writes to `product/research/spikes/`. Connects the outcome back to milestones or roadmap when concluded. |
+
+### Communication commands
+Run these when you need to explain the project to someone outside.
+
+| Command | What it does |
+|---------|-------------|
+| `/nu-pm-one-pager [dir]` | Creates or updates `product/one-pager.md` — a ~500-word single-page project summary (problem, what we're building, how it works, where we are, what's next, key numbers). Iterates with you until you approve, then saves. |
+| `/nu-pm-elevator-pitch [dir]` | Generates 3 pitch variants (tweet, 30-second verbal, 60-second investor) from `vision.md` and `one-pager.md`. Iterates on tone, audience, and concreteness. Saves to `product/elevator-pitch.md` when approved. |
+
+### Reference
+| Command | What it does |
+|---------|-------------|
+| `/nu-pm-user-guide` | This document. |
+
+---
+
+## The Document Stack
+
+Every project using this system has the same structure under `product/`:
+
+```
+product/
+├── vision.md                    ← why + who (problem, customer, north star)
+├── roadmap.md                   ← what + how (architecture, milestones, key decisions)
+├── milestones.md                ← progress tracker (story checkboxes, milestone status)
+├── now.md                       ← session pointer (current focus, what was just done)
+├── project-management-principles.md   ← how this system works (per-project copy)
+├── one-pager.md                 ← external-facing summary (generated by /nu-pm-one-pager)
+├── elevator-pitch.md            ← pitch variants (generated by /nu-pm-elevator-pitch)
+├── design/                      ← PRDs for milestones that need them (M1-PRD.md, etc.)
+├── market-research/             ← competitive analysis, user research
+├── research/                    ← technology deep-dives and domain research (nu-pm-research)
+│   └── spikes/                  ← time-boxed feasibility investigations (nu-pm-spike)
+├── operations/                  ← cluster runbooks, infra how-tos
+├── learnings/                   ← post-hoc reports, incident retrospectives
+├── reports/                     ← session history (YYYY-MM-DD.md, written by update/halt)
+└── how-to/                      ← project-specific skill extensions (see below)
+    ├── nu-pm-continue.md
+    ├── nu-pm-halt.md
+    ├── nu-pm-status.md
+    └── nu-pm-update.md
+```
+
+**One question, one document.** The moment the same content lives in two places, they drift.
+
+| Question | Answer lives in |
+|----------|----------------|
+| Why are we building this? Who is it for? | `vision.md` |
+| What are we building and how? | `roadmap.md` |
+| Which milestone am I in? Which stories are done? | `milestones.md` |
+| What am I working on right now? | `now.md` |
+| What exactly does Story N require? | `design/M{N}-PRD.md` |
+| What happened last Tuesday? | `reports/YYYY-MM-DD.md` |
+| How do I explain this project in one page? | `one-pager.md` |
+
+---
+
+## Change Tracking
+
+Different documents track changes differently:
+
+| Document | Tracking mechanism | Why |
+|---|---|---|
+| `vision.md` | Decision Log at the bottom (append-only) | Changes are rare and high-signal — losing the old direction costs context |
+| `roadmap.md` | Decision Log + resolved Open Questions move to Key Decisions | Architecture pivots need "why we ended up here", not silent rewrites |
+| `milestones.md` | None — git history + session reports are the trail | Changes too frequently; a log would duplicate reports |
+| PRDs in `design/` | Decision Log at the bottom | Story-level design decisions are what future-you will question |
+
+The Decision Log format used in `vision.md` and `roadmap.md`:
+```markdown
+## Decision Log
+
+| Date | Section | Change | Rationale |
+|------|---------|--------|-----------|
+| YYYY-MM-DD | <section name> | <what changed — brief> | <why> |
+```
+
+---
+
+## How Project-Specific Extensions Work
+
+Each session skill can be extended with a project-specific file in `product/how-to/`:
+
+| File | Extends | Common use |
+|------|---------|------------|
+| `how-to/nu-pm-continue.md` | `/nu-pm-continue` | Extra context sources to read at session start (e.g. a CURRENT_STATE.md, cluster status) |
+| `how-to/nu-pm-halt.md` | `/nu-pm-halt` | Infrastructure shutdown steps (scale down GPU nodes, hibernate cluster, etc.) |
+| `how-to/nu-pm-update.md` | `/nu-pm-update` | Extra state to capture in mid-session snapshots |
+| `how-to/nu-pm-status.md` | `/nu-pm-status` | Infrastructure prerequisite checks before suggesting the next task |
+
+**How-to files contain only the project-specific additions.** The generic steps live in the global skills. If nothing is project-specific, delete the file.
+
+---
+
+## Typical Workflows
+
+### Starting a new project
+```
+/nu-pm-scaffold [description]   # create product/ structure
+/nu-pm-vision                   # fill in vision.md interactively
+/nu-pm-roadmap                  # fill in roadmap.md interactively
+# edit product/how-to/nu-pm-halt.md — add your infra shutdown steps
+# edit milestones.md — replace placeholder tasks with real ones
+/nu-pm-continue                 # start first session
+```
+
+### Daily session
+```
+/nu-pm-continue     # read resume brief, orient to active story
+# ... do the work ...
+/nu-pm-update       # optional mid-session checkpoint
+# ... more work ...
+/nu-pm-halt         # update docs, commit, push, shut down infra
+```
+
+### After finishing a task mid-session
+```
+/nu-pm-status       # find the next task with prerequisite check
+```
+
+### End of milestone — check if strategy still holds
+```
+/nu-pm-vision       # review: did this milestone change our understanding?
+/nu-pm-roadmap      # review: is the plan still right? resolve open questions
+```
+
+### Before a meeting or investor conversation
+```
+/nu-pm-one-pager      # generate or refresh the one-pager
+/nu-pm-elevator-pitch # generate or refine the pitch
+```
+
+---
+
+## Where the Skills Live
+
+All `nu-pm-*` commands are global — they work in any project. They live in:
+```
+~/.claude/commands/nu-pm-*.md
+```
+
+Each skill file is the complete prompt for that command. To modify a skill's behavior, edit the file there. Changes take effect immediately in the next invocation.
+
+Project-specific additions go in `product/how-to/` inside each project — not in the global skill files.
+
+---
+
+## All Arguments Default to `product/`
+
+Every command that takes a directory argument (`[dir]`) defaults to `product/` if no argument is given. Pass a different path when your project uses a non-standard layout:
+```
+/nu-pm-status               # uses product/
+/nu-pm-status src/product   # uses src/product/
+```
+
+---
+
+*The per-project copy of operational conventions lives in `product/project-management-principles.md`. That document covers how milestones, PRDs, and commits work within a project. This user guide covers the tooling itself.*

package/commands/nu-pm-vision.md

@@ -0,0 +1,153 @@
+---
+name: nu-pm-vision
+description: Interactively create or review product/vision.md. Creates it from scratch if missing (e.g. after scaffold), or reviews it against current project state and proposes updates.
+---
+
+You are helping the user create or review the product vision document. Branch on whether the document exists and is filled in.
+
+The target directory is: `$ARGUMENTS` (use `product/` if empty or not provided).
+
+---
+
+## Step 1 — Assess what exists
+
+Read `<dir>/vision.md`.
+
+Classify its state:
+- **Missing**: file does not exist
+- **Placeholder**: file exists but contains scaffold boilerplate (`<Describe...>`, `TODO`, `> Replace this placeholder`, empty sections)
+- **Filled**: file has real content
+
+Then read these in parallel (they inform both creation and review):
+- `<dir>/milestones.md` — what has been proven or completed
+- `<dir>/now.md` — most recent completed work and current focus
+- The most recent file in `<dir>/reports/` — last session's findings
+
+---
+
+## Step 2A — If Missing or Placeholder: Create Mode
+
+Walk the user through each section interactively. Do not generate all sections at once — complete one, show it, get feedback, then move on.
+
+Work through these sections in order:
+
+### Problem
+Ask: *"What pain are you solving, for whom, and why existing options fall short?"*
+
+Generate a draft from whatever the user says. Aim for 3–5 sentences covering:
+- Who feels the pain and in what context
+- What they do today (and why that's inadequate)
+- What the gap is
+
+Show the draft. Offer to sharpen it. Move on when the user is satisfied.
+
+### Customer / Target user
+Ask: *"Who is this for — be as specific as you can about their role, team, and the moment they hit this problem."*
+
+Draft 2–3 sentences. Offer to add a secondary user if relevant. Move on.
+
+### Market context
+Ask: *"What alternatives exist and what's wrong with each? Are there any competitors or adjacent products?"*
+
+Draft a short paragraph. Refer to `<dir>/market-research/` if it exists and has content. Move on.
+
+### North star
+Ask: *"What does success look like in 2–3 years? What can a user do then that they can't do today?"*
+
+Draft 2–3 sentences. This should be aspirational but specific — not "best product in category" but a concrete capability or outcome. Move on.
+
+### Why now
+Ask: *"Why is this the right moment to build this — what's changed recently that makes it viable or urgent?"*
+
+Draft 1–2 sentences. Could be a technology shift, a market gap that just opened, a regulatory change, or simply that the infrastructure now exists to make it feasible. Move on.
+
+### What we are not
+Ask: *"What are the product-level anti-goals — things this product will deliberately never try to be?"*
+
+Draft 3–5 bullets. These should be principled product-scope cuts, not just feature gaps. Move on.
+
+### Finalize
+Show the complete draft. List 2–3 suggestions for anything that seems vague, unsupported, or weak.
+
+Ask: *"Anything to change before I save this?"* Iterate until the user confirms.
+
+Write to `<dir>/vision.md`. Do not include a Decision Log yet — the document is new.
+
+---
+
+## Step 2B — If Filled: Review Mode
+
+The goal is to surface drift: places where the vision no longer matches what has been learned or built.
+
+### Load context
+Read the filled `<dir>/vision.md` fully.
+
+### Check for drift — work through each section
+
+**Problem section**: Does recent work confirm or complicate the problem statement?
+- Did any completed milestone reveal that the problem is harder, narrower, or different than stated?
+- Is the "why existing options fall short" still accurate?
+
+**Customer section**: Has the target user sharpened or shifted?
+- Did actual usage (or benchmark results, or customer feedback) reveal a more specific or different user profile?
+
+**Market context**: Is this still accurate?
+- Any new competitors or reference points from the session reports or design docs?
+
+**North star**: Does it still point the right direction?
+- Did any milestone reveal that the north star is too ambitious, too narrow, or needs reframing?
+
+**Why now**: Is the timing argument still valid, or has it strengthened?
+- Did completed work prove out a key technical assumption?
+
+**What we are not**: Are the anti-goals still holding?
+- Did any scope decision in milestones or PRDs imply a different boundary?
+
+### Propose specific edits
+
+For each section where you detect drift or weakness, propose a specific change:
+
+```
+### [Section name] — suggested update
+
+**Current**: "<exact quote from current doc>"
+
+**Proposed**: "<replacement text>"
+
+**Why**: <one sentence — what changed or what's weak>
+```
+
+If a section looks solid, say so briefly and skip it.
+
+Aim for 2–5 targeted proposals. Do not rewrite the whole document.
+
+### Iterate
+Ask: *"Which of these would you like to apply? I can also make other changes or leave anything as-is."*
+
+Apply changes one at a time. Show the updated section after each change.
+
+### Decision Log
+If any changes are applied, append a row to the Decision Log at the bottom of the file:
+
+```markdown
+---
+
+## Decision Log
+
+| Date | Section | Change | Rationale |
+|------|---------|--------|-----------|
+| YYYY-MM-DD | <section name> | <what changed — brief> | <why — what prompted the update> |
+```
+
+If a Decision Log already exists, append a new row. Do not rewrite existing rows.
+
+Write the file when the user confirms.
+
+---
+
+## Step 3 — After saving
+
+Tell the user:
+- What was written or updated
+- If this was a creation: suggest running `/nu-pm-roadmap` next to align the roadmap with the vision
+- If this was a review: note any vision changes that may require a roadmap review (`/nu-pm-roadmap`)

package/package.json

@@ -0,0 +1,21 @@
+{
+  "name": "@nudata/nu-claude-pm",
+  "version": "0.1.0",
+  "description": "Claude Code slash commands for end-to-end project management — session flow, vision, roadmap, research, and external comms.",
+  "keywords": ["claude", "claude-code", "pm", "project-management", "ai"],
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "nu-claude-pm": "./bin/nu-claude-pm.js"
+  },
+  "files": [
+    "bin/",
+    "commands/"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}