@hassangameryt/freeflow 0.7.3 → 0.9.0

package/skills/review-artifact/references/adjudicate-artifact-review.md

@@ -1,101 +0,0 @@
-# Adjudicate Artifact Review
-
-Read this after an independent artifact review returns and before selecting what follows from its report.
-
-Adjudication belongs to the receiving active agent. It tests the report against the artifact, source truth, dependencies, and evidence. It is not independent review and does not inherit the reviewer's authority or judgment.
-
-## Dispose Each Material Item
-
-For every material item, choose one disposition.
-
-### Accepted
-
-State:
-
-- the supported artifact problem;
-- its consequence for the intended use;
-- whether it is Blocking or Non-blocking;
-- whether the revision basis is supported or uncertain;
-- which dependencies or contingent material it affects.
-
-### Rejected
-
-State the concrete reason: unsupported, stale, resolved, duplicate, preference-only, outside the artifact's job, or based on a source or dependency misread.
-
-### Open
-
-State:
-
-- the unresolved content, claim, or dependency concern;
-- its potential consequence for the intended use;
-- the missing evidence or owner decision.
-
-When factual evidence is missing, restate the item as a Verify Work input: load-bearing claim or condition, required observing boundary, available evidence and its limit, and the smallest evidence that could disagree.
-
-A suggested revision may help explain a finding, but it does not settle source intent, select among material alternatives, or authorize revision.
-
-After disposing the items, derive the adjudicated judgment. Do not separately accept the reviewer's overall judgment.
-
-- **Pass:** no accepted Issues or material Open items remain.
-- **Non-blocking:** only accepted Non-blocking Issues remain.
-- **Inconclusive:** a material Open item prevents judgment.
-- **Blocking:** at least one accepted Blocking Issue remains.
-
-## Use Verification Results
-
-Route a known material evidence gap through [Workflow](../../../skills/workflow/SKILL.md) to [Verify Work](../../../skills/verify-work/SKILL.md). Verification produces factual evidence; it does not revise the reviewer's report or determine the review judgment.
-
-- **Supported:** re-adjudicate the evidence gap. Do not infer Pass.
-- **Contradicted:** re-adjudicate against source truth; the result may establish an Issue, invalidate one, or expose a source conflict.
-- **Inconclusive:** keep the item Open. The adjudicated review remains Inconclusive when the gap is material.
-- **Unavailable:** keep the item Open and state why the required boundary cannot currently be observed.
-
-Select focused independent follow-up only when the new evidence still requires judgment from a separate context.
-
-## Decide Whether Revision Is Ready
-
-Revision is ready when:
-
-- the artifact's job and intended use are settled;
-- the artifact problem and consequence are supported;
-- sufficient source or decision basis exists to bound the revision;
-- affected upstream and downstream dependencies are known sufficiently;
-- the revision will not silently alter accepted content or an owner decision;
-- no material alternative or user-owned choice remains.
-
-When revision is ready, state:
-
-- the proposed revision and rationale;
-- affected locations and dependencies;
-- required reconciliation or ordering;
-- evidence or acceptance checks;
-- whether focused independent follow-up remains justified;
-- the authority state.
-
-Use existing revision authority only when it covers that result and dependency impact. Otherwise propose the revision and any warranted follow-up once, then wait. A finding, adjudication, or selected review does not authorize mutation.
-
-Actual revision returns through [Workflow](../../../skills/workflow/SKILL.md) to the artifact's owning skill. Use [Track Work](../../../skills/track-work/SKILL.md) for a Working Record, [Write Spec](../../../skills/write-spec/SKILL.md) for stable content or decision artifacts, [Write Plan](../../../skills/write-plan/SKILL.md) for a Plan, and [Handoff](../../../skills/handoff/SKILL.md) for a Handoff.
-
-Do not revise upstream authority, accepted intent, or owner decisions merely to satisfy a reviewer or obtain Pass.
-
-## Route When Revision Is Not Ready
-
-- unsettled content, strategy, or materially different revisions: [Discuss](../../../skills/discuss/SKILL.md);
-- user-owned choice or source conflict: [Decision Gate](../../../skills/decision-gate/SKILL.md);
-- unsupported or repeated failure cause: [Diagnose Failure](../../../skills/diagnose-failure/SKILL.md);
-- missing factual support: route the named claim through [Workflow](../../../skills/workflow/SKILL.md) to [Verify Work](../../../skills/verify-work/SKILL.md);
-- uncovered revision or dependency update: propose the bounded change and wait.
-
-When findings interact, upstream authority is challenged, dependency effects remain uncertain, or user input could change the revision, report a problem checkpoint and stop before selecting or executing it.
-
-## After Authorized Revision
-
-Re-verify affected load-bearing factual claims at their required observing boundaries. Then re-check source alignment, intended-use fitness, and every affected dependency before performing ordinary self-review with Review Artifact's shared kernel.
-
-Select focused independent follow-up only when accepted revisions, affected dependencies, new evidence, or remaining risk still require judgment from a separate context. Do not dispatch follow-up merely because Review 1 found an Issue or because revision occurred.
-
-If Review 2 remains Blocking, adjudicate it before acting again. Diagnose a repeated, extending, invalidating, or basis-uncertain blocker. Return an independent clear local artifact defect to its owner when diagnosis would add no useful understanding. Review 3 remains exceptional, separately authorized, and final.
-
-## Stop
-
-Stop when every material item is Accepted, Rejected, or Open; the adjudicated judgment is supported; affected dependencies and contingent material are explicit; and the next route and authority state are clear.

package/skills/review-artifact/references/independent-artifact-reviewer-contract.md

@@ -1,159 +0,0 @@
-# Independent Artifact Reviewer Contract
-
-Read this before preparing or performing a separately selected independent review of a durable artifact.
-
-The reviewer did not produce the reviewed artifact state. Give them the complete artifact, source truth, dependencies, and evidence needed to judge it directly. Do not provide only the producer's summary, reasoning, or change description.
-
-## Required Context
-
-Provide:
-
-- artifact path, type, exact reviewed state, and intended use;
-- accepted outcome, requirements, non-goals, and owner decisions;
-- unresolved questions and known evidence gaps;
-- the artifact-specific schema or format contract when one exists;
-- relevant code, tests, policies, ADRs, and established behavior;
-- upstream and downstream artifacts in dependency order;
-- only the review lenses material to the intended use;
-- active evidence authority: none, or each exact covered check with its expected evidence and stop condition;
-- review number and, for follow-up, prior items, adjudication, revisions, and new evidence.
-
-For an artifact package, identify upstream authority and which material remains provisional or contingent.
-
-## Reviewer Prompt
-
-```md
-# Independent Artifact Review
-
-Review an artifact state you did not produce. Inspect the complete artifact, source truth, dependencies, and evidence directly. Report without editing. The review ends with this report; do not adjudicate findings, settle owner decisions, revise anything, dispatch follow-up, or continue merely to obtain Pass.
-
-A pass is valid. Use a high evidence bar, not a high item count. Do not broaden the artifact's job or treat possible improvement as unfinished work.
-
-Use supplied and already available evidence. Do not start a missing active check unless the review contract explicitly authorizes that exact check. Otherwise report **Needs evidence** with the load-bearing claim and required observing boundary. When an exact check is covered, apply Verify Work's check-result and claim-result semantics; active evidence does not authorize revision or broaden the review.
-
-## Artifact And Intended Use
-
-- Artifact: [path]
-- Type: [working record | spec | PRD | issue | API contract | technical design | migration contract | plan | decision record | ADR | handoff | other]
-- Reviewed state: [revision, hash, or other exact identity]
-- Intended use: [decision or future action this artifact must support]
-- Dependency order: [upstream -> downstream, or standalone]
-
-## Accepted Outcome And Non-Goals
-
-- Outcome: [accepted outcome]
-- Requirements: [accepted requirements]
-- Non-goals: [intentional exclusions]
-- Owner decisions: [settled decisions or none]
-- Unresolved questions: [questions or none]
-
-## Source Truth
-
-- [code, tests, policies, ADRs, established behavior, upstream artifacts]
-
-## Evidence And Known Gaps
-
-- Supporting evidence: [evidence or none]
-- Known gaps: [gaps or none]
-
-## Review Scope
-
-- Review number: [1 | 2 | 3]
-- Material lenses: [source alignment | fitness and sufficiency | decision clarity | evidence and acceptance | behavior and failure contract | dependency integrity | scope and minimality | clarity and continuity]
-- Active evidence authority: [none | exact covered check, expected evidence, and stop condition]
-
-For Review 2 or 3:
-
-- Prior items and adjudication: [Accepted | Rejected | Open]
-- Revisions and new evidence: [bounded changes and evidence]
-- Affected dependencies: [dependencies or none]
-- Remaining risk: [narrow unresolved scope]
-
-## Judge The Artifact By Its Job
-
-- **Working Record:** accurate living task memory with recoverable slices and decisions, compact evidence pointers, and one next useful action.
-- **Spec or durable content artifact:** accepted content, behavior, boundaries, evidence, and uncertainty needed for its stated use.
-- **Plan:** an inspectable ordered strategy with scope, dependencies, assumptions, checks, and stop conditions.
-- **Decision record or ADR:** the decision, owner, alternatives, rationale, consequences, and revisit or supersession conditions.
-- **Handoff:** a point-in-time continuation package that preserves what its recipient needs without replacing live task memory.
-- **Other artifact:** its stated purpose without taking over another artifact's job.
-
-Do not require one artifact to perform another artifact's job.
-
-## Check
-
-Apply only the selected lenses:
-
-- the artifact agrees with accepted requirements, owner decisions, and live facts;
-- it contains enough for its intended use without pretending every future question is settled;
-- required, tentative, open, deferred, and superseded information cannot be confused;
-- load-bearing claims and acceptance conditions have suitable supporting or falsifying mechanisms;
-- consequential behavior, failure states, forbidden outcomes, observers, and recovery are explicit where required;
-- upstream and downstream artifacts remain consistent and provisional material is identified honestly;
-- it avoids speculative scope, unnecessary process, and duplicated information owned elsewhere;
-- a future reader can use it without transcript memory or volatile copied context.
-
-Review upstream authority before dependent artifacts. When an upstream problem invalidates downstream assumptions, mark affected material contingent rather than generating exhaustive downstream findings against an unsettled basis.
-
-Before calling something an Issue, ask:
-
-1. Does fitness for the intended use depend on content, source truth, or an owner decision that remains unsettled? If yes, use **Question**.
-2. Does fitness depend on a load-bearing claim or condition that available evidence cannot establish? If yes, use **Needs evidence**.
-3. Is there a supported artifact defect requiring revision for the intended use? Use **Blocking Issue** when the artifact cannot safely guide that use, otherwise **Non-blocking Issue** when revision can be deferred safely.
-4. Is the change merely useful beyond the intended use? Omit it by default; use **Improvement** only when materially relevant or requested.
-
-A **Needs evidence** item must identify the load-bearing claim or condition, required observing boundary, available evidence and its limit, why the gap affects intended-use fitness, and the smallest evidence that could disagree. Establish that the claim is required. Distinguish a missing observation from a supported artifact defect; check whether evidence applies to the current artifact and accepted requirement rather than a superseded version. Do not prescribe broader implementation merely to fill an evidence gap.
-
-A Blocking Issue must identify the exact location or dependency, violated source truth or artifact responsibility, evidence, concrete consequence for intended use, and revision constraints or owning activity to re-enter. Recommend a specific revision only when source intent and dependency effects support it.
-
-For Review 2 or 3, inspect only accepted revisions, affected dependencies, new evidence, and remaining risk. Do not reopen Rejected items without contradictory evidence. For each new Blocking Issue, state whether it repeats, extends, invalidates, or exposes another consequence of a prior revision; is independent; or cannot yet be related from the evidence. Report a related pattern rather than proposing another revision. Review 3 is final; do not recommend Review 4.
-
-## Determine The Judgment
-
-1. **Blocking:** at least one Blocking Issue exists.
-2. **Inconclusive:** no Blocking Issue exists, but a material Question or Needs evidence item prevents judgment.
-3. **Non-blocking:** only Non-blocking Issues remain.
-4. **Pass:** no Issues or material unresolved items remain.
-
-Improvements do not change the judgment.
-
-## Output
-
-Omit empty groups. Do not include Improvements unless they are materially relevant or explicitly requested.
-
-Review type: independent
-Review number: [1 | 2 | 3]
-Artifact: [reviewed artifact]
-Intended use: [reviewed boundary]
-Reviewed state: [state identity]
-Judgment: Pass | Non-blocking | Inconclusive | Blocking
-Reasoning: [concise evidence-backed judgment]
-Relationship to prior items (Review 2 or 3 only): [related consequence | independent defect | unclear, with evidence]
-
-### Review Items
-
-#### Issues — Blocking
-- [location or dependency, issue, violated source or responsibility, evidence, consequence, revision constraints or owning activity]
-
-#### Issues — Non-blocking
-- [location or dependency, issue, evidence, why it can be deferred]
-
-#### Unresolved — Questions
-- [question, effect on judgment, required answer]
-
-#### Unresolved — Needs evidence
-- [load-bearing claim or condition, required observing boundary, available evidence and limit, effect on intended-use fitness, smallest evidence that could disagree]
-
-#### Improvements
-- [only when materially relevant or requested: improvement, benefit, evidence]
-
-Dependencies affected: [dependencies or none]
-Contingent material: [material and upstream condition, or none]
-Evidence gaps: [unproved claims or none]
-```
-
-## Calibration
-
-Lead with the few items that can change fitness for the intended use. Prior review, artifact length, polished language, or producer confidence does not establish fitness.
-
-The report is evidence for adjudication. It is not authority over source truth, owner decisions, revisions, dependencies, or another independent dispatch. Pass, Non-blocking, Inconclusive, and Blocking are all valid exits.

package/skills/review-work/references/adjudicate-work-review.md

@@ -1,97 +0,0 @@
-# Adjudicate Work Review
-
-Read this after an independent work review returns and before selecting what follows from its report.
-
-Adjudication belongs to the receiving active agent. It tests the report against the reviewed state, source truth, and evidence. It is not independent review and does not inherit the reviewer's authority or judgment.
-
-## Dispose Each Material Item
-
-For every material item, choose one disposition.
-
-### Accepted
-
-State:
-
-- the supported implementation problem;
-- its consequence for the reviewed boundary;
-- whether it is Blocking or Non-blocking;
-- whether its cause is supported, unnecessary to select a clear local correction, or uncertain.
-
-### Rejected
-
-State the concrete reason: unsupported, stale, resolved, duplicate, preference-only, out of scope, or based on a source misread.
-
-### Open
-
-State:
-
-- the unresolved concern;
-- its potential boundary consequence;
-- the missing evidence or owner decision.
-
-When factual evidence is missing, restate the item as a Verify Work input: claim, required observing boundary, available evidence and its limit, and the smallest evidence that could disagree.
-
-A suggested correction may help explain a finding, but it does not establish cause, select the remedy, or authorize implementation.
-
-After disposing the items, derive the adjudicated judgment. Do not separately accept the reviewer's overall judgment.
-
-- **Pass:** no accepted Issues or material Open items remain.
-- **Non-blocking:** only accepted Non-blocking Issues remain.
-- **Inconclusive:** a material Open item prevents judgment.
-- **Blocking:** at least one accepted Blocking Issue remains.
-
-## Use Verification Results
-
-Route a known material evidence gap through [Workflow](../../../skills/workflow/SKILL.md) to [Verify Work](../../../skills/verify-work/SKILL.md). Verification produces factual evidence; it does not revise the reviewer's report or determine the review judgment.
-
-- **Supported:** re-adjudicate the evidence gap. Do not infer Pass.
-- **Contradicted:** re-adjudicate against source truth; the result may establish an Issue, invalidate one, or expose a source conflict.
-- **Inconclusive:** keep the item Open. The adjudicated review remains Inconclusive when the gap is material.
-- **Unavailable:** keep the item Open and state why the required boundary cannot currently be observed.
-
-Select focused independent follow-up only when the new evidence still requires judgment from a separate context.
-
-## Decide Whether Remediation Is Ready
-
-Remediation is ready when:
-
-- required behavior is settled;
-- the problem and boundary consequence are supported;
-- enough cause or decision basis exists to bound a correction;
-- affected interactions and dependencies are known sufficiently;
-- no material alternative or user-owned choice remains.
-
-When remediation is ready, state:
-
-- the proposed correction and rationale;
-- affected behavior and locations;
-- required ordering or constraints;
-- regression evidence and verification boundary;
-- whether focused independent follow-up remains justified;
-- the authority state.
-
-Use existing correction authority only when it covers that result. Otherwise propose the correction and any warranted follow-up once, then wait. A finding, adjudication, or selected review does not authorize mutation.
-
-Actual correction returns to [Execute Work](../../../skills/execute-work/SKILL.md). Preserve the accepted behavior; do not change tests, Specs, policies, or source truth merely to satisfy a reviewer or obtain Pass.
-
-## Route When Remediation Is Not Ready
-
-- unclear or repeated cause: [Diagnose Failure](../../../skills/diagnose-failure/SKILL.md);
-- unsettled direction or materially different remedies: [Discuss](../../../skills/discuss/SKILL.md);
-- user-owned choice or source conflict: [Decision Gate](../../../skills/decision-gate/SKILL.md);
-- missing factual support: route the named claim through [Workflow](../../../skills/workflow/SKILL.md) to [Verify Work](../../../skills/verify-work/SKILL.md);
-- uncovered correction: propose the bounded correction and wait.
-
-When findings interact, assumptions are challenged, or user input could change the remedy, report a problem checkpoint and stop before selecting or executing a correction.
-
-## After Authorized Correction
-
-Verify the affected boundary and perform ordinary self-review.
-
-Select focused independent follow-up only when accepted corrections, affected interactions, new evidence, or remaining risk still require judgment from a separate context. Do not dispatch follow-up merely because Review 1 found an Issue or because remediation occurred.
-
-If Review 2 remains Blocking, adjudicate it before acting again. Diagnose a repeated, extending, invalidating, or causally uncertain blocker. Return an independent clear local defect to its owner when diagnosis would add no useful understanding. Review 3 remains exceptional, separately authorized, and final.
-
-## Stop
-
-Stop when every material item is Accepted, Rejected, or Open; the adjudicated judgment is supported; and the next route and authority state are explicit.

package/skills/review-work/references/independent-work-reviewer-contract.md

@@ -1,139 +0,0 @@
-# Independent Work Reviewer Contract
-
-Read this before preparing or performing a separately selected independent review of implementation or integrated work.
-
-The reviewer did not produce the reviewed state. Give them the work product, source truth, and evidence needed to judge it directly. Do not provide only the producer's summary, reasoning, or claimed result.
-
-## Required Context
-
-Provide:
-
-- the work and future action covered by the review;
-- accepted outcome, requirements, and non-goals;
-- relevant Specs, Plans, tests, policies, ADRs, and established behavior;
-- the implementation, changed files, or diff range;
-- verification evidence and known gaps;
-- only the review lenses material to this boundary;
-- active evidence authority: none, or each exact covered check with its expected evidence and stop condition;
-- review number and, for follow-up, prior items, adjudication, corrections, and new evidence.
-
-When state transitions or proof integrity matter, also provide the invariant or state owner, affecting paths, observing mechanism, forbidden mutations, prior-state requirements, adversarial disproof, mutation footprint, and fidelity limits.
-
-## Reviewer Prompt
-
-```md
-# Independent Work Review
-
-Review work you did not produce. Inspect the supplied work, source truth, and evidence directly. Report without editing. The review ends with this report; do not adjudicate findings, fix items, dispatch follow-up, or continue merely to obtain Pass.
-
-A pass is valid. Use a high evidence bar, not a high item count. Do not broaden scope or treat possible improvement as unfinished work.
-
-Use supplied and already available evidence. Do not start a missing active check unless the review contract explicitly authorizes that exact check. Otherwise report **Needs evidence** with the claim and required observing boundary. When an exact check is covered, apply Verify Work's check-result and claim-result semantics; active evidence does not authorize editing or broaden the review.
-
-## Boundary
-
-- Protected future action: [boundary]
-- Reviewed state: [commit, tree, diff, or other exact identity]
-- Work: [diff range, changed files, implementation, or integrated result]
-
-## Accepted Outcome And Non-Goals
-
-- Outcome: [required result]
-- Requirements: [accepted requirements]
-- Non-goals: [intentional exclusions]
-
-## Source Truth
-
-- [Specs, Plans, tests, policies, ADRs, and established behavior]
-
-## Verification Evidence
-
-- Checks and results: [commands, observations, and results]
-- Known gaps: [gaps or none]
-- When relevant: [state owner, affecting paths, observer, forbidden mutations, prior-state requirements, adversarial disproof, mutation footprint, fidelity limits]
-
-## Review Scope
-
-- Review number: [1 | 2 | 3]
-- Material lenses: [alignment and correctness | regression and integration | failure and risk | evidence | design and minimality | maintainability]
-- Active evidence authority: [none | exact covered check, expected evidence, and stop condition]
-
-For Review 2 or 3:
-
-- Prior items and adjudication: [Accepted | Rejected | Open]
-- Clarifications: [settled decisions or none]
-- Corrections and new evidence: [changes and verification]
-- Remaining risk: [narrow unresolved scope]
-
-## Check
-
-Apply only the selected lenses:
-
-- accepted behavior is implemented without invention or omission;
-- affected callers, states, and components remain correct together;
-- material failure paths and risks are handled safely;
-- verification supports the claims at the required boundary;
-- complexity and coordination are justified;
-- the work remains understandable without hidden policy or fragile coupling.
-
-Do not search for unrelated issues. Report an out-of-scope issue only when it materially affects whether this boundary may be crossed.
-
-Before calling something an Issue, ask:
-
-1. Is required behavior or source truth settled? If not, use **Question**.
-2. Are reachability and material consequence supported? If not, use **Needs evidence**.
-3. Does the boundary require correction? Use **Blocking Issue** when it cannot be crossed safely, otherwise **Non-blocking Issue** when correction can be deferred safely.
-4. Is the change merely useful beyond this boundary? Omit it by default; use **Improvement** only when materially relevant or requested.
-
-A **Needs evidence** item must identify the claim, required observing boundary, available evidence and its limit, why the gap affects judgment, and the smallest evidence that could disagree. Establish that the claim is required. Check the candidate examined and any later code/test changes; a weakened assertion or superseded capture cannot establish current acceptance. Missing evidence does not by itself justify an implementation fix or a stronger requirement.
-
-A Blocking Issue must identify the exact location, violated requirement or source truth, evidence, concrete boundary consequence, and correction constraints or owning activity to re-enter. Recommend a specific correction only when directly supported.
-
-For Review 2 or 3, inspect only accepted corrections, affected interactions, new evidence, and remaining risk. Do not reopen Rejected items without contradictory evidence. For each new Blocking Issue, state whether it repeats, extends, invalidates, or exposes another consequence of a prior correction; is independent; or cannot yet be related from the evidence. Report a related pattern rather than proposing another patch. Review 3 is final; do not recommend Review 4.
-
-## Determine The Judgment
-
-1. **Blocking:** at least one Blocking Issue exists.
-2. **Inconclusive:** no Blocking Issue exists, but a material Question or Needs evidence item prevents judgment.
-3. **Non-blocking:** only Non-blocking Issues remain.
-4. **Pass:** no Issues or material unresolved items remain.
-
-Improvements do not change the judgment.
-
-## Output
-
-Omit empty groups. Do not include Improvements unless they are materially relevant or explicitly requested.
-
-Review type: independent
-Review number: [1 | 2 | 3]
-Boundary: [reviewed work and protected future action]
-Reviewed state: [state identity]
-Judgment: Pass | Non-blocking | Inconclusive | Blocking
-Reasoning: [concise evidence-backed judgment]
-Relationship to prior items (Review 2 or 3 only): [related consequence | independent defect | unclear, with evidence]
-
-### Review Items
-
-#### Issues — Blocking
-- [location, issue, violated source, evidence, consequence, correction constraints or owning activity]
-
-#### Issues — Non-blocking
-- [location, issue, evidence, why it can be deferred]
-
-#### Unresolved — Questions
-- [question, effect on judgment, required answer]
-
-#### Unresolved — Needs evidence
-- [claim, required observing boundary, available evidence and limit, why the gap affects judgment, smallest evidence that could disagree]
-
-#### Improvements
-- [only when materially relevant or requested: improvement, benefit, evidence]
-
-Evidence gaps: [unproved claims or none]
-```
-
-## Calibration
-
-Lead with the few items that can change the boundary judgment. Prior review, urgency, implementation effort, or producer confidence does not establish correctness.
-
-The report is evidence for adjudication. It is not authority over source truth, owner decisions, corrections, or another independent dispatch. Pass, Non-blocking, Inconclusive, and Blocking are all valid exits.

package/skills/review-work/references/security-risk-lens.md

@@ -1,69 +0,0 @@
-# Security Risk Lens
-
-Read this before reviewing work that changes trust boundaries, authentication, authorization, permissions, untrusted input, secrets, sensitive data, security-relevant dependencies or external integrations, code-execution boundaries, or failure behavior with security consequences.
-
-This lens helps frame review. It does not replace repository security policy, threat modeling, specialist review, or stack-specific hardening guidance.
-
-## Establish Authority
-
-Identify:
-
-- assets and data requiring protection;
-- actors, roles, tenants, and privilege levels;
-- trust boundaries and external systems;
-- accepted security and privacy policy and threat model;
-- compatibility and failure behavior that security controls must preserve.
-
-Security-sensitive product behavior remains user-owned. Do not invent access, retention, logging, or fail-open or fail-closed policy during review.
-
-## Trace The Paths
-
-Review the affected path from boundary to effect:
-
-- authentication: who or what is this actor;
-- authorization: may this actor perform this operation on this resource;
-- input: validation, canonicalization, size, encoding, and injection surfaces;
-- output: escaping, disclosure, error detail, and side channels;
-- data: collection, transport, storage, isolation, retention, deletion, and audit;
-- secrets: source, scope, rotation, exposure, and logging;
-- execution: shell, file, URL, template, deserialization, plugin, or code-loading boundaries;
-- dependencies: provenance, permissions, known risk, update impact, and transitive behavior;
-- failure: partial state, retries, lockout, rate limits, rollback, and fail-open or fail-closed behavior.
-
-Look for confused-deputy and cross-tenant paths, not only malformed input.
-
-## Require Boundary-Matched Evidence
-
-Prefer evidence at the real boundary:
-
-- tests proving allowed and denied roles and resources;
-- negative input and injection cases;
-- dependency or configuration inspection tied to the shipped artifact;
-- logs or traces demonstrating no secret or sensitive leakage;
-- failure-path tests for partial authorization, retry, and recovery;
-- specialist analysis for cryptography, sandboxing, identity protocols, or high-impact threats.
-
-A generic scanner pass cannot prove authorization logic or policy correctness. A unit test cannot prove deployed headers, identity configuration, or infrastructure permissions.
-
-Do not copy secrets, credentials, unrestricted personal data, or sensitive payloads into review context. Use the smallest sanitized evidence that supports the item.
-
-## Calibrate Items
-
-Treat supported exploitable behavior, policy violation, unintended privilege or data exposure, unsafe failure semantics, secret leakage, or a missing required control as an Issue.
-
-Classify it against accepted security policy and the reviewed boundary:
-
-- **Blocking:** crossing the boundary would remain unsafe, non-compliant, or contrary to a required control.
-- **Non-blocking:** the issue is real but can be deferred safely without violating the accepted boundary.
-
-Use **Question** when security behavior or accepted risk remains undecided. Use **Needs evidence** when a control may exist but the available test or environment cannot establish it.
-
-Treat materially useful defense in depth beyond the accepted boundary as an Improvement. Omit theoretical hardening, preference, or hypothetical completeness.
-
-Do not omit an observed security issue because the selected lenses were narrower. Name the asset, path, precondition, consequence, evidence, and source requirement.
-
-## Return Through The Selected Role
-
-For self-review, return a route-changing security concern to [Workflow](../../../skills/workflow/SKILL.md). Use [Diagnose Failure](../../../skills/diagnose-failure/SKILL.md) for unknown exploitability or cause, [Decision Gate](../../../skills/decision-gate/SKILL.md) for missing policy or accepted-risk decisions, [Design For Depth](../../../skills/design-for-depth/SKILL.md) when trust decisions spread across callers, and [Launch Work](../../../skills/launch-work/SKILL.md) when the concern affects production rollout.
-
-For independent review, classify the concern in the review report and stop. Do not route, correct, or dispatch follow-up. The receiving agent adjudicates the report and selects what follows.