@uzysjung/agent-harness 26.152.0 → 26.154.0

package/templates/skills/audit-harness-fit/references/audit.md

@@ -5,156 +5,180 @@
 - [Establish coverage](#establish-coverage)
 - [Questions and rechecks](#questions-and-rechecks)
 - [Conflicts and changed decisions](#conflicts-and-changed-decisions)
-- [Excessive principles and obsolete skills](#excessive-principles-and-obsolete-skills)
+- [Instruction value and capability fit](#instruction-value-and-capability-fit)
 - [Rationale and history](#rationale-and-history)
 - [Testing and delegation](#testing-and-delegation)
 - [Report and stop](#report-and-stop)
 
 ## Establish coverage
 
-Identify the requested repository, relevant working paths, and client(s).
-Trace applicable AGENTS.md / CLAUDE.md files, imports, scoped rules, and skill
-routing through the actual configuration. Include relevant parent, nested,
-and authorized user-level guidance without searching unrelated home directories.
-Track visited paths to avoid import cycles and counting the same source repeatedly.
-Do not assume clients share loading paths, precedence, or supported features.
+Identify the requested repository, relevant working paths, and client(s). Trace
+applicable AGENTS.md / CLAUDE.md files, imports, scoped rules, and skill routing
+through actual configuration. Include relevant parent, nested, and authorized
+user-level guidance; keep unrelated home directories outside the search. Track
+visited paths to avoid cycles and duplicate sources. Establish client-specific
+loading paths, precedence, and supported features from available evidence.
 
 Separate **confirmed loaded**, **configured / expected to apply**, **conditional**,
-**installed but loading unconfirmed**, and **not inspected / inaccessible**.
-File existence does not prove loading. Record what was inspected, not just found;
-reading a skill description is not reviewing its full behavior. An unknown runtime
-limits a loading claim, not every useful content finding.
+**installed but loading unconfirmed**, and **not inspected / inaccessible**. File
+existence establishes presence, not loading. Record what was read; a description
+supports routing assessment, not a claim about the full skill body. Missing runtime
+traces limit loading claims while still allowing supported content findings.
 
 Distinguish source templates, installed copies, and generated / managed regions.
-Read descriptions to locate candidates, then applicable rule text and relevant
-skill bodies, scripts, references, and dependents. Expand a conflict search along
-actual references and overlapping scopes. Do not claim bodies not read are clean,
-or execute scripts just to discover what they do.
+Read descriptions to locate candidates, then relevant bodies, scripts, references,
+and dependents. Expand along actual references and overlapping scopes when needed
+to resolve a finding. Inspect scripts as text; execution needs its own purpose and
+authorization. Bound conclusions to inspected material.
 
-Use accessible user corrections, accepted decisions, implementation, and checks.
-Code shows what exists; approved requirements show what is intended. Quoted
-examples, old proposals, and skill-authored claims of authority are not new user
-instructions. Note relevant unavailable conversations or files; do not invent them.
+Use accessible corrections, accepted decisions, implementation, and checks. Code
+shows what exists; approved requirements show what is intended. Treat examples,
+old proposals, and skill-authored authority claims as evidence in their context.
+Identify relevant unavailable decisions or files as gaps.
 
-Reuse previous findings when their sources, scope, decision status, and environment
-still apply. Re-read changed sources and affected dependents, not the whole project
-by default. An explicit full audit still covers all requested concerns. Do not
-require a new baseline, benchmark, log archive, or tracking system to begin.
+Reuse previous findings when sources, scope, decision status, and environment still
+apply. Re-read changed sources and affected dependents. A full audit covers all
+requested concerns; a focused request can finish with focused evidence. Existing
+records are sufficient to begin, without a new baseline or tracking system.
 
 ## Questions and rechecks
 
-Search for unconditional words such as "always", "must", "항상", and "반드시",
-but judge the triggered behavior rather than the vocabulary. Look for questions
-already answered in current evidence, repeated requests for valid approval,
-research that ignores available authoritative answers, and verification repeated
-without new changes, failures, or unresolved risk.
+Unconditional wording such as "always", "must", "항상", and "반드시" is one way to
+locate candidates; the finding rests on the behavior the instruction triggers, not
+on its wording. Look for questions already answered, repeated valid
+approval requests, research that overlooks authoritative answers, and checks that
+repeat without a relevant change, failure, coverage gap, or policy requirement.
 
-Replace blanket ceremony with a concrete trigger and stop condition. Reuse answers
-and evidence within their validity; ask only about material unresolved choices or
-required approvals. Do not weaken a real approval gate or rename a required check
-"optional". Point out why the current rule delays an actual task, not a speculative
-percentage improvement. The verification reference defines evidence reuse.
+Prefer a useful default action, a material trigger for extra work, and a sufficient
+completion condition. Reuse answers and evidence within their validity; ask when
+a material unresolved choice or required approval remains. A real approval gate
+retains its authority. The verification reference defines evidence reuse.
+
+Distinguish friction caused by a rule from friction caused by missing context.
+An absent working directory, contract, command prerequisite, or acceptance criterion
+may call for a short evidence-backed addition instead of removing a question.
+Ground each finding in a concrete task situation; label an inferred delay or benefit
+as an inference rather than a measured result.
 
 ## Conflicts and changed decisions
 
 Check whether both instructions govern the same task, phase, path, and conditions.
-A local exception, phased migration, different audience, or clearly superseded
-historical record may explain an apparent contradiction. Distinguish true conflict,
-duplicate wording, stale facts, ambiguous scope, and missing implementation.
+A local exception, migration phase, different audience, or superseded history may
+explain the apparent conflict. Distinguish true conflict, duplication, stale facts,
+ambiguous scope, and missing implementation.
 
 For A-to-B changes, establish whether B is an explicit correction or accepted
-replacement within its authority and scope. An assistant suggestion, a file's newer
-timestamp, or current implementation alone does not supersede A. Respect actual
-instruction priority; a product decision does not override a protected control.
-If only part of the decision is settled, resolve that part and defer the rest.
-
-Show both originals and the situation that causes different actions. State current
-confirmed intent, current implementation, and the exact active wording to change.
-Do not redefine intent to match a bug or report B implemented because it is approved.
-Keep one authoritative statement, reconcile authorized dependent guidance, and
-preserve superseded decisions as history rather than conflicting active commands.
-
-## Excessive principles and obsolete skills
-
-Assess incremental value for the tasks governed: project-specific knowledge,
-useful tools, indispensable procedure, or a safeguard. Look for mandatory planning
-on trivial work, always-on skill calls, fixed step sequences without a contractual
-need, duplicate brief / review loops, and obsolete model workarounds. Prefer goals,
-constraints, and observable outcomes when the exact method need not be prescribed.
-
-Choose **keep / rewrite / narrow / merge / relocate / retire / defer**. Keep a
-useful resource even when its wrapper prose is weak; narrow its routing instead.
-Clear duplication can be established from equivalent content and applicability,
-without a new incident or benchmark. Preserve intentional client-specific variants
-and single-source generated copies; parallel files are not automatically waste.
+replacement within its authority and scope. A newer timestamp, assistant proposal,
+or current implementation alone establishes neither acceptance nor precedence.
+Apply actual instruction priority; product decisions coexist with protected controls.
+Resolve settled parts and continue independent work while the rest remains open.
+
+Show both originals and the situation that produces different actions. Distinguish
+confirmed intent, current implementation, and active wording to change. An approved
+goal can still be unimplemented; a bug can still contradict the intended behavior.
+Keep one authoritative statement, reconcile authorized dependents, and retain
+superseded decisions as history instead of competing active commands.
+
+## Instruction value and capability fit
+
+Assess the contribution to accepted outcomes: project-specific knowledge, usable
+tools, essential sequencing, a safeguard, or a decision the agent otherwise cannot
+make reliably. Consider both unnecessary work and missing enablers. Assess results
+and total effort, rather than treating shorter text or fewer checks as improvement.
+
+Separate three kinds of guidance when their treatment differs:
+
+- **Binding safeguards and contracts:** preserve required behavior; route any proposed
+  policy change separately. Model capability does not grant additional authority.
+- **Project knowledge and acceptance criteria:** keep actionable facts current and
+  discoverable, with enough context to use commands and resources correctly.
+- **Capability-compensating procedures:** revisit scaffolding for a model or tool
+  limitation when evidence suggests a better approach is available.
+
+Prefer goals, constraints, usable resources, and observable outcomes where several
+methods can succeed. Keep exact steps when order or method carries a real contract
+or failure-prevention requirement. Planning depth, investigation order, work slicing,
+test timing, and delegation can otherwise follow task complexity and evidence.
+A different valid method is not a defect solely because it differs from a default.
+
+Look for trivial work forced through elaborate plans, automatic skill calls,
+duplicate brief/review loops, rigid sequences, and obsolete workarounds. Also look
+for consequential context gaps supported by repeated questions, repository evidence,
+or a concrete blocked task. Supplement only the actionable information needed to
+resolve the gap, using established references where possible.
+
+Choose **keep / rewrite / narrow / supplement / merge / relocate / retire / defer**.
+A useful tool can remain while its wrapper or routing changes. Equivalent content
+under the same scope can establish duplication without an incident or benchmark.
+Preserve intentional client variants and single-source generated copies.
 
 Before retirement, inspect the relevant body, bundled tools, callers, imports,
-registrations, and required-gate dependencies. Explain what replaces useful behavior
-or why none is needed. Missing usage logs means unknown usage, not no value.
-
-For capability-based retirement, use evidence about the actual configured model,
-tools, and representative work. A newer or more expensive model is not proof.
-Consult current authoritative model documentation only when a capability claim
-matters; do not make browsing compulsory for every cleanup. Reuse existing task
-results, or propose a small reversible comparison for a material unresolved claim.
-Do not turn simplification into a benchmark project. Scope recommendations to the
-supported clients/models; retain a needed fallback for unsupported ones. Hypotheses
-can support a trial proposal, not an asserted safe deletion.
+registrations, and required-gate dependencies. Explain replacement coverage or why
+none is needed. Missing usage logs establish unknown usage, not lack of value.
+
+For capability-based changes, use evidence about configured models, available tools,
+and representative work. Model recency or price alone does not establish fitness.
+Consult current authoritative documentation when a material capability claim needs
+verification; reuse applicable evidence otherwise. Scope the recommendation to
+supported configurations and retain a needed fallback elsewhere.
+
+An uncertain benefit can justify a small reversible trial, not an assertion of safe
+permanent removal. Reuse existing results; propose a comparison only when it can
+resolve a material decision. Distinguish proposal, authorized trial, and adoption.
+[Apply](apply.md) governs trial authority and recovery; [Verification](verification.md)
+governs evidence of improvement. A model update is a reason to reconsider relevant
+workarounds during requested review, not an automatic full-audit trigger.
 
 ## Rationale and history
 
-Find long decision rationales, incident narratives, alternatives, revision logs,
-and repeated explanations in anchors, rules, skill instructions, descriptions,
-and menus. Keep the current instruction, applicability, necessary exceptions, and
-only the brief reason required to apply it correctly. Menus need a label and trigger,
-not a decision history. Do not remove rationale that carries an operational condition.
+Locate long rationales, incident narratives, alternatives, revision logs, and repeated
+explanations in anchors, rules, skill text, descriptions, and menus. Keep current
+actions, applicability, necessary exceptions, and the brief reason needed for correct
+use. Menu entries need a label and trigger; decision history belongs on demand.
 
-Propose an existing decision record or a focused on-demand reference as destination.
-Preserve source evidence, known dates, and supersession status without fabricating
-history. Create or confirm the destination before removing the source text.
+Use an existing decision record or focused reference. Preserve evidence, known dates,
+and supersession status. Create or confirm the destination before removing source
+text. Retain rationale that contains an operational condition.
 
-Use a normal link, not @import or another automatic-loading mechanism. Check whether
-the target lives under an always-loaded rule glob or another auto-loaded surface;
-merely moving it does not remove it from context. Keep the reference usable in the
-installed package, not only the author's repository. Link only where useful; do not
-replace deleted history with a sprawling reference menu or require all references
-on every run. Sensitive incident details need restricted existing records, not copies
-into a distributable skill package.
+Use an ordinary link to a destination outside automatically loaded surfaces; account
+for imports, rule globs, and client behavior. Keep links usable in the installed
+package. Link at the point of need instead of replacing history with a large menu.
+Sensitive incident details stay in restricted records, with access-appropriate
+references rather than copies in distributable assets.
 
 ## Testing and delegation
 
-Use the verification reference for user scenes, implementation slices, check
-selection, reuse conditions, and higher-model delegation. In a full audit, assess
-this concern even when no excessive testing is found. This is guidance review,
-not authorization to implement product code or run the product's test suites.
+Use the verification reference to assess user outcomes, implementation slices, check
+selection, evidence reuse, and suitable execution routes. A full audit assesses this
+concern even when current guidance is sufficient. Evaluate the evidence and total
+burden of the proposed method rather than enforcing one workflow. This is guidance
+review, not authorization to implement product code or run product test suites.
 
 ## Report and stop
 
-No fixed minimum or maximum finding count applies. Keep all material supported
-findings in scope, merge common root causes while retaining every affected path,
-and avoid cosmetic nits with no behavioral consequence. Prioritize protection /
-wrong-intent conflicts, blocked delivery and repeated work, then context overhead;
-state expected benefit qualitatively unless a measurement supports a number.
-
-Give a compact summary followed by records sufficient to implement the changes.
-For each record include:
-
-- **ID, category, consequence, and recommended action.**
-- **Evidence:** path + section or line, exact relevant originals (both for conflict),
-  problematic usage/task situation, and observed fact versus inferred impact.
-- **Patch:** replacement wording or diff, affected dependents / destination, retained
-  safeguard, uncertainty, and the approval or integration boundary if any.
-
-Keep repeated fields compact; don't force a giant table. For tests include the
-scenario-to-check mapping; for retirement include replacement coverage; for history
-include the destination and loading condition. Do not quote secrets. Report each
-requested concern as findings, no issue in inspected material, or not assessed.
-
-A short requested summary does not authorize discarding findings. Retain a complete
-finding index and distinguish omitted detail or uninspected scope. If delivery limits
-prevent full details, say exactly which IDs lack detail; do not declare those complete.
-Write a report file only when requested or otherwise explicitly authorized.
-
-In read-only mode, end at proposals. For authorized application, use the apply
-reference and reuse these findings. Stop when scoped evidence supports the findings
-or identifies the remaining uncertainty; do not keep searching to manufacture issues.
+Retain all material supported findings in scope, with no count target or cutoff.
+Merge common root causes while preserving affected paths. Prioritize protection or
+wrong-intent conflicts, blocked delivery and repeated work, then context overhead.
+Include a missing enabler when its absence materially affects the task.
+
+Start with a compact summary. Scale each record to its consequence and uncertainty:
+
+- For a straightforward change, an **ID, location with its relevant original, the
+  problem it causes, and replacement wording or diff** are enough.
+- For conflicts, removals, trials, or consequential changes, add the information
+  needed to decide: the other original, affected dependents, replacement coverage,
+  retained safeguard, uncertainty, and approval / integration boundary.
+
+Explain common conditions once. Separate observed facts from inferred benefits;
+use qualitative impact unless measurements support a number. Show verification
+mapping when relevant, a retirement's replacement coverage, and a history move's
+destination/loading behavior. Keep secrets out of quoted evidence.
+
+Report each requested concern as findings, no issue in inspected material, or not
+assessed. A short summary can use a compact complete finding index, with detail
+allocated to material decisions. Identify omitted detail and uninspected scope
+instead of implying completeness. Write a report file only with authorization.
+
+A read-only audit ends at proposals. Authorized application reuses findings through
+the apply reference. Finish when scoped evidence supports a decision or identifies
+the remaining uncertainty; further search should serve an unresolved material issue.

package/templates/skills/audit-harness-fit/references/populate.md

@@ -1,74 +1,78 @@
 # Populate or Refresh Project Context
 
 Fill existing AGENTS.md / CLAUDE.md project context from current repository evidence.
-Keep its structure and language. Do not turn filling a scaffold into a full skill
-audit, a new documentation system, or authorization to modify application code.
+Keep its structure and language. Make confirmed goals, commands, boundaries, and
+verification resources usable for autonomous decisions. Filling a scaffold is a
+bounded context edit, not a full skill audit or a new documentation system.
 
 ## Locate editable context
 
 Read the target, relevant imports, fill markers, policy, and worktree changes.
 Distinguish project-owned sections from shared principles, inline rules, generated
 content, and managed blocks. Names alone do not define ownership: AGENTS.md may
-contain both context and principles; CLAUDE.md may import a separate anchor.
+contain context and principles; CLAUDE.md may import a separate anchor.
 
-For "fill", complete unresolved context sections only. For "refresh/update", update
-supported stale project context too, preserving still-valid user content. Report
-unrelated stale guidance instead of changing it. An explicit fill/update request
-permits these bounded edits where policy allows; a preview request remains read-only.
-Do not require another approval for the same permitted edit.
+For "fill", complete unresolved context sections. For "refresh/update", also update
+supported stale project context while preserving still-valid user content. Report
+unrelated stale guidance separately. An explicit fill/update request permits these
+bounded edits where policy allows; a preview stays read-only. Reuse that authority
+rather than asking again for the same permitted edit.
 
-When both files are requested, reconcile their shared project facts while preserving
-client-specific syntax, boundaries, and imports. Do not copy the complete file over
-the other, create a new cross-client import convention, or modify managed principles.
-If only one file is requested, report any conflicting other copy without silently
-expanding the edit. No file or no recognizable editable section: propose placement
-and draft content; create/restructure only when the request and policy authorize it.
+When both files are requested, align shared project facts while retaining client
+syntax, boundaries, and imports. Edit their relevant sections rather than copying
+one file wholesale or introducing a cross-client import convention. When only one
+file is requested, report conflicting copies outside scope. If no recognizable
+editable section exists, propose placement and content; create or restructure only
+within the request's authority and project policy.
 
 ## Ground the existing sections
 
 | Existing section, or equivalent | Fill from evidence |
 |---|---|
-| Identity & Purpose | README, package description, accepted product decisions; project, users, core usage scene, and observable result. Do not describe the harness unless it is the project. |
-| Stack & Commands | Manifests, lockfiles, runtime/configuration and scripts; useful exact commands, working directory and prerequisites. A selected installation track is not proof of stack. |
-| Architecture & Layout | Main boundaries, entry points, data flow and non-obvious locations; link to detail instead of copying a tree or file-by-file catalog. |
-| Installed Harness Assets | Confirm installed files; retain useful project-specific routing/exceptions and a valid inventory reference. Do not duplicate every description or claim loaded from presence. |
-| Boundaries | Explicit project policy and references to shared controls. Distinguish documented policy from observed enforcement; CODEOWNERS or .gitignore alone does not create approval rules. |
-| Verification Gate | Required commands, prerequisites and defined thresholds from actual policy/scripts/CI; affected usage outcomes and critical contracts mapped to existing checks and pass conditions. |
+| Identity & Purpose | README, package description, accepted product decisions; actual project, users, core usage scene, and observable result. Describe the harness only when it is the project. |
+| Stack & Commands | Manifests, lockfiles, runtime/configuration and scripts; exact useful commands, working directory and prerequisites. A selected installation track alone does not establish stack. |
+| Architecture & Layout | Main boundaries, entry points, data flow, and non-obvious locations; use maintained references for detail rather than a full file catalog. |
+| Installed Harness Assets | Confirmed installed files, useful project-specific routing/exceptions, and a maintained inventory reference; distinguish presence from loading. |
+| Boundaries | Explicit project policy and references to shared controls; distinguish documented policy from observed enforcement. CODEOWNERS or .gitignore alone does not establish approval rules. |
+| Verification Gate | Required commands, prerequisites and defined thresholds from policy/scripts/CI; affected outcomes and critical contracts mapped to existing checks and pass conditions. |
 
 Use equivalent headings when the scaffold differs. Keep the verification mapping
-compact; reference the maintained test plan for detail. Distinguish required gates,
-optional checks, and genuine coverage gaps. Preserve established model-review routing
-only where documented/configured. Put new testing or higher-model delegation ideas
-in the proposal, not into the file as already accepted policy. The verification
-reference is available for substantive advice, not required for copying an exact
-existing test command.
+compact and link to a maintained plan for detail. Distinguish required gates, optional
+checks, and genuine coverage gaps. Preserve documented model/tool routing. Put new
+testing or routing ideas in proposals rather than recording them as accepted policy.
+The verification reference is useful for substantive advice, not a prerequisite for
+copying an exact existing command.
 
-Separate **intended**, **implemented**, and **verified** when they differ. An accepted
-usage change is not an implemented feature. Leave unsupported goals, commands,
-thresholds, and unresolved A-to-B decisions explicit rather than guessing. Complete
-independent sections; mark not applicable only when evidence supports it.
+Prioritize facts that remove consequential uncertainty: where to work, which contract
+matters, what success means, and which existing tool or check can establish it. Keep
+implementation and verification methods flexible unless actual policy requires them.
+Add such context only in the authorized sections and from supported sources.
 
-Keep current actionable context in the scaffold. Link to maintained long rationale
-and history on demand, never through an automatic import. Move existing content
-only within authorized update/relocation scope. An old FILL prompt is not permission
-to invent policies, catalog every file, or claim one command proves all work safe;
-report a conflicting instruction and use confirmed project evidence.
+Separate **intended**, **implemented**, and **verified** when they differ. Accepted
+usage changes can remain unimplemented. Leave unsupported goals, commands, thresholds,
+and unresolved A-to-B choices explicit. Complete independent sections and use "not
+applicable" only when evidence supports it.
+
+Keep current actionable context in the scaffold. Reference long rationale and history
+on demand instead of automatic imports. Move existing content only within authorized
+relocation scope. Treat old FILL prompts as scaffolding, not evidence for an invented
+policy, feature, or success claim; report conflicts and use confirmed project evidence.
 
 ## Check the bounded edit
 
-Record a compact section-to-source mapping in the report, not a verbose evidence
-ledger inside the active file. Finding a command proves it is defined, not that it
-passes. Do not install dependencies, run deployments, access production, or execute
-state-changing commands merely to fill text. Obey actual required check gates and
-report anything not run.
+Give a compact section-to-source mapping in the report rather than an evidence ledger
+in the active file. Finding a command establishes its definition, not successful
+execution. Filling context authorizes bounded prose edits, not dependency installation,
+state-changing product commands, production access, or deployment. Complete applicable
+required checks and identify anything not run.
 
-Remove a section's fill marker only when resolved. Keep unresolved markers and a
-partial-scaffold notice while any sections remain uncertain. Remove or update the
-scaffold-only notice when all sections are resolved; preserve unrelated banners,
-managed markers, and imports. Completing the prose does not verify the application.
+Remove a section's fill marker when resolved. Retain unresolved markers and a partial
+scaffold notice while gaps remain. Update or remove only the scaffold notice when all
+sections are resolved; preserve unrelated banners, managed markers, and imports.
+Completing the prose does not verify the application.
 
-Check that the diff stays within authorized sections, paths/links/commands match
-sources, and shared facts agree across requested files. Report completed sections,
-remaining gaps, preserved content, and actual checks. With unchanged evidence,
-repeating the fill should not rewrite valid content, duplicate sections, or re-add
-removed placeholders. Do not rerun a broad audit just to establish this property.
+Check the diff's authorized sections, source-consistent paths/links/commands, and shared
+facts across requested files. Report completed sections, remaining gaps, preserved
+content, and actual checks. With unchanged evidence, another fill should leave valid
+text and resolved placeholders unchanged. Establish this from the bounded edit rather
+than rerunning a broad audit.