feat: refresh shared skills catalog

protocols/workflow.md

@@ -0,0 +1,45 @@
+# 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](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](telemetry.md)
+  (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.