How to Submit and Track Proposals

To file a NEW proposal, use /propose (chains /proposal-ground → /proposal-schema → writes the proposal as a note in the person's own proposals location — an Obsidian vault if they have one, or a plain folder under alignment-harness records proposals if not). Don't build a database-backed submission workflow — there is no such database by default, and inventing one to POST to would just fail silently on a fresh install.

This skill is for the two things that survive once filing itself belongs to /propose:

1. Looking up proposals that already exist — searching, checking status, finding what's still pending review.
2. The judgment calls about whether something is even worth proposing — the priority-scoring formula and the propose/don't-propose distinction below, which apply regardless of where a proposal ends up living.

Searching and tracking

Proposals live wherever /propose wrote them — the person's vault, or a plain folder under alignment-harness records proposals. To look one up:

• Find proposals matching a keyword: search the proposals folder (grep/read the files) for the term, same as searching any other set of markdown/JSON records.
• Check status: each proposal's frontmatter carries a status field (needs-review, approved, rejected, deferred, in-progress, implemented). Read it directly from the file.
• List everything still needing review: filter the folder for status: needs-review.
• Respond to feedback: if the person added a note to a proposal, append your reply to the same file rather than posting to an API — there is no API by default.
• Mark done: once implemented, update the file's own status field and reference the commit. Only the person changes a proposal's status from needs-review/approved to something else, unless they've told you otherwise — this stays a manual step by default.

If the store is empty, say so plainly — "no proposals filed yet" — rather than erroring or guessing.

If you've built a real database-backed proposals API of your own, the same search/status/reply/claim/implement operations apply — just as HTTP calls with a key instead of file reads. That's optional, advanced infrastructure this skill doesn't require.

When to Use This

• You want to check the status of proposals already filed
• The person added feedback to a proposal and you need to respond
• You're ready to implement an approved proposal and want to claim/update it
• You're deciding whether something is even worth writing up as a proposal (see below)

Priority Scoring (0-100)

Use this formula when deciding whether — and how urgently — to propose something:

Factor	Weight	Questions
User Impact	40%	How many users? How badly affected?
Business Value	30%	Revenue, retention, conversion impact?
Effort Efficiency	20%	Impact per hour of work?
Risk Reduction	10%	Prevents future outages/bugs?

Threshold: Only submit proposals scoring ≥60. Below that, skip.

Anti-Patterns

DON'T propose:

• Pure refactoring without user impact
• "Nice to have" improvements
• Tech debt that doesn't affect users
• Dependency updates without business justification

DO propose:

• Changes that unblock user value
• Fixes for known user pain points
• Features that increase retention/conversion
• Performance wins users will notice

Integration with Other Skills

After implementing an approved proposal:

1. If you have a UX-assignment or verification-generation skill set up, use it to create verification assignments for the change.
2. Link the proposal's id in that verification record.
3. If you have /playwright-validator or an equivalent, use it to capture screenshot evidence.

Opening a filed proposal for the person

If the proposal was written as a file in a configured vault (for example, Obsidian) and you want the person to see it immediately after filing, open it the way /propose does:

open "obsidian://open?vault=<their vault name>&file=<path without extension>&newtab=true"

Only run this if the person actually has that app and vault configured — otherwise just tell them the file path.