# A TypeScript style guide that installs as an agent skill > mkosir/typescript-style-guide is a written set of TypeScript conventions that also ships as installable agent skills, so a coding agent can load only the part of the guide a task needs. It is useful as a shared reference, and it enforces nothing on its own. **mkosir/typescript-style-guide** — ⚙️ TypeScript Style Guide and Agent Skill. A concise set of conventions and best practices for consistent, maintainable code. - Repository: https://github.com/mkosir/typescript-style-guide - Website: https://mkosir.github.io/typescript-style-guide/ - Stars: 784 · Forks: 38 - Language: TypeScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/mkosir-typescript-style-guide ## A written guide that doubles as an agent skill Most TypeScript style guides are documents. You read them, you argue about them once, and then they sit in a wiki nobody opens. This project takes a different route: the repository carries both a published guide and a set of agent skills that install into a coding agent's toolkit. The project describes itself as a TypeScript Style Guide and Agent Skill, and calls the result a concise set of conventions and best practices for consistent, maintainable code. The repository layout backs that up. The top level holds .github/, .gitignore, LICENSE, README.md, a misc/ folder, a skills/ folder and a website/ folder, and the hosted guide lives at mkosir.github.io/typescript-style-guide. So there are two audiences. A human reads the website. An agent reads an installed skill, which is why the skills/ directory is a first-class part of the project rather than an export of the guide. The last push was on 2026-09-03, and the repository is not archived. ## npx skills add is the whole install step Installation is a single command run through npx, and the README shows the interactive form: ```bash npx skills add mkosir/typescript-style-guide ``` That command installs the skills and lets you choose one interactively. The alternative form installs one named skill directly, with the skill name passed as a flag. The available names are typescript-style-guide for the complete guide, plus focused skills called typescript-types, typescript-discriminated-unions, typescript-functions, typescript-variables, typescript-naming, typescript-source-organization, typescript-react and typescript-tests. There is no configuration file to write, no dependency to add to package.json and nothing to commit to your repository. That convenience is also the main trade-off. Because the install resolves the skills from the project source rather than from a published package version, what a team gets is whatever the repository holds at install time, and the repository has no GitHub releases to pin a version against. ## The complete guide loads only the sections a task touches The design decision that separates this from a plain markdown document is stated plainly in the README: the complete guide loads only the sections relevant to the task, keeping the coding agent's context focused. Focused skills provide individual guide topics independently. That is a claim about context budget rather than about code quality. A long style guide dumped into a prompt spends tokens on rules that have nothing to do with the file being edited. By splitting the guide into types, discriminated unions, functions, variables, naming, source organization, React and tests, an agent working on a naming question can pick up the naming rules without carrying the React and source organization rules along. The React and tests slices also tell you something about the intended audience. The guide is aimed at TypeScript codebases that include React components and that have a test suite, rather than at library authors or Node-only services. ## The stated goal is to end style arguments in code review The README gives a short list of reasons for having a guide at all. As a project grows in size and complexity, keeping code quality consistent and practices uniform becomes harder. Defining and following a standard approach to writing TypeScript applications leads to a consistent codebase and faster development cycles. The two remaining reasons are the ones that carry the most weight in practice. There is no need to discuss code styles during code reviews, and following a standard saves team time and energy. Notice what is not claimed. Nothing here says the guide will find bugs, enforce type safety or replace linting. It is positioned purely as a decision that has already been made once, so that reviewers spend their attention on behaviour instead of on formatting preferences. That framing is honest, and it also defines the limit of what adopting it buys you. ## Conventions in prose are not conventions in the build This is the central weakness of any prose style guide, and it is worth being blunt about. A skill installed into an agent changes what the agent tends to write, but it does not change what your build accepts. If a file arrives with a naming pattern your project has banned, no part of this repository will fail a check over it. The alternative approach is a rule set that runs as a command and returns a non-zero exit code, wired into a pre-commit hook or a CI job. The difference in approach is mechanical versus advisory: one produces a failing check that blocks a merge, the other produces a suggestion that an agent or a reviewer may follow. The two are not substitutes, and teams that already have lint rules for their formatting and naming get enforcement from the rule set and can treat this guide as the source of the conventions those rules encode. A second limitation is the install step itself. It depends on npx and on network access at install time, so it does not fit into an air-gapped CI image, and it is a separate toolchain concern that the project does not document further. ## No releases means no version to pin in a shared setup The repository has no GitHub releases, and the README describes no versioning scheme for the skills. For a guide that people are encouraged to install with a one-line command, that matters more than it would for an ordinary library, because the guide is copied into agent context and then treated as the house style. If a team decides the conventions are wrong in one place, there is no tagged version to point the team at and no changelog to read. The last push was on 2026-09-03, so the content is being edited, but the edits are not announced through the release machinery. A team that wants stability has to vendor the skills into its own repository, which is a workflow the project does not describe. Contributions are invited through pull requests, issues or discussions, all hosted on GitHub, and the licence is MIT, which permits copying the guide text into internal documentation without attribution requirements beyond keeping the licence notice. ## Conclusion Adopt this guide if your team writes TypeScript with an AI coding agent and wants one shared set of conventions the agent can read on demand, since the skills are split by topic and install with a single npx command. Do not adopt it as a quality gate: nothing in the repository checks your code, and the conventions live in prose rather than in a lint rule set. Before you wire it into a workflow, check which skill slices your agent actually loads, confirm the install step works in your CI image, and remember there are no published releases to pin to. ## FAQ ### How do I install the mkosir TypeScript style guide as an agent skill? Run npx skills add mkosir/typescript-style-guide, which installs the skills and lets you pick one interactively. The guide itself is also published as a website at mkosir.github.io/typescript-style-guide if you only want to read it. ### Can I install just one section of the TypeScript style guide? Yes. The README lists focused skills that can be installed by name, including typescript-types, typescript-discriminated-unions, typescript-functions, typescript-variables, typescript-naming, typescript-source-organization, typescript-react and typescript-tests. ### Does the typescript-style-guide project include lint rules or an editor config? The repository's top level holds .github/, .gitignore, LICENSE, README.md, misc/, skills/ and website/, with no linter configuration. The conventions are written guidance rather than checks that fail a build. ### How often is the TypeScript style guide updated? The last push to the repository was on 2026-09-03, and the project has no GitHub releases, so there is no published version history to track. ### What licence is the mkosir TypeScript style guide under? MIT. The repository carries a LICENSE file at the top level, and contributions are accepted through pull requests, issues and discussions. ## Sources - [Issues](https://github.com/mkosir/typescript-style-guide/issues) - [License: MIT](https://github.com/mkosir/typescript-style-guide/blob/main/LICENSE) - [mkosir/typescript-style-guide on GitHub](https://github.com/mkosir/typescript-style-guide) - [Project website](https://mkosir.github.io/typescript-style-guide/) - [README](https://github.com/mkosir/typescript-style-guide/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/mkosir-typescript-style-guide