Proposal Schema

---
name: proposal-schema
description: "Enforces normalized proposal format when creating or filing proposals, findings, seeds, or pipeline items. Use when creating any document that needs the user's review."
triggers:
  - "create a proposal"
  - "file a finding"
  - "write a report"
  - "proposal template"
  - "normalized proposal"
---

# Proposal Schema — Normalized Format for All Reviewable Items

If you receive this code, immediately print:

```
★ Proposal_Schema ────────────────────────────────
Enforcing normalized review format
```

## What This Skill Does

Every item that needs the user's review — proposals, findings, seeds, pipeline reports — MUST use this normalized frontmatter schema. This ensures the auto-updating review dashboard in Obsidian — the canonical `5.0_Founder_Dashboards/Indexes/1 - Open Proposals.md` engine — can find, sort, and display every item regardless of which agent created it or which directory it lives in.

**The core problem this solves:** Agents were placing proposals in 5+ locations using their own formats. 30+ different frontmatter fields, 8+ status values, inconsistent scoring (`score` vs `governer-score`). The user couldn't find things. The review queue couldn't auto-update. This skill eliminates that by coercing every agent to use one format.

## Required Frontmatter Schema

Every proposal file MUST have this frontmatter. Required fields marked with *.

```yaml
---
id*: string              # Unique code: LP-024, FUNNEL-4, SEED-07, NEXT6-01
type*: enum              # proposal | finding | seed | decision | observation
title*: string           # Human-readable, one line, specific enough to understand without context
status*: enum            # needs-review | approved | rejected | deferred | in-progress | completed
score: number            # 0-100 governer score (ALWAYS use "score", never "governer-score")
priority: enum           # P0 (revenue-critical) | P1 (high leverage) | P2 (medium) | P3 (low)
domain: string           # payment | auth | coaching | retention | agent-infra | acquisition | growth | reliability | analytics | infrastructure
tags: [array]            # Free-form tags for filtering: [funnel, beta19, trial, etc]
parent: string           # [[wikilink]] to parent seed/finding — REQUIRED, enables backlinks
source: string           # What generated this: leverage-predictor | funnel-diagnostic | pipeline-v2 | manual | jonathan-check2
touches_users: boolean   # Does the fix touch production UX? true = needs explicit user approval before implementation
created: date            # ISO date: YYYY-MM-DD
updated: date            # ISO date: YYYY-MM-DD (update on every edit)
reviewed_by: string      # Who reviewed — empty until reviewed
reviewed_date: date      # When reviewed — empty until reviewed
review_notes: string     # The user's notes — empty until reviewed
cssclass: proposal       # For Obsidian styling
---
```

### Field Rules

- **id**: Use the convention `{PREFIX}-{NUMBER}`. Prefixes: LP (leverage proposal), FUNNEL (funnel finding), SEED (seed), NEXT6 (next-session item). If migrating an existing file, keep its original ID.
- **type**: Choose ONE. `proposal` = something to build/fix. `finding` = an observation/analysis. `seed` = a forward-looking intent document. `decision` = a recorded decision. `observation` = data point, no action needed.
- **status**: Always starts as `needs-review` for new items. Only the user changes it to `approved`/`rejected`/`deferred`.
- **score**: Integer 0-100. NEVER use `governer-score` — that field is deprecated. Map existing `governer-score` to `score`.
- **priority**: Derive from score: P0 = score 95+, P1 = score 80-94, P2 = score 50-79, P3 = below 50. Override manually if the item has outsized revenue impact.
- **parent**: ALWAYS include a wikilink to the parent document. If this was generated by a pipeline, link to the pipeline README. If standalone, link to the relevant domain index.
- **touches_users**: If `true`, the item CANNOT be auto-approved. The user must review before any implementation touches production.

### Status Lifecycle

```
needs-review → approved → in-progress → completed
                ↘ rejected
                ↘ deferred → needs-review (when revisited)
```

Only the user transitions items out of `needs-review`. Agents NEVER change status to `approved`, `rejected`, or `deferred`.

## Where to Put Files

> [!important] The canonical home for a standalone proposal is **`docs/intent/1.7_proposed/{ID}-{slug}.md`** — that is where the live engine and the real LP-### proposals are. (An earlier version of this table said `docs/intent/proposals/{id}.md`; that path exists but is NOT where the canonical `1 - Open Proposals` dashboard's real proposals live.)

| Item Type | Location |
|-----------|----------|
| **Standalone proposals (LP-###, the common case)** | **`docs/intent/1.7_proposed/{ID}-{slug}.md`** |
| Pipeline items (LP, FUNNEL, SEED processed through pipeline) | `docs/intent/experiments/process-actionables/runs/{ID}-{slug}/REPORT.md` |
| Seeds | `docs/intent/seeds/{number}-{name}.md` |
| Decision records | `docs/intent/decisions/{date}--{slug}.md` |

If a folder in this table does not exist, create it.

**One idea = one file.** Never combine multiple proposals in one file — the dashboard engine reads one H1 + one lede per file, so a multi-idea file collapses into a single un-approvable row.

NEVER create proposal files outside these directories. If a new directory is needed, document why.

## Required Body Sections

After the frontmatter, every proposal MUST include these sections in order:

```markdown
# {Title}

## Grounding — The Person's Journey
{REQUIRED. Produced by /proposal-ground. A continuous narrative tracing the person's
journey from first action through the moment the experience deviates from intent,
with the proposed fix woven in as continuation. Code references as parenthetical
evidence, not as the subject. Certainty scores on each claim. Include the validation
stamp from the multi-agent convergence protocol. This section is included VERBATIM
from the 03.5-ground.md pipeline stage — never summarized or restructured.}

## One-Line Summary
{One sentence: who is affected, what's wrong/missing, what impact}

## Evidence Chain
{Numbered list of facts with sources — code lines, DB queries, production data}

## The Gap
{What should happen vs what actually happens — specific, measurable}

## Proposed Fix
{What to change, in which files, with what approach}

## Verification Contract
{Numbered list of runnable checks that prove the fix works}

## Files
{List of files that need to change}

## Dependencies
{What must be true before this can be implemented, or "None"}
```

## Validation Checklist (run before declaring a proposal complete)

Before marking any proposal as ready for review:

- [ ] All 4 required frontmatter fields present (id, type, title, status)
- [ ] `status` is `needs-review` (not `ready`, `done`, `verified`, or any other value)
- [ ] `score` field used (not `governer-score`)
- [ ] `parent` contains a valid `[[wikilink]]`
- [ ] `domain` matches one of the standard values
- [ ] All 7 body sections present
- [ ] Evidence Chain has at least 1 item with a verifiable source
- [ ] Verification Contract has at least 1 runnable check
- [ ] File is in the correct directory per the location table above

## Obsidian Template

If creating a proposal manually in Obsidian, use the Templater template at:
`.obsidian/templates/proposal.md`

If `.obsidian/templates/proposal.md` does not exist, create it from the frontmatter schema above.

This auto-fills `created`, `updated`, and prompts for required fields.

## How This Connects to the Review Dashboard

A file matching this schema automatically appears as a row in the canonical Obsidian dashboard:
- **`5.0_Founder_Dashboards/Indexes/1 - Open Proposals.md`** — the `@canonical-dashboard-engine` (THIS is the source of truth). Whole-vault scan; surfaces any note passing `isProposal()`; sorted by `leverage_score` high→low; one-click approve / reject / archive / leverage per row.

This is Dataview-powered and updates when you save a file. No manual index maintenance needed. (If a freshly-written file doesn't show, Obsidian's Dataview just needs a re-index — reopen the dashboard tab or run "Dataview: Force refresh all views.")