Open tools. Shared standards.

Give your agents a shared way to work.

Turn individual prompts into reusable capabilities. AI Cortex brings skills, contracts and quality rules to software delivery and project governance.

Open source under MIT. Built for the tools you already use.

The AI Cortex modelFour distinct responsibilities

One library. Clear boundaries.
Capabilities you can reuse across projects.

Bring it to your agent

How installation works

The capability atlas

The whole library, in view.

Start with a work objective. Open a branch to see its capabilities. Contracts, constraints and coordination provide the shared foundation below; adopt the assets that fit your task.

AI CORTEXSoftware delivery & project governanceSkills execute · Specs define · Rules constrain · Protocols coordinate
Skill

Choose a work objective to explore every capability

70 skills
01Research & opportunityUnderstand a problem before committing.Evidence → opportunity recommendation6
  • deep-research

    Investigate an open question through scoped decomposition, source selection, corroboration, and traceable findings without making a product decision.

    ↗
  • competitive-research

    Compare a dated competitor set by capabilities, positioning, pricing, and evidence quality without treating undocumented features as absent.

    ↗
  • market-research

    Define a market and examine customers, demand, segments, trends, and defensible size estimates with transparent evidence.

    ↗
  • policy-research

    Research a jurisdiction's policy or compliance question with official sources, effective dates, applicability, and product implications.

    ↗
  • assess-product-opportunity

    Assess a product opportunity from existing research reports and user signals, producing a restrained, traceable decision layer.

    ↗
  • product-opportunity-analysis

    Coordinate relevant research lenses and deliver a traceable Opportunity Package for a product or feature decision.

    ↗
02Direction & planningConnect everyday work to a project purpose.Purpose → priorities → roadmap16
  • define-mission

    Define the fundamental purpose of a project or organization. Answers why the project exists; produces a single mission statement persisted to docs.

    ↗
  • define-vision

    Define the long-term future the project aims to create. Answers what future we are building; produces a vision statement aligned with mission, persisted to docs.

    ↗
  • define-north-star

    Define the single most important metric representing the core value delivered to users. Produces North Star Metric with rationale, optional supporting metrics, and anti-pattern examples; persisted to docs.

    ↗
  • define-strategic-pillars

    Derive 3–5 strategic pillars (high-level themes) from vision and North Star that structure and guide strategic goals and roadmap. Produces a strategic pillars document; persisted to docs.

    ↗
  • design-strategic-goals

    Define 3–5 long-term strategic goals that move the project toward the vision and North Star. Produces a goals document aligned with mission, vision, and NSM; persisted to docs.

    ↗
  • capture-work-items

    Capture requirements, bugs, or issues from free-form input into structured, persistent artifacts. Use when user wants to record a work item quickly without deep validation.

    ↗
  • prioritize-backlog

    Apply a project's priority policy to unresolved backlog items, or explicitly reassess a batch using RICE, WSJF, MoSCoW and ICE; preserve settled decisions unless replacement is requested.

    ↗
  • map-item-dependencies

    Identify dependencies among backlog and roadmap items across five categories, record depends_on and required-deliverable evidence, and assess next-step readiness with need-by dates and reduction options before promotion.

    ↗
  • define-roadmap

    Design roadmap structure, populate source-backed content on a settled layout, or complete both stages; first-align existing plans while preserving business decisions and stable links, with optional local generation.

    ↗
  • promote-roadmap-items

    Promote prioritized requirements and defects into Now/Next/Later using settled project priorities and dependency readiness; preserve version membership and timing commitments.

    ↗
  • update-roadmap

    Maintain requirement-and-defect roadmap summaries — change item status, shift dates with downstream impact analysis, and retain source-backed revision history. Does not move items between Now/Next/Later tiers.

    ↗
  • archive-milestone

    Archive completed roadmap work packages or iteration/phase/version/period snapshots while preserving milestone event evidence and unfinished work.

    ↗
  • plan-next

    Analyze governance state and suggest next actions; ask whether a skipped recommendation lasts for the session or until revoked.

    ↗
  • orchestrate-governance-step

    Safely advances one governance action from plan-next, re-diagnoses stale or conflicting routes, and reports whether to continue, ask, wait, or stop.

    ↗
  • orchestrate-roadmap-planning

    Route roadmap structure-only, content-on-settled-structure, continuous planning or existing-project alignment through scoped atomic skills; preserve decisions, links and authorization boundaries.

    ↗
  • orchestrate-repair-requirements-loop

    Run a bounded requirements review, targeted repair and re-review loop until the requirement passes or needs a business decision. Use for repairing existing requirement documents from review findings, before design or implementation.

    ↗
03Design & verificationInspect intent, implementation and evidence.Design → findings → verified change30
  • review-architecture

    Review code against the canonical architecture quality Rule set, including boundaries, dependency direction, cohesion, cycles, contract stability, coupling, composition, change surface, unreachable code and deprecation discipline. Cognitive-only atomic skill; output is a findings list.

    ↗
  • review-codebase

    Review given file/dir/repo for current-state code organization: module boundaries, design patterns, cross-module dependencies, tech debt, and interface stability. Scope-only atomic skill; output is a findings list.

    ↗
  • review-diff

    Review only git diff for impact, regression, correctness, compatibility, and side effects. Scope-only atomic skill; output is a findings list for aggregation.

    ↗
  • review-dotnet

    Review .NET (C#/F#) code for language and runtime conventions: async/await, nullable, API versioning, IDisposable, LINQ, and testability. Language-only atomic skill; output is a findings list.

    ↗
  • review-error-surfacing

    Review code against the canonical error surfacing quality Rule set, covering boundary decisions on untrusted input, stopping on a broken invariant, detection layer, and messages a person or a program can act on. Cognitive-only atomic skill; output is a findings list.

    ↗
  • review-functional-design

    Review an existing functional design against its modeling Spec and canonical quality Rule before technical design begins. Evaluative atomic skill; outputs findings without rewriting.

    ↗
  • review-go

    Review Go code for language and runtime conventions: concurrency, context usage, error handling, resource management, API stability, type semantics, and testability. Language-only atomic skill; output is a findings list.

    ↗
  • review-implementation-alignment

    Compare an implemented change and its verification evidence with approved requirements, designs and tasks. Post-coding atomic functional-alignment review; outputs findings without repairing.

    ↗
  • review-java

    Review Java code for language and runtime conventions: concurrency, exceptions, try-with-resources, API versioning, collections and Streams, NIO, and testability. Language-only atomic skill; output is a findings list.

    ↗
  • review-observability

    Review production telemetry against the canonical observability quality Rule set, including structured outcomes, correlation, SLIs, tracing, data safety, error ownership and background-work visibility.

    ↗
  • review-orm-usage

    Review ORM usage patterns for N+1 queries, connection management, migration safety, transaction handling, and query efficiency. Library-level atomic skill; output is a findings list.

    ↗
  • review-performance

    Review code against the canonical performance quality Rule set, covering bounded work, I/O amplification, complexity, memory, concurrency, caching, budgets and resource ownership.

    ↗
  • review-php

    Review PHP code for language and runtime conventions: strict types, error handling, resource management, PSR standards, namespaces, null safety, generators, and testability. Language-only atomic skill; output is a findings list.

    ↗
  • review-powershell

    Review PowerShell code for language and runtime conventions: advanced functions, parameter design, error handling, object pipeline behavior, compatibility, and testability. Language-only atomic skill; output is a findings list.

    ↗
  • review-python

    Review Python code for language and runtime conventions: type hints, exceptions, async/await, context managers, dependencies, and testability. Language-only atomic skill; output is a findings list.

    ↗
  • review-react

    Review React code for component design, hooks correctness, state management, rendering performance, and accessibility. Framework-only atomic skill; output is a findings list.

    ↗
  • review-reliability

    Review failure behavior against the canonical reliability quality Rule set, including timeouts, retries, idempotency, partial failure, isolation, dead letters, fault tests and release objectives.

    ↗
  • review-requirements

    Review an existing requirement document against its modeling Spec and canonical quality Rule before design begins. Evaluative atomic skill; outputs findings without rewriting.

    ↗
  • review-roadmap

    Review roadmap structure, business content or both with separate scoped conclusions; check source-backed planning and selected views without rewriting or expanding authorization.

    ↗
  • review-security

    Review code and configuration against the canonical security quality Rule set. Resolves trust-boundary profiles, gathers tool-assisted evidence and emits findings traceable to stable Rule IDs.

    ↗
  • review-sql

    Review SQL and query code for injection risk, parameterization, indexing and performance, transactions, NULL and constraints, and dialect portability. Language-only atomic skill; output is a findings list.

    ↗
  • review-tasks

    Review an existing task list against its modeling Spec and canonical quality Rule before assignment or coding, including design coverage, affected scope, Rule references and verification evidence.

    ↗
  • review-technical-design

    Review an existing technical design against its modeling Spec, canonical quality Rule and applicable engineering Rule profiles before tasks or coding begin.

    ↗
  • review-testing

    Review changed behavior and tests against the canonical testing quality Rule set, including direct oracles, boundary paths, integration assembly, contracts, determinism, doubles and coverage evidence.

    ↗
  • review-typescript

    Review TypeScript/JavaScript code for type safety, async patterns, error handling, and module design. Atomic skill; output is a findings list.

    ↗
  • review-vue

    Review Vue 3 code for Composition API, reactivity, components, state (Pinia), routing, and performance. Framework-only atomic skill; output is a findings list.

    ↗
  • orchestrate-code-review

    Orchestrator skill — sequence atomic review-* skills into the post-coding engineering gate and aggregate their findings; functional alignment and acceptance verification remain separate.

    ↗
  • orchestrate-repair-loop

    Iteratively converge the sibling engineering and functional gates, apply targeted fixes, then re-review and re-verify until both pass or a stop condition is reached.

    ↗
  • automate-tests

    Discover and execute repository test commands safely with evidence-based command selection and safety guardrails.

    ↗
  • scaffold-agent-tests

    Generate an LLM agent test suite (golden cases, mock-LLM unit tests, evaluator harness) from an agent implementation and its agent-test contract. Use when an agent has no tests, or a contract exists but the test code is missing.

    ↗
04Delivery & releaseMove reviewed work into a usable release.Commit → integrate → publish8
  • commit-work

    Create high-quality git commits with clear messages and logical scope. Core goal - produce reviewable commits following Conventional Commits format with pre-commit quality checks.

    ↗
  • deliver-feature

    From inside a linked worktree, deliver the current feature branch into main — merge with --no-ff, push, and optionally clean up the worktree, all without leaving CWD.

    ↗
  • integrate-branches

    From the main repo on the main branch, scan all linked worktrees and local branches, let the user multi-select, then merge --no-ff + push them sequentially and clean up succeeded worktrees together.

    ↗
  • prepare-release

    Build and validate a Release Package from repository history, version policy, quality gates, and optional release artifacts; does not publish or announce.

    ↗
  • publish-release

    Validate a ready Release Package and execute the repository's publication steps—tag, build, package, and provider release—with explicit mutation gates.

    ↗
  • announce-release

    Create and optionally deliver grounded release announcements from a published Release Package across available channels; never owns changelog generation.

    ↗
  • changelog-video

    Generate and validate an optional release video from confirmed Release Package change items using repository-local media tooling; never installs tools or decides or publishes the release.

    ↗
  • redeploy-local

    After code changes, auto-detect the project's build system and local deployment method for a given directory, then build the project and restart its locally-deployed environment (Docker Compose / systemd / process manager). Never assumes — asks only when detection is ambiguous. Caches detected commands per project in .cortex/redeploy-local.yaml; re-invocations on the same project skip re-scanning until signal files change, the cache expires (30 days), or the skill version bumps.

    ↗
05Communication & integrationExchange information with explicit boundaries.Contract → message → shared understanding5
  • prepare-presales-response

    Prepare evidence-backed presales questionnaire answers and supporting materials, maintain reusable product knowledge, and separate customer-specific terms from product facts. Use for capability, operations, service and procurement inquiries before delivery.

    ↗
  • publish-nats-message

    Publish a NATS message conforming to a cross-team contract, using NATS MCP tools. Authors the contract on first use if missing. Reads project-level cache (.cortex/nats.yaml) to avoid re-prompting basics across sessions.

    ↗
  • consume-nats-message

    Drain pending NATS messages from a producer contract via NATS MCP tools. Discovers the available NATS tool capabilities, selects exact-subject or wildcard mode from .cortex/nats.yaml, applies Tolerant Reader semantics, executes ack/nak/term decisions, and returns aggregated stats.

    ↗
  • decontextualize-text

    Convert text with private context or internal dependencies into generic, unbiased expressions that are standalone and reusable. Core goal - produce decontextualized text that preserves logic while removing organizational identifiers. Use for project handoff, open-source prep, methodology abstraction, cross-team sharing.

    ↗
  • manage-secret

    Store, look up, rotate, or delete a personal credential — passwords, API keys, tokens, certificate passphrases — in the macOS Keychain under a project-env-kind naming scheme. Use it even when the user does not say "Keychain". Not for team vaults, CI secret injection, or cross-machine sync.

    ↗
06Project & asset maintenanceKeep reusable knowledge discoverable and usable.Entry points → documentation → reusable skills5
  • define-docs-norms

    Create or update docs/ARTIFACT_NORMS.md from an approved proposal and establish project docs norms as canonical rules.

    ↗
  • generate-agent-entry

    Write or revise AGENTS.md with project identity, authoritative sources, behavioral expectations and verified loading entries for adopted workflows. Use when creating, auditing or revising a project's agent entry, including AI Cortex adoption.

    ↗
  • generate-standard-readme

    Generate lean, high-density README. Sections pruned by value threshold — not fixed count. Primary goal — reader knows what the project is, where to look, and how to use it within 30 seconds.

    ↗
  • generate-github-workflow

    GitHub Actions YAML with embedded output contract: security-first, minimal permissions, version pinning. For CI, release, PR checks. Differs from generic templates by spec compliance and auditability.

    ↗
  • refine-skill-design

    Audit and refactor one or more existing SKILL.md files for Agent Skills format compliance, clear execution, local asset boundaries, and portable tool use. Use when a user asks to refine, audit, or repair skill design.

    ↗
Shared foundation

Define outputs, constrain the work, coordinate participants

SpecWhat should the output look like?21
  • agent-test-modeling

    fields of a single LLM agent's test contract: capability boundary / input contract / tool boundary / write-back preconditions / oracles / golden cases. Does not cover how test code is written

    ↗
  • adr-modeling

    frontmatter fields of an ADR document, the 5-value status enum, and the fields decay depends on

    ↗
  • cross-team-contract

    naming suffix, contract_version, CHANGELOG, flat layout and version references for a cross-team contract document

    ↗
  • claude-md-modeling

    section structure, form requirements and per-level responsibilities of CLAUDE.md, the three-level long-term AI memory file

    ↗
  • findings-list

    the six elements, severity enum and category convention of a finding; the output contract every evaluative skill emits and every orchestrator aggregates

    ↗
  • functional-design-modeling

    field definitions and validation for a functional design document: functional modules, business workflow, permissions, states, exceptions and conditional UI interaction decisions

    ↗
  • technical-design-modeling

    field definitions and validation for a technical design document: architecture, components, database, interfaces, error handling, technology selection and applicable UI implementation traceability

    ↗
  • nats-messaging

    subject, headers, payload and version evolution contract for cross-project NATS messages; the NATS specialisation of cross-team-contract

    ↗
  • opportunity-package

    JSON contract for a reviewable product opportunity recommendation, lane status, and claim-to-source trace

    ↗
  • plan-next-preferences

    project-local YAML contract for exact plan-next recommendation exclusions that persist until restored

    ↗
  • research-evidence

    JSON contract for sources, classified findings, conflicts, gaps, and research trace

    ↗
  • roadmap-modeling

    structure-before-content stages, scenario selection, requirement/iteration/version/flow views, main/detail ownership, priority vocabulary, retained revision history and offline generator input

    ↗
  • requirement-modeling

    field definitions, format and validation for a requirement document

    ↗
  • rule-modeling

    the data contract for modeled Rule documents, stable item IDs, applicability profiles, project parameters and auditable waivers

    ↗
  • release-package

    version identity, release materials, quality evidence and stage status contract for a Release Package

    ↗
  • spec-modeling

    the spec for specs: the section skeleton, frontmatter contract and three-state classification every spec document follows

    ↗
  • skill-source-modeling

    the local copy, pinned upstream commit and digest, license, modification record and maintenance update contract for an externally derived skill

    ↗
  • task-modeling

    fields, status enum and dependency semantics of a task list

    ↗
  • test-case-modeling

    fields, traceability anchor (covers) and status enum of a QA business test case document. Does not cover code-level tests

    ↗
  • test-coverage-modeling

    fields and body skeleton of a test coverage report (traceability matrix + mutation summary + traceability health audit); the input artifact for suite coverage review and cross-artifact alignment review

    ↗
  • universal-notification

    structure and fields of a notification artifact

    ↗
RuleWhich constraints must hold?33
  • agentic-artifact-paradigm

    The agentic artifact production paradigm: structure is scaffolding not an agenda, substance-led, extraction preferred over interrogation, the quality rule as oracle with the oracle guarded against form-filling. The higher-order principle shared by interactive and one-shot capabilities.

    ↗
  • architecture-quality

    Stable architecture criteria for responsibility ownership, dependency direction, cycles, boundary leakage, contract evolution, coupling, composition, change surface, unreachable code and deprecation discipline.

    ↗
  • security-quality

    Stable security criteria for input-to-sink safety, authorization, secrets, protected data, cryptography, dependencies, defaults and safe security telemetry.

    ↗
  • reliability-quality

    Stable reliability criteria for timeouts, retries, idempotency, partial failure, isolation, terminal background work, fault tests and release objectives.

    ↗
  • performance-quality

    Stable performance criteria for bounded work, I/O amplification, complexity, streaming, concurrency, caching, budgets and resource ownership.

    ↗
  • error-surfacing-quality

    Stable criteria for where a defect is decided and how a failure is reported: boundary decisions on untrusted input, stopping on a broken invariant, detecting at the earliest layer that can decide, and messages an actor — person or program — can act on.

    ↗
  • literal-and-copy-quality

    Stable criteria for a value that exists in more than one place: one defining source for a cross-runtime value, display formats from a formatting API, whole copy entries, full language coverage, and fallback copies that agree with their source.

    ↗
  • observability-quality

    Stable observability criteria for structured outcomes, correlation, SLIs, spans, telemetry safety, error ownership and background-work visibility.

    ↗
  • testing-quality

    Stable test adequacy criteria for behavior oracles, boundaries, integration assembly, contracts, critical paths, determinism, doubles and reproducible coverage.

    ↗
  • implementation-alignment-quality

    Stable post-coding alignment criteria from approved acceptance/design/task intent to production code and verification evidence.

    ↗
  • writing-chinese-technical

    Chinese technical writing and typography, including spacing around numbers and units, and interface strings.

    ↗
  • writing-presales-response

    Evidence, service boundaries, disclosure, freshness and deliverable criteria for presales answers.

    ↗
  • standards-import

    Keeping references in sync and ordered during refactoring, to reduce compile and runtime failures.

    ↗
  • standards-jenkins-job-naming

    Reusable naming format for Jenkins job folder paths and items, with rules for stable identity, actions, qualifiers and run-specific values.

    ↗
  • workflow-documentation

    Documentation management constraints such as minimise, DRY and naming for temporary documents. The decision tree lives in docs/guides.

    ↗
  • workflow-rule-governance

    Stable IDs, applicability, source hierarchy, compatibility, validation and auditable-waiver constraints for modeled engineering Rules.

    ↗
  • standards-coding

    General coding principles: organisation, comments, naming, error handling, logging, simplicity, complexity thresholds.

    ↗
  • standards-shell

    Shell scripts: strict mode, log functions, trap, naming and variable quoting.

    ↗
  • standards-test-code

    Test code standards: one explicit objective per case, AAA, necessary multi-step evidence, naming, isolation, determinism, Covers traceability and restraint with mocks. Does not cover QA business test cases.

    ↗
  • standards-agent-testing

    Agent testing standards: separating deterministic from non-deterministic, extended oracles (contract / trajectory / rubric / golden / statistical), isolating real-model tests, regression gates on model and prompt changes. Applies on top of standards-test-code.

    ↗
  • requirement-quality

    The 5-dimension review checklist and spec compliance for a requirement document.

    ↗
  • requirement-intake-triage

    The triage vocabulary for raw intake (functional / non-functional / design proposal / task / defect / insufficient information), the decision questions and the soundness lenses. The diagnostic SSOT shared by clarification and review.

    ↗
  • functional-design-quality

    The 5-dimension review checklist, conditional UI decisions and spec compliance for a functional design document.

    ↗
  • technical-design-quality

    Stable pre-coding criteria for a technical design: completeness, executability, clarity, soundness, traceability and the triggered quality-attribute design.

    ↗
  • task-quality

    Stable pre-coding criteria for a task list: field completeness, dependency safety, executability, design coverage and engineering-governance annotations.

    ↗
  • roadmap-quality

    Roadmap quality: evidence-led scenario selection and reuse, requirement granularity, selected iteration/version/schedule and main/detail consistency, separate approval/execution, source-backed closure, priority, readiness, delivery evidence and retained revision history.

    ↗
  • test-case-quality

    The 5-dimension review checklist and spec compliance for a QA business test case document. Does not cover code-level tests.

    ↗
  • test-coverage-quality

    The 5-dimension review checklist for a test coverage report (completeness / truthfulness / explainability / risk alignment / currency and traceability) and spec compliance. Used when reviewing suite coverage and cross-artifact alignment.

    ↗
  • doc-health-criteria

    The document health criteria: spec compliance, link graph, SSOT, code alignment, layer readiness.

    ↗
  • repo-structure-hygiene

    Repository directory hygiene: misplacement, naming, empty directories, stale artifacts.

    ↗
  • adr-management

    ADR discipline: the two-question admission test, status field enforcement (5-value enum), the decay policy (archive at 12 months, deletable 6 months after that, ADRs themselves exempt from deletion), the boundary with decisions, and which maintenance edits a written record still allows.

    ↗
  • claude-md-management

    CLAUDE.md discipline: length limits (≤ 300 lines at project level), expression, no-go content, revision principles, and a self-check that cites the spec item by item.

    ↗
  • diagram-selection

    Diagram selection criteria: the relationship → diagram type → tool lookup, heuristics for choosing across tools (default Mermaid, and when to leave for PlantUML / Graphviz / flowchart.js), the rendering traps checklist, and constraints on splitting.

    ↗
ProtocolHow do multiple roles interact?1
  • im-notification-delivery

    rendering and delivery of notifications to IM channels such as Feishu and WeCom; pairs with [Universal Notification](../specs/universal-notification.md) in specs, which defines the structure

    ↗

Lines show library membership, not dependencies or a required execution order. Expand a branch to read every asset’s purpose here; source arrows are optional references.

The foundation

Good instructions have boundaries.

AI Cortex separates what an agent can do from the contracts and constraints it works within. The result is a library you can compose and maintain.

CapabilitySkill

What can the agent complete?

A single agent follows an objective and execution process to produce a defined output.

Explore skills
ContractSpec

What does this thing look like?

The structural and behavioral contract for an artifact, data model or interface.

Explore specs
CoordinationProtocol

How do the parties interact?

The steps, states and message sequence that coordinate two or more roles.

Explore protocols
ConstraintRule

What must hold true?

An independently verifiable obligation or prohibition, shared by the work and its review.

Explore rules

How it fits together

A shared standard.
From planning to delivery.

An example path through the library. Start with the capability you need; a full workflow is optional.

  1. Frame the work

    Capture the need and retain its purpose, acceptance criteria and strategic connection.

    Capture a work item
  2. Check the evidence

    Review the implementation against engineering rules and check alignment with the approved requirement.

    Understand the quality gates
  3. Prepare the handoff

    Package changes with the validation and release information the next person needs.

    Prepare a release

Make it part of your workflow

One library.
Your environment.

Clone the library and run the installer. It links skills into supported agent environments and syncs user-scoped rules for detected IDEs.

Read the full installation guide
Install AI Cortex

mkdir -p ~/.local/share
git clone --depth 1 https://github.com/nesnilnehc/ai-cortex.git ~/.local/share/ai-cortex
~/.local/share/ai-cortex/bin/cortex install

Review the commands before running them. The installer reports detected IDEs and any PATH setup needed.

Adopting project quality rules? Read the configuration guide

Before you start

A few useful answers.

Is AI Cortex an agent or an application?

It is an asset library for agents. It supplies callable skills, structural specs, interaction protocols and quality rules. Your existing agent runs the work.

Do I need to adopt everything?

No. Start with a skill that fits a current task. Orchestrator skills combine smaller capabilities for longer workflows. Project-specific governance needs its own explicit adoption. See the adoption guide.

What gets installed?

The installer links skills into ~/.agents/skills and supported IDE locations. User-scoped rules are synced for detected IDEs. Specs, protocols and project-scoped rules stay in the canonical clone for agents to read when needed. See supported installation behavior.

Can I inspect and adapt the library?

Yes. The project is open source under the MIT license. Read the assets, reuse them across projects and contribute improvements through the repository. Read the contribution guide.