All onus commands should read project-level rules before executing

[dpuglielli]

Problem

Onus commands (/onus:create, /onus:fetch, /onus:update, /onus:close, /onus:commit, /onus:pr) use only built-in generic knowledge for each platform. Projects can define detailed work item and git rules in .claude/rules/ and .claude/context/ that override or extend onus defaults, but onus commands don't read them before executing.

This means project-specific requirements are only available if they happen to be in conversation context from session start — they're not guaranteed to be present when a command runs.

Affected Commands and What They Miss

/onus:fetch │ Which fields to read per work item type, image downloading, authentication method
/onus:create │ Required fields, markdown formatting, title conventions, writing style, duplicate prevention, authentication
/onus:update │ Field names per type, authentication, allowed state transitions
/onus:close │ Final state name, required fields before closing

Proposed Change

Before executing, each onus command should check for project-level rules:

1. Look for project work item rules scanning the rules directory of the project using the plugin
2. If a matching rule file has a companion: field, also read the companion context file
3. Apply project rules as overrides to onus defaults (project > plugin, consistent with mantra's priority model)

Why Generic Lookup

Different projects use different platforms. A Jira project might have custom field requirements, issue type mappings, or label conventions. A GitHub project might have specific label taxonomies or template requirements. The mechanism should work for any platform — onus already abstracts across platforms for config; command execution should follow the same pattern.
Examples

An Azure DevOps project has .claude/rules/azure-devops.md with extends: onus/work-items.md. When /onus:create runs, it reads this file and learns:

• Authentication requires Azure CLI token (not PAT)
• Multiline fields need /multilineFieldsFormat operations for markdown
• Titles must follow Portal Server - convention
• Work items must be created sequentially (duplicate prevention

A Jira project has .claude/rules/jira.md with extends: onus/work-items.md. When /onus:fetch runs, it reads this file and learns:

• Custom fields to extract (story points, sprint, epic link)
• Which Jira fields map to acceptance criteria

Backward Compatible If no project-level rules are found, behavior is unchanged — onus uses its built-in defaults.

Relationship to Existing Config
.claude/config.json handles format strings (commit format, branch format, platform name). Project rules handle behavioral guidance (how to authenticate, which fields are required, what conventions to follow). These are complementary — config is structured data, rules are contextual guidance.