Interactive PRD authoring for NCS IoT projects. Guides the Product Manager through creating, extending, or updating PRD.md under docs/. No coding knowledge required. Use when creating a new PRD, adding or changing a feature, or syncing the PRD after code changes.
This skill is for the Product Manager role. It asks questions in plain language
and maintains a single PRD.md in docs/ with a built-in revision history table.
No Kconfig, no Flash/RAM numbers, no architecture diagrams — those are for the engineer. The PRD answers: What should this device do, for whom, and how should it behave?
Template: PRD_TEMPLATE.md
Check what exists in the project:
cat docs/PRD.md 2>/dev/null # existing PRD (check Revision History)
git log --oneline -10 -- src/ prj.conf CMakeLists.txt # recent code changes
Present the user with the right starting options:
| Situation | Offer |
|---|---|
| No PRD exists yet | New |
| PRD exists, no code changes after last PRD revision date | Add Feature or Change Feature |
| PRD exists, code commits exist after its last revision date | Update (code moved ahead of PRD), Add Feature, or Change Feature |
Ask: "Which would you like to do?" — then follow the matching section below.
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.
Ask which Wi-Fi modes are needed in plain terms:
mydevice.local)?For each board, ask:
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".
Ask: which P0 requirements must all pass before the product can be released?
docs/PRD.md and check the current Revision History.docs/PRD.md and check the current Revision History.Use this when the developer has made code changes but the PRD has not been updated.
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/
For each commit or changed area, describe in plain language what the code change means from a user perspective. For example:
Present a table to the user:
| Code change | User-visible effect | Update PRD? |
|---|---|---|
| Added wifi-p2p support | New connectivity option for users | Yes / No |
| Fixed DHCP timeout | Faster connection (non-visible internally) | No |
For each agreed change, ask for:
Proceed to Generate Output.
After any mode:
docs/PRD.md using PRD_TEMPLATE.md as the structure.| YYYY-MM-DD-HH-MM | <one-line summary of changes> |
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."
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:
AskQuestion.Do not modify this skill mid-conversation unless the user explicitly asks.