「baseline」の検索結果

Use when C code is written or audited and needs a pure-C baseline: standard, undefined behavior, integer and buffer safety, sanitizers, fuzzing, build flags. Not for C++: use modern-cpp-practices.

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

Use when invoked to apply an invariant-first, fail-fast, special-case-eliminating baseline. Not for domain models in types: use type-driven. Not for design-by-contract: use contract-driven.

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

Create or evolve an implementation-agnostic website design system from existing-site evidence, verified brand inputs, and an optional Visual Reference Brief. Use to establish visual and restrained-motion baselines, extract an existing site's rendered system for style-preserving extensions, validate one selected baseline with a compact Design Board, or update shared rules before page/module design. Do not conduct cross-industry reference research, map Elementor settings, create page layouts, design modules, or implement production code.

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

Append a DiT-tuning round to history.yaml. DiT-side counterpart of the LLM-path accuracy_append.py; records practice.md5, inference_outputs, fp_baseline_outputs, and the scoring fields (scores / overall_score / loss_vs_baseline / is_satisfied) populated by quant-tuning-score-dit. Idempotent on practice_id.

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

Define a Lean Six Sigma improvement project using DMAIC, problem framing, baseline measures, root-cause hypotheses, CTQs, and control planning. Use when an existing process is underperforming and the team needs a charter, SIPOC, baseline, and improvement path. Do not use for brand-new process design or vague complaints with no process boundary.

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

Visual regression testing — screenshot baselines, determinism, diff review, baseline custody and CI wiring. Load when adding, reviewing or debugging tests that compare a rendered subject against an approved image.

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

Use when a task needs the judgment of a systems engineer/architect working at the whole-program level — decomposing requirements across hardware/software/network subsystems, writing or reviewing an interface control document (ICD), making a build-vs-buy tradeoff for a subsystem, or tracing a verification failure back through the requirements baseline. Distinct from a software engineer (owns one service's code) or DevOps/SRE (owns operational reliability) — this role owns the technical baseline for a whole system-of-systems and is accountable when subsystems built by different teams or vendors don't fit together.

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

Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.

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

Initialize or safely upgrade a processor project's root AGENTS.md from a maintained baseline. Use when starting a processor project, adding project-level Agent collaboration rules, or comparing an existing AGENTS.md with the package baseline. This skill only handles AGENTS.md; it does not scaffold documentation, inspect or configure environments, install tools, or modify processor source.

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

Simulate transcription factor perturbation effects on cell state in silico with CellOracle and Dynamo, and predict transcriptional responses to genetic perturbations with GEARS, scGen, and CPA. Covers the direction-not-magnitude principle, local-linear validity, the GRN/velocity error it inherits, baseline discipline (mean and additive baselines), and the validation gap. Use when predicting TF knockout or overexpression effects, ranking driver TFs for fate transitions, or planning perturbation experiments. For GRN construction see multiomics-grn; for experimental Perturb-seq see single-cell/perturb-seq.

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

Normalize read-depth copy-ratio profiles and segment them into copy-number regions using circular binary segmentation (CBS, DNAcopy), hidden Markov models, HaarSeg, and fused-lasso methods. Covers GC-content, mappability, and replication-timing (wave-artifact) bias correction, panel-of-normals/PCA denoising, diploid-baseline centering, and algorithm selection by sequencing depth and event size. Use when choosing a segmentation algorithm, correcting depth bias, diagnosing oversegmentation or a mis-centered baseline, tuning CBS or HMM parameters, or understanding why a downstream CNV caller produced fragmented or shifted segments.

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

Run an org-team workflow — a flat pod of up to four peer Claude Code sessions claims lane-tagged slices of an approved spec over the baseline MCP channel and implements them concurrently, each in its own git worktree. Each peer DECIDES its own in-lane implementation choices in its own main context (Article X); only un-decidable or cross-lane forks escalate peer→lead→human (yield_fork for task-bound forks, ask_lead for free-form queries). Opt-in and OFF by default (velocity.org_mode.enabled). Graduates the retired sprint-dispatch prototype into the constitutionally-sanctioned org-team model (Article X — Multi-session coordinated workflows). Requires git.

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

Bootstrap the central system spec at `docs/system/` for a repository that has never had one. Scans the governed surface, proposes a concept map clustered by directory, and materializes elements + shards ONLY after a human confirms that map. Use when adopting the baseline on an existing project, or when the corpus needs re-deriving from scratch. Re-runnable. Requires `memory.architecture_map.enabled` and a declared `governed_surface`.

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

Run or change the macOS UX trace harness for action-to-visual-completion latency, scroll stability, fixture pressure, and baseline evidence.

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

Audit ClawJS/Clawix code hygiene without editing code, producing categorized findings, baseline status, and validation evidence.

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

Run and interpret Clawix UI geometry, screenshot, protected-surface, and debt-baseline checks without authorizing visual repair.

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

Knowledge base from NIST SP 800-37 Revision 2, the Risk Management Framework (RMF) for information systems and organizations. Use for the seven RMF steps (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) and their tasks; the three-tier organization-wide risk model; authorization boundaries; the requirements-to-controls relationship; security categorization (FIPS 199/200 high-water mark) and control selection/tailoring (SP 800-53/53B baselines); assessment, the authorization decision and risk acceptance, continuous monitoring and ongoing authorization; the security/privacy distinction; and supply chain risk management. This is the security-and-privacy-risk-governance edge of systems engineering — it governs how much protection and whether to accept residual risk, complementing the disciplines that decide how protection is built. Does NOT reproduce the SP 800-53 control catalog or its baselines, the FIPS impact tables, or the ISO/IEC/IEEE 15288 process text; it names and routes to them rather than restating them.

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

Knowledge base from the GAO Schedule Assessment Guide (GAO-16-89G, 2015). Use for building, assessing, or auditing a program's integrated master schedule (IMS): the ten best practices of a reliable schedule (capture, sequence, resource, duration, traceability, valid critical path, reasonable total float, schedule risk analysis, updating, baseline), the four characteristics (comprehensive, well-constructed, credible, controlled), critical path method arithmetic (forward/backward pass, total float), schedule risk analysis (Monte Carlo, contingency), statusing and baseline control, and the Appendix II audit triad. Scheduling/time-management oriented: it is the authority on schedule reliability, but it is NOT a cost-estimating guide, a full SE process model, an agile guide, or a risk-management framework — see sibling packs (gao-cost, dau-se-guidebook, nasa-schedule, nasa-risk) for those.

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

検査器（linter / ガード / CI ゲート / バリデータ / フィルタ）そのものの検出力が差分で静かに落ちていないか、また新設した検査が実際に検出できることが実証されているかを diff-time で検出する。Check 1 unverified detection reduction（検査器の検出ロジック（正規表現・除外パターン・解決集合・allowlist・baseline）を変更して検出件数が減ったのに、減った 1 件ずつが誤検出であった根拠が示されないまま「誤検出を潰した」「N → M 件に減少」と改善として主張している）、Check 2 unproven guard detection power（新しい検査ロジック・CI ゲート・バリデーションを追加・変更したのに、検出すべき入力を注入して検出されること／検出すべきでない入力で黙ることを示す変異注入の証跡が無く、「追加した」「CI が緑」を検出力の証拠として扱っている）、の 2 Check を対象とする report-only。テスト自身のアサーションが実質何も検証していない構造は test-assertion-effectiveness、レビュー基準・品質ゲートの明示的な弱体化（ルールの削除・閾値の引き下げ・suppression entry 追加・lint ルールの無効化）は review-criteria-integrity、リファクタ完了主張一般の検証は refactor-claim-audit、workflow の permissions と action pin は gha-workflow-security、設定ファイルの構文・型の妥当性は config-json へ委譲する

Establish build performance baselines and apply systematic optimization techniques. Only activate in MSBuild/.NET build context. USE FOR: diagnosing slow builds, establishing before/after measurements (cold, warm, no-op scenarios), applying optimization strategies like MSBuild Server, static graph builds, artifacts output, and dependency graph trimming. Start here before diving into build-perf-diagnostics, incremental-build, or build-parallelism. DO NOT USE FOR: non-MSBuild build systems, detailed bottleneck analysis (use build-perf-diagnostics after baselining).

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

Review board (Busabase App-in-Skill) that runs a fixed suite of mock test cases against a baseline vs candidate agent version and surfaces rubric-scored regressions before a release. Use when the user invokes $kelly-agent-eval or /kelly-agent-eval, wants to review agent-version regressions, compare baseline vs candidate quality, triage a release, or record a release approve/block decision. Deterministic mock rubric scores only — not a real LLM-judge call, and it never deploys anything.

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

Signals scout that watches a PostHog project's most-viewed dashboards and insights for recent anomalies — sudden bursts, drops, flat-lines, and trend breaks at the daily or hourly level. It discovers what the team actually looks at (view counts, dashboard access), curates a durable watchlist in the scratchpad, and balances re-checking known high-value insights (exploit) against discovering new ones (explore) across runs, since no single run can cover a busy project. Anomalies are scored by robust deviation from each insight's own seasonality-matched baseline; it emits a finding only when a move clears the confidence bar, otherwise it updates the baseline memory and closes out empty. Self-contained peer in the signals-scout-* fleet.

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

Rigorous methodology for evaluating ML models on established benchmarks. Covers proper train/val/test splits, baseline verification from original papers, exact metric formula discrepancies, data-leak detection checklist, multi-seed robustness, and honest reporting templates. Use when claiming to beat published baselines, writing methods papers, or auditing existing results.

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

Android アプリ開発 (Kotlin) の Gradle ビルドシステムリファレンス。 Android Gradle Plugin (AGP), Kotlin DSL (build.gradle.kts), version catalog, KSP, R8/ProGuard, App Bundle, baseline profile。