Move sync marker to end of generated command files so Claude CLI preview shows useful text

[sebastientaggart]

Problem

When Claude CLI lists available slash commands, it shows a short preview of the first line of each command file. Currently, the first line of every generated file is the sync marker comment:

<!-- generated by CodeCanon/sync.sh | skill: start | adapter: claude | hash: 24909c1a | DO NOT EDIT -->

This means the preview looks like:

/start   <!-- generated by CodeCanon/sync.sh | skill: start | adapter: claude | hash: 24909c1a | DO NOT ED...
/ship    <!-- generated by CodeCanon/sync.sh | skill: ship | adapter: claude | hash: 3a68d170 | DO NOT EDI...

Instead of showing something useful about what the command does.

Solution

Move the sync marker comment from the first line to the last line of the generated file. This way the preview will show the invocation header (e.g., "You are executing the /start skill...") which is more meaningful.

Impact

• All generated command files will have the marker at the end instead of the beginning
• The sync hash detection logic needs to check the last line instead of the first
• No functional change to how skills work — purely a cosmetic/UX improvement

[sebastientaggart]

Agent Implementation Notes

Files to change: sync.sh only

Approach:

1. In sync_skill() (around line 298-299): move the marker line from the beginning to the end of final_content

   • Before: final_content = marker_line + full_content
   • After: final_content = full_content + marker_line

2. In read_file_info() (lines 205-222): update to check the last line for the sync marker instead of the first line, and compute body_hash over content before the marker (i.e., everything except the last line)

Edge cases:

• Files with no_invocation_header: true — the first line will be the skill body directly, which is fine
• Existing generated files will be detected as "customized" on next sync since the marker moved — one-time regeneration with --force or just running sync normally (since the stored hash won't match body hash anyway, it'll regenerate)