Investor Skills is judged as Swift and ships only Markdown and YAML

The repository is recorded as Swift and contains no Swift

The project's language is recorded as Swift, and there is no Swift in it. The top level is eight entries: a licence, the readme, an assets directory, and five directories holding documents, examples, scripts, skills and templates. Every deliverable the page describes is plain text, either Markdown or YAML, and the skill packages it walks through are two files in a folder. So the language detection has been captured by something in the tree that is not the product, most likely an asset, and anyone filtering by language on a code index will rank this repository as a native application. It is a small inaccuracy and it is the first thing a search tool will tell you about this project.

A public template layer with a paid judgment layer behind it

The repository is openly two things at once, and the page does not hide the split. What is here is described as the free public layer: portable judgment systems, templates, schemas, and three indexes of reference material, one for reading, one for podcasts and one for video. What is not here is described just as plainly: closed-source skills that are not published in this repository, distilled from traders by labelling their judgment across real trades, covering what they watched, why they entered, how they sized, what would invalidate the thesis, and how they reviewed the outcome. Those are for paying members inside the hosted product. The difference the page draws is one of use rather than of quality, with the free skills aimed at study and research and the paid ones at execution-grade judgment.

Two files per skill, and the split depends on size

A skill package is either one file or two. The entry point is always the instruction file, which carries five things: when to use the model, what inputs are required, how to apply the process, what to avoid, and how to format the answer. Alongside it there is an optional schema file holding the investment system itself, with signals, filters, sizing and risk. The page gives a clear rule for choosing. For a simple skill, put the investment system directly inside the instruction file. For a larger or reusable model, keep it as the separate schema file and reference it from the instruction file's frontmatter. The frontmatter is three lines in the example, a name, a description written as a trigger condition, and a relative path to the schema:

---
name: buffett
description: Use when evaluating a business through Buffett-style ownership, moat, owner earnings, and margin-of-safety judgment.
invest: ./invest.md
---

The schema is machine tokens and human prose in the same file

The interesting design decision is that one file carries both audiences. A YAML block holds the machine-readable half: signals with weights, frequencies and thresholds, filters as required or not, sizing limits, and risk parameters. Markdown around it holds the human-readable half: philosophy, the analysis process, execution rules and behavioural guardrails. The specification for a standalone version of this file is written for teams who want the judgment system stored separately from the skill, and the page is careful to say that this is not a separate product, just the same schema used in a different place. The one worked example on the page is a value and quality style with a five-to-ten year horizon and a quarterly decision cadence.

The worked example asks for a fifteen percent return and no stop loss

The example schema is worth reading as a position rather than as documentation, because it is specific. The universe is large-cap and highly liquid, the asset class is public equities, the market regime preference is any, and the posture is patient. The fundamental signal is return on invested capital, weighted high, measured annually, preferring higher, with a threshold above fifteen percent. Two filters are marked required: a durable moat and consistent free cash flow. Sizing caps a position at twenty-five percent and the portfolio at fifteen holdings. Risk asks for a thirty percent margin of safety and, notably, no stop loss, which is consistent with the stated style and is the kind of field that only makes sense when the schema forces you to state it. The file's own version field reads alpha.

The printed structure ends in an unclosed placeholder

The repository layout is printed as a tree and it is mostly a map of the four documents, the one example file and the two templates. Then it reaches the skills directory and stops mid-line on an opening angle bracket and the words of a placeholder name, with no closing bracket and no example skill underneath. The package structure shown earlier on the same page names a concrete skill directory instead, so the page contains two different skill names and the tree contains neither as a directory. The only example file that exists in the tree is the standalone schema for one investor, which is the piece a newcomer can read in full to understand the format.

References are attached one to three at a time, and the instruction is to apply

The intended way to use the reference indexes is narrower than it looks. You load a skill first, then open that skill's own section in the reading, podcast or video index, or use the shared index, then attach one to three sources as reference material. The instruction on what to do with them is the part that matters: ask the agent to apply the skill's process rather than summarise the source. That is a different request from retrieval, and it is the reason the indexes are per skill rather than a flat bibliography. The last line of that section is cut off partway through the word for the thing the agent should not merely summarise.

Portable filename, non-portable assumptions

The portability claim is precise and worth repeating exactly: the skills are plain-text packages you can use in any agent harness that can read the instruction filename, and four are named. The tailoring claim sits immediately next to it and is just as specific: the skills are built for one product's financial harness, where models, skills, plugins and execution accounts work together across market data, portfolio context, broker or exchange or wallet permissions, and fund workflows. So the format travels and the assumptions do not. An agent in a different harness will read the same files and follow the process, but the permissions, the portfolio context and the execution accounts it was written against will not be there, which is the gap to think about before promising an agent it can act.

Editorial conclusion

This suits someone building an agent that has to reason about an investment and show its work, since the format forces the reasoning into named fields rather than prose. Two things to know before you build on it. The schema version in the worked example is labelled alpha, so the field names are still moving. And the packages are portable only in filename: the instructions are tailored to one commercial financial harness with plugins, execution accounts and broker or wallet permissions, so an agent in another harness will read the format correctly and lack the machinery behind it. Treat the closed-source tier for what it is, a paid product described accurately rather than a hidden version of the same files.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. questflowai/investorskills on GitHub
5. README