Promptless

The product

Promptless uses AI agents to draft documentation updates directly from GitHub pull requests, so engineering and product teams can keep docs current as they ship. It pulls context from tools like Jira, Confluence, Linear, and Slack to keep those updates accurate and relevant.

The developer problem

A pull request says what changed in the code. It does not say which pages now describe the product wrongly. An agent that drafts doc updates has to connect the two: read the diff, pull in the related ticket or thread, find the pages it affects, and write a change a reviewer can accept quickly. The failure that matters is a confident edit that is wrong, such as a renamed parameter or a removed step still described as current. That makes evaluation the core problem, along with fitting each update into the review flow the team already runs.

My focus

• Doc-update agents. I’d focus on the path from a pull request to a drafted doc change, feeding in the diff, the linked ticket, and the current page as staged passes instead of one oversized request.
• Evals for generated docs. I’d score each draft against the code change that triggered it, so a wrong parameter name or a stale step is caught before a reviewer sees it.
• Docs-platform integrations. I’d work on Mintlify, Docusaurus, and ReadMe integrations that deliver each draft in the format and review flow the team already uses.
• Prompt and output design. I’d draw few-shot examples from the team’s own docs and use schema-constrained output wherever a pipeline has to parse the result.

Why it fits my experience

• At Meta I designed and refined AI-augmented authoring pipelines on Claude and Llama 4, covering draft generation from SDK source, structural rewriting, and automated consistency checks against the organization style guide.
• At Meta I also built an evaluation harness in Python that scores generated documentation against source-of-truth SDK signatures and a held-out set of human-written reference pages, so regressions in the prompt chain are caught before a developer sees them.
• At Red Hat I worked docs-as-code throughout: AsciiDoc source in Git, changes reviewed as merge requests, and builds run in CI. I set up style linting in the build pipeline, with Python scripts checking cross-references and broken procedure steps on every merge request.