What to Do First
A concrete first-week playbook for getting real value out of a fresh Cygent instance.
Overview
You've finished the install wizard, the agent is running, and Cygent has DM'd you in Slack. Now what?
This is the playbook Cyfrin runs new customers through. Five steps, each one concrete — real commands, real outputs to look at, real decisions to make.
Step 1 — Run your first full audit
Pick your most active repo (not the archive you forgot about) and kick off an audit. Three equivalent ways to do it:
| Surface | How |
|---|---|
| Dashboard | Projects tab → select the repo → click Run Audit |
| Chat | @cygent run a full security audit on <repo> |
| GitHub | Drop /cygent audit as a comment on the default branch |
The live progress view shows CARA working through the codebase. Expect a few minutes for a small repo, longer for a monorepo. You'll get a notification in your default review channel when it's done.
For a first run, audit the whole repo. On subsequent runs you can scope to a specific contract (@cygent audit Vault.sol) or a branch to speed things up.
Step 2 — Triage the findings
Open the project in the dashboard. You'll see findings grouped by severity — Critical, High, Medium, Low, Info — each with a title, a root cause, a code location, and a recommendation. For each finding, you've got three calls to make:
| Question | What to do |
|---|---|
| Is this real? | If it's a textbook pattern that isn't reachable in your protocol, mark it Invalid with a reason. |
| Is this a priority? | Critical and High fix before next deploy. Medium gets scheduled. Low/Info live in the backlog. |
| Deserves a GitHub issue? | Anything above Medium should get one. Configure auto-issue creation in settings if you want this automated. |
Marking findings Invalid is a feature, not a limitation. A scanner-only tool dumps everything it finds on you. Cygent reasons about which findings actually matter in your protocol. See Understanding Findings for the full lifecycle.
Step 3 — Fix your first finding with Cygent Code
Pick a real finding — preferably a High or Critical — and ask Cygent to fix it. In your chat channel:
@cygent plan how to fix finding H-1
Cygent replies with an implementation plan: files it'll touch, functions it'll modify, any tests it'll add. Read the plan. If it looks right, approve:
@cygent looks good, open the PR
Cygent writes the code, runs the build to verify, and opens a PR on GitHub. You can keep iterating in the same thread — also add a natspec comment explaining the fix, use a mapping instead of an array. See Cygent Code overview for the full workflow.
Step 4 — Watch a PR review happen live
Open any pull request on a connected repo — even a trivial one is fine. Within a minute or two, Cygent will either review it automatically or ask for confirmation, depending on your autonomy setting.
Look at what the inline comments look like on GitHub. Each comment has a severity indicator, a description of the issue, and a recommendation. The PR summary in your review channel categorizes findings three ways:
| Bucket | Meaning |
|---|---|
| New | Issues introduced by this PR |
| Still present | Pre-existing issues this PR didn't touch |
| Resolved | Issues this PR fixed |
That three-way split is the point — you're looking at "did this PR make things better or worse?", not just "are there bugs in the diff?". See PR review comments.
Step 5 — Schedule something recurring
The single highest-leverage habit: pick one repeating security task and schedule it. Start with one of these:
- Weekly audit.
@cygent schedule a full audit of <repo> every Monday at 9am EST - Daily DeFi threat monitor.
@cygent schedule a task that scrapes rekt.news daily and checks our codebase for the same vulnerability classes - PR review digest.
@cygent schedule a task that summarizes PRs merged in the last 7 days, every Friday at 4pm
Confirm the task in the Scheduled Tasks tab on the dashboard. Once it fires a few times, you'll see the run history build up. See Scheduled Tasks for the full pattern library.
Once those five are done, you've exercised every major Cygent capability at least once.
After your first week
The habits that separate teams who get long-term value from teams who let the instance go stale:
- Triage quickly. Don't let the Active findings list grow past what you can scan in a morning. Invalid is a valid outcome.
- Use Cygent Code for real work, not just demos. Let it fix the boring High findings so your engineers spend their time on the interesting ones.
- Add Cygent to your design conversations. Invite it to Google Meet calls when you're debating architecture. The context it picks up becomes the rules for future audits.
- Review the scheduled task output. If your Monday audit is producing the same three findings every week, something's not getting fixed — that's a signal to act, not to ignore the digest.