Chsh Pm Ncs Prd

Ask: "Which would you like to do?" — then follow the matching section below.

Mode A — New PRD

Existing project with no PRD yet? This is still Mode A. Before asking the questions below, scan the existing code (src/, prj.conf, CMakeLists.txt) to understand what features are already implemented, then use those findings to pre-fill answers and confirm them with the user rather than starting from a blank slate.

Walk through each section of the PRD template conversationally. Ask one section at a time. Wait for answers before moving on.

A1. Project Identity

• What is the name of the product?
• One sentence: what does it do?
• Which NCS version? (e.g. v3.2.4)
• Which development board(s) will it run on?

A2. Problem & Users

• What problem does this device solve?
• Who will use it? (primary / secondary users)
• What would a user have to do today without this product?

A3. Wi-Fi Connectivity

Ask which Wi-Fi modes are needed in plain terms:

• Should the device join an existing Wi-Fi network (like a laptop does)?
• Should the device create its own Wi-Fi hotspot for others to connect to?
• Should the device connect directly to a phone without any router?
• Can the user switch between modes at runtime, or is it fixed at build time?
• What is the default mode on first boot?

A4. Network Communication

• Should the device serve a webpage that users open in a browser?
• Should it expose a REST API for other apps to call?
• Should it send data to the cloud via MQTT?
• Should it be reachable by a friendly hostname (like mydevice.local)?
• Any other communication needs?

A5. Buttons & LEDs

For each board, ask:

• What should each button do? (short press, long press, hold at boot)
• What should each LED indicate? (connected, connecting, error, etc.)

A6. Storage & Persistence

• Should the device remember its Wi-Fi mode after power-off?
• Should it remember Wi-Fi credentials so it reconnects automatically?
• Any other settings that should survive a power cycle?

A7. Optional Capabilities

• Should the device support remote monitoring and OTA updates (Memfault)?
• Should Wi-Fi credentials be set via a phone app over Bluetooth?
• Should a developer be able to type commands over the serial console?

A8. Success Metrics

Ask for 3–5 things that prove the product is working well. Examples: "connects within 30 seconds", "page loads under 2 seconds", "runs for 24 hours without restart".

A9. Release Criteria

Ask: which P0 requirements must all pass before the product can be released?

Mode B — Add Feature

1. Read docs/PRD.md and check the current Revision History.
2. Show the current feature list (Sections 2 and 3) as a brief summary.
3. Ask: "What feature would you like to add?"
4. For the new feature, ask:
   • Who needs it and why?
   • How should it behave from the user's point of view?
   • What are 2–3 acceptance criteria that prove it works?
   • Is it P0 / P1 / P2?
5. Ask: "Does this change any success metrics, hardware notes, or release criteria?"
6. Proceed to Generate Output.

Mode C — Change Feature

1. Read docs/PRD.md and check the current Revision History.
2. List the current functional requirements (FR-xxx) with one-line titles.
3. Ask: "Which requirement would you like to change?"
4. Show the current text, then ask what should change:
   • The user story?
   • The acceptance criteria?
   • The priority?
5. Collect the updated text.
6. Proceed to Generate Output.

Mode D — Update (Code Changed, PRD Stale)

Use this when the developer has made code changes but the PRD has not been updated.

D1. Find the gap

Read the Revision History table in docs/PRD.md to get the last PRD revision date.

PRD_DATE=<last revision date from table>
git log --oneline --since="$PRD_DATE" -- src/ prj.conf CMakeLists.txt Kconfig boards/

D2. Summarise what changed

For each commit or changed area, describe in plain language what the code change means from a user perspective. For example:

• "P2P mode was added — users can now connect directly to a phone without a router."
• "A mode-selection menu was added — users can now hold Button 1 at boot to choose Wi-Fi mode."

Present a table to the user:

D3. Collect updates

For each agreed change, ask for:

• Updated or new user story
• Acceptance criteria
• Priority

Proceed to Generate Output.

Generate Output

After any mode:

1. Update docs/PRD.md using PRD_TEMPLATE.md as the structure.
2. Add a new row to the Revision History table at the bottom of the document:

   | YYYY-MM-DD-HH-MM | <one-line summary of changes> |
   

3. Confirm: "PRD updated. New revision added to Revision History."

Handoff Prompt

After saving the PRD, always ask:

"The PRD is updated at docs/PRD.md (see Revision History for this change).

Would you like to hand off to chsh-dev-spec to update the engineering specs, or to chsh-dev-ncs-project to implement or update the code?

Reply design, implement, or no to stop here."

Self-Update Policy

At the end of each conversation, review what was discovered and check whether any facts in this skill are new, corrected, or outdated (e.g. new PRD section patterns, handoff question wording, revision history conventions).

If updates are warranted:

1. Collect all proposed changes with a brief rationale for each.
2. Present a summary to the user and ask for approval using AskQuestion.
3. Apply approved updates to this file immediately.

Do not modify this skill mid-conversation unless the user explicitly asks.