What makes the plan trustworthy
The plan is grounded.
The work is checked.
An agent that only knows your prompt writes a plausible plan. These are the things
that make the output answerable to your systems and your definition of done.
Grounded in your system
Your codebase, not just your prompt.
Point Codepixel at an existing repository and it indexes the code — every file chunked,
typed by language and summarised into how the system actually fits together — and
re-indexes as commits land. Share architecture docs and prior specifications alongside it
(Markdown natively; PDF, DOCX, PPTX, XLSX and HTML through a converter), split along their
headings. Plans are retrieved from that corpus rather than invented.
Context
4 documents
·
21 systems known
·
3 PRD sections unsupported
Multi-repository impact
Which repositories does this change touch?
The question a lead asks first about a ticket on an estate they did not write, and the one
most tools cannot answer. Codepixel selects the repositories in scope and then shows the
evidence for each: the files that import what is changing, and the services that consume a
schema or a signature being altered — including the repository that never mentions
the change by name and breaks anyway. Selection is kept separate from evidence on purpose,
so a cheap guess is never dressed up as a finding.
In scope
3 repositories
·
11 files implicated
·
1 consumer, no direct reference
Cited PRDs
Every claim traces to a source.
Claims in a generated PRD carry a footnote that resolves to the exact passage
supporting them, shown with its heading path so a reviewer can find it in the original
document. A section the engine could not ground is counted as unsupported rather than
quietly passed — the number is honest in the direction that costs us.
Settlement must continue to run through the existing ledger
service.1
platform-architecture.pdf
Services › Ledger › Settlement
Quality gate
“Done” is something a machine checked.
Before a ticket can reach review it passes three stages, cheapest first, stopping at
the first failure. When it fails, the ticket goes back to the agent with the reason
— not onto your review pile.
-
1
Baseline. The dependency manifest is committed, dependencies install from
a clean checkout, and the app answers on its port.
-
2
Criteria. The runnable check attached to each acceptance criterion.
-
3
Judge. A second model reads the evidence and may only fail a
ticket, never pass one — and it is never the model that wrote the code.
It gets better at your codebase
A ticket you repaired becomes a rule.
When the gate rejects a ticket and the agent fixes it, what was wrong is worth more than
the fix. Codepixel records it as a candidate rule, and a person keeps or discards it at the
review gate — nothing reaches a later build on the model’s own say-so. Kept rules
join the conventions drafted from your code when the repository was first read, so the
second ticket in a codebase starts where the first one finished.
Teams with domain knowledge that is not in any repository can add it as a skill pack:
a folder of plain markdown, versioned alongside the project, that the agent reads before
it plans. Insurance rules are not code, and they should not have to be.
After it ships
Verified against the thing that is running.
The quality gate checks a ticket in a sandbox, before it merges. That is not the same
question as whether the deployed application does what the issue asked, and one cannot
stand in for the other. Codepixel derives a probe from each acceptance criterion and runs
it against the live environment after release, so the ticket closes on evidence from
production rather than on a merge.
GitHub
GitLab
Bitbucket
Jira
Linear
Slack
Notion