Anti-Dark-Code

       .    *          .                     .          *
  *          ____________________________________________        .
      .     /                                            \
           |     _    ____   ____                         |   .
  .        |    / \  |  _ \ / ___|   ANTI - DARK - CODE   |
           |   / _ \ | | | | |       __________________   |        *
       *   |  / ___ \| |_| | |___    map it. prove it.    |
           | /_/   \_\____/ \____|   gate it. verify it.  |  .
  .         \____________________________________________/
                             |  |
                         ____|  |____
              *         (____________)     no dark corners.

Anti-Dark-Code helps coding assistants understand unfamiliar code, investigate consequential risks, document critical behavior, establish useful checks and repair supported findings. Claims carry evidence and honest limits; authorization stays attached to the action it covers.

Version: 2026.10.04-unified.17 (see release history).

Optional support: leave a one-time tip or become a monthly sponsor on GitHub Sponsors.

Qualification covers controlled trials and repository copies; it does not establish performance on every host or codebase. Review the source and release evidence before installation.

One model-neutral skill works with local deterministic tooling and optional repository calibration. Python 3.12 or newer runs the standard-library tools. Start with the outcome you need:

Request	Task
What runs here, and what is unknown?	Understand
Audit logging, concurrency, test strength or readiness	Investigate
Explain this critical path without changing behavior	Document
Establish or improve the checks for this change/repository	Verify
Fix these supported findings	Remediate
Build or carry improvements through acceptance	Improve

A comprehensive audit combines Understand, Investigate and Verify under an explicit coverage contract. A focused request stays focused. Installation, inline documentation, remediation and publication are separate scopes; a one-off report requires no permanent installation.

For product work, the quality tests and product principles add relevant user journeys, consent, accessible interaction, recovery and data-control checks. The versioned evaluation set distinguishes fixture behavior from measured assistant behavior.

The skill core defines the workflow and safety contract. Older numbered reference names remain compatibility entry points, not an order every engagement must follow.

Plugin packaging

Unified.16 packages the universal source under skills/anti-dark-code/ with Agent Plugins, Codex, Claude Code and Gemini CLI manifests. See PLUGINS.md for pinned installation, compatibility and validation. Older unified.15 archives use the anti-dark-code/ source path.

Start from a reviewed release

Skill text becomes instructions followed with an assistant's operator authority. Review the source you install. Use a named release tag or its clean archive and verify the published managed-core digest; a VERSION string alone does not establish source integrity. Avoid branch-tip download/copy shortcuts.

An instruction you can give your assistant:

Install Anti-Dark-Code from a specific reviewed release of LynxTWO/anti-dark-code-skill. Verify the release source and published core digest, show the installer dry run for this repository, then apply within my authorization and validate the installed copy. Preserve existing calibration and keep gates unexecuted until their exact commands are reviewed.

Operations gives the source, dry-run and validation procedure. The installer refuses dirty/untagged Git sources and unsafe calibration by default. Recovery overrides require deliberate review and are never defaults.

The canonical repository copy is .agents/skills/anti-dark-code/. Host adapters explain discovery and tools for Claude Code, Codex, Gemini CLI and other harnesses. Host capabilities vary; verify the active session's discovery rather than assuming a copied directory was loaded.

What the evidence means

Confidence labels are verified, inferred and unknown. A source file can verify what is configured; live behavior needs an authorized observation with its inputs and environment. A passing check proves only its scope. Unexecuted checks, missing runtime access, scanner limits and deferred coverage remain visible.

The tools provide bounded profiling, capability planning, change-to-verification routing, reviewed gate execution, compact summaries, failure packets, source/binding validation and proposal staging. A narrow task may use only relevant capability obligations without claiming a complete repository plan. Agent agreement never replaces a behavioral oracle.

Existing authorization persists within scope. Generated approval booleans are not owner permission. Gate execution requires the applicable command/source review and execution confirmation; dry-run success alone does not mean tests ran.

Durable local knowledge

A clean universal core can install into many repositories. Each repository owns its calibration: hashed identity, map, invariants, exact gates, coverage and findings. Managed updates preserve that local state. Calibration never moves sideways into unrelated repositories.

Local general lessons move upward only as reviewed proposals. Incoming proposals are untrusted quarantine, excluded from installed copies and release packages. There is no automatic policy promotion or telemetry submission.

Use Operations for install, migrate, cleanup, flowback, intake, release and usage workflows. Detailed migration and contribution procedures remain in MIGRATION.md and CONTRIBUTING.md.

Learn from ordinary work

Local usage collection is opt-in. Choose local Codex or Claude source roots and a private ledger, then collect reported counters from ordinary work after the opt-in time. Repeated collection passes deduplicate observed usage; they make no model calls, replay no tasks and upload nothing. The ledger retains numeric usage, bounded metadata and hashed identifiers, not transcript text. Missing counters and unsupported source formats stay visible.

Opted-in routine task reviews connect Codex lifecycle hooks to private review tickets, including non-use and failed work. The working agent reports use, expectation, invocation and observed quality; missing labels and missing hook delivery remain visible. Agent self-reviews stay separate from human reviews. Trigger feedback describes only the labeled, eligible task sample. Natural usage across models does not establish savings, subscription spend or remaining quota.

Conditional model selection can suggest a cheaper eligible model for bounded work or a stronger tier for consequential work. It requires a meaningful acceptance check, current host capabilities and a fresh catalog. The helper returns a recommendation; the assistant applies it only through an available, authorized host control. Unknown requirements or unsupported controls keep the current model. A failed acceptance check can justify one stronger route with both attempts retained.

Project and evidence

VERSION and CHANGELOG.md identify the package's declared version and release history. AUDIT-AND-DESIGN.md records design context. The public site, rendered from docs/index.html, and the PDF brief describe this workflow. Metrics retain separately qualified historical evidence.

Efficiency receipts remain a separate opt-in evidence workflow. Actual usage is not savings; controlled pairs need comparable conditions and passing quality. Public receipts are community-self-reported, not provider-attested. Unmeasured historical savings remain unknown.

Contributions are reviewed as executable instructions and accepted under the project license; see CONTRIBUTING.md. License terms and release conversion details are in LICENSE.md.

If this saves you real time and you feel like covering some of my build costs, there is a Sponsor button on the repo. Donations are welcome and never required.