ワンクリックでManusで任意のスキルを実行

$pwd:

validation

Name: Validation
Author: numman-ali

// Use this skill when working on MLXR runtime debugging, log triage, validation discipline, benchmark-backed claims, or deciding whether runtime behavior is strong enough to count as evidence rather than a one-off run.

Manusで実行

$ git log --oneline --stat

stars:3

forks:0

updated:2026年3月14日 21:28

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

name	validation
description	Use this skill when working on MLXR runtime debugging, log triage, validation discipline, benchmark-backed claims, or deciding whether runtime behavior is strong enough to count as evidence rather than a one-off run.

Validation

Use this skill for the narrow slice that sits beyond the normal dev loop:

debugging runtime behavior
inspecting logs after source, artifact, or daemon changes
validating whether a claim is benchmark-grade or still provisional
triaging whether a behavior is a platform truth, a family quirk, or a likely bug

Do not use this skill for the common implementation path. The default loop still lives in AGENTS.md, MEMORY.md, and docs/dev-harness.md.

For real LTX-2.3 fidelity bring-up and stage-local smoke debugging, use the dedicated ltx-fidelity-debugging skill instead of stretching this generic validation overlay.

Default workflow

Run the repo harness first:
- uv run python scripts/dev.py verify
- uv run python scripts/dev.py logs --tail 120
Inspect the relevant platform docs before interpreting results.
When a promoted clip or showcase result depends on semantic correctness, run scripts/gemini_describe_video.py as an automated semantic cross-check and keep the parsed XML review with the receipt.
Distinguish between:
- implementation bug
- missing benchmark evidence
- stale docs
- still-open architecture question
If the result is still uncertain, downgrade the claim instead of over-stating it.

What to load

For benchmark strength and freeze criteria:
- docs/benchmark-matrix.md
- docs/research/09-open-questions-and-validation-plan.md
For runtime and scheduler interpretation:
- docs/technical-design.md
- docs/research/05-optimization-playbook.md
For LTX-specific runtime pressure:
- docs/research/07-ltx-integration-seams.md

Validation rules

Prefer measured local evidence over inferred explanations.
Separate model behavior, output-path behavior, and harness behavior.
Treat logs as evidence, not decoration.
Do not promote a result to a stable claim if it still depends on one machine, one family, or one narrow path.

related-skills.json

同じリポジトリ

swiftui-pro.md

from "numman-ali/mlxr"

Comprehensively reviews SwiftUI code for best practices on modern APIs, maintainability, and performance. Use when reading, writing, or reviewing SwiftUI projects.

2026-03-143

family-bringup.md

from "numman-ali/mlxr"

Use this skill when bringing up a new model family, re-basing an existing family onto the current platform contract, or deciding what belongs in core workflow orchestration versus family or host code.

2026-03-143

media-asset-composer.md

from "numman-ali/mlxr"

Design static and light-motion media assets such as posters, slides, cards, flyers, invitations, social graphics, thumbnails, hero images, banners, certificates, README art, and short promo reels. Use when Codex needs to turn text, images, icons, or video into polished layout-driven visuals, especially through a reproducible Python, Pillow, SVG, or ffmpeg workflow.

2026-03-133

ltx-fidelity-debugging.md

from "numman-ali/mlxr"

Use this skill when debugging real LTX-2.3 output quality, running safe manual smoke tests, interpreting stage snapshots, or deciding whether a result is specific enough to count as a clear dog or other visually coherent subject.

2026-03-073

package.json

"author": "numman-ali"

"repository": "numman-ali/mlxr"

GitHub リポジトリを開く Creator のリポジトリを見る

$ install --global

$ download --local

Manusで実行

$ useful --forSOC

ソフトウェア品質保証アナリスト・テスターコンピュータ・数学職15-1253L4

Validation

Use this skill for the narrow slice that sits beyond the normal dev loop:

debugging runtime behavior

inspecting logs after source, artifact, or daemon changes

validating whether a claim is benchmark-grade or still provisional

triaging whether a behavior is a platform truth, a family quirk, or a likely bug

Do not use this skill for the common implementation path. The default loop still lives in AGENTS.md, MEMORY.md, and docs/dev-harness.md.

For real LTX-2.3 fidelity bring-up and stage-local smoke debugging, use the dedicated ltx-fidelity-debugging skill instead of stretching this generic validation overlay.

Default workflow

Run the repo harness first:

uv run python scripts/dev.py verify
uv run python scripts/dev.py logs --tail 120

Inspect the relevant platform docs before interpreting results.

When a promoted clip or showcase result depends on semantic correctness, run scripts/gemini_describe_video.py as an automated semantic cross-check and keep the parsed XML review with the receipt.

Distinguish between:

implementation bug
missing benchmark evidence
stale docs
still-open architecture question

If the result is still uncertain, downgrade the claim instead of over-stating it.

What to load

For benchmark strength and freeze criteria:

docs/benchmark-matrix.md
docs/research/09-open-questions-and-validation-plan.md

For runtime and scheduler interpretation:

docs/technical-design.md
docs/research/05-optimization-playbook.md

For LTX-specific runtime pressure:

docs/research/07-ltx-integration-seams.md

Validation rules

Prefer measured local evidence over inferred explanations.

Separate model behavior, output-path behavior, and harness behavior.

Treat logs as evidence, not decoration.

Do not promote a result to a stable claim if it still depends on one machine, one family, or one narrow path.

validation

Validation

Default workflow

What to load

Validation rules

このリポジトリの他の Skills

このリポジトリの他の Skills

Validation

Default workflow

What to load

Validation rules