If you want an AI system to write in a style that feels like yours, the first problem is not a clever prompt. It is deciding what "your style" means and how to test whether a generated passage resembles it.
AuthorStyle takes a research-oriented approach to that problem. It is a Python command-line tool that learns recurring patterns from a local corpus, records evidence for its style profile, and evaluates generated candidates against held-out writing. The project is alpha software, so the useful outcome is an inspectable experiment, not a promise of a perfect voice clone.
Install AuthorStyle 0.2.1, create a profile, ingest a directory of Markdown or other supported documents, and analyze it locally. The minimal path produces corpus statistics and a Style Card with measurable observations such as sentence rhythm, paragraph rhythm, lexical diversity, and punctuation rates.
This tutorial uses the repository's English fixtures so the workflow is reproducible without supplying private writing. Replace that directory with your own corpus only after reviewing the privacy mode and data-handling boundaries.
You need:
AuthorStyle 0.2.1 is published in the repository's v0.2.1 tag. The package declares the MIT license and supports Windows, macOS, and Linux through Python's normal environment model. The project is marked alpha in its package metadata, which matters when deciding how much to rely on generated output.
Clone the repository and create an isolated virtual environment. Pinning the tag keeps the example aligned with the documented release instead of silently following unreleased main changes.
git clone --branch v0.2.1 https://github.com/paladini/authorstyle.git
cd authorstyle
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
On Windows PowerShell, activate the environment with:
git clone --branch v0.2.1 https://github.com/paladini/authorstyle.git
Set-Location authorstyle
py -3 -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"
The development extra installs the test tools in addition to the runtime dependencies. The optional embeddings and nlp extras are separate; the basic workflow does not require them.
Start with a profile name and ingest the fixture corpus. A profile is stored below ~/.authorstyle/profiles/<profile_id>/ according to the README.
authorstyle init demo
authorstyle ingest demo ./fixtures/corpus/en
authorstyle corpus stats demo
authorstyle analyze demo
authorstyle profile show demo
On Windows PowerShell, the same commands use the installed console script:
authorstyle init demo
authorstyle ingest demo .\fixtures\corpus\en
authorstyle corpus stats demo
authorstyle analyze demo
authorstyle profile show demo
The repository's current fixtures produced three documents and seven chunks during verification. The exact counts will differ for your corpus. corpus stats reports documents, chunks, words, canonical families, and modes, while profile show summarizes the resulting global profile.
The important detail is the order. Ingestion normalizes and records source material, analysis builds the profile and Style Card, and the display commands let you inspect what was actually learned. You are not handing the tool a paragraph and asking it to guess a personality in one step.
AuthorStyle combines explicit stylometry with pluggable style and semantic encoders. The documented methodology separates the two concepts: style describes how text is written, while semantic signals describe what it is about. The current methodology lists sentence and paragraph rhythm, punctuation rates, lexical diversity, Markdown structure, and technical prose or code ratios among the explicit features.
A generated Style Card can contain observations like these:
## Sentence rhythm
Typical sentences center around 18.0 words (q25=12.0, q75=24.0).
Evidence metrics: median_sentence_length
## Punctuation and typography
Notable punctuation rates: comma=4.20/100w, question=1.10/100w
Evidence metrics: punct_comma_per_100_words, punct_question_per_100_words
Those numbers are evidence about the supplied corpus, not universal facts about the author. If the corpus contains only API documentation, the profile may reflect that document type as much as the writer's broader voice.
AuthorStyle supports .md, .txt, .html, and .docx files. Markdown can include YAML front matter with fields such as title, date, language, and mode. A .authorstyleignore file can exclude paths using gitignore-style rules.
---
title: "A technical article"
date: 2025-04-02
source: devto
language: en
mode: technical
published: true
tags:
- databases
---
Keep the corpus representative and permitted for local processing. Remove private documents that do not belong in the experiment, and keep source provenance intact so you can identify why a profile changed.
After analysis, the documented commands for generation and evaluation are:
authorstyle write demo --prompt "Write about distributed databases"
authorstyle evaluate demo
Generation stores candidates, component scores, retrieved exemplars, and provider metadata for reproducibility. Evaluation uses document-level held-out splits, so chunks from one document are not placed in both profile and test sets. The project compares baselines such as generic, card, examples, hybrid, and full, and reports style distance, explicit stylometric fit, content adherence, naturalness heuristics, originality, and calibration percentiles.
Do not interpret a high score as proof that a passage is authentically yours. The repository explicitly warns that it models recurring patterns from the supplied corpus, does not guarantee topic-independent style transfer, and does not automatically infer beliefs or personality.
The default LOCAL_ONLY mode permits only local or mock providers. REMOTE_PROFILE_ONLY sends the task and Style Card but not raw corpus excerpts. REMOTE_EXEMPLARS also sends selected exemplar passages. These are materially different boundaries, so choose the mode deliberately rather than treating a remote provider as an implementation detail.
The security policy also calls out prompt injection risks in Style Cards and generation prompts, unsafe file handling, accidental corpus disclosure, and unexpected network access when LOCAL_ONLY is configured. Never commit .env files, API keys, private corpora, or generated profile data unless you have a specific reason and have reviewed the consequences.
Run the project's test suite from the tagged checkout:
python -m pytest -q
The v0.2.1 checkout passed 24 tests in the verification environment. It also passed the CLI help command and the fixture path from initialization through analysis. Re-run those checks after changing dependencies or using a different Python version. A passing test suite validates the repository's current test cases; it does not validate the quality of your personal corpus or guarantee useful generated prose.
This is a documented risk. Separate style and semantic embeddings help, but recurring subjects can still correlate with style signals. Add varied documents and inspect modes instead of treating one narrow corpus as a complete author model.
Mode profiles require matching front-matter metadata. The methodology says insufficient evidence triggers warnings and fallback toward the global profile. That fallback is safer than pretending a small sample is a reliable mode.
Review the configured privacy mode before running write. Start with LOCAL_ONLY when testing ingestion and analysis. Remote generation is optional and must be explicit.
The project includes originality checks for long exact spans and word n-gram overlap. Inspect the overlap diagnostics and keep generated text under human review, especially when the corpus contains published or third-party material.
No. The README describes a local research CLI with profiles, exemplars, encoders, candidate generation, scoring, and evaluation. Fine-tuning is not the documented quick-start path.
No. Persona extraction is deferred in the current MVP. A style profile should not be treated as a biography.
The package metadata marks the project as alpha. Treat it as an experiment that produces inspectable evidence and keep backups of any corpus or profile you care about.
The useful lesson in AuthorStyle is methodological: define style as measurable observations, keep the source corpus under a clear privacy boundary, and evaluate against held-out documents. That makes the experiment easier to inspect than a prompt-only imitation workflow, while still leaving room for the project's alpha-stage limitations.
If you try this with your own corpus, which verification signal would you trust first: sentence-level stylometry, document-level holdout evaluation, or originality diagnostics?
AI assistance disclosure: This tutorial was researched and drafted with AI assistance. Commands, project details, limitations, and verification results were checked against the public AuthorStyle repository, its tagged release, and a local test run before publication.