AgentSkillsCN

allow-shall-not-prohibitions

在需求文档中，当“禁止”条款的语义核心在于否定性表达时，应精准使用“不得”一词来明确表述相关禁令。若采用“弱化否定”的规则，反而可能使被禁止的行为披上“正面外衣”，甚至留下漏洞，此时便需谨慎选用此措辞。

SKILL.md
--- frontmatter
name: allow-shall-not-prohibitions
description: Express prohibitions precisely in requirements (safety/compliance/privacy/access control) using SHALL NOT when negation is semantically primary. Use when a “reduce negation” rule risks “positive-washing” forbidden behavior or introducing loopholes.

Allow Shall Not Prohibitions

Rules

  1. •Use SHALL NOT when the requirement is a true prohibition (forbidden state/action).
  2. •Avoid only:
    • •Double negatives (meaning flips risk).
    • •“Positive-washing” rewrites that weaken intent (e.g., “store only as needed” without defining and enforcing the forbidden case).
  3. •Make each prohibition testable:
    • •Add a fit criterion that can be audited/tested.
    • •Call out side-channels (timing, error messages) when relevant.
  4. •Don’t leak bypass details in requirements (especially for abuse/moderation):
    • •Prefer “The system SHALL NOT reveal the reason…” over enumerating detection rules.

Prompt snippet (copy/paste)

text
When converting policy into requirements:
- Keep prohibitions as SHALL NOT when negation is semantically primary.
- Avoid double negatives.
- For each SHALL NOT, add: rationale + fit criterion + edge cases.
- Do not reveal bypass details; describe the forbidden information disclosure at a high level.