agent-guidance

Agent Guidance

This skill handles "whether Agent guidance is the correct expression and carrier": turning tasks, methods, or collaborative relationships that already have source boundaries into guidance that an Agent can discover, understand, act on, report failure on, and hand results back through. Skills and prompts are only two kinds of carrier among them; it does not manufacture reliability by piling up templates, fields, or process length.

First distinguish three objects:method is a reusable judgment or action relationship;guidance carrier is the task expression, handoff, project instruction,SKILL.md, reference, or focus anchor that carries it;activation is the process by which a given task actually discovers, loads, and uses guidance. A prompt is the expression carrier for one task or delegation; the harness is the receiving environment; only the runtime/base owns permissions, tool capabilities, transactions, concurrency, recovery, persistence, and non-bypassable effect boundaries.

When to use

Creating, reviewing, splitting, merging, downgrading, or deleting task prompts, handoffs,AGENTS.md instructions, skills, references, or focus anchors.
A judgment/action gap for some Agent keeps recurring, and it needs to be determined whether to fix the task expression, project instruction, skill, tool, or runtime.
Instructions are getting longer and longer, skills overlap, triggers are unclear, or context is starting to be filled with irrelevant material.
An accepted method needs to be written up as an independently handoff-able Agent task or method material.
Designing or reviewing information layering, in-place help, history browsing, or tool-result expansion entry points in Agent context assembly.

Concept definitions, human-facing articles, delegation topologies, tool implementations, and runtime hard guarantees go to the corresponding adjacent owners; do not force the creation of a skill file just to use this skill. If the main problem is residual cleanup of code/design/directories, use defrag; for UI aesthetics use interface-design; for on-site evaluation of Agent behavior use the evaluation method provided by the current task environment; for personality-difference design use agent-personality. This skill only owns judgments about instruction carriers and method expression. If the method itself still needs to be developed from theory, existing practice, and experimental feedback, use skill-incubator. It designs the core method and workflow and iterates based on evidence; this method continues to be responsible for carrier validity, expression, and activation. Local edits to an already-determined method do not need incubation first.

If the problem is how an entire set of skills, roles, or project units should divide labor, cover tasks, and evolve together, use architecture to organize an overall review. This method continues to be responsible for judgments about the validity, expression, discovery, and activation of each guidance carrier; the overall review brings in goals, environment, nearest-neighbor conflicts, and existing evidence, and reuses local results. Modifying a single skill does not require doing system architecture first, and links do not require recursive loading.

Main flow

Recover the real pressure. Find the Agent, environment, behavior object, observed gap, repetitiveness, positive and negative triggers, nearest-neighbor owner, and the next unknown that would change the judgment. Do not start from a filename specified by the user or from "a skill must be produced."
Choose the smallest real carrier. Compare the current task expression, project-local instructions, ordinary documents, references, skills, projections, tools, and runtime. Propose a skill only when a method that can be selectively loaded recurs in relevant tasks, can change behavior through expression, has observable boundaries, and whose benefit exceeds the context and maintenance cost.
Write it as actionable expression. Preserve the object and goal, source status, receiving context, allowed effects, judgment and acceptance, unknowns and failures, and return relationships. Distinguish facts, instructions, candidates, references, and unknowns; do not write wishes as permissions or as current state.
Organize the loading surface. description states only the triggers and important exclusions; the root SKILL.md does minimal routing; put only conditional branch details into on-demand references. Do not stuff theory, research records, whole-repo background, or a second authoritative source into ordinary activation.
Verify actual activation. Report format passing, post-activation behavior, boundary support, matching improvement, and regression evidence separately; without a baseline, counterexamples, or repeated observation, keep it unknown, and do not present file existence or one success as proof of effect.

Read on demand

To judge whether something is worth recording as a skill or other persistent guidance, and how to split/merge/downgrade it: read formation.md。
To write or compress agent-facing tasks, handoffs, skill bodies, or focus anchors: read composition.md。
To organize context content, state, and operation hints, or to design progressive disclosure: read context-interface.md。
To diagnose carrier hierarchy, overlap, conflict, and context burden: read review.md。
To design behavior probes or report evidence strength: read evaluation.md。

Read only the references that would change the current judgment or action. Theory and research are the generative source of this skill, not prerequisite reading for ordinary activation; task facts still return to the task's own canonical source.

Invariants

prompt、skill、AGENTS.md or a reference does not gain tools, permissions, atomicity, persistent identity, concurrency, recovery, publication, or final acceptance through text alone; these relationships are owned by tools, the runtime, the project owner, or the acceptor.
File format passing, a skill being loaded, and an agent claiming to understand and producing an artifact each cannot substitute for behavior observation, semantic judgment, and final acceptance, respectively.
Preserve load-bearing semantics that would change object identity, source status, scope, judgment path, allowed effects, failure handling, return, or acceptance rights; compress only repetition, courtesy preambles, uninformative summaries, and background that would not change the next step.
Do not prescribe a fixed tool order, number of questions, number of candidates, or mandatory stages; the method should state conditions and reasons for shifting, not be written as a script.
Do not create a second source of facts, plans, evaluation ledgers, or a permanent coordinator; derived views retain the canonical source and update relationships.
Within authorized scope, proceed directly with reversible carrier edits, reference fixes, and local checks; only when changing goals, owners, public contracts, permissions, or irreversible effects should you pause the affected branch and request a decision.

Delivery

Return a compact record that lets the caller reconstruct the decision:

对象与真实压力：<Agent 在什么环境中反复缺什么判断/行动>
载体决定：<直接表达 / 局部指令 / 文档 / reference / skill / 工具 / runtime / no-proposal>
主要方法：<希望改变的判断、正负触发和最近邻 owner>
实际改动：<正文、description、路由或引用如何变化>
验证与未知：<机械结果、行为观察、边界/回归证据、尚未确认的关系>

Done means the carrier choice is justified, the expression can be acted on independently, references and authority relationships are closed, and the report reaches only the strength the current evidence supports. If the user asks for implementation, activation, and repair, continue to re-verify on the same observation and do not stop at a first draft or a first mechanical check passing; merely writing a nice prompt or skill draft does not count as behavior verification.