recipe-quality-profile

Execute Skill: llm-friendly-context before proposing profile conditions or writing the profile. Execute Skill: coding-principles to distinguish repository-owned policy from general code-quality knowledge.

Purpose

Establish repository-specific implementation and code-review acceptance conditions with the user, then create or update docs/project-context/quality.yaml.

Requested policy change: $ARGUMENTS

Profile Contract

version: 1
review_dimensions:
  - id: stable-kebab-case-id
    applies_when: Observable condition that makes this repository rule relevant to a change.
    pass: Observable accepted state to verify.
    evidence:
      - "repository/path: section, identifier, or contract"

Each dimension owns one repository-specific quality decision. applies_when limits its implementation and review surface, pass defines the accepted state, and evidence identifies why the repository owns the rule.

Authoring Flow

1. Use the current working repository as the target and read its docs/project-context/quality.yaml when present. For an existing profile, use the requested policy change as the update boundary; when none is supplied, ask for it and keep the profile unchanged.
2. Build candidates from acceptance conditions expressed or enforced by repository instructions, contributor documentation, CI, manifests and scripts, schemas and public contracts, tests, or representative implementation patterns. For an update, derive candidates only from the requested policy change and preserve unrelated dimensions.
3. For each candidate, inspect supporting and contradicting evidence wherever it can change the candidate's applicability, accepted state, or repository ownership. Separate observed repository facts from policy choices that require user confirmation.
4. Retain a candidate only when failing its pass condition would change implementation acceptance and every repository fact it depends on has cited evidence. Give it the narrowest useful applies_when, one positive observable pass condition, and consolidate candidates that would produce the same finding and correction. Omit a candidate when required repository evidence is unavailable and report the exact evidence needed.
5. Present proposed additions, changes, and removals, confirm that other dimensions remain unchanged, show the supporting and contradicting evidence, and state unresolved policy choices with their effect on implementation and review acceptance. Obtain explicit user confirmation of a proposal with no unresolved choices before writing.
6. Write only the confirmed profile content. Read the result and verify version 1, unique IDs, all required fields, observable conditions, readable evidence references, and consistency with the confirmed proposal.