Certyn is most effective when it has stable, explicit context about your application. The Wiki is where you provide that context so its agents can make better decisions, write better tests, and produce higher-signal issues.
What lives in the Wiki
In the app, open Knowledge from the sidebar. It has four tabs:
- Overview: what the product does, who uses it, critical flows, and what to ignore.
- Rules: testing rules that should always hold, including your Definition of Ready.
- Skills: your team's procedures, for example how you test checkout.
- Sources: the specs and task systems Certyn reads, through your connections.
The wiki also has a Business logic section. It has no tab: ask Certyn in the chat to read or edit it.
Keep these short, testable, and stable. Treat the wiki like the "ground truth" you would give a QA engineer on day one.
Runs and the chat get the start of each section in their prompt, and read the full text when they need it. Every save keeps a version. To go back, ask Certyn in the chat to restore an older one.
Product docs and specs
Connect the system where your docs and specs live under Sources. Ask Certyn reads them in the chat, for example to write test cases from a spec. Put what every run must know in the wiki. Avoid putting secrets or personal data in the wiki.
How context affects Runs and Issues
With better context, Certyn can:
- focus exploration on critical workflows
- avoid "false failures" caused by ambiguous expectations
- write tests that are aligned with real business rules
- produce issues with better reproduction steps and impact statements