prompt-rewriter:generate-midnight-network-dapp-spec

What this skill does

# Generate Midnight Network DApp Spec Brief

## Overview

Walk the user through an adaptive, multi-step Q&A and produce a short
markdown brief that describes a Midnight Network DApp at enough depth
to seed a spec/planning skill but without locking in implementation
details. The brief is returned inline in the chat; it is **not** written
to disk by default.

<HARD-GATE>
Do NOT write Compact contracts, TypeScript code, project scaffolding,
or implementation files. This skill collects direction and produces a
markdown brief. Implementation decisions happen downstream in
/superpowers:brainstorming, /sdd:specify, or similar.
</HARD-GATE>

## When to Use

- User wants to generate a Midnight DApp spec from scratch.
- User typed `/prompt-rewriter:midnight-dapp-spec`.
- User says things like "I want to build a Midnight DApp for X — help me
  write the spec brief."

## When NOT to Use

- User already has a detailed spec and wants to *implement* it. Use an
  implementation-focused skill instead.
- User wants to write prompts for non-Midnight ecosystems. This skill is
  Midnight-specific.

## Checklist

Create a todo for each item via `TodoWrite` and complete in order:

1. Intake — discover any existing DESIGN.md
2. Use-case — Educational / PoC / MVP
3. Core concept — one-line description + audience
4. Value movement (Phase 3) — how / whether the DApp moves value
5. Privacy direction (Phase 3a) — inferred private/public items
6. Interfaces — Web UI / CLI / TUI / Headless
7. Design system (only if Web UI or TUI) — reuse, full flow, or brief
8. Developer-experience priorities (Educational / PoC only)
9. Networks — always asked
10. Out of scope
11. Render and return the brief

## References

Read each reference only when its phase is entered:

- `references/use-case-defaults.md` — Phase 1 / 6 / 7 branching rules; also seeds Phase 3a privacy inference.
- `references/privacy-goals.md` — Phase 3a inference and fallback list.
- `references/interface-defaults.md` — Phase 3a privacy-item hints per interface.
- `references/design-integration.md` — Phase 5 design sub-flows.
- `references/output-template.md` — Phase 9 render template.

## Phase 0 — Intake

No user-facing prompting. Do this silently:

```bash
ls ./DESIGN.md ./docs/DESIGN.md 2>/dev/null
ls ./TUI_DESIGN.md ./docs/TUI_DESIGN.md 2>/dev/null
```

Record any hits. They become reuse candidates in Phase 5.

Announce the start of the flow:

> "I'll ask a series of questions about the Midnight DApp you want to
> spec out. We'll work through use-case, concept, privacy, interfaces,
> networks, and (if UI is involved) design direction. The end result is
> a concise brief you can hand to a spec/planning skill."

## Phase 1 — Use-case

Read `references/use-case-defaults.md` before asking.

```text
AskUserQuestion(
  question: "Which best describes the kind of Midnight DApp you're building?",
  header: "Use-case",
  options:
    - label: "Educational example"
      description: "Learning resource — zero-config, demo-oriented, local-devnet first. Not aimed at production users."
    - label: "Proof of Concept (PoC)"
      description: "Internal or technical validation of an idea. Real users not yet in scope."
    - label: "MVP"
      description: "First shippable slice. Real users in scope; deployment story matters."
)
```

Record the answer. It gates Phase 6 (skipped for MVP) and Phase 7
(Educational treats local as implicit).

## Phase 2 — Core concept

Ask two questions in sequence.

### Q2a — One-line description

```text
AskUserQuestion(
  question: "In one sentence, what does this DApp do?",
  header: "Concept",
  options:
    - label: "It's <X> for <audience> that does <Y>"
      description: "Product framing: who uses it, what it does for them."
    - label: "It solves <problem> by <approach>"
      description: "Problem/solution framing: what problem, what is the private mechanism."
    - label: "I'll describe it freely"
      description: "Free-form via Other."
)
```

Accept free-form text via Other when the seeded framings don't fit.
Store the one-line description verbatim — it seeds the `Summary`
section of the brief.

### Q2b — Audience

```text
AskUserQuestion(
  question: "Who is this DApp for?",
  header: "Audience",
  options:
    - label: "Developers learning Midnight"
      description: "The DApp exists to teach. (Most common in Educational use-cases.)"
    - label: "A specific user group"
      description: "End users outside the dev audience — e.g., DAO members, event attendees, researchers."
    - label: "An internal team"
      description: "Validating an idea for internal stakeholders — PoC / MVP flavour."
)
```

Record the answer. Feeds Phase 3a's privacy-item inference.

## Phase 3 — Value movement

```text
AskUserQuestion(
  question: "Does this DApp move value between parties?",
  header: "Value movement",
  options:
    - label: "No value movement"
      description: "Informational / gated logic / ZK proofs only."
    - label: "NIGHT transfers"
      description: "Moves the public, fixed-supply NIGHT token. Balances and transfers observable on-chain."
    - label: "Custom shielded token"
      description: "DApp mints / manages its own Zswap-shielded token. Balances and transfers private."
    - label: "Custom unshielded token"
      description: "DApp mints / manages its own public token. Balances observable."
    - label: "Shielded unique assets"
      description: "NFT-style unique items via Zswap."
    - label: "Multiple kinds"
      description: "A mix of the above."
)
```

If the user picked "Multiple kinds," follow up with a **multi-select**
across the same four concrete options (excluding "No value movement"
and "Multiple kinds").

**Do not** ask a balance-privacy follow-up — privacy is implicit in the
chosen option (shielded vs unshielded).

**Do not** mention DUST as a DApp-level privacy item in later phases.
DUST is a non-transferable fee resource auto-generated from NIGHT; it
is not a user-transferable asset.

## Phase 3a — Privacy direction

Read `references/privacy-goals.md`, `references/interface-defaults.md`, and the "Inference hints for Phase 3a" section of `references/use-case-defaults.md`.

1. **Infer candidate items.** Using Phase 2 (concept + audience),
   Phase 3 (value movement), and interface hints, produce a list of
   4–10 concrete data items likely present in this DApp. Follow the
   inference heuristics in `privacy-goals.md`.

2. **Fallback if inference under-produces.** If the list has fewer
   than 4 items, merge in items from the generic fallback list in
   `privacy-goals.md`.

3. **Ask per item.** For each candidate item, ask one
   `AskUserQuestion` with options:

   ```text
   - label: "Likely private"
     description: "The DApp should keep this hidden from observers."
   - label: "Likely public"
     description: "Observable or deliberately disclosed."
   - label: "Undecided / depends on design"
     description: "The spec skill should explore this further."
   - label: "Doesn't apply"
     description: "Not relevant to this DApp."
   ```

   For speed, group related items (e.g., identity / actions /
   aggregates) and issue one multi-select `AskUserQuestion` per group
   where the items clearly share a category.

4. **Store buckets.** Record items as three lists: `likely_private`,
   `likely_public`, `undecided`. Drop items marked "Doesn't apply".

**Never use** Compact vocabulary in the questions. Say "individual
donation amounts", not "committed donation leaves".

## Phase 4 — Interfaces

Read `references/interface-defaults.md`.

```text
AskUserQuestion(
  question: "Which interfaces should this DApp expose? (Select all that apply.)",
  header: "Interfaces",
  multiSelect: true,
  options:
    - label: "Web UI"
      description: "Browser-based interface for end users."
    - label: "CLI"
      description: "Terminal command-line tool."
    - label: "TUI"
      description: "Full-screen terminal interface."
    - label: "Headless / library"
      descripti