「scope」の検索結果

Safety guardrails for destructive operations. Wraps workflows and agent actions in configurable safety modes: CAREFUL (warns before destructive commands), FREEZE (restricts file edits to one directory), GUARD (both modes combined). Use when working in production, running destructive scripts, or debugging in sensitive areas. Voice triggers: "be careful", "safety on", "guard mode", "freeze scope". Also used automatically by the workflow engine when a workflow preset has safety: "guard" enabled.

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

One-command pre-execution review pipeline. Runs scope review → architecture review → security review → design review (auto-detects which apply) before executing any workflow. Surfaces only taste decisions for user approval. Auto-fixes obvious issues. Use before executing multi-step workflows, deploying, or when user says "review this plan", "check before running", "pre-flight", or "is this ready?". Runs CEO → eng → security automatically with encoded decision principles.

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

Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.

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

Turn a short natural-language request into a bounded work contract (intent, scope, acceptance, initial queue) without asking for code or architecture review.

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

Breaks work into ordered, parallel-dispatchable tasks with an execution DAG. Output format is consumable by CI matrices and parallel agent runners — each task has a stable ID, declared file writes, conflict edges, and branch suffix. Use when you have a spec, brief, or shaper output and need to decompose it into implementable units. Use when a task feels too large, when scope spans multi-repo or multi-week work, or when parallel execution across multiple agents is on the table.

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

Apply this opinionated workflow when reverse-engineering legacy or undocumented systems: scope, explore the code, trace data flows, document in EARS format, flag uncertainties. For code archaeology, onboarding, and requirements extraction.

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

Opinionated house conventions for NestJS backends — module boundaries and layering, provider wiring and injection scopes, guards/interceptors/pipes/filters, DTOs and validation, domain exceptions, config, and the Nest 11 / Express 5 behaviour that compiles cleanly and fails at runtime. Use whenever the code is NestJS (`@nestjs/*` in package.json, or `@Module`/`@Injectable`/`@Controller`/`@Cron` in the file), including when the question sounds like plain TypeScript, an OOP refactor, a code review, or an ops problem — the Nest-specific answer differs from the generic one. Typical asks: scaffolding a module, adding a controller, provider, or endpoint, wiring an enhancer, a boot-time DI or circular-import failure, a response leaking entity fields despite `@Exclude()`, a cron job firing on every replica, upgrading NestJS, or reviewing a Nest diff. Not for plain Express or Fastify, Angular, frontend, SQL, or CI.

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

Select, write, or review proportionate tests and verification for dygo Go packages, PostgreSQL behavior, metadata, CLI contracts, Studio, integrations, and releases. Use when test scope or confidence strategy is the main decision.

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

Improve or review ordinary dygo code changes for simplicity, focused scope, canonical ownership, clear boundaries, and verifiable behavior. Use for normal implementation and refactoring quality; use dygo-thermonuclear-review only for an explicitly severe audit.

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

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

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

Guide building a minimum viable product through manual-first, then processized, then productized stages. Use when someone is ready to build their first product or struggling with scope.

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

Query and filter Datadog logs from the shell using the Composio CLI. Run scoped log searches, pivot across services/environments, and export structured JSON for incident investigation and diagnostics.

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

Create concise, actionable plans for coding tasks. Scope work, identify dependencies, and deliver atomic, ordered steps from discovery through validation and rollout.

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

Locate and summarize Azure resources quickly across scopes using consistent query patterns. Use this skill when users ask where resources are, what they are configured as, or need inventory by type, region, or tag.

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

Implement dependency injection in Angular v20+ using inject(), injection tokens, and provider configuration. Use for service architecture, providing dependencies at different levels, creating injectable tokens, and managing singleton vs scoped services. Triggers on service creation, configuring providers, using injection tokens, or understanding DI hierarchy.

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

Design and apply Azure role-based access control with least privilege at the right scope. Use this skill when users ask about permissions, role assignments, access errors, or governance. Covers built-in roles, custom roles, managed identities, PIM, and access reviews per Well-Architected principles.

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

Auto-activate for litestar_security, SecurityPlugin, SecurityConfig, SecureController, CurrentUser, Principal, SecurityContext, or requires_role/scope/tenant/capability/assurance. Not for basic Litestar Guards.

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

GEODE CHANGELOG.md management rules. Version releases, change logging, scope determination, format standards. Triggers on "changelog", "release", "version", "릴리스", "변경사항", "버전".

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

Scope, preregister, execute, audit, normalize, and publish GEODE evaluations with research-question, reproduction, attempt-lineage, trajectory, verifier-receipt, and immutable artifact contracts. Use for benchmark runs or comparisons, eval-artifact and cache-accounting audits, GPT or subscription result normalization, research question or hypothesis framing, retry diagnosis, trajectory publication, DPO or reward-data readiness reviews, and requests involving MCPMark, tau2, BFCL, Agent-World, HAL, Terminal-Bench, or Toolathlon.

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

Triages an already-dirty Git working tree: breaks down every uncommitted change hunk by hunk, separates deliberate edits from tool-written churn, possibly accidental reversions, misplaced scope, and sensitive content, asks the user about the ambiguous cases, and proposes an ordered set of commits plus a list of hunks to hold back. Use when the user invokes `/pc` or `$pc`, asks what they should commit, wants their uncommitted changes broken down, or wants commits proposed for a dirty working tree or pile of accumulated local modifications. To plan commit boundaries for a change before or while implementing it, use `incremental-commits` instead.

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

Puts the agent into a cautious production mode for live systems: read-only inspection may proceed, but credentials and out-of-scope personal data need permission first, every state-changing action needs explicit per-action approval with its resource risks and rollback stated, and anything unexpected halts work until the user decides. Use when the user invokes `/prod` or `$prod`, or says they are working on production, a live or customer-facing server, a mail server, or a production database, or asks for care on a system where mistakes affect real users.

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

融合单元的范围判定与收益前置评估：判定「哪些计算该被融进同一个融合单元、边界画在哪、 融了值不值」。结构侧按融合单元构造规则切边界——函数边界即候选组；FA（含 BSA 等变种）为 禁融锚点；以 norm / rope / FA 为分界分区，全 Vec 区域优先试融；区域内有 Cube 时以 Cube 为 首算子向后包裹 Vec（Σvec 小于 cube 或遇下一 Cube 封口）；一轮之后纯 Vector 单元之间再迭代； MLP / MoE 以矩阵乘族（MatMul / BatchMatMul / GroupedMatmul）为界；若该段计算已由单个 融合算子承载，按规则 6 先确认载体是否已生效（不重复建单元）。 收益侧按计算单元利用率判型（memory_bound、*_vec|mac|mte2|mte3_ratio、cube_utilization）， 叠加带宽下限 / 区域占比 / 天花板法 / 地板先行 / Amdahl 传导校验给出 go/no-go。 当用户问「这几个算子能不能融成一个」「融合边界画在哪」「融多大范围」「融了值不值得」， 或 profiling-analyze 给出融合机会候选需要定范围与收益时使用；即使用户只说「这条链要不要 合成一个 kernel」「这里能不能省一次读写」也应触发。 **已经做完、实测收益却打平或为负时同样触发**——此时的任务不是接受"融合无收益"， 而是按事后复核做**等功忙计数对照**归因，并在缺陷落在融合核自身时**升级 operator-dev**。 边界：只出「融合单元草案 + 收益判定 + 否决理由」。不做采纳与选点（dit-perf-opt 依收益选 top 并派活）、不做采集与瓶颈定位（profiling-collect / profiling-analyze）、不写 kernel、不写 pattern、 不做使能与并行选型、不定义验收标准（引 accuracy-gate / perf-gate）。 由 profiling-analyze（融合机会候选）与 operator-dev（实现前的收益评估）调用。

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

分布式并行策略选型与实测（USP / CP 通信掩盖 / CFG / TP/RSP/PP 概览；含拓扑相关选型 （按实测拓扑分域条件化：域内 bulk vs 跨域 head-parallel 翻转）与 AlltoAllV 缺陷绕过）。在 model-auto-optimization 中承担 S3：优先 USP、结合拓扑带宽差异选 CP，少量 step + 多 rank 验证特性开启与掩盖（产物：并行方案 + 多 rank 证据）。当用户需要多卡并行 策略选择、**序列并行形态抉择**（纯 Ulysses vs 复合 AllGather-KV×Ulysses：按 GQA / 跨域带宽 / 形态 plumbing 条件化定胜负）、**并行 × 稀疏叠加**（seam 契约：先汇聚后稀疏、 窗口偏移、块对齐、per-head 掩码；含「稀疏看似生效实则未生效」判定）、通信掩盖调优 （含**掩盖率上限**：1-1/n 何时成立、c/f 决定的真实上限、没生效的排查）、**并行方案 差异归因**（阶段 Δ 分解 / 集合通信按 communicator 归属 / 4→8 卡线性度），或排查多卡 跑不动 / 通信暴露大 / 换卡组 / 端口 bind / HCCL 带宽验证问题时使用；**并收编原并行作用域诊断**： 改了 SP/CP/Ulysses/AllGather-KV 后**不报错但结果没变/性能没变**、或小规模能跑大规模崩 （如 Ascend EE1003 coreDim 超限）时，用本技能证明"改动到底有没有生效"（判别量逐层收窄 + 两侧对照 + 日志≠生效，见 `references/scope-effectiveness-check.md`）； 即使用户只说 "多卡跑不动""通信暴露大""为什么没达到 6/7 的掩盖率""CP 和 USP 该选哪个""CP 叠稀疏 怎么不生效"而未说并行，也应触发。特性档位/接口事实见 `docs/zh/features/parallelism.md` /`usp.md`（仓内真源），框架侧开启见 framework-integration； 本技能承载选型决策、monkey-patch 掩盖与多卡诊断实测。 由 dev-workflow 多卡场景触发，亦由 model-auto-optimization 的 S3 阶段触发。

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

对 profiling 数据（kernel_details.csv / trace_view.json / step_trace_time.csv）做统一分析： 5 层递进管道（analyze_trace.py）+ baseline/优化后 kernel diff（compare_traces.py），输出 瓶颈诊断、算子执行序、可融合候选与 P0-P2 方向建议。输入统一来自 profiling-collect。 只要用户有 profiling 产出并问"为什么慢/瓶颈在哪/优化前后差多少/往哪个方向"，都用本技能；采集走 profiling-collect，方案选档走 dit-perf-opt，实现/并行/基准走 pattern-dev/dit-parallel-opt/benchmark-dev——本技能只做诊断与方向。 由 model-auto-optimization 的 S1（融合分析）/S3（并行）阶段调用，亦由 dev-workflow 的分析阶段指引加载。 融合机会候选只做**识别**；候选的**边界与收益判定**（能不能融成一个单元、融多大、值不值）交 `fusion-scope-analyze`（本技能的辅助技能）——本技能不判融合边界。

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