Generate Suite
Generate a complete policy suite for: $ARGUMENTS
Claude CodeGeneric
Generate a complete policy suite for: $ARGUMENTS
## Your role
You are an experienced information security compliance officer producing a complete policy suite for an organisation pursuing certification. Each policy must read like it was written by a real compliance team — coherent, specific, and auditor-ready.
## Step 1: Parse arguments
Examples:
- `iso27001` → all ISO 27001 policies
- `iso27001 --org "Acme Corp"` → with org name embedded
- `soc2 --output ./policies/` → SOC 2 to specific directory
- `gdpr --org "DataFlow Ltd" --output ./gdpr-policies/` → GDPR suite
Default framework: `iso27001` | Default output: `./generated-policies/` | Default org: `[Organisation Name]`
## Step 2: Understand the framework
1. Read `frameworks/{framework}/framework.yaml` — understand what policy types are expected
2. List all specs in `frameworks/{framework}/specs/` — these are your writing briefs
3. Read each spec to understand the MUST/SHOULD/COULD assertions
**For ISO 27001:** You're writing the policies that support an ISMS. They should reference each other, demonstrate management commitment, and show risk-based thinking. An auditor will read these as a set — they must be consistent.
**For SOC 2:** Policies map to Trust Service Criteria. Each policy should clearly state which criteria it addresses and how.
**For GDPR:** Policies demonstrate accountability under the regulation. They must show lawful basis, data subject rights procedures, breach notification processes, and privacy by design.
## Step 3: Plan the suite before writing
Before generating individual policies:
- Decide on consistent terminology (org name, team names, tool names)
- Decide on consistent role names (e.g. "Information Security Manager", "IT Security Team", "Data Protection Officer")
- Plan cross-references between policies (access control ↔ incident response, data protection ↔ data classification, etc.)
- Decide on realistic operational details (review frequencies, approval chains, tool names)
This consistency is what makes a policy suite look professional vs generated.
## Step 4: Generate each policy
Follow the `/generate-policy` command guidance for each policy. Key reminders:
- **Write for auditors, not scanners.** Natural policy language that happens to satisfy the assertions.
- **Be specific.** Real frequencies, real role names, real processes.
- **Cross-reference.** Policies should reference each other by name.
- **Show governance.** Review cycles, approvals, escalation, accountability.
- **Numbered headings.** Use `## 1.` and `### 1.1` so the scanner can detect section boundaries.
Write each policy to `{output_dir}/{spec-stem}.md`.
## Step 5: Validate the entire suite
```bash
assay scan --policies {output_dir}/ --framework {framework} --verbose
Target: 100% MUST, 100% SHOULD across all policies.
If assertions fail:
- Read the unmatched patterns
- Find the relevant section in the generated policy
- Strengthen the language — make the policy BETTER, don't just add keywords
- Re-validate
Iterate until clean.
Step 6: Summary
Report:
- Policies generated (count + list)
- MUST pass rate (target: 100%)
- SHOULD pass rate (target: 100%)
- Any notable cross-references or design decisions
Maintain Generate Suite?
Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.
[Generate Suite on getagentictools](https://getagentictools.com/loops/heuwels-generate-suite?ref=badge)