메뉴
Use when starting, continuing, changing, coordinating, recovering, or releasing work in this repository.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when starting, continuing, changing, coordinating, recovering, or releasing work in this repository.
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.
| 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.
When discovering or redefining the product, treat the initial product request as the first material answer. Infer discoverable facts, checkpoint normalized meaning rather than raw dialogue, and verify a successful apply before asking the next material question. When choices help, use 2–3 exclusive options labeled A/B/C, put the recommended option first and mark it recommended, and accept either a letter or free-form input. 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, prepare its tests and implementation normally, and use the chosen issue or PR workflow to request review. Git user.name and user.email are display metadata, not authority. Never mark a proposal approved from cached review data; integration and release require a fresh exact-commit approval.
When an editable UI workspace exists, inspect external sources before bringing accepted whole or selected files into it. Treat them as ordinary editable files, bind approved UI to an exact published commit, and ensure frontend work names that baseline fingerprint. UI creation tools are optional inputs, not canonical service state.
