Champion kit
A champion is the person on a team who got comfortable with Syntic Code early and is willing to help others get there. This page is for you if you have taken on that role. It covers what the job is (and is not), how to share what you learn, how to answer the questions you will hear, and a simple plan for your first month.
What the role is
- A first point of contact for questions on your team, so people don’t get stuck alone.
- A source of real examples. Your own work shows what the tool is good at far better than any guide.
- A feedback line to whoever runs the rollout: what gets in people’s way, which rules are too strict, which are missing.
What it is not: a trainer, a support desk, or someone who has to know every feature. “Let me check” is a perfectly good answer.
Time
Expect about an hour a week for the first month, mostly answering questions as they come up and posting one or two tips. After that it usually drops to a few minutes here and there. If it takes much more, tell the rollout lead; that is a sign the setup needs work, not that you need to try harder.
Share what you find
Good things to post
The most useful posts are small and specific:
- A prompt that solved a real problem, with the result.
- A permission rule that removed a repeated prompt for the whole team.
- A line you added to
SYNTIC.mdthat stopped a recurring mistake. - A time it went wrong, and what you changed to prevent it.
The failures are often more useful than the wins. They show where to be careful, and they make the tool feel honest rather than hyped.
Where to share it
Wherever your team already talks: the team channel, stand-up, or a short slot in a team meeting. A separate channel just for Syntic Code is useful during the pilot but tends to go quiet later; bring the good posts back to the team’s normal places.
A format that works
Three lines are enough:
Task: Track down why the nightly export skipped some rows. What I asked: “The export in
jobs/export.pydrops rows when [condition]. Find out why and write a failing test first.” Result: Found an off-by-one in the paging logic in about ten minutes, with a test. Reviewed and merged as usual.
Be the person people ask
Answer with a prompt
When someone asks “can it do X?”, the fastest answer is often to try it together. Open a session, type the prompt, and let them watch. People learn more from seeing one good prompt than from a description of the feature.
Point at the feature, not the manual
Most questions have a short answer that names a command or a setting:
| Question | Short answer |
|---|---|
| ”It keeps asking before it runs our tests.” | Allow the test command with a rule in .syntic/settings.json. See Permission rules. |
| ”It doesn’t follow our conventions.” | Add them to SYNTIC.md. /memory shows which memory files are loaded. |
| ”The session got slow and confused.” | /clear for a new task, /compact to shrink a long one. |
| ”I want to see the plan before it edits anything.” | Plan mode: Shift+Tab until the footer shows it. See Permission modes. |
| ”It changed something I didn’t want.” | Rewind to an earlier point. See Checkpointing. |
| ”How much have I used?” | /usage for your plan, /cost for this session. |
| ”Something seems broken.” | syntic doctor, then /feedback to save a report. |
| ”Can it use our issue tracker?” | Probably, through an MCP server, if your organization allows it. See MCP servers. |
Questions you’ll hear
“Will it replace us?” It handles parts of the work that are slow and repetitive. Decisions about what to build, judging whether a change is right, and reviewing it remain with people. Teams that use it well tend to spend more time on those parts, not less.
“Is it safe to let it run commands?” It asks before running anything not on an allow list, and your organization has deny rules in place. Read what it proposes before approving, the same as you would for a script from a colleague.
“Is the code it writes any good?” Sometimes very, sometimes not. It does better when it knows how to check its work, so tell it which tests to run. Review its changes like any other pull request.
“Why did it do something odd?” Usually missing context. Ask it to explain its reasoning, then add the missing fact to SYNTIC.md so it doesn’t happen again.
Grow the circle
Patterns that tend to work
- Pair for twenty minutes with someone on their own task. This beats any demo.
- Collect good prompts in a shared file or a skill in the repository, so they are one command away.
- Improve
SYNTIC.mdtogether. When someone hits a wrong assumption, fix the file in the same pull request. - Celebrate small wins in public, and name the person, not the tool.
Your first thirty days
| Week | Focus |
|---|---|
| 1 | Make sure everyone on the team can sign in and run a first session. Collect setup problems and pass them on. |
| 2 | Post two examples from your own work. Pair with one or two people who have not got going yet. |
| 3 | Review the project’s SYNTIC.md and shared permission rules with the team. Remove friction. |
| 4 | Ask the team what they want next (an MCP server, a hook, a shared skill) and send the list to the rollout lead. |
When someone wants to go deeper
Point them to:
- Hooks to run their own checks around the agent’s actions.
- Subagents for focused helpers with their own instructions.
- Skills to package a repeatable procedure.
- Headless mode for scripts and CI.
Responding to concerns
Take concerns seriously, and answer with specifics rather than enthusiasm.
| Concern | A useful response |
|---|---|
| Code quality | ”Let’s try it on one real ticket and review the result together.” |
| Security | Explain the deny rules and approvals in place, and pass any gap you hear about to the rollout lead. See Security. |
| Data leaving the company | Point to Data usage, and to your organization’s own policy. |
| Cost | Share the cost habits. Most savings come from smaller context. |
| ”I’m faster without it.” | That may be true for some work. Suggest one task type to try it on, and accept the answer. |
Not everyone needs to use it for everything. A team where a few people use it daily and others occasionally is a healthy result.
Quick reference
| Need | Command or setting |
|---|---|
| Write a first project guide | /init |
| See loaded memory files | /memory |
| Manage permission rules | /permissions |
| Change model or speed | /model, /fast, /effort |
| Start fresh / shrink context | /clear, /compact |
| Check the setup | syntic doctor |
| Check sign-in | syntic auth status |
| Review current changes | /review |
| Usage and cost | /usage, /cost |
| Save a problem report | /feedback |