「fea」の検索結果

設計書や要件書から、最初から最後まで動く小さな機能単位を計画し、ひな形作成、生成と評価の反復、レビューと承認を経て動く最小限の製品を組み立てるスキル。

• 設計書から動くMVPを作りたいとき
• 一連の処理が動く小さな機能単位の計画
• 最初に動く機能のひな形作成

まだ存在しない機能の追加を、調査・計画からテスト先行の実装、レビュー、コミットまで進めるスキル。工程を担当エージェントに分担し、計画とコミット前に承認を挟みます。

• 未実装の機能を追加したいとき
• テスト先行で新機能を実装
• 認証機能のセキュリティレビュー

言語モデル内部の反応を少数の特徴に分解し、学習した概念を調べます。学習済みSAEの分析、自作SAEの訓練、特徴を使った出力調整と品質評価を案内します。

• 学習済みSAEで特徴を調べたいとき
• 特定のモデル層にSAEを訓練する
• 入力文ごとの特徴の反応を比較する

.NET MAUI safe area and edge-to-edge layout guidance for .NET 10+. Covers the new SafeAreaEdges property, SafeAreaRegions enum, per-edge control, keyboard avoidance, Blazor Hybrid CSS safe areas, migration from legacy iOS-only APIs, and platform-specific behavior for Android, iOS, and Mac Catalyst. USE FOR: "safe area", "edge-to-edge", "SafeAreaEdges", "SafeAreaRegions", "keyboard avoidance", "notch insets", "status bar overlap", "iOS safe area", "Android edge-to-edge", "content behind status bar", "UseSafeArea migration", "soft input keyboard", "IgnoreSafeArea replacement". DO NOT USE FOR: general layout or grid design (use Grid and StackLayout), app lifecycle handling (use maui-app-lifecycle), theming or styling (use maui-theming), or Shell navigation structure.

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

Define a frontend feature flag with `defineFlag` and wire its readers. Use when adding, suggesting, or changing a feature flag, PostHog flag, `ENABLE_*` env flag, `useFeatureFlag`, `isFeatureEnabled`, or `ShowFeatureFlag`.

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

Migrate Infrahub docs feature pages from the legacy topic+guide pair into a cleaner structure (single merged page, hub+spokes, or tutorial extraction). Supports both single-feature migrations (one feature like Profiles or Webhooks) and section-wide migrations (a whole section like Branches & Change Control with multiple features migrated together) when the team has agreed on a section-wide restructure plan. Trigger when the user names a specific feature or section to migrate (e.g. "let's migrate profiles", "start the Resource Manager migration", "do the entire Branches & Change Control section"). Each migration is its own branch off `demo/groups-diataxis-example`, its own PR back to that branch.

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

.NET MAUI safe area and edge-to-edge layout guidance for .NET 10+. Covers the new SafeAreaEdges property, SafeAreaRegions enum, per-edge control, keyboard avoidance, Blazor Hybrid CSS safe areas, migration from legacy iOS-only APIs, and platform-specific behavior for Android, iOS, and Mac Catalyst. USE FOR: "safe area", "edge-to-edge", "SafeAreaEdges", "SafeAreaRegions", "keyboard avoidance", "notch insets", "status bar overlap", "iOS safe area", "Android edge-to-edge", "content behind status bar", "UseSafeArea migration", "soft input keyboard", "IgnoreSafeArea replacement". DO NOT USE FOR: general layout or grid design (use Grid and StackLayout), app lifecycle handling (use maui-app-lifecycle), theming or styling (use maui-theming), or Shell navigation structure.

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

Use when designing, implementing, reviewing, testing, or cleaning up feature toggles, feature flags, kill switches, runtime configuration gates, canary controls, staged rollouts, experiments, or temporary compatibility switches in Java enterprise systems. This should trigger for requests such as Design a feature toggle strategy; Review this feature flag; Add a kill switch safely; Test toggle on and off paths; Clean up an expired feature toggle; Plan controlled rollout and rollback behavior. Part of Plinth Toolkit

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

Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation. Produces a feature specification focused on system behaviors, not implementation detail. Does not plan a restructure of code that already exists — use plan-a-change. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features — use project-documentation. Does not design the contract for an interface — use design-an-api. Does not research open-ended options before there is a feature to specify — use research. Does not map the bounded contexts of existing code — use ddd-analysis.

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

Builds a feature specification from scratch with plan-a-feature and publishes it to a user-specified Confluence location, posting the spec as a parent page and each companion artifact (decision log, team findings, technical notes) as a child page beneath it. Use when the user wants a new feature planned, designed, scoped, or specified AND posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not plan to local files only — use plan-a-feature. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features to Confluence — use project-documentation-to-confluence.

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

Apply requirement quality principles when generating or validating feature specifications. Enforces feature completeness, scenario structure, AC verifiability, feature independence, and implementation slice quality. Use when writing feature specs, validating existing requirements, or when the user mentions 'validate this spec', 'check this feature', 'requirement quality', 'is this spec complete', or 'requirement-quality'. This skill governs the craft of writing individual feature specifications — not technical design (see design-blueprint), not implementation (see code-forge).

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

Design and implement a feature engineering pipeline for a ML problem. Use when asked to "engineer features for this model", "what features should we build", or "design feature transformations".

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

Design or audit a feature store — serving, freshness, and sharing across models. Use when asked "do we need a feature store", "design a feature store", or "share features across models".

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

Drive a whole tdmcp feature BACKLOG to completion as resumable, wave-by-wave releases — the campaign layer ABOVE tdmcp-pipeline/tdmcp-feature-lead. Use whenever the user wants to implement an ENTIRE backlog or discovery file (e.g. _workspace/discovery*/FEATURE_BACKLOG*.md), 'all the features', many features across multiple releases, or a long autonomous build campaign, AND for every follow-up: continue/resume the campaign, run the next wave, re-run a failed wave, fold in QA results, or check campaign status. Backed by a ledger.json so re-running is idempotent (skips shipped work, resumes interrupted work) and resilient (retry-once then quarantine-and-continue). For a SINGLE feature or one small batch, use tdmcp-pipeline instead; this skill is for the whole ledger.

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

Feature flag lifecycle management -- safe feature toggling, gradual rollouts, A/B testing patterns, flag cleanup strategies, and technical debt prevention. Covers LaunchDarkly, Unleash, OpenFeature, and custom implementations.

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

Create a complete feature module with folder structure, Assembly Definition (.asmdef), test assembly, and namespace. Use when adding a new feature, system, or module to a Unity project. Triggers on requests like "create a new feature", "scaffold a module", "add a combat system", "I need a health system", "set up inventory", "create a new module for X", "add a new system", "new feature folder", or any task requiring new folders, assemblies, or namespaces for a gameplay feature — even when the user just names a system they want to build from scratch. Reads ProjectConfig.yaml for folder_strategy and MCP availability.

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

Drive a whole tdmcp feature BACKLOG to completion as resumable, wave-by-wave releases — the campaign layer ABOVE tdmcp-pipeline/tdmcp-feature-lead. Use whenever the user wants to implement an ENTIRE backlog or discovery file (e.g. _workspace/discovery*/FEATURE_BACKLOG*.md), 'all the features', many features across multiple releases, or a long autonomous build campaign, AND for every follow-up: continue/resume the campaign, run the next wave, re-run a failed wave, fold in QA results, or check campaign status. Backed by a ledger.json so re-running is idempotent (skips shipped work, resumes interrupted work) and resilient (retry-once then quarantine-and-continue). For a SINGLE feature or one small batch, use tdmcp-pipeline instead; this skill is for the whole ledger.

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

Use when the user wants a code review of an explicit range or set of files — correctness, security, performance, conventions, tests — with stable findings (CR-nnn, BLOCKER..INFO) and rule citations — 'revisar os últimos commits', 'code review da feature X', 'review base..HEAD'. Plans a REPORT-mode review (no code changes, no commit). Do NOT use to fix code (feat-feature / feat-quick), to write tests (feat-test) or for UI/UX design critique.

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

Use when the user asks for the state of pwdev-feat plans — 'status do feat', 'quais planos estão pendentes', 'show feature status' — listing pending, complete, with-caveats, failed and resumable plans plus codebase-context health. Read-only. Do NOT use to execute (feat-exec) or query the audit trail (feat-audit).

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

Write the executable feature specification — the WHAT and WHY artifact that agents and reviewers treat as source of truth. Owns both /specify and /clarify modes. Load when the user asks to write a feature spec, write a specification, write an executable spec, define functional requirements, capture acceptance criteria as Given/When/Then, or when the spec-driven-development orchestrator routes here. Also triggers on "feature spec", "executable spec", "/specify", "/clarify", "write the spec for this feature", "specification for", "spec-driven", "machine-readable spec". Output: docs/specs/YYYY-MM-DD-<slug>-feature-spec.md. Hard gate: cannot Approve while [NEEDS CLARIFICATION] markers remain.

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

Doctrine for adding a capability INTO a live, existing feature to a world-class bar. Use on 'add X to Y', 'extend Y to support X', a new option, button, setting, endpoint, or tool for Y, or a sub-feature spec to implement. NOT for whole-feature audits or overhauls (use feature-deep-dive).

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

Doctrine for auditing an ENTIRE feature and building it to its ideal state. Use on 'deep dive on X', 'audit the X feature', 'figure out everything X does', 'take over X and finish it', 'bring X up to best practices', or when a whole feature needs overhauling, unifying, or finishing, not patching. NOT for one small addition (use build-sub-feature).

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

正常に動いている既存機能を新しい仕様へ変更するスキル。テストを先に更新し、実装の修正、レビュー、承認を挟んだコミットまで順に進めます。

• 既存の通知しきい値を変えたいとき
• 動作中の機能を新仕様に合わせたいとき
• 振る舞いの変更前にテストを更新したいとき

機能追加や不具合修正などの開発を、規模に応じて調査・計画・テスト・レビューへ振り分けます。計画承認とコミット確認を組み込む、関連スキル共通の手順です。

• 機能追加と不具合修正の手順を揃えたいとき
• 変更規模に合わせて工程を選びたいとき
• 設計書からMVP開発を進めたいとき