harness

Plugin harness from marketplace studioKjm-harness in studioKjm/ai-harness-template. Commands read from the repo's manifest — 28 days ago.

Skills (2)

• supabase-migration

  DB 스키마를 바꾸거나 테이블/컬럼/RLS 정책/함수를 추가할 때 사용. 마이그레이션 생성, RLS 체크리스트, 로컬 검증, 타입 재생성 절차를 따른다. "테이블 추가", "컬럼 추가", "RLS", "마이그레이션" 요청에 사용.

• verify

  기능 구현이나 버그 수정 후 실제 앱에서 동작을 검증하고 증거를 남긴다. 로컬 환경에서 시드 계정으로 접속해 화면과 콘솔·서버 로그를 확인한다. "동작 확인", "검증", "E2E", "화면 확인" 요청이나 작업 완료를 선언하기 전에 사용.

Slash commands (13)

• /harness:decompose

  Break seed AC into atomic layer-aware tasks BEFORE /run. USE WHENEVER implementation spans multiple files or layers. Prevents mega-prompts; each unit is independently implementable and testable.

• /harness:evaluate

  Run 3-stage verification (Mechanical gates → Semantic AC compliance → Judgment quality) after /run. ALWAYS run before committing. Blocks at Stage 1 failures — no Stage 2 until gates pass.

• /harness:evolve

  Evolve the system when /evaluate fails. Runs Wonder → Reflect → Re-seed cycle with fan-out multi-perspective analysis (Contrarian + Simplifier + Researcher). Stops at convergence (ontology similarity ≥ 0.95).

• /harness:install

  Interactive installation wizard for AI Harness Template. Guides through version, track, permissions, gates, and more via step-by-step questions.

• /harness:interview

  START HERE for ANY new feature or unclear requirement. Socratic interview that surfaces hidden assumptions before a single line of code is written. Measures 4D ambiguity score — blocks progress until score ≤ 0.2.

• /harness:methodology

  Methodology plugin manager. List, activate, compose, deactivate development methodologies (Ouroboros, Living Spec, Parallel Change, BMAD-lite, Exploration). Harness gates remain enforced regardless of methodology.

• /harness:pm

  Generate a stakeholder-facing PRD from interview results. USE WHEN non-engineering stakeholders need a Product Requirements Document. Optional — most workflows go interview → seed directly.

• /harness:review

  Lightweight mid-run verification. Runs Stage 1 (Mechanical) gates only. Use between AC implementations to catch drift early. Much faster than /evaluate.

• /harness:rollback

  USE WHEN /run fails mid-way, /evaluate reports severe drift, or partial implementation must be undone. Saga-pattern rollback via git stash/checkout/branch — chooses safest strategy based on scope.

• /harness:run

  Execute seed spec via Double Diamond (Discover → Define → Design → Deliver). USE AFTER /decompose. Enforces D→L→P implementation order, writes tests immediately, runs gates continuously. Supports Pair Mode for medium/high complexity ACs.

• /harness:seed

  Crystallize interview results into an IMMUTABLE seed spec (YAML). Run ONLY after /interview reaches ambiguity ≤ 0.2. Extracts ontology, AC, constraints. Once created, seeds cannot be modified — only versioned.

• /harness:trd

  Generate layer-aware technical design document from seed spec. USE AFTER /seed and BEFORE /decompose. Maps features to 3-tier architecture, surfaces discussion points before final design.

• /harness:unstuck

  USE WHEN stuck on a bug, architecture decision, or recurring failure. Applies 5 perspectives sequentially (Researcher → Architect → Contrarian → Simplifier → Hacker) to break deadlock.

Subagents (11)

• architect

  USE THIS WHEN symptoms keep recurring, layer boundaries blur, or changes ripple unexpectedly. ALWAYS invoke for structural diagnosis during /unstuck or major refactors. Finds root causes in design, not symptoms. Names tradeoffs explicitly.

• contrarian

  USE THIS WHEN the team reaches quick consensus, before committing to a major design decision, or during /evolve and /unstuck. Challenges assumptions with "what if we're wrong?" scenarios. Always proposes at least one alternative.

• evaluator

  USE THIS WHEN verifying implementation against a seed spec, running gates, or assessing AC compliance. ALWAYS invoke during /evaluate. Never fixes — only judges Pass/Fail with file:line evidence. Runs 3-stage verification (Mechanical → Semantic → Judgment).

• hacker

  USE THIS WHEN the official path is blocked, a deadline looms, or a temporary workaround is acceptable. ALWAYS invoke during /unstuck when standard approaches fail. Finds safe bypasses (monkey-patch, polyfill, shim) with explicit expiry dates.

• interviewer

  USE PROACTIVELY whenever the user describes a new feature, vague requirement, or unclear goal. ALWAYS run BEFORE writing code or creating a seed spec. Asks Socratic questions to surface hidden assumptions. Never writes code or gives answers — only questions.

• navigator

  USE THIS as the planning half of pair programming during /run (PAIR_MODE). Generates 3 solution plans per AC, selects optimal one, directs Driver. Never writes code directly. Based on PairCoder (ASE 2024) Navigator-Driver methodology. MUST be spawned as a background agent and communicated via SendMe

• ontologist

  USE THIS WHEN defining domain terms, extracting entities/relationships from requirements, or unifying synonyms (e.g., "user" vs "member" vs "account"). ALWAYS invoke during /seed spec generation. Extracts Entity/Attribute/Relationship from interviews.

• researcher

  USE THIS WHEN a claim needs evidence, debugging requires history, or library/API behavior is uncertain. ALWAYS invoke before guessing — checks official docs, existing code patterns, git log/blame first. Evidence over speculation.

• seed-architect

  USE THIS WHEN crystallizing interview results into an immutable specification. ALWAYS invoke during /seed. Converts conversation + ontology into structured seed YAML with zero TODO/TBD tolerance. Blocks progress if any field is ambiguous.

• simplifier

  USE THIS WHEN code feels over-engineered, scope seems to creep, or abstractions pile up. ALWAYS invoke during /evolve and /unstuck. Asks "is this needed for MVP?" on every feature. YAGNI-first — prefers convention over configuration.

• test-designer

  USE THIS for independent test case generation during /run (PAIR_MODE). Designs tests from AC and seed spec only — never reads implementation code. Prevents biased testing. Based on AgentCoder (2024) test separation methodology. MUST be spawned with isolation worktree to physically prevent source cod

Similar plugins