Results for “rfc”

Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs. NOT for service-worker or browser-only caching, Redis/memcached application caching, or edge-function compute.

The English summary is being prepared. Showing the original description.

Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs. NOT for GraphQL schema evolution, gRPC/Protobuf wire compatibility, database schema migrations, or library/SDK semver.

The English summary is being prepared. Showing the original description.

RFCドリブンのマルチエージェントDAG実行パターン。品質ゲート、マージキュー、ワークユニットオーケストレーションを含む。

The English summary is being prepared. Showing the original description.

Write and maintain Architecture Decision Records (ADRs), documents explaining important technical choices. Capture the context, options, decision, and consequences, then organize records and track their status so teams can revisit the reasoning.

• Record the reasons for choosing a framework or database
• Document design options and their trade-offs
• Explain past technical decisions to new team members

Organize SGLang GPU operations when adding or moving code. It guides API placement, operation registration, test organization, and migration checks to preserve existing behavior, references, and continuous integration coverage.

• Choose where to place a new GPU operation
• Split or move existing operation files
• Review API registration and test placement

Monitor public Certificate Transparency logs, which record TLS certificates, to spot unexpected issuance and discover subdomains. Use crt.sh data to maintain a certificate inventory, check domain findings against DNS, and configure alerts for suspicious activity.

• Monitoring owned domains for unexpected certificate issuance
• Discovering subdomains and checking their DNS records
• Investigating certificates for look-alike domains

Turn agreed requirements or design documents into actionable development tasks grounded in existing code. Define observable acceptance criteria, scope, affected behavior, and unresolved decisions so builders can understand what to deliver and verify.

• Turning a requirements document into a task
• Checking a design against existing code
• Identifying missing behavior decisions

Create a technical design document before implementation by answering questions about the problem, scope, architecture, risks, and delivery plan. The skill adjusts sections to project size and covers security, testing, monitoring, and recovery where relevant.

• Documenting the design of a new feature
• Planning an external service integration
• Preparing a system migration proposal

Plan substantial DeepChat changes with a written design proposal and a clear implementation path. Record decisions, track progress, review the completed change, and select focused validation for features, complex bugs, or architecture updates.

• Planning a substantial new feature
• Recording the diagnosis and fix for a complex bug
• Documenting architecture changes or migrations

Co-write proposals, technical specifications, and decision documents through context gathering, section-by-section drafting, and revision. A fresh AI reader then tests the document to reveal unclear explanations, missing context, and contradictions before it is shared.

• Drafting a proposal through discussion
• Organizing the structure of a technical specification
• Writing a document that explains a decision

Co-write proposals, technical specifications, and decision documents through context gathering, section-by-section drafting, and revision. A fresh AI reader then tests the document to reveal unclear explanations, missing context, and contradictions before it is shared.

• Drafting a proposal through discussion
• Organizing the structure of a technical specification
• Writing a document that explains a decision

Explore a codebase to find tightly coupled or fragmented modules, then compare interface designs that hide complexity behind simpler entry points. Produces a GitHub issue proposing a refactor, including dependency handling, testing impact, and design trade-offs.

• Finding architectural refactoring opportunities
• Consolidating tightly coupled modules
• Comparing interfaces for easier boundary testing

Doctrine for drafting and keeping working-group docs under `docs/wg/**` — RFC/RFD specs and findings/research/glossary. A WG doc is a language-agnostic, code-agnostic study of a domain: it argues *why* and defines *what*, never *how in our code*. Use when writing or editing anything under `docs/wg/`, an RFC/RFD, a spec, a design note, a glossary, or research findings — including "write up the design", "document the spec", or "capture what we learned". Not for plans/TODOs (untracked `*.plan.md`), user docs, or SDK API refs — use `docs` to route those.

The English summary is being prepared. Showing the original description.

Record a decision, document existing code, or file a supplied research material, in free text; no first word is a mode. Use for 'we decided', 'record this decision', 'document why we chose X', 'make it our standard', 'draft an RFC', 'should we switch to Y' proposals, 'resolve the RFC', 'we accepted the proposal', 'document the auth module', 'capture how the payment system works', reference material, how-to instructions, a repeated agent procedure, a user flow with examples over an existing spec, or a finished report or one external material already in hand. Name any document type inside the subject — journey, prd, idea, or cpat included — to get exactly that type. Planning a feature, an investigation not yet done, or an intended user journey the request asks to plan ('plan the onboarding journey') → /archcore:plan. Checking docs against code or docs health → /archcore:review.

The English summary is being prepared. Showing the original description.

Use when you need to design, review, or improve REST APIs with Quarkus REST (Jakarta REST) — including resource classes, HTTP methods, status codes, request/response DTOs, Bean Validation, exception mappers, optional runtime OpenAPI exposure (SmallRye), contract-first generation from OpenAPI, content negotiation, pagination, sorting and filtering, API versioning, idempotency (Idempotency-Key), optimistic concurrency (ETag / If-Match), HTTP caching (Cache-Control), API deprecation (Sunset / Deprecation headers), RFC 7807 Problem Details, ISO-8601 for time in contracts, and security-aware boundaries. This should trigger for requests such as Review or improve JAX-RS resources in a Quarkus project; Design HTTP APIs with validation and error handling on Quarkus; Add API versioning, idempotency, ETag concurrency, or deprecation headers; Implement pagination, sorting, or RFC 7807 Problem Details error responses; Improve Quarkus REST resources and exception mappers. Part of Plinth Toolkit

The English summary is being prepared. Showing the original description.

Use when implementing exception mapping or RFC 9457 error responses in Spring Boot 3. Preserve an existing legacy error contract unless migration is requested.

The English summary is being prepared. Showing the original description.

Use when generating REST controllers, DTOs, success response contracts, pagination, HTTP status mapping, or API versioning. For RFC 9457 exception and error response formatting, use problem-details-rfc9457 unless the project explicitly requires a legacy error envelope.

The English summary is being prepared. Showing the original description.

Use when implementing exception mapping or RFC 9457 error responses in Spring Boot 4. Preserve an existing legacy error contract unless migration is requested.

The English summary is being prepared. Showing the original description.

Implement one RFC: check its predecessors, present a plan for approval, write the code, then demonstrate every acceptance criterion.

The English summary is being prepared. Showing the original description.

Review an implemented RFC in a fresh context against its acceptance criteria, RULES.md and the test plan, and save the review to reviews/.

The English summary is being prepared. Showing the original description.

Prepare to work on a GitHub issue or RFC. Use when the user says /start-work, asks to start an issue, begin an RFC implementation, or pick up a task. Creates the branch, gathers context, and checks learnings.

The English summary is being prepared. Showing the original description.

RFC-driven multi-agent DAG execution pattern with quality gates, merge queues, and work unit orchestration.

The English summary is being prepared. Showing the original description.

Collaborative document creation via a structured three-stage workflow. Use for writing specs, PRDs, design docs, proposals, RFCs, and any long-form document where quality and clarity matter. Brainstorms 5-20 options per section, builds iteratively, and tests with reader sub-agents.

The English summary is being prepared. Showing the original description.

Specialized software engineering prompt methodology for Claude. Use when building prompts for system design, code review, incident response, security analysis, API design, architecture decisions, RFCs, ADRs, runbooks, or technical leadership. Trigger on: "build a prompt for code review," "system design prompt," "SRE prompt," "security review prompt," "incident response prompt," "API design prompt," "architecture decision prompt," "RFC prompt," "runbook prompt." Provides 11 tested approaches across identity, reasoning, and output for engineering analysis. Do NOT use for general coding help, writing code, or debugging — this builds prompts that shape engineering analysis, not code itself. Do NOT use for evaluating existing prompts (use rootnode-prompt-validation if available).

The English summary is being prepared. Showing the original description.