Files
global-skills/protocols/workflow.md
T

2.6 KiB

Shared workflow

Skills simplify an authorized task. User instructions and repository conventions set the scope; a skill supplies defaults where those leave a gap.

  • Use the existing conversation, files, and project state before asking questions. Ask only when a missing answer changes the outcome and cannot be inferred safely.
  • A report or audit stays read-only. An implementation request authorizes the necessary reversible edits and checks. Continue authorized work without asking the user to approve each step.
  • Follow the repository's operational boundaries (agents-template.md): distinguish autonomous actions (ALWAYS), user-approved boundaries (ASK FIRST), and hard invariants (NEVER).
  • Do not create a spec, force a review, run an editing skill, or start a refactor merely because another skill mentions it. Use another workflow only when its prerequisites and purpose fit the current task.
  • Preserve unrelated changes. Stage and commit only within the authorized scope, following repository and session instructions. A skill does not require commits.
  • Keep references optional: read the relevant section when needed. Do not load every protocol or checklist on each task.
  • Report completion and pull requests using the telemetry protocol (WHAT-WHY-HOW-LEARNINGS).

Verification

"The model proposes, but the engine measures." Choose checks that can detect a real failure in the changed behavior.

  1. Run the smallest relevant check first: syntax, a focused test, type check, rendered interaction, or direct output inspection.
  2. Broaden to integration or the full suite when shared behavior, security, migrations, or unresolved failures justify it, or project instructions require it.
  3. Do not add tests that mirror implementation or cover only a reversible prose or cosmetic edit. Add regression coverage for meaningful behavioral bugs when practical; a reproduction or manual check can be the evidence when automation is unsuitable.
  4. Distinguish new failures from pre-existing failures and missing dependencies. Report what passed and what remains unverified; do not claim unavailable checks passed or rewrite unrelated code to make the entire repository green.
  5. Once relevant checks pass, stop repeating them unless something changed.
  6. When reporting verification in task handoffs or PRs, document the exact terminal command, exit code, and pass counts under the HOW section of telemetry.

Complete means the requested behavior is implemented and supported by empirical evidence. A successful command exit alone does not prove the user-facing outcome.