メニュー
Feature design methodology. Covers research, comparison, requirements refinement, ideation, implementation planning, and DX completeness. Use when starting a new feature, planning a refactor, or designing APIs. Invoked via /design [topic].
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Reviewer persona for authorization models — RBAC, ABAC, ReBAC, and hybrids. Catches the bugs that ship after auth is correct but authz is wrong: missing tenant scoping, IDOR via predictable IDs, role escalation through unchecked write paths, permission caching staleness, transitive-trust loopholes, RBAC/ReBAC drift between policy doc and code. Use when reviewing endpoints that gate access by user/role/relationship, when adding a new role/permission/scope, when changing tenant isolation, or when designing a permission system from scratch. Triggers: RBAC, ABAC, ReBAC, IDOR, tenant isolation, multi-tenant, permission check, role, scope, principal, Zanzibar, OpenFGA, casbin, authz, can_, has_permission, isAuthorized.
Stand up a full c1 dev stack inside a Squire env — process-compose, postgres, envoy, pub-api, pub-auth, be-* services — wired so an external client can drive c1's gRPC surface end to end with TLS + OAuth2 client_credentials. Use when testing a Latchkey or other c1 client against a real (not stubbed) c1 backend, or when reproducing c1 server-side behavior locally. Triggers on: c1 dev env, squire c1 stack, pc/up, dev-util mint-test-client, test against c1, c1 OAuth client_credentials, run c1 integration tests in squire, repro buildkite integration test, TEST_LOCAL_EXEC, api_no_uplift.
c1-specific values for the general squire dispatch protocols defined in squire-env-management. Provides the c1 gate bundle's contents, the task-family table for c1 work, the c1 always-actives, and the list of c1 skills that should NOT be spent on a squire env. Use when about to spawn a squire env to execute c1 work, when writing a brief for a remote c1 agent, or when filing a c1 bead intended for squire dispatch. Triggers: c1 squire dispatch, c1 squire brief, c1 remote work, c1 ephemeral env, c1 fire-and-forget.
Reviewer persona for detecting hand-rolled cryptography. Distinct from `sharp-edges` (which catches footgun APIs) and `key-lifecycle-review` (which covers lifecycle hygiene): this skill catches the class where someone wrote their own MAC, KDF, AEAD, signature scheme, secret-comparison routine, RNG, or password hash. Almost all custom crypto is broken. Use when reviewing any code that does math on bytes, manipulates buffers in a 'crypto-shaped' way, or implements something whose docs reference a named primitive (HMAC, AES-GCM, Argon2, X25519). Triggers: hand-rolled crypto, custom MAC, custom hash, custom KDF, byte XOR, constant-time compare, derived key, password hashing, HKDF, encrypt_then_mac, mac_then_encrypt, AE, AEAD.
Reviewer persona for the full lifecycle of cryptographic keys and high-value secrets: generation, storage, distribution, rotation, revocation, and destruction. Trail of Bits' `zeroize-audit` covers the destruction half; this skill covers the other four phases plus closes the loop with destruction. Use when reviewing key management code, secret stores, KMS integrations, rotation logic, key derivation, RNG usage, or any system that issues, holds, or revokes long-lived credentials. Triggers: key generation, key rotation, KMS, HSM, secret store, vault, key derivation, KDF, master key, DEK, KEK, rotation, revocation, RNG, entropy, random, secrets management.
Reviewer persona for OAuth 2.0 / 2.1 and OpenID Connect flow implementations. Catches the well-documented attack classes that still ship: missing PKCE, wildcard redirect URIs, mishandled refresh tokens, scope creep, mixed flows on a single endpoint, leaking tokens through referrer or logs, JWT signature bypass. Use when reviewing any code that issues, accepts, validates, exchanges, refreshes, revokes, or stores tokens; when designing a new auth integration; when a PR touches /authorize, /token, /userinfo, /jwks, /introspect, /revoke, OIDC discovery, or a third-party identity provider client. Triggers: OAuth, OIDC, JWT, PKCE, redirect_uri, scope, refresh token, access token, id_token, client_credentials, authorization code, implicit, device code, token exchange, identity provider, IdP, SSO.
| name | design |
| disable-model-invocation | true |
| description | Feature design methodology. Covers research, comparison, requirements refinement, ideation, implementation planning, and DX completeness. Use when starting a new feature, planning a refactor, or designing APIs. Invoked via /design [topic]. |
| argument-hint | [feature or topic] |
Structured approach to feature design. Not every step applies to every feature. Skip steps that don't add value. The sequence matters more than completeness.
What exists? Read the codebase. Read competing implementations. Read the docs. Capture findings in DATA_SOURCES.md.
How do others solve this? Build a comparison matrix: feature vs platform. Look for patterns across 3+ implementations.
Convert vague requirements ("make it fast") into measurable attributes ("p99 latency under 200ms"). Challenge ambiguous terms.
Generate concrete features with examples. Each feature gets: name, one-line description, CLI example or API shape, which attribute it serves.
Cut aggressively. What's the smallest thing that delivers the core value? Use the Level Framework: Level 0 (platform), Level 1 (workflow), Level 2 (polish). Build Level 0 first.
Vertical slices, not horizontal layers. Each slice is deployable and testable. Count lines of code per slice. If a slice exceeds 500 lines, split it.
Run /critique on the plan before implementing.
Every developer-facing feature needs three things:
If any leg is missing, the feature is incomplete.
