Focus Code Skill Marketplace

Skill Introduction

Overview

Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior

Core value

Turns reusable Debugging know-how into an installable skill, helping users complete github, community, claude, claude-code work faster.

Target users

Developers, testers, and maintainers who handle Debugging tasks in Focus Code.
Teams that already trust workflows or content from Yeachan-Heo.
Users who want standardized prompts, steps, or conventions instead of repeating setup work.

Best practices

Read the skill content first to confirm required inputs, expected outputs, and dependencies.
Try it on a small task before relying on it for critical work.
Add project-specific constraints such as coding style, target platform, test expectations, and delivery format.
For external sources, verify the source link, version, and recent maintenance activity.

Best use cases

Tasks related to github, community, claude, claude-code that need a reusable execution flow.
Converting a community repo, team convention, or personal workflow into day-to-day assistance.
Starting from a proven skill instead of writing prompts or procedures from scratch.

Limits and boundaries

Results depend on the quality of the original skill content and may need human correction.
It does not replace code review, tests, security review, or professional judgment.
External tools, APIs, account permissions, and local dependencies still need separate setup.

Differentiation

Structured around Debugging, making it easier to discover and reuse than loose prompt snippets.
Marked as GitHub, which helps users judge trust and maintenance expectations.
Keeps the original source link available for repository, documentation, or discussion follow-up.
Tagged with github, community, claude, claude-code, so it can be filtered by concrete task intent.

Install and use

Install

Copy Install Command

focus install autoresearch-e4958b

View source

Detail Preview

SKILL.md

Primary filemarkdown4 KB

name: autoresearch description: Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior argument-hint: "[--mission-dir <path>] [--max-runtime <duration>] [--cron <spec>] [--resume <run-id>]" level: 4

<Purpose> Autoresearch is a stateful skill for bounded, evaluator-driven iterative improvement. It owns one mission at a time, keeps iterating through non-passing results, records each evaluation and decision as durable artifacts, and stops only when an explicit max-runtime ceiling or another explicit terminal condition is reached. </Purpose>

<Use_When>

You already have a mission and evaluator from /deep-interview --autoresearch
You want persistent single-mission improvement with strict evaluation
You need durable experiment logs under .omc/autoresearch/
You want a supported path for periodic reruns via Claude Code native cron </Use_When>

<Do_Not_Use_When>

You need evaluator generation at runtime — use /deep-interview --autoresearch first
You need multiple missions orchestrated together — v1 forbids that
You want the deprecated omc autoresearch CLI flow — it is no longer authoritative </Do_Not_Use_When>

<Contract> - Single-mission only in v1 - Mission setup/evaluator generation stays in `deep-interview --autoresearch` - Evaluator output must be structured JSON with required boolean `pass` and optional numeric `score` - Non-passing iterations do **not** stop the run - Stop conditions are explicit and bounded, with max-runtime as the primary strict stop hook </Contract>

<Required_Artifacts> Canonical persistent storage lives under .omc/autoresearch/<mission-slug>/ and/or .omc/logs/autoresearch/<run-id>/.

Minimum required artifacts:

mission spec
evaluator script or command reference
per-iteration evaluation JSON
markdown decision logs

Recommended canonical shape:

.omc/autoresearch/<mission-slug>/
  mission.md
  evaluator.json
  runs/<run-id>/
    evaluations/
      iteration-0001.json
      iteration-0002.json
    decision-log.md

Reuse existing runtime artifacts when available rather than duplicating them unnecessarily. </Required_Artifacts>

<Workflow> 1. Confirm a single mission exists and evaluator setup is already available. 2. Ensure mode/state is active for `autoresearch` and records: - mission slug/dir - evaluator reference - iteration count - started/updated timestamps - explicit max-runtime or deadline 3. On every iteration: - run exactly one experiment/change cycle - run the evaluator - persist machine-readable evaluation JSON - append a human-readable markdown decision log entry - continue even when evaluation does not pass 4. Stop when: - max-runtime ceiling is reached - user explicitly cancels - another explicit terminal condition is recorded by the runtime </Workflow>

<Cron_Integration> Claude Code native cron is a supported integration point for periodic mission enhancement. In v1, prefer documenting/configuring cron inputs over building a large scheduler UI.

If cron is used:

keep one mission per scheduled job
preserve the same mission/evaluator contract
append new run artifacts rather than overwriting prior experiments </Cron_Integration>

<Execution_Policy>

Do not hand execution back to omc autoresearch
Do not create multi-mission orchestration
Prefer reusing src/autoresearch/* runtime/schema helpers where they already match the stricter contract
Keep logs useful to humans, not only machines </Execution_Policy>

autoresearch