「fea」の検索結果

Creates and updates coding standards, conventions, rules, and guidelines for the current project. Use when creating new standards from scratch, converting existing documents into coding standards, or updating existing standards. Does not create architectural decision records — use architectural-decision-record for ADRs. Does not write feature or system documentation — use project-documentation for that. Does not research open-ended options — use research. Does not produce runbooks for operational scenarios — use runbook for that.

日本語の概要は準備中です。原文の説明を表示しています。

Produces a human-readable, progressive-disclosure overview of unfamiliar code or a pull request's changes — why it exists (the real problem it solves or goal it serves for the business or a user), and from there what it does, how it flows, and where to start — so you can get up to speed before working on or reviewing it. Use when you want to understand, get oriented in, make sense of, explain, or get up to speed on a chunk of code, a file, a directory, a symbol, or a PR's changes. Writes the overview to a scratch file and changes no code. Does not review code quality or raise findings — use code-review for auditing changes or post-code-review-to-pr for posting them. Does not produce durable feature or system documentation — use project-documentation. Does not assess architecture or structural risk — use architectural-analysis. Does not diagnose bugs or root-cause failures — use investigate. Does not pace a person through the code one step at a time in conversation — use code-walkthrough.

日本語の概要は準備中です。原文の説明を表示しています。

Create or update a runbook for an operational scenario — an incident an alert fires for, a recurring scheduled task, or a known failure mode on a live service — using a consistent template. Use when writing, drafting, authoring, or updating a runbook for an alert, incident, on-call procedure, scheduled maintenance, or operational SOP. Applies a YAGNI preflight requiring the scenario to be real before producing the runbook. Does not produce feature or system documentation — use project-documentation. Does not record architectural decisions — use architectural-decision-record. Does not create coding standards — use coding-standard.

日本語の概要は準備中です。原文の説明を表示しています。

Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by hand and the outcomes they should expect. Use when you want to create, draft, generate, or outline a manual test plan, manual QA steps, hands-on verification steps, or an acceptance walkthrough for a feature, change, branch, plan, or PR. When the plan holds more than five tests and at least two natural categories emerge, both the test list and the detail sections are organized under plain-language categories. When nothing in the supplied context can be manually tested, it says so and asks for more context instead of producing a document. Does not analyze code for automated test coverage gaps — use automated-test-planning. Does not write test code — use tdd. Does not review code quality — use code-review. Does not stress-test an existing plan — use iterative-plan-review.

日本語の概要は準備中です。原文の説明を表示しています。

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for writing documentation or architectural decision records.

日本語の概要は準備中です。原文の説明を表示しています。

Plans an architecture-driven change to code that already exists: module boundaries, type responsibilities, layering, coupling, and the public surface a revision moves. Produces a buildable change plan that names the types, modules, and methods involved and records the surface delta each change makes. Use when the user wants to plan, scope, or sequence a restructure, extraction, split, consolidation, responsibility shift, or API revision of existing code, including "these responsibilities are wrong, plan the fix". Does not assess an area and stop at findings — use architectural-analysis. Does not specify new behavior — use plan-a-feature. Does not diagnose a bug — use investigate. Does not write the code — use refactor to restructure it or tdd to build it.

日本語の概要は準備中です。原文の説明を表示しています。

Reverse engineer native, managed, Electron/JavaScript, packaged, firmware, and browser targets with REA. Use shipped-artifact or requested runtime evidence to explain features, compare versions, decompile code, or guide a reconstruction. Skip REA for ordinary source-repository architecture analysis.

日本語の概要は準備中です。原文の説明を表示しています。

Use when writing, changing or reviewing code that touches the house contract for Jetpack Compose and Compose Multiplatform apps: module graph, MVI/BaseViewModel, error tiers, state ownership, naming, Koin DI, Navigation 3 and coroutines. The compose skill is the entry point. Do NOT use for Gradle-only work (compose-project), new screens (compose-feature), composable-only work (compose-ui), repositories or persistence (compose-data), or expect/actual splits (compose-platform).

日本語の概要は準備中です。原文の説明を表示しています。

Use this skill first for any Jetpack Compose or Compose Multiplatform task: a new feature or screen, a change to existing code, a bug fix, a review, making code follow the kit, project or build setup, or a question. It picks the task path and the exact kit files to read. Not for Kotlin work outside a Compose or CMP app.

日本語の概要は準備中です。原文の説明を表示しています。

Owns repositories, data sources and mapping for Compose and Compose Multiplatform apps: DTO to domain to UiModel boundaries, Ktor clients and bearer auth, WebSocket and SSE, Room, DataStore, Paging 3, offline-first and data-layer tests. Use when writing or reviewing a repository, data source, DTO, mapper, HttpClient, bearer token, WebSocket, SSE, Room DAO, migration, DataStore, PagingSource, RemoteMediator, offline cache or MockEngine test. Do NOT use for ViewModel or UI wiring (compose-feature), composables (compose-ui), the MVI contract or error tiers (compose-architecture), Gradle modules (compose-project), or commonMain vs platform splits (compose-platform).

日本語の概要は準備中です。原文の説明を表示しています。

Writes and reviews composables for Compose and CMP: the Route/Screen/leaf split, state-read placement and stability, loading/empty/error UX states, LazyColumn lists and grids, animation choice, accessibility and semantics, design-system tokens, CMP Res resources, Coil images, and keyboard/focus. Use when touching @Composable code, recomposition, stability, LazyColumn, animation, shimmer or skeleton, accessibility, theme, colors, Res.string, Coil, focus, or keyboard. Do NOT use for MVI, error tiers, or module graph (compose-architecture), ViewModel or data work (compose-feature, compose-data), Gradle or module work (compose-project), or expect/actual splits (compose-platform).

日本語の概要は準備中です。原文の説明を表示しています。

Interview the user about a product idea and write PRD.md. Use at the start of a new project, before features, rules or RFCs exist.

日本語の概要は準備中です。原文の説明を表示しています。

Document an existing codebase as PRD.md, FEATURES.md and RULES.md, so new work is planned against the code as it is. Use instead of create-prd when the code already exists.

日本語の概要は準備中です。原文の説明を表示しています。

Maintenance of the contributor issue pipeline for JSONbored/awesome-claude (HeyClaude) — closing issues that are already done but not marked so, and keeping a small, high-value contributor-available backlog stocked with real website/content/feature/bugfix work. Runs every ~24h via a dedicated scheduled task. Invoke for "run the issue gardening", "audit open issues for stale/complete ones", "generate new contributor issues", or any recurring/scheduled run of this process. `reference.md` (next to this file) has the exhaustive label/milestone/ template detail — read it before doing real work, not just this file. This is the awesome-claude-specific instance; JSONbored/loopover and JSONbored/metagraphed each have their own separate copy with different conventions and a much larger backlog target — do not cross-apply either repo's specifics to this one without being asked.

日本語の概要は準備中です。原文の説明を表示しています。

Legacy v1 (voiceover-led, GSAP + HyperFrames). Use when making, directing or rescuing a product launch video, promo, teaser, demo reel, sizzle, feature-announcement film or animated product explainer built from code — and when an existing one looks basic, reads as a slideshow, has reveals that miss the voiceover, an invisible cursor, an inaudible sound effect, a clipped or too-quiet mix, or every video coming out looking the same. Covers SaaS, apps, hardware, e-commerce, dev tools, services. Keywords include motion design, storyboard, voiceover sync, kinetic typography, GSAP, HyperFrames, Remotion, film grain, LUFS, ffmpeg.

日本語の概要は準備中です。原文の説明を表示しています。

Write model-native Seedance 2.0 video prompts from text, images, video, or audio references. Use for text/image generation, multimodal reference, video editing, extension, track fill, or combined tasks that need stable subjects, explicit asset roles, coherent event order, camera, sound, visible text, and a 4–15 second feasibility check.

日本語の概要は準備中です。原文の説明を表示しています。

Turn real product images and a verified brief into a clean Seedance 2.0 minimalist product film. Use for 4–15 second e-commerce or launch ads that require faithful product color/material/geometry, independent anchor-image roles, product-specific actions, restrained camera, readable integrated copy, sound, and a stable closing frame; not for talking-head ads or invented product features.

日本語の概要は準備中です。原文の説明を表示しています。

Plan, diagnose, and verify performance budgets, latency targets, load tests, capacity estimates, bottleneck analysis, caching strategy, query efficiency, queue throughput, and regression gates. Use when a feature may be slow, a system must scale, a performance regression is suspected, or release readiness depends on throughput, cost, memory, CPU, or response time.

日本語の概要は準備中です。原文の説明を表示しています。

Plan and verify software releases with versioning, changelogs, release branches, feature flags, canaries, migration gates, rollback, deployment checks, and release readiness. Use when preparing a release, shipping a risky PR, coordinating app/backend/database rollout, recovering from a bad deploy, or defining release policy for a repo.

日本語の概要は準備中です。原文の説明を表示しています。

Use when the user needs product management workflows such as RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, go-to-market strategy, feature prioritization, research synthesis, or requirements documentation.

日本語の概要は準備中です。原文の説明を表示しています。

PRD writing and product definition expert. Use when writing PRDs, user stories, acceptance criteria, or prioritizing features. Covers RICE/MoSCoW frameworks, agile requirements, and specification best practices.

日本語の概要は準備中です。原文の説明を表示しています。

Threat-model product features, APIs, data flows, secrets, permissions, supply-chain changes, auth boundaries, and risky code paths before or during implementation. Use when touching authentication, authorization, payments, secrets, user data, uploads, webhooks, admin tools, innerHTML/eval/exec, dependency upgrades, or cross-tenant access.

日本語の概要は準備中です。原文の説明を表示しています。

Guides clean architecture design with strict 200-line file limits. Use when starting new features, refactoring large files, or planning module structure. Enforces modular design and real testing.

日本語の概要は準備中です。原文の説明を表示しています。

Use this skill when reasoning about generative AI, adversarial machine learning, neural network security, algorithmic fairness, or deep learning fundamentals. This skill channels the thinking of Ian Goodfellow, inventor of Generative Adversarial Networks (GANs). Trigger this skill when the user asks about model robustness, mitigating bias, evaluating AI guardrails, designing generative models, or defending against adversarial attacks. Apply his frameworks of minimax games, adversarial feature learning, and worst-case robustness analysis to shift the user's perspective from average-case optimization to adversarial resilience.

日本語の概要は準備中です。原文の説明を表示しています。