CtrlK
BlogDocsLog inGet started
Tessl Logo

frame-a-proposal

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).

67

Quality

82%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

73%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-sequenced, gated authoring workflow with strong validation checkpoints and concrete executable MCP calls and templates. Its main weakness is moderate repetition of the same discipline warnings across multiple sections, which lightly inflates the token budget without adding new guidance.

Suggestions

Consolidate the repeated 'don't skip the Step 1 gate' and 'don't pad Alternatives / leave Drawbacks empty' warnings — state each once (e.g., in Non-goals) and reference it rather than restating in the intro, Step 1, Step 5, and Step 6.

Fully parameterize the Step 8 validation calls (`links({ kind: "backlinks", ... })` and `audit({ path: ... })`) so they are copy-paste ready rather than leaving args implicit.

Consider extracting the reusable framing/alternatives/recap output templates into a single reference block or a `references/templates.md` file to reduce body length and enable one-level-deep progressive disclosure.

DimensionReasoningScore

Conciseness

Mostly efficient and assumes Claude's intelligence (no basic-concept padding), but several sections repeat the same discipline points verbatim across Step 1, Non-goals, and the opening — e.g., the 'skipped gate' / 'strawmen / empty Drawbacks' warnings appear three times — so it could be tightened.

3 / 5

Actionability

Gives concrete, copy-ready commands and templates — `exec("ls -A proposals/")`, the `write({ document: { path: ..., template: "proposal" } })` call, the exact framing/alternatives/recap blocks — with only minor gaps (the audit/links MCP calls are named but not fully parameterized).

4 / 5

Workflow Clarity

A hard-gated 0–9 sequence with an explicit STOP gate at Step 1, per-step validation in Step 8 (audit returns clean, all five H2 sections non-empty, status still draft), and a recap checklist with explicit feedback on rejection — matching the level-5 anchor of explicit validation steps and error-recovery loops for a non-destructive authoring workflow.

5 / 5

Progressive Disclosure

Well-organized into clear H2 sections with one-level-deep references to sibling skills (record-a-decision, write-a-spec) and to external decisions/specs via plain relative links; there are no local bundle files to reference, so structure is appropriate but it cannot hit the level-5 'reference files' pattern because the skill is intentionally self-contained.

4 / 5

Total

16

/

20

Passed

Description

91%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is strong across all dimensions: it states the concrete proposal-crafting actions, gives comprehensive natural trigger phrases with synonyms, and explicitly delimits when to use vs. not use the skill with named sibling skills. It is long but every clause earns its place as trigger or boundary guidance rather than fluff.

DimensionReasoningScore

Specificity

Lists several concrete actions — 'problem before solution, named beneficiary and observable change, real alternatives, honest drawbacks, and a live open-questions backlog' — naming the domain and the proposal sections it produces, with only minor coverage gaps (e.g., the sequence/linking steps are implied, not enumerated).

4 / 5

Completeness

Explicitly answers both 'what' (frame a design proposal under proposals/ with problem-first structure and the listed sections) and 'when' via a concrete 'Read when...' clause plus a 'Do NOT read to...' exclusion list, satisfying the level-5 anchor for both what and when with concrete trigger phrases.

5 / 5

Trigger Term Quality

Comprehensive natural triggers with synonyms and variants — 'frame a proposal', 'write an RFC', 'propose a design', 'pitch a change', 'draft a PRD-style design doc', 'open a design proposal for review' — plus explicit anti-triggers, matching the level-5 anchor's coverage including synonyms.

5 / 5

Distinctiveness Conflict Risk

Clear niche (RFC-shape proposals under proposals/) with distinct triggers and an explicit boundary list naming the sibling skills it is not (record-a-decision, write-a-spec, write-a-postmortem, review-a-design), giving minimal conflict risk as the level-5 anchor describes.

5 / 5

Total

19

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

relative_links

Relative link issues: 2 missing

Warning

Total

14

/

16

Passed

Repository
inkeep/open-knowledge
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.