Everyday tasks
Syntic Code ships with commands for the jobs developers do every day. Each one turns into a carefully worded request to the agent, so you get a consistent result without retyping instructions. This page also collects prompt ideas and habits that make sessions go smoothly.
Get to know a codebase
| Command | Does |
|---|---|
/init [focus] | Studies the project and writes a SYNTIC.md guide (build and test commands, layout, conventions) for future sessions. Run it once per repository. |
/team-onboarding [role or focus] | Writes an ONBOARDING.md ramp-up guide for a new teammate. |
/deep-research <question> | Investigates a question in several steps and answers with sources. |
Prompt ideas:
Trace what happens from the moment a user clicks "Pay" to the row landing in the orders table.
Which modules would I touch to add a new export format? List them with one line each.
Where are feature flags read, and which ones are dead?Plan before you build
/planswitches to plan mode: the agent reads and proposes but changes nothing./plan <task>switches and sends the task in one go. When the plan looks right, approve it and the agent starts working./ultraplan <task>asks a background subagent for a long-form plan (goal, what exists, approach, steps, risks, tests, open questions). It writes the plan to your plans folder (~/.syntic/plans) and reports the file path when done.
Reviews
| Command | Does |
|---|---|
/review [PR number or focus] | Reviews your current changes, or a pull request. |
/code-review [level] [--fix] [--comment] [--max-findings N|all] [target] | A bug hunt that runs in a background subagent, so it does not fill your conversation. Findings are shown when it finishes. |
/ultrareview [--fix] [target] | The deepest review: three passes (correctness, security, tests) run side by side, then their findings are merged, de-duplicated and sorted by severity. |
/security-review | Looks at the pending changes on your branch for security problems. |
/simplify [focus] | Cleans up changed code (reuse, simpler logic, faster paths) and applies the fixes. |
/code-review levels:
| Level | Reports | Findings shown (default) |
|---|---|---|
low | Only clear, high-confidence bugs | 5 |
medium | Likely bugs, each with a concrete case | 10 |
high | Adds plausible bugs, marked as uncertain | 20 |
max | Everything, with one subagent per area | 40 |
With no level, the one you used last in the session is reused (medium the first time). --fix applies the fixes afterwards; --comment posts the findings as pull request comments (needs the gh CLI); --max-findings changes the cap.
Commits and pull requests
| Command | Does |
|---|---|
/commit [instructions] | Writes a commit for the current changes. |
/commit-push-pr [instructions] | Commits, pushes and opens a pull request. |
/pr-comments | Pulls in the review comments on the current pull request. |
/autofix-pr [number|url] | Reads a pull request’s failing checks (with the tail of each failed log) and its review comments, then starts a subagent that fixes them on the branch and commits locally. Nothing is pushed. Uses gh, or glab for GitLab. |
Pushing to a remote always asks for your OK in auto mode. Commits get an attribution line by default; change or remove it with the attribution setting (Settings keys).
Big changes in parallel
/batch <task>splits a large change into parts and runs them with parallel agents; every agent gets a separate git worktree. See Parallel work with worktrees./init-verifierssets up automated checks the agent can run to verify its own work in this project.
Quick questions on the side
/btw <question> asks something without derailing the current task. The answer is shown, but it is not added to the main conversation. /btw on its own lists recent side questions.
Show it, do not describe it
| Share | How |
|---|---|
| A file | Type @ and pick it, for example @src/auth/session.ts. Its contents go straight into the conversation. |
| A folder | @src/auth/ points at a whole folder. |
| A screenshot or mockup | Copy the image and press Ctrl+V in the prompt. |
| Command output | Pipe it in from your shell: npm test 2>&1 | syntic -p "why do these fail?". |
| An MCP resource | @<server>:<uri>, for example @docs:file:///guide.md (MCP servers). |
Prompts that work well with images: “Build this form to match the mockup”, “What is wrong with the layout in this screenshot?”, “Turn this whiteboard photo of the schema into a migration”.
Think harder on hard problems
For tricky bugs, architecture questions and plans, give the model more room to reason:
/effortcycles the reasoning effort (low,medium,high). Higher effort is slower and costs more, and pays off on problems with many moving parts. See Models & reasoning.Alt+Tturns reasoning on or off;/thinkingexpands or collapses the reasoning blocks in the transcript.Ctrl+Oopens the full transcript, including tool calls and reasoning, when you want to see how it got somewhere.
Use it as a command-line tool
syntic -p reads standard input and prints a result, so it fits into pipes and scripts:
# explain a failure
cat build.log | syntic -p "what is the root cause? one paragraph"
# write a commit message
git diff --staged | syntic -p "write a conventional commit message for this diff"
# machine-readable output
syntic -p "list the public functions in src/lib.rs" --output-format json | jq -r .resultAdd it to package.json scripts, git hooks or CI jobs. See Scripting and CI.
Pick up later, or try another way
| To | Do |
|---|---|
| Continue the last conversation in this folder | syntic -c |
| Pick an older one | syntic --resume, or /resume in a session |
| Give the current one a name you will recognize | /rename <name> |
| Try a different approach without losing this one | /branch copies the conversation into a new session |
| Undo the last edits | Esc twice on an empty prompt, or /rewind |
See Sessions and resume and Checkpointing.
Ask about Syntic Code itself
“How do I add an MCP server?”, “What does /goal do?”, “Can you run in CI?” are fair questions in any session. A built-in guide agent answers questions about Syntic Code’s own features. /help lists the commands, /keybindings the keys, and /powerup gives short lessons on features that are easy to miss.
Prompt ideas
Many more, grouped by task, are in the Prompt library.
| Goal | Try |
|---|---|
| Fix a failing test | ”npm test -- auth fails on the token refresh case. Track down the cause and repair it; leave the test as is.” |
| Add a feature end to end | ”Add a --dry-run flag to the import command. Show what would change, write nothing, and add tests.” |
| Refactor safely | ”Split OrderService into read and write parts. Keep the public API the same and run the tests after each step.” |
| Write tests | ”Cover parseDuration with table-driven tests, including bad input.” |
| Update dependencies | ”Upgrade the HTTP client to the latest minor version and fix whatever breaks.” |
| Understand an error | Paste the stack trace and ask “what is the root cause, and what is the smallest fix?” |
| Work from a screenshot | Ctrl+V a screenshot of the broken page and ask for the fix. |
Habits that pay off
The longer version, with examples, is Best practices.
- Say what done looks like. “Tests pass and the CLI prints the new column” beats “improve the output”.
- Hand it a yardstick. Mention the test or build command, or put it in
SYNTIC.md, so the agent can verify before it reports back. - Plan first for anything big. A minute in plan mode saves a lot of rework.
- Keep sessions focused. One task per conversation;
/clearbetween unrelated jobs. - Interrupt early. If the agent heads the wrong way, press
Esc, say what to change, and send again. - Write lessons down. When you correct the same thing twice, add it to
SYNTIC.md(start a message with#to do it in one step). - Let rules do the approving. If you keep clicking yes for the same safe command, add an allow rule instead (Permissions).
Want your own commands like these? See Skills & custom commands.