Implement GitOps workflows with ArgoCD and Flux for automated, declarative Kubernetes...
npx skills add front-depiction/claude-setup --skill "writing-laws"
Install specific skill from multi-skill repository
# Description
Write formal laws and covenants for codebases using proper legal-style structure. Use when establishing inviolable standards, architectural constraints, or domain-specific rules that must be followed without exception.
# SKILL.md
name: writing-laws
description: Write formal laws and covenants for codebases using proper legal-style structure. Use when establishing inviolable standards, architectural constraints, or domain-specific rules that must be followed without exception.
Writing Laws Skill
Use this skill when creating formal laws, covenants, or standards for a codebase. Laws are not suggestions or guidelines - they are inviolable requirements that govern behavior within a specific domain.
Core Principle: Laws Define, They Do Not Persuade
Laws state what IS and what SHALL BE. They do not:
- Explain why (that belongs in preambles)
- Describe consequences (that belongs in severity classifications)
- Use conditional or hedging language
- Appeal to preference or opinion
Law Structure
Section Numbering
Laws use hierarchical section notation with the section symbol (§):
§ I - Roman numerals for major laws
§ I.1 - Decimal for subsections
§ I.1.a - Lowercase letters for sub-subsections
Section Naming
Each section receives a bracketed name that serves as its short identifier:
§ VII [The Atom Suffix Convention]
§ VIII [The Confinement of Atoms]
§ XII [The Service Yield]
Internal References
Reference other sections by their number and name:
As required by § III [The Export of the Live Layer], ...
This law supersedes § IV.2 when ...
See § IX [The Action Patterns] for related requirements.
Legal Language
Mandatory Modal Verbs
| Verb | Meaning | Usage |
|---|---|---|
| SHALL | Absolute requirement | [Subject] SHALL [action]. |
| SHALL NOT | Absolute prohibition | [Subject] SHALL NOT [action]. |
| MUST | Equivalent to SHALL | [Subject] MUST [provide/include/satisfy]. |
| MUST NOT | Equivalent to SHALL NOT | [Subject] MUST NOT [action]. |
| IS REQUIRED TO | Alternative to SHALL | [Subject] IS REQUIRED TO [action]. |
| IS PROHIBITED FROM | Alternative to SHALL NOT | [Subject] IS PROHIBITED FROM [action]. |
| IS HEREBY DECREED | Declarative establishment | IT IS HEREBY DECREED that ... |
Definitional Language
| Phrase | Purpose |
|---|---|
[Term] means ... |
Define a term |
[Thing] is [classification] |
Classify something |
Any [X] that [condition] |
Define scope by condition |
For purposes of this section |
Limit scope of definition |
includes but is not limited to |
Non-exhaustive list |
Classification Language
Any [thing] that [exhibits property] is [classified as] [category].
Any [action] that [meets criteria] constitutes [violation type].
Law Templates
Simple Prohibition Law
## § X [Name]
**IT IS HEREBY DECREED** that [subject] SHALL NOT [prohibited action].
[Subject] that [exhibits prohibited behavior] constitutes a violation of this law.
Simple Requirement Law
## § X [Name]
**IT IS HEREBY DECREED** that [subject] SHALL [required action].
The [required element] MUST [satisfy condition]. [Additional requirements].
Multi-Part Law
## § X [Name]
**IT IS HEREBY DECREED** that [general principle].
### § X.1 [First Aspect]
[Subject] SHALL [requirement 1].
### § X.2 [Second Aspect]
[Subject] SHALL NOT [prohibition].
### § X.3 [Exception]
This law does not apply when [exception condition].
Definition Law
## § X [Definitions]
For purposes of these covenants:
**"[Term A]"** means [definition].
**"[Term B]"** includes:
- [item 1]
- [item 2]
- [item 3]
**"[Term C]"** does not include [exclusion].
Document Structure
Preamble
The preamble establishes WHY the laws exist. It uses WHEREAS clauses:
## PREAMBLE
WHEREAS [foundational truth 1];
WHEREAS [foundational truth 2];
WHEREAS [problem being solved];
NOW THEREFORE, the following LAWS are hereby declared and SHALL govern [domain] in perpetuity.
Laws Section
Laws follow the preamble. Each law stands alone as a complete requirement:
## LAW I: [The Principle Name]
**IT IS HEREBY DECREED** that [core requirement].
[Elaboration of requirements, conditions, and constraints.]
```[language]
// Code example showing compliance
```[language]
// FORBIDDEN: Code example showing violation
### Severity Classification
After all laws, classify violation severity:
```markdown
## SEVERITY CLASSIFICATION
| Severity | Laws | Consequence |
|----------|------|-------------|
| CRITICAL | [Laws X, Y] | [Impact description] |
| MAJOR | [Laws A, B, C] | [Impact description] |
| MINOR | [Laws D, E] | [Impact description] |
Compliance Checklist
Provide a verification checklist:
## COMPLIANCE CHECKLIST
Before [artifact] is considered complete:
- [ ] **LAW I**: [Verification statement]
- [ ] **LAW II**: [Verification statement]
- [ ] **LAW III**: [Verification statement]
Good Law Writing
Characteristics
- Precise - No ambiguity about what is required
- Complete - All cases covered
- Testable - Compliance can be objectively verified
- Self-contained - Each law understandable without external context
- Imperative - Commands, not suggestions
Examples
GOOD:
## § VII [The Atom Suffix Convention]
**IT IS HEREBY DECREED** that all atom properties SHALL bear the `$` suffix.
This convention provides immediate visual identification of reactive state.
```typescript
export interface SessionVM {
readonly inputValue$: Atom.Atom<string>; // $
readonly history$: Atom.Atom<Prompt>; // $
readonly setInputValue: (value: string) => void; // No $ - not an atom
}
THE $ SUFFIX is the mark of reactivity. Its absence on an atom constitutes deception.
**BAD:**
```markdown
## Naming Things
You should probably use the $ suffix for atoms because it makes them easier to identify.
If you don't use it, other developers might get confused and that would be bad.
Consider using it when you remember to.
What to Avoid
Hedging Language
| Avoid | Use Instead |
|---|---|
| should | SHALL |
| might | - (remove uncertainty) |
| probably | - (state definitively) |
| consider | IS REQUIRED TO |
| try to | SHALL |
| it's better to | SHALL |
| you might want to | IS REQUIRED TO |
Consequence Descriptions in Laws
Laws define requirements. Consequences belong in severity classifications, not in the law itself.
AVOID in law body:
If you violate this, bad things will happen and the codebase will become unmaintainable.
ACCEPTABLE in severity section:
| CRITICAL | VIII, XII | Immediate remediation required. Untestable code. |
Opinion and Preference
Laws do not express preference. They establish fact.
AVOID:
I think it's better to use namespace imports because they're cleaner.
USE:
[Subject] SHALL be imported as a namespace. Named imports are PROHIBITED.
Conditional Requirements
If something is conditional, make the condition explicit and the requirement absolute:
AVOID:
You might need to add spans if you want observability.
USE:
All asynchronous actions SHALL be wrapped with `Effect.withSpan()`. No exceptions.
Adding Laws to Existing Standards
When extending an existing covenant document:
1. Identify the Next Law Number
Review existing laws and use the next sequential Roman numeral.
2. Follow Established Patterns
Match the structure, language, and formatting of existing laws in the document.
3. Add to Severity Classification
Determine the appropriate severity for the new law and add it to the classification table.
4. Update Compliance Checklist
Add corresponding verification item(s) to the checklist.
5. Cross-Reference Related Laws
If the new law relates to existing laws, add cross-references in both directions.
Example: Complete Mini-Covenant
# THE IMPORT COVENANTS
## PREAMBLE
WHEREAS consistent import patterns reduce cognitive load;
WHEREAS namespace imports preserve type and value unity;
WHEREAS scattered named imports cause name collisions;
NOW THEREFORE, the following LAWS are hereby declared and SHALL govern all import statements.
---
## LAW I: The Namespace Requirement
**IT IS HEREBY DECREED** that all Effect module imports SHALL use the namespace pattern.
```typescript
// CORRECT
import * as Effect from "effect/Effect"
import * as Option from "effect/Option"
// FORBIDDEN
import { Effect, pipe } from "effect"
import { Option, none, some } from "effect/Option"
LAW II: The Local Module Pattern
IT IS HEREBY DECREED that local domain modules SHALL be imported as namespaces.
// CORRECT
import * as Task from "@/schemas/Task"
const task = Task.makePending({ ... })
// FORBIDDEN
import { makePending, isPending } from "@/schemas/Task"
SEVERITY CLASSIFICATION
| Severity | Laws | Impact |
|---|---|---|
| MINOR | I, II | Inconsistency. Compounds over time. |
COMPLIANCE CHECKLIST
- [ ] LAW I: All Effect imports use namespace pattern
- [ ] LAW II: All local domain imports use namespace pattern
```
When to Use This Skill
- Establishing architectural constraints that must never be violated
- Codifying patterns that have proven essential to maintainability
- Creating domain-specific standards for new areas of the codebase
- Formalizing existing informal rules into enforceable covenants
- Extending existing covenant documents with new laws
Key Principles Summary
- Laws use SHALL/SHALL NOT - never suggestions
- Definitions are precise - no ambiguity
- Structure follows § section notation
- Preambles explain why; laws state what
- Consequences belong in severity tables, not law bodies
- Every law is testable and verifiable
- Code examples show both compliance and violation
- Cross-reference related laws explicitly
- Compliance checklists enable verification
- Laws define - they do not persuade
# Supported AI Coding Agents
This skill is compatible with the SKILL.md standard and works with all major AI coding agents:
Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.