원클릭으로 Manus에서 모든 스킬 실행

propose-rfc

스타5

포크0

업데이트2026년 4월 21일 04:30

Draft a community RFC (Request for Comments) for a non-trivial change to the Summoned AI Gateway — anything that touches the public contract, core architecture, or cross-cutting concerns. Trigger when the user says "I want to propose X", "let's RFC this", "design doc for Y", or when a change obviously needs broader discussion (breaking header change, new middleware ordering, new top-level config field).

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

summoned-tech

summoned-tech/summoned-ai-gateway

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Propose RFC

Open-source projects move faster when design decisions are written down before code. This skill generates a community-facing RFC so contributors can weigh in before implementation.

When is an RFC needed?

Required when the change:

Adds/removes/renames an X-Summoned-* response header
Adds/removes/changes a top-level config field
Changes the provider/model slug format
Adds a new route under /v1/, /admin/, or /ws/
Alters middleware ordering
Adds a new runtime dependency
Breaks backward compatibility with either SDK

Not required for: new providers (just use add-provider), pricing updates, bug fixes, internal refactors.

Step 0: Gather info

Title — short, imperative (e.g. "Unify cache backends behind a registry")
Problem — what is broken or missing today?
Proposal — one paragraph
Alternatives considered
Affected surfaces — which files/contracts?
Breaking changes — yes/no + migration path

Step 1: Find the next RFC number

ls rfcs/ 2>/dev/null | grep -E '^[0-9]{4}' | sort | tail -1

If rfcs/ doesn't exist, create it with RFC-0001. Otherwise next zero-padded 4-digit number.

Step 2: Draft the RFC

File: rfcs/NNNN-<kebab-title>.md

# RFC <NNNN>: <Title>

- **Status:** Draft
- **Author:** <you>
- **Created:** YYYY-MM-DD
- **Target release:** <version or "next minor">

## Summary

One paragraph: what + why.

## Motivation

What is broken today? What can users NOT do? Cite issue numbers
(`#42`) and file paths when referencing current behavior.

## Detailed design

Describe the change at implementation level. Include:
- Before/after code or config snippets
- New/changed contracts (request shape, response header, env var)
- Interaction with existing features (cache, fallback, guardrails, rate-limit)

## SDK impact

- TypeScript SDK: <changes>
- Python SDK:     <changes>
- Both follow via `sdk-syncer` agent after implementation lands.

## Migration

How do existing users adopt the new behavior? Is it opt-in via config,
auto-upgraded, or a breaking change with a deprecation window?

## Alternatives considered

At least two:
- Option A: <describe> — rejected because…
- Option B: <describe> — rejected because…

## Open questions

- <question>
- <question>

## Unresolved security/privacy concerns

…

Step 3: Wire it in

Add a row to rfcs/README.md (create the index file if it doesn't exist) with | NNNN | Title | Status | Author |.
Reference the RFC in any tracking issue (gh issue comment <n> -b ...).

Step 4: Announce

Do NOT post to GitHub/Slack/Twitter yourself. Produce a ready-to-paste announcement snippet (one paragraph + a link) and hand it to the user.

Rules

RFCs are prose, not decisions. Don't write "we will do X" — write "this proposes X".
No code changes in the same commit as the RFC. Keep separate.
Keep under 1000 words unless the change truly warrants more.
Respect CLAUDE.md design principles — if the RFC violates one (e.g. adds a static model catalog), call that out explicitly in the Alternatives section.

이 저장소의 다른 Skills

같은 저장소

add-cache-backend

summoned-tech/summoned-ai-gateway

Add a new cache backend implementation to the Summoned AI Gateway. Trigger whenever the user wants to support a new cache store — e.g. "add Memcached support", "cache to Cloudflare KV", "use DynamoDB as cache", "swap cache for Upstash", "add in-memory fallback". Does NOT trigger for tuning TTL or existing Redis cache (that's a config change).

2026-04-215

add-guardrail

summoned-tech/summoned-ai-gateway

Add a new guardrail type (input or output validation rule) to the Summoned AI Gateway. Trigger when the user wants a new safety check, content filter, PII detector, prompt-injection detector, toxicity filter, or any per-request validation — e.g. "add a toxicity guardrail", "block prompts with X", "filter output for Y", "add a prompt-injection check".

2026-04-215

add-middleware

summoned-tech/summoned-ai-gateway

Add a new Hono middleware to the Summoned AI Gateway. Trigger whenever the user wants to intercept every request — e.g. "add IP allowlist middleware", "add a request logger", "add per-tenant quota middleware", "add a GeoIP-based routing middleware", "add CORS tweaks".

2026-04-215

add-prompt

summoned-tech/summoned-ai-gateway

Scaffold a new versioned prompt template for the Summoned AI Gateway and upload it to a running gateway's /admin/prompts API. Trigger whenever the user wants to add/create/store a prompt, save a system prompt, version a template, or "make this prompt reusable" — e.g. "add a customer-support prompt", "save this as a prompt template", "version my prompt for Claude".

2026-04-215

add-router

summoned-tech/summoned-ai-gateway

Add a new HTTP route or router to the Summoned AI Gateway (Hono). Trigger whenever the user wants a new endpoint, REST resource, admin API, webhook receiver, or WebSocket handler — e.g. "add a /v1/rerank endpoint", "expose an endpoint for X", "we need an API for Y", "add a webhook for Z".

2026-04-215

bench-provider

summoned-tech/summoned-ai-gateway

Benchmark one or more providers through the gateway — latency, tokens/second, cost per completion, and streaming first-byte-time. Trigger when the user says "benchmark X", "compare providers", "is provider Y fast enough?", "measure TTFT for …", or wants numbers for a blog/docs post.

2026-04-215

name

propose-rfc

description

Propose RFC

Open-source projects move faster when design decisions are written down before code. This skill generates a community-facing RFC so contributors can weigh in before implementation.

When is an RFC needed?

Required when the change:

Adds/removes/renames an X-Summoned-* response header
Adds/removes/changes a top-level config field
Changes the provider/model slug format
Adds a new route under /v1/, /admin/, or /ws/
Alters middleware ordering
Adds a new runtime dependency
Breaks backward compatibility with either SDK

Not required for: new providers (just use add-provider), pricing updates, bug fixes, internal refactors.

Step 0: Gather info

Title — short, imperative (e.g. "Unify cache backends behind a registry")
Problem — what is broken or missing today?
Proposal — one paragraph
Alternatives considered
Affected surfaces — which files/contracts?
Breaking changes — yes/no + migration path

Step 1: Find the next RFC number

ls rfcs/ 2>/dev/null | grep -E '^[0-9]{4}' | sort | tail -1

If rfcs/ doesn't exist, create it with RFC-0001. Otherwise next zero-padded 4-digit number.

Step 2: Draft the RFC

File: rfcs/NNNN-<kebab-title>.md

# RFC <NNNN>: <Title>

- **Status:** Draft
- **Author:** <you>
- **Created:** YYYY-MM-DD
- **Target release:** <version or "next minor">

## Summary

One paragraph: what + why.

## Motivation

What is broken today? What can users NOT do? Cite issue numbers
(`#42`) and file paths when referencing current behavior.

## Detailed design

Describe the change at implementation level. Include:
- Before/after code or config snippets
- New/changed contracts (request shape, response header, env var)
- Interaction with existing features (cache, fallback, guardrails, rate-limit)

## SDK impact

- TypeScript SDK: <changes>
- Python SDK:     <changes>
- Both follow via `sdk-syncer` agent after implementation lands.

## Migration

How do existing users adopt the new behavior? Is it opt-in via config,
auto-upgraded, or a breaking change with a deprecation window?

## Alternatives considered

At least two:
- Option A: <describe> — rejected because…
- Option B: <describe> — rejected because…

## Open questions

- <question>
- <question>

## Unresolved security/privacy concerns

…

Step 3: Wire it in

Add a row to rfcs/README.md (create the index file if it doesn't exist) with | NNNN | Title | Status | Author |.
Reference the RFC in any tracking issue (gh issue comment <n> -b ...).

Step 4: Announce

Do NOT post to GitHub/Slack/Twitter yourself. Produce a ready-to-paste announcement snippet (one paragraph + a link) and hand it to the user.

Rules

RFCs are prose, not decisions. Don't write "we will do X" — write "this proposes X".
No code changes in the same commit as the RFC. Keep separate.
Keep under 1000 words unless the change truly warrants more.
Respect CLAUDE.md design principles — if the RFC violates one (e.g. adds a static model catalog), call that out explicitly in the Alternatives section.