Creates structured Request for Comments (RFC) documents for proposing and deciding on significant changes. Use when the user says "write an RFC", "create a proposal", "I need to propose a change", "draft an RFC", "document a decision", or needs stakeholder alignment before making a major technical or process decision. Do NOT use for TDDs/implementation docs (use technical-design-doc-creator instead), README files, or general documentation.
79
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./packages/skills-catalog/skills/(creation)/create-rfc/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that hits all the marks. It provides specific actions, comprehensive trigger terms users would naturally use, explicit 'Use when' and 'Do NOT use' clauses, and clear differentiation from related skills. The cross-reference to an alternative skill (technical-design-doc-creator) is a particularly strong touch for disambiguation.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description specifies a concrete action ('Creates structured Request for Comments (RFC) documents') and clarifies the purpose ('proposing and deciding on significant changes'). It also explicitly distinguishes what it does NOT do, adding further specificity. | 3 / 3 |
Completeness | Clearly answers both 'what' (creates structured RFC documents for proposing significant changes) and 'when' (explicit 'Use when...' clause with multiple trigger phrases). Also includes explicit 'Do NOT use' guidance, which further strengthens completeness. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'write an RFC', 'create a proposal', 'propose a change', 'draft an RFC', 'document a decision', 'stakeholder alignment', 'major technical or process decision'. These are phrases users would naturally say. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with clear niche (RFC documents). The explicit exclusion of TDDs, README files, and general documentation, along with a cross-reference to 'technical-design-doc-creator', makes it very unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
47%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a well-structured workflow with clear sequencing and validation steps, making it functionally sound for guiding RFC creation. However, it is significantly over-verbose—explaining concepts Claude already understands, repeating key points multiple times, and including large blocks of content (anti-patterns, example prompts, RFC vs TDD tables) that add marginal value relative to their token cost. The core templates being in an external file is appropriate, but the main file should be much leaner.
Suggestions
Cut the 'When to Use This Skill' section entirely—this belongs in frontmatter/description, not in the body that consumes context window tokens.
Remove or drastically reduce the anti-patterns section; condense to a 3-line bullet list (e.g., '- Don't present biased options; - Always include do-nothing; - Define criteria before options'). Claude understands these concepts from brief cues.
Remove the example prompts section entirely—trigger phrases belong in the skill description/metadata, not in the instructional body.
Consolidate the RFC vs TDD table, Important Notes, and Language Adaptation sections into a single brief 'Key Constraints' section of ~5 bullet points.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~250+ lines. It explains concepts Claude already knows (what an RFC is, RFC vs TDD distinctions at length), includes extensive anti-pattern examples that are general knowledge, lists example prompts in three languages that add no instructional value, and repeats guidance across multiple sections (e.g., 'do nothing' option mentioned 3 times, language adaptation mentioned multiple times). | 1 / 3 |
Actionability | The skill provides a structured workflow with specific steps and a quality checklist, plus concrete JSON for the AskQuestion tool. However, the actual RFC section templates are deferred to an external file (references/section-templates.md) rather than being inline, meaning the core executable content—the actual templates Claude would use to generate output—is missing from this file. The anti-pattern examples are helpful but the skill lacks a complete, copy-paste-ready RFC example. | 2 / 3 |
Workflow Clarity | The 5-step interactive workflow is clearly sequenced (gather context → validate mandatory fields → detect type → generate → offer next steps) with explicit validation checkpoints (Step 2 mandates asking for missing fields before generation, the quality checklist serves as a pre-finalization gate). The workflow handles the iterative nature of RFC creation well. | 3 / 3 |
Progressive Disclosure | The skill correctly references an external file for section templates (references/section-templates.md), which is good progressive disclosure. However, the main file itself is a monolithic wall of text with too much inline content that could be split out (anti-patterns, example prompts, RFC vs TDD comparison). The document structure section and section templates section feel redundant given the external reference. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
81e7e0d
Table of Contents
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.