Context from Step 0: Reference any relevant patterns from improvement context
If the slice is ambiguous, pick the most recent complete attempt and state the exact boundary you chose.
Step 2: Recreate the Workflow (workflow-recreated)
Reconstruct the workflow as a numbered list of 5 to 20 steps, identifying inputs, branch points for decisions, and outputs such as file changes or state modifications. During this reconstruction, identify specific friction points that reduce efficiency. These often include repeated steps or redundant tool calls, as well as missing guardrails where validation occurs too late or prerequisites are unclear. Other common issues are a lack of automation for tasks that should be scripted, and discoverability gaps caused by confusing naming conventions.
Cross-reference with Step 0 context:
Are friction points matching known failure patterns?
Do repeated steps align with git history themes?
Are missing guardrails mentioned in review-chamber lessons?
Generate 3 to 5 distinct improvement approaches and score each on impact, complexity, reversibility, and consistency with existing sanctum patterns. The scoring should specifically address whether the change prevents the recurrence of patterns identified in Step 0. Prioritize improvements that address components with a high stability gap (greater than 0.3) or recurring issues found in the git history. You should also incorporate lessons from the review-chamber and aim to reduce failure modes identified in the skill logs. Prefer small, high-use changes such as tightening a skill's exit criteria, adding missing command options, improving hook guardrails for better observability, or splitting overloaded commands into clearer phases.
Step 4: Agree on a Plan (plan-agreed)
Choose 1 approach and define:
Acceptance criteria ("substantive difference")
Files to change
Validation commands to run
Out-of-scope items to defer
Keep the plan bounded: aim for ≤ 5 files changed unless the workflow truly spans more.
Step 5: Implement (changes-implemented)
Apply changes following sanctum conventions:
Keep naming consistent across commands/, agents/, skills/, hooks/
Prefer documentation-first improvements if ambiguity was the primary issue
If behavior changes, add/adjust tests in plugins/sanctum/tests/
After validation, capture the improvement for future reference:
7.1: Update Git History
Commit with descriptive message that future searches will find:
git add <changed-files>
git commit -m "improve(sanctum): <component> - <specific fix>
Addresses recurring issue: <pattern from Step 0>
Reduces <metric> by <percentage>
Evidence: stability_gap reduced from 0.35 to 0.12
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"
7.2: Post Tooling Learnings to Discussions (Preferred)
Observations about night-market tooling (skill behavior, agent
coordination, hook timing, command UX) belong in
https://github.com/athola/claude-night-market/discussions,
not local memory. Always target the night-market repo
regardless of which repo you are currently working in.
# Post to night-market Learnings category# See fix-pr Step 6.7 for the full GraphQL pattern# targeting athola/claude-night-market explicitly
This creates a feedback loop where future /fix-workflow and /update-plugins runs will reference this lesson.
Record Lessons Learned (decision journal)
If this work involved rework, a failed approach, or a blocker, record it to
docs/lessons-learned.md so the insight survives past the session (draft and
confirm):
If leyline is installed, invoke Skill(leyline:decision-journal) and append
a lesson entry (what_happened, what_didnt_work, root_cause, action;
set phase to review). Show the draft; append on confirmation.
Fallback (leyline absent): append to docs/lessons-learned.md using the
in-file ENTRY TEMPLATE; assign the next LL-NNN id.
Supporting Modules
Auto issue creation - patterns for automatically creating GitHub issues from deferred items
Exit Criteria
The session slice is captured with a stated boundary, trigger, goal, and
artifacts touched
At least 3 distinct improvement approaches were generated and scored
One approach was chosen with acceptance criteria and a bounded file list
(<= 5 files unless justified)
Validation records before/after metrics (step count, tool calls, or
failure points), not prose
If the slice involved rework, a failed approach, or a blocker, the lesson
is recorded to docs/lessons-learned.md via the decision journal
Troubleshooting
Common Issues
If a command is not found, confirm that all dependencies are installed and accessible in your PATH. For permission errors, check file system permissions and run the command with appropriate privileges. If you encounter unexpected behavior, enable verbose logging using the --verbose flag to capture more detailed execution data.
