Skip to main content

Write a coding task

Coding does not require a fixed template, but an actionable request should answer four questions: what result is needed, what may change, what must not happen, and how completion will be checked.

General structure​

Outcome: Fix the settings page showing the old value after save.
Scope: Change only the settings page and its data-request code.
Constraints: Do not change the database schema, add dependencies, or overwrite existing uncommitted work.
Done when: Reproduce the issue, implement the fix, run relevant checks, and report changed files and anything not checked.

Name known directories, commands, and files. If they are unknown, ask Ghast to investigate and report first instead of guessing paths.

Common task types​

Fix a bug​

Provide reproduction steps, expected behavior, actual behavior, and the allowed change area. Include operating system, account, or data conditions when the problem depends on them.

Add a feature​

List the user entry point, primary states, error states, existing behavior that must remain, and completion criteria. Attach a design or screenshot and state which details are required to match.

Refactor​

State which external behavior must not change and which commands or scenarios should confirm that. “Improve this” rarely defines a safe boundary.

Read-only review​

Investigate and report only. Do not edit files, run state-changing commands, install dependencies, or change Git.
List findings by severity and include file locations.

Also switch command authorization to Ask and disable unneeded Tools. A written constraint does not replace a capability control.

Authorize risky actions separately​

Completing the task is not blanket authorization for later actions. State whether each of these is allowed:

  • installing or upgrading dependencies and changing lockfiles;
  • migrations, database writes, or production access;
  • signing in to services, sending messages, or creating remote objects;
  • staging, committing, pushing, creating a Pull Request, or merging;
  • deleting files, discarding changes, or removing a worktree.

Work with existing changes​

When a project already has uncommitted work, identify files that belong to it and ask Ghast to show Git state first. If the new task may touch the same file, name the content that must be preserved. If the changes cannot be separated safely, pause edits to that file.

Make the result reviewable​

Ask the final response to include the cause or approach, changed files, commands run, results, and unfinished work. For UI tasks, add the target interaction path. For service tasks, add an observable request, response, or log outcome. Then inspect Review and inline diffs and the Git panel yourself.