Refine Kanon worker implementation guidance

[kelos-bot]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Updates the task-specific kanon-workers prompt with two focused conventions backed by recurring review findings from Kanon implementation PRs.

First, the worker now tests every affected command, flag, scope, and guard outcome directly instead of relying on another path as indirect coverage:

• Kanon PR Add axon CLI for managing Tasks #9 review found that the new update command had only an early-return test and no pull-to-apply happy-path coverage.
• Kanon PR Add config file support with direct token credentials #16 review found that a two-outcome prune safety guard was untested in both directions and that project scope was covered only indirectly through agent scope.
• Kanon PR Add cron source to TaskSpawner #40 review found that testing apply -n did not cover the distinct update -n pull-plus-no-write contract.

Second, the worker now treats external repository inputs as one trust boundary across subprocess arguments, filesystem traversal, error output, and persistent caches:

• Kanon PR Add axon CLI for managing Tasks #9 review found that a user-controlled repository value could be interpreted as a git option.
• Kanon PR axon install/uninstall feature #29 reviews repeatedly found external-source boundary gaps: symlink traversal could read files outside the repository, expanded URL credentials could leak through git errors, and root clone metadata could persist credentials in the source cache.

Motivating reviews:

• Kanon PR Add axon CLI for managing Tasks #9: Reorganize CLI concept around chezmoi-style state model kanon#9 (review)
• Kanon PR Add config file support with direct token credentials #16: Prune orphaned managed files so the destination mirrors the source kanon#16 (review)
• Kanon PR Add cron source to TaskSpawner #40: Add --dry-run (-n) flag to apply and update kanon#40 (review)
• Kanon PR axon install/uninstall feature #29 symlink finding: Add remote git skill sources kanon#29 (review)
• Kanon PR axon install/uninstall feature #29 output-redaction finding: Add remote git skill sources kanon#29 (review)
• Kanon PR axon install/uninstall feature #29 cached-metadata finding: Add remote git skill sources kanon#29 (review)

The rules remain in the implementation worker prompt because they address mistakes made while writing Kanon changes. Shared skills remain only in self-development/base-agent.yaml.

The audit did not promote Kanon PR #68's single README finding, Kanon PR #22's feature-specific schema findings, or Kanon PR #45's line-ending edge case into general rules. Other findings were already covered by Kanon's current repository instructions, including co-owned configuration preservation and resource-naming errors.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

There were no Kanon PRs updated or merged during the last-seven-days window of August 17-24, 2026. The newest PR activity in the requested recent-20 sets was July 25, 2026, and the newest merge was July 2, 2026. The audit therefore inspected the diffs, reviews, inline comments, and conversations for the review-bearing and generated-by-kelos PRs in those sets, while retaining the existing recurring evidence from PRs #9 and #16.

Only self-development/kanon/kanon-workers.yaml is changed. make verify passes.

Does this PR introduce a user-facing change?

NONE

[gjkim42]

Why do we need to refine kanon-development? self-development has the same instructions but it works fine.
/kelos pick-up

[kelos-bot]

🤖 Kelos Task Status

Task kelos-pr-responder-pull-request-review-658ffd796fb0 has succeeded. ✅

[kelos-bot]

🤖 Kelos Agent @gjkim42

Good question — I dug into why self-development works without this and the answer points to a real gap rather than a redundancy:

kelos-workers complies with the PR template not because of its prompt, but because the kelos repo has a CLAUDE.md ("Always follow .github/PULL_REQUEST_TEMPLATE.md…"). That standing guidance is what clears the label gate. The kanon repo has no CLAUDE.md (verified via the GitHub API and a code search), so kanon-workers got no equivalent guidance from anywhere — and after kanon PR #8 added check-pr-labels, its PRs would trip the gate.

I've reworked the change to match how self-development does it: the convention now lives in the kanon-workers-agent agentsMD (the agent's standing instructions, the kanon analog of kelos's CLAUDE.md), and the numbered procedure steps are reverted to be identical to kelos-workers. Net diff is now just a 10-line ## Pull Requests section.

If you'd prefer this live in a CLAUDE.md added to the kelos-dev/kanon repo itself (which would also cover the other kanon agents and human contributors), I'm happy to open that as a follow-up against kanon instead — let me know.