Stand it up on your project

Builds a reverse-dependency graph so consumers can process a change's whole blast radius rather than only the file that changed. The graph is produced by a backend behind a fixed contract. homegrown ships with the toolkit, needs nothing but Python, and scrapes imports for TypeScript/JavaScript, Python and Go — 4 languages, 6 extensions. graphify is opt-in and needs its binary on PATH: tree-sitter ASTs across 40 languages and 93 extensions, plus calls/inherits/references relations the built-in one has no notion of.

# the package is graphifyy, two y's; the command it installs is graphify, one y
uv tool install "graphifyy[sql,terraform]==0.9.47"   # or pip, on Python 3.10+

freya code-graph --use graphify            # this project
freya code-graph --use graphify --global   # and every future one

Pinned deliberately, and it is the same line freya install prints. graphifyy is pre-1.0, and 0.9.47 is the release this toolkit was measured against. The [sql,terraform] extras are not optional decoration either: without them graphify still declares .sql, .tf and .tfvars and parses none of them, and the coverage census — which filters by the running backend's declared extensions — would then affirm that nothing went unread while the graph held no nodes for those files.

freya install asks this once and records the answer as your machine default; the first build in a project writes it into that project's committed knowledge-base/settings.json, so a clone and CI resolve the same backend you do. It is never chosen automatically — installing a binary on PATH must not silently change every blast radius on the machine.

Limits

• The built-in backend is regex, not an AST. A dynamic import(variable) is missed; imports inside comments or strings can mismatch. graphify does not have this limit.
• Every answer says what it could not read. A build, query or impact answer may carry an unmapped_source block naming the in-scope source the backend could not parse, and the directories to grep instead. It is absent when there is nothing to say — so its presence means the answer above it is incomplete.
• External packages are recorded as external: leaves and never traversed.
• Bare Go imports and absolute-Python module specifiers often fall through to external:. Internal-edge resolution is strongest for TS/JS relative and aliased imports.
• Monorepos want one graph per subproject, and a tsconfig extends chain is not followed.
• Nothing outside the project root is reached unless you declare it. An import's .., a tsconfig paths escape and an absolute import all come back unresolved:, and a committed symlink pointing out of the project is refused rather than followed. A symlink that stays inside the project still works. Naming a sibling directory under outside in knowledge-base/settings.json — {"ui": "../packages/ui"} — makes imports that land there resolve to outside:ui/<path> instead of disappearing into a package tag. That is all it buys: the directory is never scanned, walked or globbed, the declaration causes no file under it to be read (the whole reach is a realpath, one is_file() and one cached listdir of the named file's own directory), no file under it becomes a node, and there is still no reverse edge or blast radius on the far side. Relative paths only, and it is a per-project setting — a machine-wide one would point every repository on the machine at one directory. Only the built-in homegrown resolver honours declarations: on the graphify backend a declared root reports crossings: 0 whether or not anything crossed it, because that backend never consults them.
• On build it classifies directories in the order rules → AI → user, and non-interactively an uncertain directory defaults to source — so real code is never silently dropped, at the cost of occasionally graphing something you would have excluded.

Commands and output schema: knowledge-base/reference/SKILL_REFERENCE.md#code-graph

Creates and maintains a standard documentation set: a coordinator detects the stack and gathers business context, then one worker per doc type runs the write. Undetectable details become [TODO:] markers resolved later in batched questions.

Limits

• Almost entirely prose-driven. Its only real code is stack and test-runner detection; doc quality is the model following instructions.
• Certainty scoring is not one of its features — that is spec-manager. Its analog is [TODO:] markers plus a check / warn / fail review pass.
• Some of its templates and evals still name the older docs/ layout; knowledge-base/ is authoritative.

Commands and outputs: knowledge-base/reference/SKILL_REFERENCE.md#docs-manager

The intent owner: what a feature does, why it was designed that way, and — the part that pays for itself — which of its oddities are deliberate.

Limits

• scan only ever produces proposed candidates — never accepted, never files in the code tree. Acceptance is a human act.
• Authority order for contradictions is fixed: principle > ADR > spec. A spec never wins against a principle.
• Certainty (0–100) gates review of inferred specs only. Trust in an executable behavior is its lifecycle state, not that number.

Commands and outputs: knowledge-base/reference/SKILL_REFERENCE.md#spec-manager

Projects your specs' behavior records, merges in coverage from behavior-runner, and answers impact both ways: which behaviors a code change affects, and which code implements a behavior.

Limits

• Only accepted and confirmed behaviors are projected; proposed lives only in the specs.
• Only accepted behaviors can gate a change.
• Queries reflect the last --build snapshot. Change specs or code and the answer is stale until you rebuild.
• Coverage merges by trust: observed beats static. A red test invalidates prior coverage; any other unknown preserves it, so a runner that could not run does not erase what was already known.

Commands and outputs: knowledge-base/reference/SKILL_REFERENCE.md#behavior-graph

A producer only. It runs accepted, non-quarantined behaviors through their adapter and prints TEST → CODE coverage fingerprints as JSON. It never writes behavior.json.

Limits

• Only the vitest unit path is implemented. Other adapters are allow-listed but return unknown with a reason.
• The vitest invocation is hardcoded to pnpm.
• confirmed behaviors are never executed — a test is still owed — so they can never be test-failed and never gate.
• Coverage is observed at 0.8 (real V8 runtime), static at 0.5 (graph closure of a declared entry point), or unknown with a reason. It is never faked, and there is no fourth value.

Commands and outputs: knowledge-base/reference/SKILL_REFERENCE.md#behavior-runner

Six specialised finders scan in parallel — auth/authz, injection, secrets, API/network, config/deps, file/resource — and every finding is validated and then adversarially attacked before it is allowed into the report.

Limits

• Only accepted behaviors downgrade a finding; proposed and confirmed add an advisory note at most. The query checks that the behavior's state is accepted in the specs, that its locator resolves to a file in the project, and that the exercised path was observed rather than inferred from the import graph — all read from artifacts the scanned repository commits — and returns a sentence saying so, which the report must carry verbatim. The scan passes --verify, so the linked test is re-run; on the plain query, which runs nothing, that sentence is a label on evidence and not a verification.
• On the driver path, exactly three refutation lenses run per finding. (The "2–3 lenses" wording elsewhere describes the in-loop update pass, not the driver.)
• A finding is dropped only on a unanimous refutation. A split verdict stays needs review — which is why the lens count is never the thing that gets cut to save money.
• Neither driver mode is wired into wrap-up. See Security below for what wrap-up runs instead, and why.

Commands, modes and the exit-code table: skills/freya-codebase-security-scan/SKILL.md

The supply-chain half of security — its sibling covers your code. It detects the package manager from the lock file, runs that manager's audit, then enriches and validates each finding with web searches to strip false positives and note applicability.

Limits

• Node ecosystem only — npm, yarn, pnpm. No pip, no cargo, no Go modules. (The quick-reference entry for this skill claims otherwise; the skill file is the accurate one.)
• It reports, it does not fix. It suggests the upgrade; you run it.
• It is not invoked by wrap-up. Nothing schedules it — you do, with whatever recurring mechanism your agent offers.

Commands and outputs: skills/freya-dependency-vulnerability-check/SKILL.md

The actor half of the security loop: list → select → validate → confirm → plan → implement → commit the code, then hand off to wrap-up for the artifacts commit. Its signature move is that skipping is never a no-op — every skipped finding still gets routed to a terminal state. Already resolved becomes RESOLVED; intentional gets a spec entry and becomes INTENTIONAL; code that no longer exists becomes OBSOLETE; not actually a security issue is downgraded to INFO. Nothing rots in the report as a permanent open item nobody will ever look at again.

Limits

• When a finding's file has zero dependents, it recommends deleting the dead code rather than fixing it — occasionally the right answer, always worth a second look before you agree.
• Prose-only: its tables and status lines are templates the agent reproduces, not program output. They look like a tool speaking and they are not.

Commands and outputs: knowledge-base/reference/SKILL_REFERENCE.md#codebase-security-resolver

The post-implementation orchestrator: commit the code, refresh the graph, then docs, then specs, then the behavior-integrity and governance gates, then an in-loop security pass, then commit the artifacts. Five steps between two commits.

Limits

• It warns and skips any missing skill rather than failing. A partial install produces a partial run that tells you so.
• A behavior scaffold's commit class follows its lifecycle state, not its file location: a proposed .feature scaffold rides the artifacts commit even though it sits among tests, and an accepted behavior's test rides the code commit.
• Its security step is the in-loop update mode, never the paid driver — see Security.

Pipeline, flags and staging rules: knowledge-base/reference/SKILL_REFERENCE.md#wrap-up

The check-counterpart of wrap-up. Where wrap-up does and syncs, status only reports — and on request regenerates the git-tracked BACKLOG.md, which diffs in a pull request so a reviewer sees outstanding work without running anything.

Limits

• Read-only. The one file it writes is the backlog.
• The intent worklist is sorted lowest-certainty first, so the least trustworthy proposals reach you first.
• It drains the cold tail — behaviors no change ever touches, which wrap-up's validate-on-hit will therefore never surface.
• It never auto-authors a test. That is the engineer's work, on purpose.
• Every source degrades to a note independently, so a missing or corrupt input narrows the census rather than blocking the command — and, new since 0.3.0, those notes are carried into the generated BACKLOG.md as well, under a banner saying a section may be empty because its input was missing rather than because it is clean.
• An unreadable finding counts as open, never as absent. findings.json's status vocabulary is open / resolved / intentional, and both ends of that file are written by hand. A fourth value — a capitalisation, a synonym, a missing key — used to be dropped silently, so a file holding three high-severity findings could report zero open findings and say nothing about it. It is now counted as open and named in the note. A silently-zero security bucket reads as clean, not as never scanned, and those are the same number and opposite facts.

Commands and outputs: knowledge-base/reference/SKILL_REFERENCE.md#status