myhiss-terminal-tasks

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:

1. welcome screen
2. trust workspace
3. choose theme
4. choose provider
5. collect credentials or local endpoint
6. choose approval mode
7. confirm readiness
8. open prompt workspace

Code Change Flow

The code-change task sequence should be:

1. identify files
2. inspect contents
3. propose edits
4. show review state
5. apply on approval
6. validate

Provider Recovery Flow

If a provider fails:

1. preserve session context
2. explain the failure mode
3. suggest a direct recovery action
4. 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:

1. Represent task stages as explicit states.
2. Keep setup flows separate from editing flows.
3. Make retry behavior consistent across providers.
4. Preserve enough context so the user can recover after an error.
5. 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