How it works
From your repository to a draft pull request
Stenlio reads one repository and one website, drafts articles unattended, and — only after you approve one — opens a single draft pull request in the directory you registered.
Last substantive change:
The run, step by step
- 1. Bind one company
- You install the GitHub App on one private repository, give your canonical website URL, and point at the Markdown or MDX directory your blog already lives in. Nothing is read before this.
- 2. Collect
- Stenlio reads the repository tree, samples file contents, and crawls your public site. Each collection is stored as a snapshot with a content hash, so a later claim can be traced back to the bytes it came from.
- 3. Analyse and rank
- Agents produce findings, name the gaps in your data rather than filling them in, and rank content opportunities. Every finding carries its citation.
- 4. Draft
- The writer produces an article artifact at a path inside your registered directory. It exists in Stenlio only. Nothing has touched GitHub at this point.
- 5. Approve
- An owner or admin presses approve. That single transaction records the approval, freezes the base commit, re-checks the path against the registered directory, and reserves a deterministic branch name.
- 6. Open the draft PR
- Stenlio opens a draft pull request on that branch. It never marks it ready, never merges it, and never opens a second pull request for the same artifact — a retried approval converges on the one that exists.
| Step | What happens |
|---|---|
| 1. Bind one company | You install the GitHub App on one private repository, give your canonical website URL, and point at the Markdown or MDX directory your blog already lives in. Nothing is read before this. |
| 2. Collect | Stenlio reads the repository tree, samples file contents, and crawls your public site. Each collection is stored as a snapshot with a content hash, so a later claim can be traced back to the bytes it came from. |
| 3. Analyse and rank | Agents produce findings, name the gaps in your data rather than filling them in, and rank content opportunities. Every finding carries its citation. |
| 4. Draft | The writer produces an article artifact at a path inside your registered directory. It exists in Stenlio only. Nothing has touched GitHub at this point. |
| 5. Approve | An owner or admin presses approve. That single transaction records the approval, freezes the base commit, re-checks the path against the registered directory, and reserves a deterministic branch name. |
| 6. Open the draft PR | Stenlio opens a draft pull request on that branch. It never marks it ready, never merges it, and never opens a second pull request for the same artifact — a retried approval converges on the one that exists. |
What you need before step 1
- Claim a seat: One of a hundred. No card, and nothing connects yet.
- Bind one company: Install the GitHub App on a single private repository, give your canonical site URL, and point at the blog directory.
- Read the first analysis: Stenlio reads both sources overnight and returns findings, data gaps, and a ranked plan, each claim carrying its citation.
- Authorise, then approve: Authorise the one directory Stenlio may write to. From then on it opens drafts and you approve them. Checkout opens at the first execution, not at sign-up.
How the agents reach a decision
Ten department agents run against the same snapshot. When they disagree, the disagreement is recorded rather than averaged into one confident answer.
- Debate: A question enters the boardroom. The relevant agents argue it from their own vantage point, and disagreement is recorded rather than averaged away.
- Synthesise: The Chief of Staff collapses the debate into a decision memo: the call, the dissent, and the tasks it implies.
- Hand off: Work crosses departments as a typed payload. Sales hands an MSA to Legal. Engineering hands cloud spend to Finance. Nothing is retold in prose.
- Check the guardrail: Every effectful action is evaluated before it runs. Routine work proceeds. Anything that carries your name stops.
- Execute, durably: Approved work runs as a checkpointed workflow. A crash resumes at the last completed step instead of starting over.
The limits on each run
- One draft PR per 24 hours
- Per company. A seventh step attempted inside the window is refused with DAILY_PR_LIMIT_REACHED rather than queued.
- File extension
- The path must end in one of the extensions registered with the content surface, or the approval is refused.
- Path
- The path is re-derived against the registered directory root twice — once when you approve, once again at the write itself. Neither check trusts the other.
- Revocation
- Revoking the content surface removes the row the approval query joins on, so a revoked directory cannot be approved at all rather than being approved and then blocked.
- Free tier
- One bounded analysis per repository and site pair every 30 days. No scheduled runs, and no draft pull requests.
| Limit | What it means in practice |
|---|---|
| One draft PR per 24 hours | Per company. A seventh step attempted inside the window is refused with DAILY_PR_LIMIT_REACHED rather than queued. |
| File extension | The path must end in one of the extensions registered with the content surface, or the approval is refused. |
| Path | The path is re-derived against the registered directory root twice — once when you approve, once again at the write itself. Neither check trusts the other. |
| Revocation | Revoking the content surface removes the row the approval query joins on, so a revoked directory cannot be approved at all rather than being approved and then blocked. |
| Free tier | One bounded analysis per repository and site pair every 30 days. No scheduled runs, and no draft pull requests. |
What ships today
- Overnight analysis of one repository and one website, with sources cited
- A ranked, source-backed content plan for your blog
- Draft pull requests opened in one blog directory you register, one per 24 hours, after you approve each one
- Guardrail policy on every effectful action, with the decision recorded
- Daily briefing assembling what each department did and what needs you
Actions that do not exist. No plan, setting, or approval enables them:
- Merging, publishing, or deploying anything
- Writing anywhere outside the registered content directory
- Sending email, posting to social, or spending on ads
- Moving money, issuing refunds, or changing a price
- Modifying infrastructure or running database migrations
Product surface that is not built yet, named here so the gap is not discovered after signup:
- Multi-company portfolio control and cross-company benchmarks
- Non-technical operator path without a GitHub repository
Where to go next
Permissions, storage, and revocation covers what Stenlio keeps and for how long. The GitHub integration page covers the supported directory structure and the errors you can hit. Pricing covers what the free tier includes and when a card is required.