# cti-expert: a threat intelligence skill pack for coding agents

> CTI Expert is a set of commands, techniques and tools packaged as a skill for Claude Code and Codex, aimed at threat intelligence and open source intelligence work. The design decision that shapes everything is that the core runs with no installation and no API keys, and every paid data source is an upgrade to a capability that already works. The deeper layers, a model driven pipeline, a typed model context protocol server, and the report and graph generation, are what the optional dependencies unlock.

**7onez/cti-expert** — CTI Expert — Cyber Threat Intelligence & OSINT analysis skill for Claude Code / Codex. 120+ commands, 57 techniques, 79 typed MCP tools, deterministic case pipeline + ICD-203 reports. No API keys required for core.

- Repository: https://github.com/7onez/cti-expert
- Website: https://chongluadao.vn
- Stars: 616 · Forks: 88
- Language: Python
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/7onez-cti-expert

## A skill pack, not a library

The repository description is dense and worth unpacking, because it tells you the shape of the thing. CTI Expert is a cyber threat intelligence and OSINT analysis skill for Claude Code and Codex, with 120 plus commands, 57 techniques, 79 typed model context protocol tools, a deterministic case pipeline, and ICD-203 reports. The final claim is that no API keys are required for the core.

The framing in the readme is that it transforms Claude into a trained intelligence analyst. That is a marketing sentence, but the structure underneath it is real: the project is a set of slash commands, a catalogue of techniques, a set of tools exposed over a typed protocol, and a case pipeline that puts a report at the end of it.

The counts are the headline and the badges repeat them, one per number. A version number in the two series, the licence, the command count, the technique count, and a badge asserting that no keys are needed for the core. Behind them sit the usual repository statistics, which is a sign that the author is courting stars and contributors, and there is a sponsors table with a dozen organisations listed as backing the work with data and tooling rather than money.

That sponsors table is the most interesting part of the readme, and it is a different kind of sponsorship. Each entry names an organisation and describes what it brings and which commands it feeds: a phishing research coalition whose symposium papers ground eight of the techniques, an infostealer infection intelligence service, a dark web monitoring service, an interactive malware sandbox, a passive DNS provider, a search engine results API, a cloud bucket exposure search, an OSINT investigation platform, and a graph-based intelligence service that does DNS, certificates, favicons, and response body hashes in one place.

So the model is: the toolkit is the free part, and the data providers are what a user brings. The tool is a way of running investigations consistently across all of them.

The project is MIT licensed according to the badge, the site is chongluadao.vn, and the last push was on 2026-10-20. There are no tagged releases. The readme is available in English, in Vietnamese, and in Chinese, which tells you where the audience is.

## The layering, and the standard library core

The requirements file is where the architecture is stated, and its opening comment is the most informative paragraph in the repository.

The comment divides the code into two groups. The collection layer, the web pivoting scripts and the top level scripts, and the knowledge base, correlation, and case tools, are standard library only, and they run with no installs at all. The dependencies listed below open up the deeper layers, and the comment names them: the harness orchestrator and the model context protocol server, which are the model driven pipeline and the typed tool server, and the IntelGraph scripts, which produce the publication quality charts and network graphs.

That is a very unusual dependency strategy, and it is worth understanding why it matters here.

For most projects, a dependency list is a list of things the code needs. Here it is a list of things the code might need, and the dividing line is drawn by capability rather than by convenience. A standard library only collector has no import errors, no version conflicts with the agent's own environment, and nothing to audit for a security team. That matters more than usual for this kind of project, because the whole thing is a security tool and a supply chain review of a security tool is not a formality.

The deeper layers are where the model is in the loop, and where the heavy dependencies live. The pipeline and the tool server need an agent SDK, typed schemas through a data validation library, and a console output library. The reporting layer needs a charting library, a rasteriser that turns a drawn entity map into the house document formats, a numerical library for the heatmap and confidence scatter grids, and the graph library, which also needs the graphviz binary on the system.

There is also a third group that the comment calls collector extras, described as light and as closing silent degrade paths. Those are the ones worth reading twice, because silent degradation is the failure mode of a tool like this. An Excel export of the evidence ledger, with a CSV-only fallback when the library is absent. A barcode decoding library for the QR path in the web pivoting, which needs a system library for the barcode support. An image library for that path. And a PostgreSQL driver, used as a public fallback for the certificate transparency search when the primary route is unavailable.

The pattern is consistent: where a paid or fragile dependency exists, there is a weaker path that still produces something. A tool that silently returns nothing is worse than one that returns less, and the design here is that the lesser result is the default.

## Keyless by default, and the resolution order

The environment file is the second document that explains the design, and its header is a statement of philosophy rather than a list of variables.

The project runs keyless and free by default. Every key is optional and only upgrades an existing capability. If you leave one blank, that feature falls back to its free or keyless path.

That is a claim about every single integration in a tool with twenty-odd of them, and it is the claim that decides whether this project is usable at all for a reader who does not have a budget for a dozen commercial intelligence feeds. Most OSINT tooling is written the other way round: the free path is a trial, the paid path is the product, and the documentation leads with the price. Here the free path is the product, and the paid path is an upgrade.

The header then gives the mechanics. Copy the example file to a dot-env file in the same folder, paste in the keys you have and leave the rest blank, or skip the editing entirely and use the key management script to set one. And then the resolution order, which is the part to be careful about: the environment variable wins, then the dot-env file, then the keyless fallback.

So there are three levels of configuration and a well defined precedence, which means a key can come from the shell, which is what you want in a script, or from a file in the skill root, which is what you want for a machine. And the fallback is not an error state: leaving a key blank does not disable the feature, it selects a different implementation of it.

The security notes are brief and correct. Never commit the real file, which is why it is ignored by git, and restrict its permissions. And there is a management script with four subcommands: one to set a key, one to check the status of the configured keys, one to test them, and one to list what each key would unlock.

That last command is the interesting one. A list of which key unlocks what is a capability map for the tool, and it lets an analyst decide, before spending anything, which paid source is worth a subscription for the work they actually do. The regeneration command writes the example file back out, which keeps the documentation of the variables in step with the code that reads them.

The variables themselves are named after the services they belong to, and each has a comment saying which command uses it and what for. The favicon and certificate pivots are the recurring theme: several providers can reverse a favicon hash or a certificate fingerprint back to a set of hosts, which is the pivot that turns a single indicator into a footprint, and each provider does it with a different hash and a different cost.

## What the commands actually cover

The command reference is the part of the toolkit the readme summarises through the sponsors table, and reading the table tells you the shape of the workflow.

There is a web pivot command that is the busiest one, and it is fed by most of the sponsors: Shodan for reverse favicon hashing and certificate fingerprints, Censys for the same with different hashes plus certificate and host search, a search service for favicon icon hashes and tracker body hashes and address reverse lookups, and the graph-based intelligence service which handles domain lookup, reputation, certificate and favicon hosts natively inside the pivot command. There is a certificate pivot command that takes the same idea to certificates alone, and a separate censorship-aware host search command.

There is a threat intelligence pivot command, which is the general one, and a case pivot command beside it.

The phishing detectors are a group in their own right, and the list of them is revealing about the current state of the field: a detector for a specific attack where the user is tricked into running a command, a domain survival check, a kit fingerprint that identifies which phishing kit built a page, visibility aware HTML analysis that looks for content only visible to certain users, a tracer, and an analysis of the permission scope an Android package requests. The sponsor entry for that organisation mentions that its symposium papers ground eight of the toolkit's techniques, which is a nice detail, because it means the techniques are sourced from published research rather than invented.

Then there are the dark web and credential commands. A deep breach command and a stealer log command, both fed by an organisation that monitors infostealer infections and knows which machines leaked which credentials and when. A dark web collection and review path from a service that monitors forums, markets, and private channels.

There is a malware analysis command and a hash lookup, fed by an interactive sandbox that can give you command and control addresses and endpoints observed in packed samples. There is a web content pivot that works passively, and an impersonation check, and a search pivot with a search engine results and advertising transparency command, whose description notes that it reveals who paid to send traffic, which is an attribution capability rather than a search one.

Then the exposure commands: a secrets command and a document leak command, fed by a service that grades exposure in open cloud buckets, with the comment that it is graded exposure rather than a same operator pivot, which is a distinction that shows the author is thinking about false positive rates.

And there is a threat model command with an adversary modelling overlay, an appliance scan command, and an email command. The breadth is the point: 120 plus commands and 57 techniques covering collection, pivoting, correlation, exposure, and reporting.

## The deterministic pipeline, and the typed tool server

The two deepest layers are the ones that make this more than a pile of scripts, and they are named in the requirements comment.

The first is the orchestrator, described as a model driven collect, correlate, assess pipeline, and it sits in a harness directory next to the tool server. The three verbs are the stages of an investigation, and the word deterministic in the project description refers to the case pipeline rather than to this one, which is a distinction that matters.

A deterministic pipeline is one where the steps and their outputs do not depend on how the model happened to phrase things. The case pipeline is described as deterministic, and the report it produces follows the ICD-203 standard, which is the intelligence community's framework for analytic standards. Producing a report against a published standard rather than an ad hoc format is a significant choice, because it means the output of the tool can be read by somebody who expects a particular structure, and it means the tool's quality can be assessed against a checklist rather than a preference.

The second is the typed tool server, and the typing is the point. The project claims 79 typed tools exposed over the model context protocol. The count is large, and the claim is that they are typed, which in this context means each tool has a declared input schema and a declared output schema rather than being a free text function the model has to guess at. That is what makes a tool call reliable enough to run in a pipeline rather than only in an interactive session, and it is also what lets the tool server validate a call before it reaches the network.

The dependency choices for that layer are consistent with the rest of the design. A schema validation library for the typed tools, the agent SDK for the model driven loop, and a console output library for the harness output.

The report layer is the third piece, and its toolchain tells you what a report actually is here. The charting library, with a house style theme file, produces charts, timelines, and Gantt views. The numerical library produces heatmap and confidence scatter grids, which is the standard way to show an analyst which of many findings are more or less certain. The rasteriser takes a drawn entity map into the house document formats, and the graph library produces the entity and infrastructure link graphs.

And the two system tools mentioned in the requirements comment are the document pipeline: a document converter and a typesetting engine for the PDF export of the intelligence report, and the diagram command line tool for the flow diagrams. The flowchart file in the repository listing, the one for the skills, is the same kind of artefact as the workflow diagrams the tool renders, which is a small sign that the documentation and the tooling share a vocabulary.

## How it is packaged and how it is built

The repository layout is the clearest evidence of how this thing is meant to be used, because it is a collection of content directories rather than a code project.

At the top there is a skill definition file, a structure document, a plugin directory, and an agent configuration file. The plugin directory is the packaging: it is what makes the thing installable as a skill into a coding agent rather than something you clone and read. The skill definition is the manifest that tells the agent what the skill is and when to use it.

Then the content directories, and they map onto the workflow stages. There is a commands directory for the slash commands, a techniques directory for the catalogue of the 57 techniques, a scripts directory for the collection layer, an engine directory, an intelligence engine directory, a connectors directory for the data sources, a validation directory, an analysis directory, an output directory, a guides directory, a handbook directory, a documents directory, a hooks directory, and an experience directory.

The presence of a validation directory and an output directory alongside the commands is the detail that says the project is designed for a workflow rather than for a single query. The output directory is where the results land, the validation directory is where they are checked, and the analysis directory is where the correlation happens. A command that produced a result with nowhere to put it would be a script; a command that produces a result that is validated and then written into a case directory is a step in a process.

The three diagram files at the top level are the process documentation: one for the API key flow, one for the case flow, and one for the skills flow. Written as diagram source rather than as prose, which is the right format for describing a pipeline.

The build is not in the repository in the usual sense. There is a requirements file and a Makefile, but the packaging is by the agent plugin directory and the commands are markdown files with front matter, which is the convention the coding agents use for skills. That means the artefact a user installs is a directory of text with a manifest, and the code it runs is Python with a standard library core.

There is also a directory for a code analysis tool, a directory for the environment example, and a directory for assets. The agent configuration file and the agent instruction file at the top of the tree are the modern equivalent of a contributing guide written for a machine rather than a person.

The last thing worth noting is the licence and the language spread. The licence badge says MIT, the readme is in three languages, and the homepage is a personal domain rather than a project site. Taken together with the sponsors table and the call for contributors, this reads as a project that is being run as a business and a piece of public infrastructure at the same time, with the code open and the data partnerships not.

## Conclusion

cti-expert fits an analyst who wants the routine collection and pivoting steps of an investigation scripted and repeatable rather than typed by hand each time, and who works inside an AI coding assistant already. It does not fit an organisation that needs the outputs to be evidence-grade on their own, because the collection layer is largely built on public and free sources, and it does not fit somebody who has to keep every query inside their own perimeter. Verify first which capabilities in your workflow need a paid source and which work keyless, since the whole design assumes you start with the free path and add keys where they help, that the output you need is a report and not an evidence ledger with chain of custody, and that the techniques catalogue matches the kind of work you actually do, because the catalogue is broad and general rather than deep in any one area.

## FAQ

### What is the cti-expert project?

It is a cyber threat intelligence and OSINT toolkit packaged as a skill for Claude Code and Codex, with 120 plus commands, 57 techniques, 79 typed tools over the model context protocol, a deterministic case pipeline, and reports produced against the ICD-203 analytic standard. The readme is in English, Vietnamese, and Chinese.

### Do I need API keys to use cti-expert?

Not for the core. The collection layer and the knowledge base, correlation, and case tools use only the Python standard library and run with no installs. Every key in the example environment file is optional and only upgrades an existing capability, and the fallback when a key is blank is a weaker free path rather than a disabled feature.

### How does cti-expert resolve configuration?

In a defined order: the environment variable first, then the dot-env file in the skill root, then the keyless fallback. You can either edit the environment file directly or use the key management script to set a value, and the same script can show the status of the configured keys, test them, and list which capability each key would unlock.

### What are the optional dependencies in cti-expert for?

They unlock the deeper layers. The agent SDK, the schema validation library, and the console output library are for the model driven pipeline and the typed tool server, while the charting, rasterising, numerical, and graph libraries are for the intelligence report and its entity and infrastructure graphs. Some system tools are needed too, including a document converter, a typesetting engine, the graphviz binary, and a diagram command line tool.

### What do the cti-expert commands cover?

Collection and pivoting across many providers: web and certificate pivots by favicon hash and certificate fingerprint, a threat intelligence pivot, a case pivot, phishing detectors, a breach and infostealer log command, dark web collection, malware analysis and hash lookup, passive web content pivots, an impersonation check, a search pivot with advertising transparency, and graded exposure searches of open cloud buckets and leaked documents.

## Sources

- [7onez/cti-expert on GitHub](https://github.com/7onez/cti-expert)
- [Issues](https://github.com/7onez/cti-expert/issues)
- [Project website](https://chongluadao.vn)
- [README](https://github.com/7onez/cti-expert/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/7onez-cti-expert