The pipeline
- 01
Work comes in
A meeting note, a short written request, a production alert, a groomed backlog item, or a call from another AI tool over MCP. CodeLynq pulls the actual work out of whatever arrives.
- 02
Scope gets settled
The validation chat asks what was left unsaid: edge cases, scope, acceptance criteria. Ambiguity is resolved while it is still a conversation rather than a diff.
- 03
You approve the technical spec
CodeLynq drafts a Technical Solution Document against your actual codebase, informed by what it has learned from your previous runs. You review, comment and approve. The architecture stays your call.
- 04
The run builds and checks its own work
The agent implements the approved spec, then runs your verify command, reviews its own diff, scans it for security issues and updates the docs — fixing what it finds before a human sees it.
- 05
A pull request opens, and keeps up
The PR lands in your normal review flow. When CI fails or a reviewer asks for changes, CodeLynq iterates on the same branch until it is green or it hits the limit you set.
- 06
Release and operate
You merge — CodeLynq never does. That merge can then trigger your own deploy pipeline and record the release. When something breaks later, live debugging works against your real environment through limits you set.
What a development run actually does
A run clones your repository, reads the approved spec and the context you gave the project, makes the change, and runs your verify command. If that command fails it tries to fix the problem rather than opening a broken pull request.
Before the pull request opens, the diff goes through a self review and a security scan. Findings feed back into the same run.
When continuous integration reports back
If your CI fails on the pull request, or a reviewer asks for changes, CodeLynq can pick that up and iterate on the same branch until the checks pass or it reaches the limit you set. It never opens a second pull request for the same task.
What your reviewers asked for does not stop at that branch. It is distilled into durable memory for the project, so the next run starts already knowing the convention you just explained.
After the merge
You merge — CodeLynq has no ability to merge anything itself. That merge can then trigger your own deployment pipeline, either a GitHub Actions workflow or a signed webhook to whatever you already run, and the release is recorded against the commit so you can see what shipped and when.
When something misbehaves later, the troubleshooting agent can look at the running environment rather than guessing from the code: application logs, read-only database queries, and a command allowlist you write yourself. Each of those is opt-in per environment and does nothing until you enable it.