Harness

Entry point and router for Harness-governed AI engineering. Use automatically for software engineering tasks, feature implementation, bug fixes, refactors, architecture changes, repository initialization, spec/plan/task workflows, risk classification, TDD, evaluation, reporting, debugging, product definition, supervisor PM loops, code semantic auditing, or when the user says "use Harness", "按 Harness 流程", "接管这个任务", "implement this", "fix this", "debug this", "review this", "product idea", "worth building", "goal", "supervisor", "atlas", "语义地图", "语义审计", "audit this code".

Low token Codex PM loop skill. Reads .pm/ files, generates bounded tasks, delegates to OpenCode Intern, reviews reports, and updates project state. Designed for long-running /goal sessions where Codex acts as product supervisor and OpenCode acts as engineering intern. Use when: "goal", "supervisor", "PM loop", "advance the product", "long-running product evolution", "Codex /goal".

Convert source code into semantic audit documentation — Mermaid diagrams, structured tables, and pseudocode — for human semantic verification. Triggers on "atlas", "semantic map", "audit this code", "代码语义地图", "语义审计".

OpenCode CLI 调用指南。提供所有 CLI 命令、标志、环境变量的速查参考，用于在终端中编程式调用 OpenCode。当用户需要通过 shell 脚本、CI/CD、自动化流水线或非交互模式使用 OpenCode 时触发。触发词：opencode cli、opencode run、opencode serve、非交互模式、自动化调用、脚本调用 opencode。

OpenCode worker skill. Executes bounded tasks written by harness-supervisor. Reads next-task.md, follows Harness engineering flow, modifies code, writes tests, runs verification, and outputs structured worker-report.md. Use when: "execute task", "run intern", "worker", or when instructed by supervisor to read .pm/runtime/next-task.md.

High-level product definition and UX discovery skill. Runs seven gates to determine whether a product is worth building, who it's for, what experience should exist, what the MVP boundary is, and what UI/UX direction should guide implementation. Produces .pm/stable/ files and initializes .pm/runtime/state.yaml. Use when: product idea, "worth building", "product definition", "define this product", user journey, UX principles, UI direction, MVP boundary.

Initialize a new project with Harness engineering discipline. Creates directory structure, copies templates, sets up Makefile, installs skills. Use when starting a new project or adopting Harness on an existing codebase.

Optimize agent context for cache-friendly assembly. Standardizes prompt prefix ordering (stable → semi-stable → active → dynamic), generates cache geometry configuration, and produces cache-aware context bundles. Use when context is too large, agent is repeatedly reading same files, user asks about cache/cost/ token reduction, or before implementation to minimize context pollution. Triggers: "cache context", "optimize context", "reduce tokens", "context too large", "cache-friendly", "prompt cache", "token optimization", "context order".

Systematic debugging as a maintenance transaction. Use when encountering bugs, test failures, regressions, unexpected behavior, or any fix request in existing code. Enforces: symptom → reproduce → evidence → root cause → minimal patch → regression → review → close. Triggers on: "debug this", "fix this bug", "test failed", "not working", "regression", "unexpected behavior", "why is this broken", "修一下", "为什么失败".

Find architecture improvement opportunities: shallow modules, deep module candidates, DDD dependency violations, testability gaps. Use periodically to prevent AI-accelerated code rot. Triggers: 'codebase feels complex', 'untestable', 'hard to navigate', 'architecture review'.

Evaluate whether an implementation satisfies the spec (Product Eval) and whether the agent followed Harness process gates (Harness Eval). Use before merge, after implementation, or when asked to "eval", "evaluate", "check compliance", "verify against spec", "did we follow process", "is this ready to merge", "run eval", "product eval", "harness eval".

Create a feature specification with user stories, functional requirements, Given/When/Then acceptance scenarios, success criteria, assumptions, and explicit out-of-scope boundaries. Use when user wants to define a feature, convert an idea into a spec, write a PRD, or start a new implementation workflow.

Run a role-isolated TDD workflow: RED (tests only, no implementation), GREEN (implementation only, no test changes), REFACTOR (implementation only), REVIEWER (reports only). Use when implementing features with test-first discipline, or when the user says 'TDD', 'red green refactor', 'test first', or 'role-isolated testing'.

Create a minimal context bundle for a feature so coding agents read only the relevant spec, plan, tasks, policies, project language, ADRs, and forbidden context list. Use before implementation or review to reduce agent context pollution. Triggers: "context bundle", "what should I read", "prepare context", "agent context", "context for agent", "zoom out", "what's relevant", "narrow context", "context window".

Extract or maintain a DDD-style ubiquitous language for the project. Identifies ambiguous terms, resolves synonyms, establishes canonical terminology, and writes CONTEXT.md, UBIQUITOUS_LANGUAGE.md, and ADR records. Use when starting a new project, onboarding agents, or when agents use inconsistent terminology.

Stress-test a plan or spec by asking the user pointed questions one at a time. Each question probes assumptions, edge cases, and implicit requirements. Provides recommended answers. Use before spec finalization or when requirements feel fuzzy.

Create an implementation plan from an existing spec, including architecture impact analysis, DDD layer impact, blast-radius classification (leaf/branch/core/infra), test strategy, and rollback plan. Use after spec exists and before implementation. Use when turning a spec into a build plan.

Produce an implementation report with changed files, risk classification, test evidence, review findings, known issues, and rollback plan. Use after implementation or before PR review to create an evidence package. Triggers: "report", "implementation report", "evidence package", "what changed", "ship report", "create report", "generate report", "PR report", "rollback plan".

Classify a proposed change by blast radius (leaf/branch/core/infra) and determine required gates. Use when planning a change that touches multiple files, core logic, infrastructure, auth, schema, or deployment config. Triggers on "risk level", "blast radius", "classify change", "what gates do I need", or "is this safe to auto-merge".

Break a spec and plan into vertical-slice implementation tasks with dependencies, parallel-safe markers, checkpoints, and exact file paths. Use when turning a plan into executable work items, creating tasks.md, decomposing work for AI agents, or when the user says "create tasks", "break this down", "task DAG", or "implementation order".