@hassangameryt/freeflow 0.6.0 → 0.7.0

package/skills/write-skill/SKILL.md

@@ -5,96 +5,236 @@ description: Use when creating or revising an agent skill.
 
 # Write Skill
 
-Write the smallest agent-first skill that changes one named behavior.
+Write the smallest agent-first skill package that changes one coherent behavioral policy.
 
-## Establish The First Read
+A skill is a prompt intervention, not merely a document. A host may read its body once and retain it across later messages and tool interactions until context projection or loss. Design the first useful read, retained influence, dependencies, and recovery paths; do not assume the body will be reread before every use.
+
+Smallest means behaviorally minimal—not shortest. A detailed skill is justified when each instruction changes action or judgment, makes a dependency executable, protects a behavioral boundary whose failure is supported by evidence, or establishes an evidence, return, or stop condition.
+
+## Establish The Behavioral Claim
 
 Before writing, identify:
 
-- the behavior and failure the skill must change;
-- the earliest natural prompt or situation where its guidance becomes useful;
-- the cues an agent can observe before reading the body;
-- the context guaranteed to be loaded before this skill;
-- a nearby case that should not be hijacked.
+- the behavior the skill should produce;
+- the failure or misclassification it must prevent;
+- the earliest decision where its guidance can change the trajectory;
+- cues visible before the body is read;
+- context guaranteed across every valid activation path;
+- a nearby case that should not be hijacked;
+- how the skill should stop influencing behavior after its method no longer applies;
+- the evidence that could support or contradict the intended effect.
 
-A description cannot rely on terminology or classifications taught only inside the skill. The body must work for an agent reading it for the first time with only declared guaranteed context.
+Do not begin with sections, wording, examples, or file layout. Begin with the behavioral intervention.
 
-If public behavior, dependencies, safety, or compatibility remain unsettled, stop and resolve that boundary before encoding it.
+If accepted behavior, public dependencies, safety, compatibility, or another user-owned boundary remains unsettled, stop and resolve it before encoding a runtime rule.
 
-## Preserve Before Substantial Revision
+## Preserve The Exact Baseline
 
-Before rewriting or substantially editing an existing skill, snapshot the complete current package—`SKILL.md`, references, scripts, and other owned resources—and record an exact identity. Use a recoverable Git ref or task evidence outside the active package so the rewrite cannot replace its own baseline.
+Before substantially revising an existing skill, preserve the complete current package:
 
-A small local wording correction does not need an extra snapshot when the exact prior state is already recoverable and the change does not alter behavior, dependencies, or package structure.
+- `SKILL.md`;
+- references;
+- scripts;
+- assets and other owned resources;
+- exact package identity.
 
-## Write The Description
+Use a recoverable Git ref or task evidence outside the active package so the revision cannot replace its own baseline.
 
-Optimize for the first useful read, not repeated reads.
+A small local correction does not require another snapshot when the exact previous state is already recoverable and the change does not alter behavior, activation, dependencies, resource structure, or compatibility.
 
-- State the broad core job in plain language.
-- Use cues observable in the user request or immediate task state.
-- Prefer broad recall when loading the skill is safe and the body can exit cleanly.
-- Do not require the agent to predict an internal classification taught only after activation.
-- Do not turn the description into an exhaustive trigger taxonomy or compressed summary of the body.
-- Treat “Use when…” as useful advice, not required grammar.
+Preserving a baseline supports recovery and comparison. It does not prove that the baseline or candidate behaves correctly.
+
+## Design The First Read
+
+A skill cannot activate itself. Its first read must be caused by context already available to the agent:
+
+- an observable skill description;
+- guaranteed base or system guidance;
+- an already-loaded owner or sibling;
+- an effective capability cue;
+- another declared upstream route.
+
+Do not rely on an instruction inside the unread skill to cause that skill to be read.
+
+Optimize activation for the earliest useful decision. Missing that decision may be much more harmful than a harmless early read.
+
+A nearby case can pass by:
+
+- not loading the skill; or
+- loading it safely, recognizing that its method does not apply, and exiting without later hijacking retained behavior.
+
+False-positive activation is cheap only when the body remains safe after retention. A skill that exits on the first turn but continues distorting later work is not a safe read.
+
+Read [Activation Boundaries](references/activation-boundaries.md) when activation is unclear or evidence shows missed, late, early, task-hijacking, or retained-interference behavior.
+
+## Write The Description For Recall
+
+Treat the description as a routing interface, not a summary of the body.
 
-A nearby case may pass by not loading the skill or by loading it and exiting without changing the task incorrectly. Do not narrow a description solely to prevent harmless reads, and do not broaden it until the skill routinely overrides the actual owning job.
+- State the broad core job in plain language.
+- Use natural user verbs or task conditions visible before activation.
+- Prefer recall when nearby reads are safe and missed activation is materially worse.
+- Do not require terminology or classifications introduced only inside the skill or an optional dependency.
+- Do not encode future-duration guesses, named internal phases, exhaustive trigger catalogs, or marketing claims.
+- Do not compress the body into the description.
+- Treat “Use when…” as useful wording, not mandatory grammar.
 
-Read [activation boundaries](references/activation-boundaries.md) when the boundary is unclear or evidence shows missed, late, early, or task-hijacking activation.
+Optimize for the first useful read, not repeated reads. Do not narrow a description solely to prevent harmless activation. Do not broaden it when retained guidance routinely overrides another owner or method.
 
 ## Write For The Executing Agent
 
-1. Establish the skill’s job immediately.
-2. Define necessary terms before relying on them.
-3. Put rules where the agent first makes the affected choice.
-4. Keep the normal route understandable from `SKILL.md`; when it requires another resource, name that dependency and its read condition before relying on it.
-5. Say what to do, what not to do, and when to stop, exit, or route.
-6. Lead with required behavior. Use a negative instruction only to block a plausible or observed failure, and pair it with the positive action, exit, or route.
-7. Use direct instructions that change action or judgment.
-8. Include why only when it helps the agent generalize, choose correctly in an unseen case, or avoid a harmful literal reading.
-9. Repeat a shared rule only when a local reminder prevents a real failure; do not copy the owning workflow.
-10. Keep authoring status, evaluation summaries, evidence gaps, changelog notes, and readiness prose out of the executing skill.
+Write for an agent seeing the skill for the first time with only guaranteed context.
+
+1. Establish the job immediately.
+2. Define necessary terms before using them.
+3. Put each rule where the agent first makes the affected choice.
+4. Keep the normal route understandable from `SKILL.md`.
+5. State what to do, what not to do, and when to stop, return, or route.
+6. Prefer a positive route; use negative instructions to block plausible or observed failure.
+7. Pair a negative rule with the correct action or owner whenever possible.
+8. State why only when it helps the agent generalize or avoid a harmful literal reading.
+9. Keep the skill focused on one coherent job. Do not copy the surrounding workflow’s authority, routing, continuity, review, or completion method into a focused skill; repeat only the local guard needed at the affected choice.
+10. Keep authoring status, evaluation summaries, evidence gaps, changelog notes, and readiness prose out of the executing package.
 
-Use discussion, research, and author reasoning to understand the target behavior. Do not copy conversation history, author debate, iteration notes, rejected drafts, or explanation written for collaborators into the skill. Translate that context into only the instructions, definitions, boundaries, and examples a first-time executing agent needs.
+A useful rule normally identifies:
 
-A skill may rely on guaranteed base context. Do not assume an optional sibling skill, reference, or accidental earlier read. Link dependencies and state when to read them.
+```text
+observable pressure
+-> required or forbidden action
+-> evidence, return, or stop condition
+```
 
-Read [agent-first instructions](references/agent-first-instructions.md) when wording, placement, undeclared context, or author explanation is obscuring execution.
+Use discussion, research, and author reasoning to understand the behavior. Compile that understanding into runtime instructions. Do not copy conversation history, rejected drafts, author debate, fixture narration, or explanation whose only reader is the author.
+
+A skill may rely on guaranteed base context and dependencies explicitly required before use. It may not rely on an unread optional sibling or reference, a common-but-unguaranteed route, or an accidental earlier read.
+
+Read [Agent-First Instructions](references/agent-first-instructions.md) when a concrete first-read or retained-use failure involves wording, placement, undeclared context, author explanation, or competing instructions.
 
 ## Use Examples Deliberately
 
-Add a compact behavioral example when prose alone leaves a likely misclassification. Show the observable situation and the required action, stop, exit, or route.
+Add a compact example when prose alone leaves a likely behavioral misclassification.
+
+Show:
+
+- the observable situation;
+- the required action or judgment;
+- the relevant stop, exit, or return.
+
+Keep examples transferable. Do not turn the body into a transcript, fixture library, or scenario catalog.
+
+Inline examples teach the subject and are part of the candidate intervention. They are not independent evidence that the skill works.
+
+## Plan Terminology And Dependencies
+
+For one self-contained skill, declare only the dependencies its normal and conditional routes need.
+
+Before creating or revising multiple related skills, shared terminology, cross-skill links, capability activation, direct or routed entry paths, or context-loss recovery, read [Skill Dependency Graphs](references/skill-dependency-graphs.md).
+
+For every skill:
 
-Keep examples general enough to transfer beyond one fixture. Do not turn the body into a transcript, test suite, or scenario catalog. Inline examples teach; behavioral evals test whether the skill changes behavior under pressure.
+- identify every valid direct and routed activation path;
+- rely only on context guaranteed across all valid paths;
+- place shared vocabulary in the nearest upstream context guaranteed before every consumer;
+- keep leaf-specific terms local;
+- distinguish owner routes, method composition, environment interactions, references, capability cues, and retained context;
+- ensure critical skills have an upstream activation or recovery edge;
+- do not assume a commonly preceding skill is guaranteed.
 
-## Add Resources Only When Needed
+A Markdown link declares a package dependency. It does not automatically select the target owner or execute the linked skill.
 
-Before adding or reorganizing references and scripts, read [progressive disclosure](references/progressive-disclosure.md) to classify each read as entry-required, activity-required, or conditional. References do not activate independently: `SKILL.md` directs each read at its first useful point, and required means necessary rather than recommended.
+## Compact Without Erasing Behavior
 
-Start with one `SKILL.md`. Remove repeated prose and low-value checklists before expanding the file set.
+Compact after the behavioral policy, dependencies, and failure boundaries are understood.
 
-- Add a required reference when normal execution genuinely needs separately owned depth; state whether it is read at entry or before its normal activity.
-- Add a conditional reference when a distinct branch needs depth that would obscure the normal route; state the observable condition for reading it.
-- Add a script for repeated deterministic work or a feature the skill owns when automation is safer, clearer, or materially less wasteful than retyping it.
-- Make the body instruction and reference introduction name the same read condition; neither may silently narrow or widen it.
-- Link every agent-facing reference, asset, declared dependency, and executable entrypoint from `SKILL.md`; internal implementation modules need not be linked.
-- Keep owned resources inside the skill package unless a declared package dependency is required.
-- Treat unlinked-file inspection as factual inventory, not an automatic defect.
-- Do not add resources merely to make the package look complete.
+For each instruction, ask:
 
-There is no universal body template, section inventory, wording rule, file-count target, or requirement that a script follow an earlier failure.
+> Can this be removed without losing required behavior, introducing ambiguity, obscuring a dependency, or reintroducing a previously observed failure?
+
+If yes, remove or merge it. If uncertain, preserve it until evidence distinguishes the variants.
+
+Do not compact by:
+
+- deleting the positive route while retaining only prohibitions;
+- moving normal required behavior into an always-read reference;
+- merging rules whose triggers or stop conditions differ;
+- replacing a concrete instruction with generic quality language;
+- removing terminology required by a direct activation path;
+- deleting repetition that protects a distinct decision or recovery boundary.
+
+Length is a diagnostic fact, not a quality verdict. A long skill may be minimal. A short skill may force the agent to reconstruct missing judgment through reasoning or environment interactions.
+
+## Repeat Rules Deliberately
+
+Repetition is justified when local presence protects:
+
+- an independently activated skill;
+- a distinct decision point;
+- a context-loss or host path;
+- a dangerous literal interpretation;
+- a previously observed failure;
+- a required body-to-reference read condition.
+
+Use one canonical owner for the full definition or method. Repeat only the compact local guard needed at the affected choice.
+
+> Repeat the behavioral invariant, not the owning skill’s entire explanation.
+
+Do not repeat rules merely for emphasis, author reassurance, or stylistic consistency. Check that repeated wording preserves the same meaning and route.
+
+When removing, merging, moving, or rewording a rule that protects measured behavior, treat the candidate as a behavioral change and evaluate the affected boundary.
+
+## Add Resources Only When They Change Loading Or Ownership
+
+Before adding or reorganizing references, assets, or scripts, read [Progressive Disclosure](references/progressive-disclosure.md).
+
+Start with one `SKILL.md`. Remove accidental complexity before splitting files.
+
+- Keep normal first-read behavior inline.
+- Add an activity-required reference when one named normal activity genuinely needs separately owned depth but the skill may exit before that activity.
+- Add a conditional reference when an observable branch requires depth that would obscure the normal route.
+- Use an entry-required reference only when separation has independent value, such as canonical reuse, separate ownership or lifecycle, generated contracts, compatibility, or host constraints.
+- Inline entry-required content when every useful activation reads it and separation provides no distinct value.
+- Add a script when deterministic repeated work owned by the skill is safer, clearer, or materially less wasteful than model-generated operations.
+- Link every agent-facing resource, package dependency, and executable entrypoint from the body at its first useful decision.
+- Keep owned resources inside the package unless canonical cross-package ownership is required.
+
+The body and reference must name the same read condition. A reference cannot activate itself.
+
+There is no universal body template, line limit, reference count, or requirement that a script follow an earlier failure.
 
 ## Evaluate The Behavioral Claim
 
-Static validation proves structure, not activation or behavior. Name the exact claim being tested: description activation, first-read body behavior, nearby behavior, dependency composition, retained use, or artifact outcome.
+Static inspection and package validation prove structure, not behavior.
+
+Name the exact claim being tested:
+
+- description activation;
+- first-read body behavior;
+- nearby behavior;
+- dependency composition;
+- retained use;
+- artifact outcome;
+- cross-host behavior.
+
+Use [Evaluate Skill](../evaluate-skill/SKILL.md) to compare exact baseline and candidate environments under fixed declared inputs.
+
+Preserve adequate existing evidence. Revise one measured pressure point at a time. After a behavior-sensitive change, rerun the complete fixed group with both variants.
 
-Use [Evaluate Skill](../evaluate-skill/SKILL.md) to compare exact baseline and candidate environments under fixed declared inputs. Preserve adequate existing evidence, revise one measured pressure point at a time, and rerun the complete fixed group after a behavioral change.
+Do not claim:
 
-Do not claim activation from body injection, retained use from one turn, or dependency behavior from ambient context. Keep behavior conclusions and missing evidence in the owning evaluation, Working Record, or delivery response rather than annotating the executing skill.
+- activation from explicit body injection;
+- retained use from one turn;
+- dependency behavior from ambient context;
+- unchanged behavior from prose review;
+- improvement from structural validation;
+- readiness from one favorable example.
+
+Small wording, ordering, vocabulary, repetition, and structural changes may alter model behavior. Human review can establish intended meaning; behavioral evidence establishes observed effect.
+
+Keep evaluation conclusions and missing evidence in the evaluation artifact, task record, or delivery report—not in the executing skill.
 
 ## Check The Package
 
-Use the bundled [skill author](scripts/skill-author.mjs) for deterministic structure work:
+Use the bundled [skill author](scripts/skill-author.mjs) for deterministic package work:
 
 ```text
 node <write-skill-directory>/scripts/skill-author.mjs init <directory> --name <name> --description <text>
@@ -102,19 +242,35 @@ node <write-skill-directory>/scripts/skill-author.mjs validate <directory> [--pa
 node <write-skill-directory>/scripts/skill-author.mjs inspect <directory> [--package-root <directory>]
 ```
 
-Choose the command by job:
+Choose the operation by its evidence:
+
+- `init`: create a new minimal package; never overwrite an existing one.
+- `validate`: check frontmatter, heading shape, recursive links, declared package dependencies, and containment.
+- `inspect`: report body sizes, resource classes, scripts, unlinked files, and validation findings.
+
+Run `validate` after structural or dependency changes and before claiming package validity. Use `inspect` when factual inventory or package composition matters.
 
-- `init`: use only for a new package. It creates the directory and minimal `SKILL.md` and refuses to overwrite an existing one.
-- `validate`: use after structural or resource changes and before claiming structural validity. It checks frontmatter, the top-level heading, recursive links, package dependencies, cycles, and containment.
-- `inspect`: use when body sizes, resource classes, scripts, unlinked files, and validation findings are needed. It reports facts rather than quality.
+Commands emit JSON. Invalid structure still emits a report and exits nonzero; command errors emit structured error JSON.
 
-Commands emit JSON. Invalid structure still emits its report and exits nonzero; command errors emit structured error JSON.
+Package root defaults to the nearest `package.json` ancestor, then the skill directory’s parent. Use `--package-root` when validating a candidate in an overlay or another package context.
 
-- Package root defaults to the nearest `package.json` ancestor, falling back to the skill directory’s parent. Use `--package-root` to set it explicitly.
-- Frontmatter accepts flat plain strings or JSON-compatible double-quoted strings. Double-quote values when there is any ambiguity, especially punctuation, numbers, booleans, or null-like text.
+Frontmatter accepts flat plain strings or JSON-compatible double-quoted strings. Quote ambiguous punctuation, number-like, boolean-like, or null-like values.
 
-Never import or invoke deprecated tooling.
+Package validity does not prove behavioral quality. Never use deprecated authoring tooling.
 
 ## Stop
 
-Stop when the requested skill is minimal, executable on first read, honest about its dependencies, and free of author-facing status. Stop and ask when public behavior, activation boundaries, dependencies, safety, or compatibility cannot be settled from evidence. Do not add resources or procedure merely to make the package look complete.
+Stop when the requested package:
+
+- expresses one coherent behavioral policy;
+- activates at the earliest useful boundary;
+- remains safe on nearby and retained use;
+- works from guaranteed context on every valid path;
+- keeps its normal route executable on first read;
+- declares dependencies and resource conditions honestly;
+- contains no unsupported author-facing residue;
+- passes required structural checks.
+
+Stop and ask when accepted behavior, activation, dependencies, safety, compatibility, or another user-owned boundary cannot be settled from evidence.
+
+Do not add sections, references, examples, scripts, or procedure merely to make the package look complete.

package/skills/write-skill/references/activation-boundaries.md

@@ -1,51 +1,79 @@
 # Activation Boundaries
 
-Read this when an activation boundary is unclear or evidence shows missed, late, early, or task-hijacking activation.
+Read this when activation is unclear or evidence shows missed, late, early, task-hijacking, or retained-interference behavior.
 
-A description should make the skill available at the earliest useful moment without requiring language introduced by the skill itself.
+A description should make the skill available at the earliest useful decision without requiring language introduced by the skill itself.
 
 ## Diagnose The First Read
 
 Identify:
 
-- the earliest natural prompt or state where the method can change behavior;
+- the earliest natural prompt or task state where the skill can change behavior;
 - cues visible before the body is read;
 - context guaranteed before activation;
-- the consequence of missing that read;
-- the consequence if a nearby prompt also loads the skill.
+- the consequence of missing or delaying the read;
+- the consequence if a nearby prompt also loads the skill;
+- how retained guidance should behave after the immediate method ends.
 
-Do not optimize for repeated reads. Diagnose the first decision the skill should influence.
+Do not optimize for repeated reads. A body may enter context once and continue influencing later messages and tool interactions until context projection or loss.
+
+## Compare Activation Costs
+
+False-positive and false-negative activation have different costs.
+
+A false-positive read may be acceptable when:
+
+- loading cost is proportionate;
+- the body identifies that its method does not apply;
+- it exits without changing ownership or route;
+- retained instructions do not hijack later work.
+
+A false negative is material when missing the first useful read causes:
+
+- an irreversible or expensive action;
+- a wrong owner or method;
+- repeated low-value environment interactions;
+- missing safety or evidence boundaries;
+- later work that the skill cannot reliably undo.
+
+Prefer recall when nearby reads are demonstrably safe and missed activation is materially worse. Tighten activation when early or retained guidance can distort ordinary work.
 
 ## Check The Cues
 
-Useful cues include the skill’s job, natural user verbs, visible task situations, and distinctions from neighboring jobs.
+Useful cues include:
+
+- the skill’s core job;
+- natural user verbs;
+- visible task situations;
+- observable distinctions from neighboring jobs.
 
 Reject cues that depend on:
 
 - vocabulary defined only in the body or an optional sibling;
 - future-duration guesses;
-- unexplained classifications or named phases;
+- unexplained internal classifications or named phases;
 - generic “help with” or “improve” language;
-- marketing claims or exhaustive trigger catalogs.
+- marketing claims;
+- exhaustive trigger catalogs.
 
 Guaranteed base context may define a term. Otherwise use plain observable language.
 
-## Test Nearby Behavior
+## Test Nearby And Retained Behavior
 
-A nearby case can pass in two ways:
+A nearby case can pass through:
 
-- **Non-trigger:** the skill should not load.
-- **Safe read:** loading is acceptable, but the body exits or defers without applying the wrong method.
+- **Non-trigger:** the skill is not read.
+- **Safe read:** the body loads, exits or defers correctly, and does not interfere later.
 
-Do not narrow a description solely to prevent harmless reads. Do not broaden it until the skill routinely overrides the actual owning job.
+Test both the immediate response and later declared turns when retained influence matters.
 
-## Examples
+Examples:
 
-Broad core trigger:
+Broad useful trigger:
 
 > Use when committing work.
 
-Over-specified trigger that hides the job behind later workflow details:
+Over-specified trigger that hides the job:
 
 > Use after final verification when a planned checkpoint requires a locally reviewable commit.
 
@@ -53,10 +81,24 @@ Broad safe-read trigger:
 
 > Use when working with software design—especially boundaries, interfaces, ownership, state, and failure behavior.
 
-The body can exit when the local interface remains sound; the description need not encode every structural-pressure case.
+The body must exit when the local interface remains sound and avoid turning later local choices into architecture work.
+
+## Preserve The Evidence Boundary
+
+Natural activation proves the host read the exact skill snapshot from a natural prompt.
+
+Explicit body delivery tests first-read instructions, not activation.
+
+Dependency composition tests exact declared skill and context order.
+
+Multi-turn evidence tests retained use.
+
+Artifact and transcript evidence show whether activation helped, exited safely, or hijacked behavior.
 
-## Evidence Boundary
+Preserve:
 
-Natural activation proves the host read the exact skill snapshot from a natural prompt. Explicit body delivery tests first-read instructions, not activation. Composition tests declared dependencies. Multi-turn evidence tests later use. Artifact or transcript evidence shows whether the loaded skill helped or hijacked behavior.
+- the earliest useful positive prompt;
+- at least one close nearby case;
+- later-turn evidence when retained influence is part of the claim.
 
-Preserve the earliest useful positive prompt and at least one close nearby case before making a broad activation claim.
+Do not infer one evidence class from another.

package/skills/write-skill/references/agent-first-instructions.md

@@ -1,6 +1,6 @@
 # Agent-First Instructions
 
-Read this when a concrete first-read failure involves wording, placement, undeclared context, or author explanation.
+Read this when a concrete first-read or retained-use failure involves wording, placement, undeclared context, author explanation, or competing instructions.
 
 ## Reconstruct The Reader’s Context
 
@@ -9,8 +9,9 @@ Assume the agent is seeing the skill for the first time.
 - State the job before local vocabulary.
 - Define terms before relying on them.
 - Assume only guaranteed runtime or declared base context.
-- Do not rely on an optional sibling, reference, or accidental earlier read.
+- Do not rely on an optional sibling, reference, common route, or accidental earlier read.
 - Make required reads explicit before their content is used.
+- Do not assume the skill will be reread before later use.
 
 Dependency direction remains:
 
@@ -29,19 +30,28 @@ Keep a sentence only when it:
 
 - changes an action or judgment;
 - defines required language;
-- protects a likely failure boundary;
-- states an evidence, exit, or stop condition;
-- provides a compact example that resolves a likely misclassification.
+- protects a likely or observed failure boundary;
+- states an evidence, return, or stop condition;
+- makes a dependency executable;
+- provides a compact example resolving likely misclassification.
 
-Translate rationale into a direct rule plus only the why needed to generalize. Translate debate into the selected boundary and stop condition. Omit rejected drafts, conversation history, and explanation whose only audience is the author.
+Translate rationale into a direct rule plus only the why needed to generalize.
+
+Translate debate into the selected boundary and stop condition.
+
+Translate a measured failure into the smallest transferable guard that prevents it.
+
+Omit rejected drafts, conversation history, fixture narration, evaluation status, and explanation whose only audience is the author.
 
 ## Strengthen Rules
 
 A useful rule names:
 
-- the observable trigger or pressure;
-- the required or forbidden action;
-- the evidence, exit, or stop condition.
+```text
+observable trigger or pressure
+-> required or forbidden action
+-> evidence, return, or stop condition
+```
 
 Prefer:
 
@@ -51,37 +61,61 @@ Over:
 
 > Keep evaluation efficient and aligned with best practices.
 
+Concrete rules reduce the judgment the agent must reconstruct.
+
 ## Pair Negative Rules With The Route
 
-```text
 Bad:
-Do not recreate the old worker/verifier architecture.
+
+> Do not recreate the old worker/verifier architecture.
 
 Better:
-The active agent owns implementation and verification.
-Workflow selects optional independent review.
-```
 
-```text
+> The producing activity handles implementation and verification. The surrounding workflow may select independent review.
+
 Bad:
-Do not implement the recommendation.
+
+> Do not implement the recommendation.
 
 Better:
-Return the recommendation to Workflow.
-Implementation requires authorized execution.
-```
 
-A negative rule may preserve an invariant directly:
+> Return the recommendation to the owning workflow. Implementation requires separate authorization.
 
-```text
-Preserve the accepted scope.
-Do not split it into MVP or roadmap phases without approval.
-```
+A negative rule may preserve an invariant directly when the positive route is already clear:
+
+> Preserve the accepted scope. Do not split it into MVP or roadmap phases without approval.
 
 ## Fix Placement Before Adding Prose
 
-Put a rule where the agent first makes the affected choice. A late caveat rarely defeats an early command. Move or sharpen the controlling sentence before adding another section.
+Put a rule where the agent first makes the affected choice.
+
+A late caveat rarely defeats an early command. Move or sharpen the controlling sentence before adding another section.
+
+When an early rule and later exception conflict, restructure the route rather than adding another disclaimer.
+
+## Repeat Local Guards Deliberately
+
+Repeat a shared rule only when local presence protects:
+
+- an independently activated path;
+- a distinct decision point;
+- retained behavior;
+- context-loss recovery;
+- a dangerous literal interpretation;
+- a measured failure.
+
+Keep one canonical owner for the full definition or method. Repeat only the compact local guard needed at the choice.
+
+> Repeat the behavioral invariant, not the owning method.
+
+Do not copy complete orchestration, authority, review, or task-memory sections into every consumer.
+
+## End The Skill’s Influence
+
+A skill body may remain in context after its immediate method ends.
+
+State stop, return, or exit conditions clearly enough that retained instructions do not continue claiming ownership or broadening later work.
 
-Repeat shared policy only where a short local reminder prevents a real failure. Do not copy an owning workflow into a method skill.
+A first-turn exit is insufficient when later turns still show method hijacking.
 
-After editing, rerun the same first-read pressure while keeping unrelated rules stable.
+After editing, rerun the same first-read and retained-use pressure while keeping unrelated rules stable.