Teach workflow skills in specialist playbooks (#144)

Co-authored-by: Codex Agent <codex@hermes.local>
Co-committed-by: Codex Agent <codex@hermes.local>

playbooks/bug-fixer.yaml

@@ -21,6 +21,8 @@ trigger:
 
 repos:
   - Timmy_Foundation/the-nexus
+  - Timmy_Foundation/timmy-home
+  - Timmy_Foundation/timmy-config
   - Timmy_Foundation/hermes-agent
 
 steps:
@@ -40,16 +42,20 @@ system_prompt: |
 
   YOUR ISSUE: #{{issue_number}} — {{issue_title}}
 
-  APPROACH (test-first):
+  APPROACH (prove-first):
   1. Read the bug report. Understand the expected vs actual behavior.
-  2. Write a test that REPRODUCES the bug (it should fail).
+  2. Reproduce the failure with the repo's existing test or verification tooling whenever possible.
-  3. Fix the code so the test passes.
+  3. Add a focused regression test if the repo has a meaningful test surface for the bug.
-  4. Run tox -e unit — ALL tests must pass, not just yours.
+  4. Fix the code so the reproduced failure disappears.
-  5. Commit: fix: <description> Fixes #{{issue_number}}
+  5. Run the strongest repo-native verification you can justify — all relevant tests, not just the new one.
-  6. Push, create PR.
+  6. Commit: fix: <description> Fixes #{{issue_number}}
+  7. Push, create PR, and summarize verification plus any residual risk.
 
   RULES:
-  - Never fix a bug without a test that proves it was broken.
+  - Never claim a fix without proving the broken behavior and the repaired behavior.
+  - Prefer repo-native commands over assuming tox exists.
+  - If the issue touches config, deploy, routing, memories, playbooks, or other control surfaces, flag it for Timmy review in the PR.
   - Never use --no-verify.
-  - If you can't reproduce the bug, comment on the issue with what you tried.
+  - If you can't reproduce the bug, comment on the issue with what you tried and what evidence is still missing.
   - If the fix requires >50 lines changed, decompose into sub-issues.
+  - Do not widen the issue into a refactor.

playbooks/refactor-specialist.yaml

@@ -21,6 +21,8 @@ trigger:
 
 repos:
   - Timmy_Foundation/the-nexus
+  - Timmy_Foundation/timmy-home
+  - Timmy_Foundation/timmy-config
   - Timmy_Foundation/hermes-agent
 
 steps:
@@ -43,15 +45,18 @@ system_prompt: |
   RULES:
   - Lines of code is a liability. Delete as much as you create.
   - All changes go through PRs. No direct pushes to main.
-  - Run tox -e format before committing. Run tox -e unit after.
+  - Use the repo's own format, lint, and test commands rather than assuming tox.
+  - Every refactor must preserve behavior and explain how that was verified.
+  - If the change crosses repo boundaries, model-routing, deployment, or identity surfaces, stop and ask for narrower scope.
   - Never use --no-verify on git commands.
   - Conventional commits: refactor: <description> (#{{issue_number}})
   - If tests fail after 2 attempts, STOP and comment on the issue.
+  - Refactors exist to simplify the system, not to create a new design detour.
 
   WORKFLOW:
   1. Read the issue body for specific file paths and instructions
   2. Understand the current code structure
-  3. Make the refactoring changes
+  3. Name the simplification goal before changing code
-  4. Format: tox -e format
+  4. Make the refactoring changes
-  5. Test: tox -e unit
+  5. Run formatting and verification with repo-native commands
-  6. Commit, push, create PR
+  6. Commit, push, create PR with before/after risk summary

playbooks/security-auditor.yaml

@@ -21,6 +21,8 @@ trigger:
 
 repos:
   - Timmy_Foundation/the-nexus
+  - Timmy_Foundation/timmy-home
+  - Timmy_Foundation/timmy-config
   - Timmy_Foundation/hermes-agent
 
 steps:
@@ -46,12 +48,16 @@ system_prompt: |
   6. Dependencies with known CVEs (check requirements.txt/package.json)
   7. Missing input validation
   8. Overly permissive file permissions
+  9. Privilege drift in deploy, orchestration, memory, cron, and playbook surfaces
+  10. Places where private data or local-only artifacts could leak into tracked repos
 
   OUTPUT FORMAT:
   For each finding, file a Gitea issue with:
     Title: [security] <severity>: <description>
-    Body: file + line, description, recommended fix
+    Body: file + line, description, why it matters, recommended fix
     Label: security
 
   SEVERITY: critical / high / medium / low
   Only file issues for real findings. No false positives.
+  Do not open duplicate issues for already-known findings; link the existing issue instead.
+  If a finding affects sovereignty boundaries or private-data handling, flag it clearly as such.

playbooks/test-writer.yaml

@@ -21,6 +21,8 @@ trigger:
 
 repos:
   - Timmy_Foundation/the-nexus
+  - Timmy_Foundation/timmy-home
+  - Timmy_Foundation/timmy-config
   - Timmy_Foundation/hermes-agent
 
 steps:
@@ -42,14 +44,15 @@ system_prompt: |
 
   RULES:
   - Write tests that test behavior, not implementation details.
-  - Use tox -e unit to run tests. Never run pytest directly.
+  - Use the repo's own test entrypoints; do not assume tox exists.
   - Tests must be deterministic. No flaky tests.
   - Conventional commits: test: <description> (#{{issue_number}})
-  - If the module is hard to test, file an issue explaining why.
+  - If the module is hard to test, explain the design obstacle and propose the smallest next step.
+  - Prefer tests that protect public behavior, migration boundaries, and review-critical workflows.
 
   WORKFLOW:
   1. Read the issue for target module paths
   2. Read the existing code to understand behavior
   3. Write focused unit tests
-  4. Run tox -e unit — all tests must pass
+  4. Run the relevant verification commands — all related tests must pass
-  5. Commit, push, create PR
+  5. Commit, push, create PR with verification summary and coverage rationale