comment-speclisted

# comment-spec — shape only as much as the decision needs Use this above `comment-feature` when goal, product fit, or acceptance is materially unsettled. The scarce resource is a clear decision and fast learning, not maximal specification. Optimize for the cleanest architecture and smallest useful learning step appropriate to the product's current phase. Act like a fast-moving startup: the goal is a feature users love, not speculative enterprise completeness. Prefer the simplest useful hypothesis and real-user validation. Add extensibility, exhaustive edge cases, and operational machinery only when current evidence, risk, or a hard invariant justifies their cost. Direct `comment-spec` uses the Spec comm as Project Root. On build, pass that same human-openable URL to `comment-feature`; do not create another root or re-derive the approved design. This skill composes `delivery-methodology`, `worklog`, `steer`, and `comment-feature`. Read a composed skill's full `SKILL.md` (its `SKILL.md`) before using it. ## Preconditions This path is read-only on the codebase. It may inspect code, docs, and available product evidence, but it does not create a worktree or edit code. ## Workflow 1. **Open the Spec comm.** Use the template below and the first working Comment.io route. Keep that identity/token; invoke `comment-identity` only immediately before an uncredentialed direct-REST write. Save the human-openable URL and make it the Project Root. Consult `$BASE/llms/noti