test-and-log
Test a target (script, demo, pipeline, CLI command, integration) without modifying any source code, then write a structured log of the process, outcomes, anomalies, and issues. Use when the user says "test X and log", "run X and document findings", or "try X without changing code". Default log location is context/logs/TIMESTAMP-task-name/TIMESTAMP.md.
Best use case
test-and-log is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Test a target (script, demo, pipeline, CLI command, integration) without modifying any source code, then write a structured log of the process, outcomes, anomalies, and issues. Use when the user says "test X and log", "run X and document findings", or "try X without changing code". Default log location is context/logs/TIMESTAMP-task-name/TIMESTAMP.md.
Teams using test-and-log should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/test-and-log/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How test-and-log Compares
| Feature / Agent | test-and-log | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Test a target (script, demo, pipeline, CLI command, integration) without modifying any source code, then write a structured log of the process, outcomes, anomalies, and issues. Use when the user says "test X and log", "run X and document findings", or "try X without changing code". Default log location is context/logs/TIMESTAMP-task-name/TIMESTAMP.md.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Test and Log Run a test target, capture every step's outcome, and write a structured log. **Never modify source code.** **This skill must be invoked explicitly by name** (e.g., `$test-and-log`). It will not trigger automatically from context. Example prompts: - `$test-and-log scripts/demo/cao-interactive-full-pipeline-demo` - `$test-and-log — run the cao-claude-session demo and log any issues to context/logs` - `$test-and-log pixi run test-runtime, log results to tmp/test-logs` - `$test-and-log the gemini-headless-session demo without touching any code` ## References - **Log template**: See [references/log-template.md](references/log-template.md) for the exact log structure to fill in. ## Workflow ### 1. Clarify parameters Collect before starting: | Parameter | Default | Notes | |---|---|---| | **Subject** | (required) | What to test — command, script, demo path, etc. | | **Log dir** | `context/logs/` | Root directory for log output | | **Task name** | Derived from subject | Kebab-case slug for directory name | Derive `<ts>` from the moment the run starts: `YYYYMMDD-HHMMSS` (UTC). Full log path: `<log-dir>/<ts>-<task-name>/<ts>.md` ### 2. Check prerequisites Before running anything, verify all stated prerequisites of the subject. Record each check result in the log's **Environment** section. If a prerequisite is missing, record it and decide (with the user if interactive) whether to abort or proceed with a caveat. ### 3. Run steps Execute each step of the subject in sequence. For each step: - Capture the full command run - Capture exit code and relevant output excerpts - Note any warnings, anomalies, or unexpected outputs — **even when exit code is 0** - Record timing where meaningful ### 4. Identify issues and anomalies After all steps complete, review the captured outputs for: - Hard failures (non-zero exit codes, exceptions, error messages) - Soft anomalies (wrong output, stale data, unexpected warnings, parser drift, etc.) - Partial successes (pipeline succeeded structurally but produced incorrect results) For each issue, record: what happened, where in the run it occurred, relevant output excerpt, and interpretation if known. ### 5. Write the log Create the log file at the derived path. Fill in the template from [references/log-template.md](references/log-template.md). Key rules: - Record actual command output verbatim (truncate only if very long — mark truncations with `[…]`) - Do not editorialize in the per-step sections; save interpretation for the **Anomalies** and **Summary** sections - Do not include speculation about fixes unless explicitly asked ### 6. Do not modify code This skill is strictly read-and-run. If a failure or anomaly is discovered, document it in the log and stop. Do not attempt to fix, patch, or work around issues in source files.
Related Skills
openspec-ext-hack-through-test
Manual invocation only. OpenSpec-specific hack-through-testing workflow targeting production-level end-to-end paths using real data and real user workflows — not CI smoke/unit/integration tests. Three subskills: `propose` to create an OpenSpec change with HTT-ready test cases (automatic scripts and interactive guides) by invoking `openspec-propose` or `openspec-ff-change`, `revise` to update an existing OpenSpec change so its artifacts support hack-through-testing-driven implementation and testing, and `run` to exercise an implemented OpenSpec change through the full hack-through-testing loop (in-place by default, or in a disposable snapshot worktree when requested). Use when the user explicitly asks for `openspec-ext-hack-through-test`, points to `openspec/changes/...` while asking to propose, revise, run, exercise, or prepare work under hack-through-testing principles, or wants OpenSpec work shaped for fast blocker discovery through patch-forward testing.
hack-through-testing
Manual invocation only. Drive a crashy, hanging, or half-broken system forward along a real production user path using real data. Two subskills: `prepare` to analyze the target and set up `<htt-home>/` with infrastructure dirs (logs, runs, issues); optionally creates `<htt-home>/autotest/` with automatic scripts and interactive guides only when the developer explicitly requests test-case generation. `run` drives testing — with or without autotest artifacts — patching forward through blockers. Run subskill operates in-place by default (stash + test on current branch) or in a disposable snapshot worktree when explicitly requested. Supports automatic and interactive driving. Default when ambiguous: both subskills, in-place, automatic. Not for CI-oriented unit, smoke, or mock-based integration tests.
do-interactive-test
Prepare for and run user-driven interactive testing of a directory the user points to. Use when the user wants the agent to read what is already there first, be prepared, follow step-by-step test instructions, or honor a constrained edit boundary during testing. Handle generic directories, demo/tutorial directories, and OpenSpec change directories differently; for OpenSpec change directories, use openspec CLI commands to gather context instead of assuming a file layout inside the directory. During interactive testing, do not automatically modify the system under test; report issues first, let the developer decide whether to log them or proceed to a fix, and only modify demo-specific code when a fix is explicitly requested. Do not create extra logs unless the developer asks for issue logging or step logging.
pixi-make-offline-channel
Use when the user wants to create a self-hosted, offline-installable Conda channel (mirror) containing a specific subset of packages using Pixi.
pixi-make-cu-build-env
Guides the agent to setup a new or existing Pixi environment for compiling C++ and CUDA code. It ensures the correct compilers, toolkits, and CMake configurations are in place for a robust user-space build.
pixi-install-nvidia
Use when the user says "use pixi to install <some nvidia tool>" (or similar) and wants NVIDIA/CUDA/GPU packages installed via Pixi (no sudo/apt), e.g., CUDA toolkit pieces, cuDNN/NCCL, PyTorch CUDA builds, RAPIDS.
pei-docker-usage
Helper for PeiDocker (`pei-docker-cli`). Trigger ONLY when the user explicitly requests PeiDocker usage OR when working within a PeiDocker-generated project (indicated by `user_config.yml`).
conan-basic-usage
Basic operations for the Conan C++ package manager. Use when the user explicitly asks to 'use conan' for tasks like creating projects, installing dependencies, or building packages, or asks for 'how to' guidance on Conan setup.
explore-dnn-model
Manual invocation only; use only when the user explicitly requests `explore-dnn-model` by name. Explore how to run a given DNN model checkpoint in the current Python environment by locating weights + upstream source code, resolving dependencies with user confirmation, running reproducible experiments under `tmp/`, and producing reports about I/O contracts, timing, and profiling.
openspec-ext-revise-by-decision
Manual invocation only; use only when the user explicitly requests `openspec-ext-revise-by-decision` by exact name. Revise OpenSpec change artifacts from a review or decision document that contains questions plus `DECISION` blocks, applying chosen decisions from a review file such as `openspec/changes/<change>/review/review-*.md` back into proposal, design, specs, and tasks.
openspec-ext-review-plan
Review an OpenSpec change (or a single OpenSpec change artifact file) for completeness, coherence, and alignment with existing system design; capture actionable feedback plus open questions; write a review report under the change directory (review/review-YYYYMMDD-HHMMSS.md).
openspec-ext-respond-to-review
Read an OpenSpec review report critically, evaluate the reviewer's proposals and findings against the current change artifacts and repository context, and write developer-owned final decisions/responses back into the review document. Use when the user explicitly mentions `openspec` or points to a path under `openspec/` while asking to examine a review report carefully, decide open questions, respond to findings, fill `DECISION` blocks, respond to an OpenSpec review file, or record final answers in an OpenSpec review document without yet revising the proposal, design, specs, or tasks.