# Frame A Proposal

Frame a new design proposal (RFC-shape) under proposals/, problem before solution...

- Repository: https://github.com/inkeep/open-knowledge (4756 stars)
- Category: Design
- License: GPL-3.0
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add inkeep/open-knowledge --skill frame-a-proposal -g -a claude-code -y`
Codex: `npx skills add inkeep/open-knowledge --skill frame-a-proposal -g -a codex -y`
Cursor: `npx skills add inkeep/open-knowledge --skill frame-a-proposal -g -a cursor -y`
Gemini CLI: `npx skills add inkeep/open-knowledge --skill frame-a-proposal -g -a gemini-cli -y`

## Description

Frame a new design proposal (RFC-shape) under proposals/, problem before solution, named beneficiary and observable change, real alternatives, honest drawbacks, and a live open-questions backlog. Read when asked to frame a proposal, write an RFC, propose a design, pitch a change, draft a PRD-style design doc, or open a design proposal for review. Do NOT read to record a decision after it is accepted (use record-a-decision), to write an implementation spec (use write-a-spec), to write a postmortem (use write-a-postmortem), or to review or critique an existing design (use review-a-design).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Frame a proposal, turn a problem into a reviewable RFC

The platform `/open-knowledge` skill still governs every markdown operation here (reads via `exec`/`search`, writes via `write`/`edit`, links as plain relative markdown, never native Read/Edit/Grep/`cat` on in-scope files). This skill layers proposal-authoring craft on top: it decides *what a good proposal contains and in what order you earn each section*.

A proposal in `proposals/` is a design argument, not a decision and not a plan. It exists to force a **choice** among options and to give reviewers enough to disagree with. Filename is `0001-feature-name.md`, a zero-padded 4-digit sequence plus a kebab title. Status flows `draft → fcp → accepted/rejected` (fcp = final comment period). Acceptance graduates the proposal to a record in `decisions/`, that is a *separate*, human act and a *separate* skill.

The failure this skill exists to prevent: an agent jumping to `## Design` before anyone agrees what the problem is, padding `## Alternatives` with strawmen, and leaving `## Drawbacks` empty. Each step below has a gate that blocks that.

---

## Mandatory execution order

**Hard gates, do NOT skip ahead.** If you are about to draft `## Design` and you have not passed the Step 1 framing gate, STOP, you skipped a gate. The whole point of a proposal is that the problem is agreed before the solution is written.

The rest: https://github.com/inkeep/open-knowledge/blob/HEAD/packages/server/assets/skills/packs/software-lifecycle/frame-a-proposal/SKILL.md