Skip to content

docs(spec-grill): add Behavior vs. Hard Constraint tiebreaker rule #112

@sungjunlee

Description

@sungjunlee

Dogfooding finding (2026-05-23, PR #110; res scoped 2026-05-31).

Several predicates can be written either as an Expected Behavior or as a Hard Constraint. Example: triage-grooming's read-only default can be framed positively (default invocation is advisory; mutation requires --apply) or negatively (never mutate GitHub without --apply). Both can pass the 3-axis test.

Without a tie-breaker, two spec-grill sessions on the same capability can classify the same intent differently, creating avoidable diff churn.

Scope

Update skills/spec-grill/SKILL.md and/or skills/spec-grill/references/capabilities.md with the classification rule.

Proposed rule

  • Positive normal outcome -> Expected Behavior.
  • Bright-line negation / anti-Goodhart guard -> Hard Constraint.
  • If both are valid, prefer the Hard Constraint only when the negative form protects against an optimization shortcut or data-loss shortcut.
  • If explicit user consent is valid, avoid the loophole phrase "never X unless asked"; write the consent condition as a Behavior instead.

Acceptance Criteria

  • spec-grill docs include the Behavior vs. Hard Constraint tie-breaker.
  • At least one example shows the same intent expressed both ways and explains the recommended placement.
  • Wording uses current spec-grill / spec/capabilities.md names, not retired backlog-charter paths.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions