Run any Skill in Manus with one click

rfc-creator

Stars2

Forks0

UpdatedApril 12, 2026 at 14:49

Create or update Requests for Comment for this repository. Use when the user wants a new feature, subsystem, module, game mechanic, API change, or vendor contribution proposal drafted in `proposals/rfc/` before implementation.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

akollegger

akollegger/aie-matrix

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	rfc-creator
description	Create or update Requests for Comment for this repository. Use when the user wants a new feature, subsystem, module, game mechanic, API change, or vendor contribution proposal drafted in `proposals/rfc/` before implementation.

RFC Creator

Overview

Use this skill to draft repository-specific RFCs that follow proposals/rfc/README.md exactly. RFCs are for proposals before implementation, not for settled architectural decisions.

Workflow

Read proposals/rfc/README.md and any relevant context from README.md, docs/project-overview.md, and docs/architecture.md.
Confirm the change belongs in an RFC:
- new subsystem, module, or feature
- significant behavior or API change
- vendor contribution introducing new interfaces or behavior
Determine the RFC filename: NNNN-short-title in lowercase kebab-case (e.g. 0001-minimal-poc).
Create a branch named proposal/NNNN-short-title matching the RFC filename exactly before writing any files. Do not proceed without switching to this branch.
Create or update proposals/rfc/NNNN-short-title.md on that branch.
Use this structure exactly:

# RFC-NNNN: Title

**Status:** draft | under review | accepted | rejected
**Date:** YYYY-MM-DD
**Authors:** @handle
**Related:** links to issues, ADRs, or other RFCs

## Summary

## Motivation

## Design

## Open Questions

## Alternatives

Writing Rules

Keep ## Summary to one clear paragraph.
Put interfaces, flows, and pseudocode in ## Design when useful.
Use ## Open Questions to surface unresolved choices instead of hiding them.
Compare realistic alternatives, not strawmen.
Keep the proposal consistent with the current architecture unless the RFC explicitly challenges it.

Output

When creating a new RFC:

Confirm the active branch is proposal/NNNN-short-title before writing files.
Write the RFC file under proposals/rfc/.
Update the index table in proposals/rfc/README.md.
Call out missing inputs or unresolved dependencies.
Remind the author to run /rfc-review before opening the proposal for comment.

More from this repository

same repository

sre

akollegger/aie-matrix

Structured SRE debugging methodology for aie-matrix production incidents. Use this skill whenever the user is investigating anything that is slow, broken, or behaving unexpectedly in production or staging — including slow deploys, failing health probes, high latency, unexpected restarts, memory pressure, or anything described as "something is wrong" or "why is X taking so long". Also use when writing a post-mortem or runbook entry. The skill enforces a disciplined observe-hypothesize-test loop rather than applying fixes based on intuition.

2026-06-182

speckit-verify

akollegger/aie-matrix

Gate check before opening a PR: clean build, all tests (unit + integration), spec coverage, doc impact, and a go/no-go verdict. Run after /speckit.implement and before opening a pull request.

2026-06-022

aie-matrix-effect

akollegger/aie-matrix

Effect-ts coding standard for all server-side packages in aie-matrix (server/agent-host/ and server/*). Use when writing or reviewing services, route handlers, error types, logging, configuration, or background fibers in any of these packages.

2026-05-212

speckit-specify

akollegger/aie-matrix

Create or update the feature specification from a natural language feature description.

2026-05-212

gram-lint

akollegger/aie-matrix

Validate gram notation snippets or files using the gram-lint CLI. Use whenever you need to check whether a gram expression or .map.gram file is syntactically valid — especially when designing format changes, reviewing example files, or verifying that proposed snippets are parseable by the WASM grammar.

2026-05-022

gram-lint

akollegger/aie-matrix

Validates Gram notation files and inline snippets using the gram-lint CLI (parse errors, optional s-expression tree). Use when editing or generating .gram files, debugging Gram.parse failures, validating converter output, or when the user mentions gram-lint, Gram syntax, or linting gram documents.

2026-04-262

name	rfc-creator
description	Create or update Requests for Comment for this repository. Use when the user wants a new feature, subsystem, module, game mechanic, API change, or vendor contribution proposal drafted in `proposals/rfc/` before implementation.

RFC Creator

Overview

Use this skill to draft repository-specific RFCs that follow proposals/rfc/README.md exactly. RFCs are for proposals before implementation, not for settled architectural decisions.

Workflow

Read proposals/rfc/README.md and any relevant context from README.md, docs/project-overview.md, and docs/architecture.md.
Confirm the change belongs in an RFC:
- new subsystem, module, or feature
- significant behavior or API change
- vendor contribution introducing new interfaces or behavior
Determine the RFC filename: NNNN-short-title in lowercase kebab-case (e.g. 0001-minimal-poc).
Create a branch named proposal/NNNN-short-title matching the RFC filename exactly before writing any files. Do not proceed without switching to this branch.
Create or update proposals/rfc/NNNN-short-title.md on that branch.
Use this structure exactly:

# RFC-NNNN: Title

**Status:** draft | under review | accepted | rejected
**Date:** YYYY-MM-DD
**Authors:** @handle
**Related:** links to issues, ADRs, or other RFCs

## Summary

## Motivation

## Design

## Open Questions

## Alternatives

Writing Rules

Keep ## Summary to one clear paragraph.
Put interfaces, flows, and pseudocode in ## Design when useful.
Use ## Open Questions to surface unresolved choices instead of hiding them.
Compare realistic alternatives, not strawmen.
Keep the proposal consistent with the current architecture unless the RFC explicitly challenges it.

Output

When creating a new RFC:

Confirm the active branch is proposal/NNNN-short-title before writing files.
Write the RFC file under proposals/rfc/.
Update the index table in proposals/rfc/README.md.
Call out missing inputs or unresolved dependencies.
Remind the author to run /rfc-review before opening the proposal for comment.