菜单
Use when starting, continuing, changing, coordinating, recovering, or releasing work in this repository.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a cloned, transferred, or paused project must be resumed, the next safe work is unclear, or shared and local progress need reconstruction.
Use when service rules, contracts, DBML, dbdiagram, external UI, ownership, repositories, submodules, or integration order cross implementation boundaries.
Use when a feature, bug, behavior, architecture, or cross-workspace change needs an executable checklist, conflict-aware ownership, or a safe start.
Use when context was compacted or forgotten, settled questions repeat, canonical sources disagree, production readiness is requested, or an exact release candidate needs validation.
Use when a service idea needs discovery, a framework-neutral full-stack project must be created, or an existing repository needs non-destructive adoption.
Use when starting, continuing, changing, coordinating, recovering, or releasing work in this repository.
| name | use-project-harness |
| description | Use when starting, continuing, changing, coordinating, recovering, or releasing work in this repository. |
Treat the user's natural-language request as the entry point; do not make them memorize commands or edit .harness/. Read .harness/entry.md, run stackcord status --json when available, and inspect actual Git, workspace, and submodule state. From a child repository, resolve the actual orchestration root before asserting service-wide context. Read only canonical sources related to the request. specs/ owns product meaning; contracts/ owns service purpose, commitments, non-goals, business rules, failure behavior, interfaces, and data obligations.
Ask one material product question at a time, infer discoverable facts, and checkpoint normalized decisions rather than raw dialogue. Keep work management proportional: a small private local edit does not need a ticket or Git work reservation. For shared, long-lived, cross-workspace, or semantically risky work, the selected task source owns live status and the Git work reservation owns exclusive semantic scope. Re-read both, check path and meaning overlap, and set ownership and merge order before parallel work. Use conventional Git names without AI markers.
Use TDD for behavior, bugs, contracts, migrations, and UI interactions; exploratory spikes may stay unmerged until evidence exists. Keep coordination internals out of normal replies. If context was compacted, settled questions repeat, or sources disagree, run a context audit before mutation. Use core release normally and enable strict release only for an explicit organizational need. If the CLI is unavailable, follow references/fallback.md and state reduced verification.
Before changing service purpose, policy, business rules, contracts, or governance, run stackcord governance check --json. If governance is enabled and the selected Git provider does not identify the current account as a product authority, keep the protected change as a proposal and request review. Git user.name and user.email are display metadata, not authority.
