Pontifex

Anyone delivering work to clients needs documents that describe that work: a timesheet, a progress report, a decision log, a commercial proposal. Assembling them by hand, after the fact, means stopping work to reconstruct it. Pontifex starts from the opposite premise: the record of the work already exists in sessions and commits, and the documents should come out of it.

Pontifex is Sigil Labs’ own operations and reporting toolset. It is the third of three toolsets Sigil Labs maintains, after a skill library for agents (superpowers) and Hadur, the review discipline. It delivers:

• timesheets for four audiences (client, manager, internal and accounting), as Markdown, PDF, JSON or CSV, with the CSV, carrying an hourly rate, reserved for accounting;
• client reports with an executive summary and project phases, with the decision log and scope changes added in the manager and internal versions;
• commercial proposals in Portuguese, in three working modes (automatic, wizard and skeleton), with pricing calculated by Sigil Labs’ methodology;
• a quality report built from Hadur findings, with a full version for the team and a warranty version for the client;
• scheduled reports, generated and saved without anyone having to remember to ask;
• automatic grading of AI responses during a session, scored from 1 to 5 with a short comment, which can be switched off per project;
• a history of tokens spent per project, in which measured and estimated values are always labeled.

Claude Code hooks record each session (when it started, which files changed, what was decided) in an agency vault. Every session belongs to a project, and that project’s identifier is declared in a registry rather than inferred from the folder name. The reason: if each side inferred the identifier on its own, one differing accent mark would be enough to keep a project’s hours from ever meeting its commits, and the report would come out partial but plausible.

A harvester on the server collects the commits and joins them to the hours through the same identifier. When the registry was introduced, the Sigil Labs working folder held about 40 projects and only one had local Pontifex configuration; the rest lost their telemetry without any error. Hooks never block a session: if the project is not in the registry, the session is still recorded, under a provisional identifier that the panel flags. Reports, on the other hand, fail loudly when a project is missing from the registry, because a report built without the registry would look, at a glance, like a correct one.

Pontifex can be used in four ways:

• from the command line;
• through a web interface, with a panel of green, amber or red cards that show, among other things, the state of synchronization, commit collection, the project registry and response quality;
• through a delivery portal with a login, where each person sees only the clients, and the level of detail (client, manager or internal), that were granted to them;
• through an MCP server with seven report tools (five that generate documents, plus a client list and a vault status check) and read-only query tools. One of the queries runs SQL, through DuckDB, over the commits, sessions, hours, tokens and projects tables, capped at 1,000 rows and 20 seconds per query.

By default, the operating system’s scheduler wakes Pontifex every 15 minutes to check which reports are due.

Pontifex is an internal Sigil Labs tool with proprietary code, and it is not a product for sale. It exists so that Sigil Labs’ own team can produce hours, reports and proposals from what actually happened. The current version is 1.0.0 and it requires Python 3.11 or later.

Proposals with equity participation, or with rights assignment and revenue share, produce only an internal, non-binding draft, marked as pending legal review. The final client document depends on lawyer-vetted contracts, which sit outside Pontifex.

Pontifex inherits its review methodology from Hadur and reads the tree of findings that Hadur produces to build the quality report.