Menu
简体中文
On this page

Common Workflows

Docs home · 简体中文

These examples are starting points for day-to-day repository work. They assume you are running the TUI with:

cd /path/to/workspace
sigil

Explore An Unfamiliar Repository

Start read-only:

Explain the repository structure. Identify the main entrypoints, test layout, configuration files, and user documentation.

Follow up with a focused question:

Explain how Sigil handles this request. Identify the user-visible stages, likely files it needs to inspect, and where it will show errors or approvals.

Good signs:

Make A Small Change Safely

Give the goal, scope, and verification expectation:

Update docs/en/quickstart.md so the first-run path is clearer for new users.
Keep the change docs-only.
After editing, check links and run the static docs checks if available.

When approval appears, review the diff before allowing it. After the run:

git diff

If the edit is too broad, deny it and restate the scope.

Plan A Larger Feature Or Refactor

Use /task when the task crosses multiple files or needs durable sequencing:

/task add a troubleshooting section for terminal copy failures and link it from the TUI guide

Then review the generated task plan before letting execution continue. You can steer the next step:

Keep this docs-only. Do not edit Rust code. Update both English and Chinese docs.

Use:

/task continue

when the latest task should continue without extra guidance.

Debug A Failing Command

Paste the failing command and the relevant output:

cargo test failed. The failing assertion says the help text is missing Alt-D.
Find the source of that help text, explain the likely cause, and propose the smallest fix before editing.

For safer debugging, ask Sigil to inspect first and edit second:

Read the failing test and implementation first. Summarize the root cause and wait before changing files.

Review Local Changes

Ask for a review stance:

Review the current diff for user-facing regressions, stale docs, and missing validation. List findings by severity with file references.

Then decide whether to apply fixes:

Fix the high-severity docs findings only. Leave unrelated Rust changes untouched.

Resume Previous Work

Use:

/resume

Select a session from the list. Restored sessions rebuild visible conversation and durable task state. Tools that were interrupted are shown as interrupted; Sigil does not silently replay them.

If the latest planned task is still unfinished:

/task continue

or type guidance in the composer.

Use Code Intelligence

Enable it in config:

[code_intelligence]
enabled = true
server_startup = "lazy"

In the TUI, use:

Alt-D

to run diagnostics over changed source files. Code intelligence can also provide symbols, definitions, references, code actions, and rename previews when an LSP server is available.

If no LSP server is available, normal chat and file tools still work. See Sigil Configuration Guide and Troubleshooting.

Connect External Tools With MCP

Use MCP when Sigil needs tool-backed access to external systems or specialized local capabilities.

Typical pattern:

  1. Configure a server in [[mcp_servers]].
  2. Set a conservative trust policy.
  3. Start with approval_default = "ask".
  4. Use /doctor to check command and trust configuration.
  5. Let Sigil list and call MCP tools only after you understand what the server can access.

See Sigil MCP Guide.

Prompt Patterns That Work Well

Good prompts include:

Example:

Improve docs/en/configuration.md for new users.
Keep provider-specific advanced fields, but move the common path before the full reference.
Update the Chinese mirror if needed.
Run docs link/path checks after editing.

What To Review Yourself

Sigil can inspect, edit, and run commands, but you should still review: