By name: myhiss-terminal-tasks description: Orchestrates Myhiss terminal task flows. Invoke when planning onboarding, workspace trust, multi-step coding tasks, review loops, or validation steps in the CLI/TUI.
Myhiss Terminal Tasks
Purpose
This skill defines how Myhiss should structure and execute terminal tasks from start to finish.
Use it when the task involves:
- multi-step terminal flows
- workspace initialization
- trusted-folder checks
- provider setup sequences
- code review loops
- validation and follow-up actions
Task Philosophy
Myhiss should behave like an organized engineering operator, not a loose chat interface.
Each task should have:
- a clear start state
- a clear current step
- a clear next action
- a safe finish state
Standard Task Stages
1. Context Capture
Establish:
- current workspace
- relevant files
- selected provider
- whether credentials are available
- whether the folder is trusted
2. Intent Framing
Translate user intent into an explicit task category such as:
- inspect code
- refactor file
- configure provider
- run diagnostics
- review changes
- apply changes
3. Controlled Execution
Only execute the next necessary step.
Keep each stage bounded and observable.
4. Review and Confirmation
When a task changes files or configuration, the user must understand:
- what changed
- why it changed
- what remains pending
5. Verification
When possible, verify with:
- project checks
- smoke runs
- diagnostics
- runtime status
Required Flows
First-Run Flow
The first-run task sequence should be:
- welcome screen
- trust workspace
- choose theme
- choose provider
- collect credentials or local endpoint
- choose approval mode
- confirm readiness
- open prompt workspace
Code Change Flow
The code-change task sequence should be:
- identify files
- inspect contents
- propose edits
- show review state
- apply on approval
- validate
Provider Recovery Flow
If a provider fails:
- preserve session context
- explain the failure mode
- suggest a direct recovery action
- allow retry or provider switch
State Management Rules
The terminal should always make the current state obvious.
Track at minimum:
- idle
- loading
- needs-input
- reviewing
- applying
- success
- error
Do not allow hidden transitions that confuse the user.
Task Copy Guidelines
For each screen or task banner, prefer:
- one status line
- one instruction line
- one primary action
Examples:
- Workspace trusted. Choose a theme.
- Provider selected. Enter an API key.
- Review ready. Apply or reject changes.
Implementation Guidance
When implementing task orchestration:
- Represent task stages as explicit states.
- Keep setup flows separate from editing flows.
- Make retry behavior consistent across providers.
- Preserve enough context so the user can recover after an error.
- Run validation after mutation, not before marking success.
Gotchas
- Do not skip trust or setup steps when local configuration matters.
- Do not merge unrelated actions into one overloaded prompt.
- Do not mark a task complete before validation finishes.
- Do not lose the user's previous input when a provider request fails.
- Do not hide whether the system is waiting on network, user input, or file I/O.
Definition of Done
A Myhiss terminal task is complete when:
- the stage progression is clear
- the user knows the current state
- risky actions are reviewable
- failures are recoverable
- validation has been attempted when relevant