/propose

One command → a proposal you understand the first time you read it.

/propose takes the current situation — a conversation, a finding, a flagged session, or an item sitting in a "get me a proposal" folder — and produces a single proposal that is instantly understood: grounded in what a real person actually experiences, in the canonical recognizable shape, and filed where it belongs.

It is a thin orchestration of three existing canonical skills. Do NOT reinvent what they do — invoke them in order.

What "instantly understood" means (the bar)

The person reads the proposal once and knows: what's broken for a real person, why it matters, and what fixing it does — with zero code jargon, zero decoding, zero follow-up questions. If a smart person who doesn't code would furrow their brow at any sentence, it fails the bar.

The chain — run these three in order

1. /proposal-ground — make the content human-legible

Invoke /proposal-ground on the situation. This translates code findings into a continuous narrative of what a person experiences — where their experience deviates from intent, and what fixing it would feel like. This is the half of "instantly understood" that is about meaning: jargon becomes a lived UX story. Capture verbatim quotes from the source (conversation / session / finding) — never substitute your own summary for the person's actual words.

2. /proposal-schema — enforce the recognizable shape

Invoke /proposal-schema to normalize the grounded narrative into the canonical proposal format. This is the half of "instantly understood" that is about shape: every proposal looks the same, so the person recognizes it on sight. The human-legible "What a real person experiences" section leads; all technical detail goes below a ## Technical Detail header. Include certainty dots (🔴<60 🟡60-69 🔵70-79 🟣80-89 🟢90+) and a "Where this came from" provenance section.

3. File it

Default — the local proposals store: write one .md file per proposal to the folder printed by alignment-harness records proposals, named {ID}-{slug}.md, carrying frontmatter: id, type: proposal, status: needs-review, tags: [proposal], leverage_score: <1-100>, score, priority, created. This folder is the review surface by default — tell the person its exact path so they can open it directly; there is no separate dashboard to build for this to work.

If the person has connected an Obsidian vault (or another note viewer) for this project (see /alignment-harness:harness-setup), file there instead, in whatever proposals location their vault uses, and open it for them. If they haven't, the plain local folder is not a fallback to apologize for — it's the default, and it works the same way.

ONE IDEA = ONE FILE. Never put multiple proposals in one file — a reviewer (human or a dashboard, if one exists) reads one H1 + one lede per file, so a multi-idea file collapses into a single un-approvable row.

(When running inside a triage-folder context, "file it" may instead mean: write the proposal to the top of the document being reviewed — follow the folder's own instructions for where the output lands, if one exists.)

Output placement

• Default: the local proposals folder (alignment-harness records proposals), one file per idea.
• If connected: the person's own Obsidian vault (or equivalent), same one-file-per-idea rule.
• Inside a triage folder (e.g. a "get me a proposal" folder): paste the proposal at the TOP of the document being reviewed, with a datestamped ## UPDATE — <date time> header above it, then leave it for the person's greenlight. Follow that folder's own instructions if it has any.

Presenting the proposal back to the person — FULL CLICKABLE PATHS ONLY

A relative path is a FAILURE. When you surface a proposal to the person — in chat, in a status update, anywhere — the link you give MUST be a full path that is clickable and actually opens the surface. A repo-relative path like docs/proposed/LP-042-slug.md is a failure: the person cannot click it to open the thing. The whole point of presenting a proposal is that they open it in one click; a path they have to hunt for defeats the proposal.

For EVERY proposal you present, give:

1. The absolute filesystem path — rooted at the real filesystem root, never repo-relative: the full path alignment-harness records proposals printed, plus the filename.
2. If filed in a connected vault or viewer, also give that surface's own opener (for example an Obsidian URI), so one click opens the reviewable surface itself.

Never present a proposal with only a repo-relative path. If you catch yourself writing a bare relative path as the person-facing link, stop and replace it with the full path above.

Anti-Hallucination Guardrail (MANDATORY — include this discipline in every proposal)

Avoid hallucination by detecting anything you are asserting, with extra emphasis on anything load-bearing. Assumptions build upon assumptions, and that compounds agent hallucination and misalignment. Rather than asserting things as fact, lean toward stating what the intent is, or your understanding, or what seems to be true — and then place a % score inline like this ( 85% ) indicating your level of certainty.

This way, when other agents read your proposal, they do not assume your assumptions are facts.

Apply this throughout the proposal: every load-bearing claim (anything a downstream agent would build a fix on) carries an inline ( % ). A claim with no number reads as fact — so if it isn't a verified fact, give it a number.

UX-Impact Completion Audit (MANDATORY — run before declaring any proposal complete)

When you believe your proposal is complete, engage an audit to determine the following.

Is there any place where you are talking about code which would touch a user experience, but not naming that expected downstream impact? That would be a critical failure of any proposal. Rather than create a separate section, weave in and synthesize the following key perspectives into the moment where you are speaking about a user facing impact.

For EACH set of conditions which would modify a user experience:

When x then y should z — with x being all the actual constraints | conditions, y being the governing system ( in charge of this ) and z being the target or expected user experience impact specifically.

For example, if you are incorrectly commenting only in specific code language like this:

It removes a dangerous fake-user injection ({_id:'placeholder-id', currentPlan:1}) and adds the retry the person explicitly asked about. It is NOT coupled to the fail-closed flip and should ship.

You would rewrite this to convert this to the semantic meaning, while citing the programming related variables in it. For example:

When a paying user signs in, it removes a risk surface which could cause a user to not be recognized for whatever their payment status standing actually is by the access-resolving logic, increasing the chances that we catch and consume that data so that we can give them the privileges they deserve. Free users would be unaffected.

Also if you write or edit a proposal in a connected note viewer, make sure you open it upon completion. If there is none, print its file path instead.

This skill improves through use

Treat this skill's own output as something to calibrate, the same way /how-to-talk-like-the-founder calibrates to a person's writing: when the person approves a proposal it produced, that shape has earned its keep. When they reject one or correct its shape, update this skill file with what you learned before running it again — don't just fix the one proposal and move on. There's no external approval gate required to call this "done"; the loop is: propose, get corrected (or not), improve the skill, repeat.