Generate Suite

Generate a complete policy suite for: $ARGUMENTS

heuwels updated 2mo ago
Claude CodeGeneric
View source ↗
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:

  1. Read the unmatched patterns
  2. Find the relevant section in the generated policy
  3. Strengthen the language — make the policy BETTER, don't just add keywords
  4. 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)