pm-add-feedback

Multi-host portability rules. When invoking AskUserQuestion:

1. The header field MUST be a short noun phrase (≤ 12 characters). Mistral Vibe rejects longer headers with string_too_long. Pick from: Start, Target, Scope, Audience, Methodology, Feature, Question, Confirm, Intake.
2. The options list MUST have at least 2 items. Vibe rejects empty/single-option calls. For free-text input, always provide ≥ 2 framing options (e.g. Yes, here's the input / Skip) — never call ask_user_question with options: [].

Preamble (run first)

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || \
  source .nanopm/lib/nanopm.sh 2>/dev/null || \
  { echo "ERROR: nanopm not installed. Run: curl -fsSL https://raw.githubusercontent.com/nmrtn/nanopm/main/setup | bash"; exit 1; }
nanopm_preamble
_OPP_DIR=".nanopm/wiki/entities/opportunities"
_BIN="$HOME/.nanopm/bin"

What this skill does

/pm-add-feedback is the single ingestion door for raw user signal. Whatever the form — an interview transcript, a pasted Slack DM, a support ticket, a Gong export, a feedback email — it comes in here, and every run ends the same way: the source is archived verbatim and the opportunity DB is grounded in fresh, verifiable verbatims, with the source cross-linked to every opportunity it touched. This is the learning loop the PRD (.nanopm/wiki/docs/prds/feedback-ingestion-and-learning-loop.md) calls non-negotiable.

The loop, every time:

• INTAKE — resolve a file path, --paste text, or a connector source to raw content.
• ARCHIVE (Wave-0 API) — nanopm_archive_raw <type> <source> drops the bytes under raw/<type>/<id>.<ext> keyed by a content hash (idempotent), before any extraction. Everything below cites back to that file.
• EXTRACT (Mom-Test discovery filter) — pull problems / past behaviors with their verbatim quotes; demote feature-requests and speculation. Each kept claim carries a citation of the exact form "<verbatim>" — <source>, <date> that resolves to the archived raw file.
• PASS 1 — ground existing opportunities (default, highest-value path) — for each problem, judge it against the existing DB; a confident match is a candidate to ground (append verbatim, propose a provenance upgrade nano-hypothesis → evidence-backed). This is a judgement — the write itself is delegated (see DELEGATE).
• PASS 2 — surface new opportunities (strategy-aware) — for unmatched signal, judge whether it deserves a NEW opportunity grounded in vision / strategy / objectives — only when the signal is both unmatched AND strategy-coherent. Again a judgement; the write is delegated.
• CONFIRM — ONE batched confirmation (accept all / edit / reject) before any write; uncertain matches carry ⚠ low-confidence. Headless (no TTY / viewer) runs fall back to write-then-review (delegate with ⚠ low-confidence, no blocking prompt).
• DELEGATE — /pm-add-feedback does NOT write opportunity files itself. For each confirmed candidate it hands the problem + verbatim/citation + raw-source ref + suggested provenance to /pm-opportunities --ingest-candidate (Change 1's "ingest confirmed candidate" entry), which is the single owner of the opportunity DB. That entry runs the full canonical process — dedup-with- confidence, match-or-create, related_to, SCHEMA conformance, reindex, the entity LOG line, AND the bidirectional nanopm_raw_manifest source→opportunity link — and returns a per-candidate result.
• SUMMARY — emit a machine-readable run-summary (archived raw path, opportunities created/updated, provenance transitions, themes) — assembled from the per-candidate results /pm-opportunities returned — AND persist it via nanopm_context_append — the linchpin the viewer digest parses.