[Feature]: Consider an optional secure development and architecture governance preset

[hindermath]

Problem Statement

Spec Kit already gives teams a strong spec/plan/tasks/constitution workflow, but teams with stronger secure-development and software-architecture governance needs still have to fork and maintain a fairly large set of custom constitution sections, agent guidance, templates, and evidence documents.

In practice, that means requirements such as secure coding, secure architecture, threat modeling, supply-chain transparency, and architecture/security evidence often live outside the standard Spec Kit flow, even though they affect specs, plans, tasks, and agent behavior.

I have been experimenting with this in my own home-baseline project and found that the missing piece is not just a single template, but a small, opinionated governance bundle that can flow through:

• constitution.md
• agent guidance files (AGENTS.md, CLAUDE.md, GEMINI.md, Copilot instructions)
• .specify/templates/
• docs/security/ evidence stubs

Proposed Solution

Would you be interested in an optional secure-development / secure-architecture governance preset (or similar catalog item) for Spec Kit?

I do not mean "make all of this mandatory in core for every project." Based on your current direction around presets/catalogs, this seems more like an optional preset/extension candidate than a default core behavior.

The idea would be to provide an opt-in package that can add:

• constitution sections for secure development and secure architecture
• compact agent-operational guidance so agents consistently apply the same governance
• additional templates for security evidence and review artifacts
• starter docs under docs/security/

The governance areas I found useful are roughly:

• Secure code generation
• Secure software architecture
• Standards/applicability matrix
• Secure SDLC / verification standards
• Supply-chain transparency and build integrity
• Threat modeling and attack-pattern coverage
• Zero Trust applicability and security program maturity

Concretely, my current implementation includes:

• constitution sections in constitution.md (chapters XII-XVIII in the current structure)
• matching agent-guidance blocks in all agent files
• templates such as:
  • threat model
  • ADR/security ADR
  • arc42 security section
  • security checklist
  • dependency audit
  • ASVS verification
  • supply-chain evidence
  • Zero Trust applicability
  • SAMM assessment
• project evidence stubs in docs/security/

If helpful, I can extract and propose a smaller, cleaner subset that is easier to evaluate for Spec Kit.

Alternatives Considered

• Keep this entirely as a private organizational fork/preset outside Spec Kit
• Publish it only as an external preset/catalog item without any upstream discussion
• Limit the idea to a single extra template, such as threat modeling only

I am opening this issue because I am not sure whether you would consider this direction useful for Spec Kit users more broadly, especially for teams that want stronger security and architecture guardrails in agent-driven workflows.

Also, issue #1708 (pluggable presets/template catalog) seems relevant here; this proposal may fit better there than as a direct core change.

Component

Spec templates (BDD, Testing Strategy, etc.)

AI Agent (if applicable)

All agents

Use Cases

1. Teams want security and architecture governance to show up directly in the same workflow as spec/plan/tasks, instead of being tracked in parallel documents outside Spec Kit.
2. Agents should apply the same secure-development expectations consistently across AGENTS.md, agent-specific files, and generated planning artifacts.
3. Projects with compliance or audit pressure need repeatable evidence locations and starter artifacts instead of ad hoc document structures.
4. Organizations want an opt-in preset for stricter engineering governance without forcing every Spec Kit user into a heavier default workflow.

Acceptance Criteria

• Maintainers indicate whether this direction is interesting for Spec Kit at all
• Maintainers indicate whether this belongs in core, as a preset, as an extension, or should stay external
• If interesting, there is agreement on a small evaluable subset rather than a large monolithic change
• If useful, I can follow up with a narrower proposal or PR aligned to that direction

Additional Context

Reference implementation in my home-baseline repo:

• Constitution:
  • https://github.com/hindermath/home-baseline/blob/main/constitution.md
• Agent guidance:
  • https://github.com/hindermath/home-baseline/blob/main/AGENTS.md
  • https://github.com/hindermath/home-baseline/blob/main/CLAUDE.md
  • https://github.com/hindermath/home-baseline/blob/main/GEMINI.md
  • https://github.com/hindermath/home-baseline/blob/main/.github/copilot-instructions.md
• Templates:
  • https://github.com/hindermath/home-baseline/tree/main/.specify/templates
• Security docs/evidence stubs:
  • https://github.com/hindermath/home-baseline/tree/main/docs/security

If you want, I can also provide a reduced proposal limited to:

• one constitution addition
• one agent-guidance addition
• one or two templates

rather than the broader bundle above.

[hindermath]

Thanks for taking a look.

To make this easier to evaluate, I would be happy to narrow the proposal down to a very small, opt-in starter instead of a broad governance bundle.

What I have in mind for a possible follow-up PR is:

• 1 small constitution addition focused only on security-governance applicability
• 1 compact agent-guidance block telling agents to:
  • determine which security/architecture standards apply
  • document N/A with rationale when something is not applicable
  • surface security evidence artifacts when relevant
• 1 or 2 starter templates only, for example:
  • threat-model
  • supply-chain-evidence
  • or security-checklist

What I am not proposing for a first step:

• not a full import of my current constitution chapters
• not a mandatory heavier workflow for all Spec Kit users
• not a large batch of security templates in one change
• not agent-specific custom behavior beyond a small shared guidance block

My intent would be to keep this:

• optional
• agent-agnostic
• small enough to review comfortably
• aligned with the preset/template direction rather than forcing more policy into core by default

If this direction is interesting, I can prepare a reduced PR proposal with a concrete file list and manual test results aligned to CONTRIBUTING.md.

[mnriem]

This is exactly what presets are designed for and we just completed the prepend, append, wrap functionality that will allow you to stack them. So yes you could opt into a multitude of presets each for a different purpose. We still need to write it all up properly in the documentation but use the specify preset --help for quick information. Some more details pending the documentation are at #2132 Also see https://github.github.com/spec-kit/reference/presets.html

Note please create those presets and publish them to a GitHub repository and then we can link them in the community catalog!

[hindermath]

This is exactly what presets are designed for and we just completed the prepend, append, wrap functionality that will allow you to stack them. So yes you could opt into a multitude of presets each for a different purpose. We still need to write it all up properly in the documentation but use the specify preset --help for quick information. Some more details pending the documentation are at #2132 Also see https://github.github.com/spec-kit/reference/presets.html

Note please create those presets and publish them to a GitHub repository and then we can link them in the community catalog!

@mnriem Thank you for your answer. Working on it and develop the Spec-Kit Presets. I am creating an answer/comment in this issue with my progress and when the presets are ready.

[hindermath]

Thank you again for pointing me toward Spec Kit presets.

I have now published the governance material as six standalone public preset repositories under my GitHub account:

• https://github.com/hindermath/spec-kit-preset-security-governance
  Secure development governance: memory-safe-language preference, secure code generation, NIST SSDF, CWE Top 25, OWASP ASVS, SBOM/VEX/SLSA, OpenSSF Scorecard, and EU CRA applicability.

• https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance
  General software architecture governance based on iSAQB/CPSA-F and arc42: architecture goals, context view, building blocks, runtime view, deployment view, quality scenarios, ADRs, architecture risks, and technical debt.

• https://github.com/hindermath/spec-kit-preset-architecture-governance
  Secure architecture governance: trust boundaries, threat modeling, STRIDE/CAPEC, secure architecture decisions, arc42 security concepts, Zero Trust applicability, and OWASP SAMM.

• https://github.com/hindermath/spec-kit-preset-a11y-governance
  Accessibility and inclusion governance: WCAG 2.2 Level AA, user-facing artifact checks, CLI accessibility, bilingual DE/EN delivery, CEFR-B2 readability, and inclusive-content guidance.

• https://github.com/hindermath/spec-kit-preset-agent-parity-governance
  Multi-agent guidance parity: keeps shared AI-agent instructions aligned across a project-defined set of agent surfaces and documents intentional deviations.

• https://github.com/hindermath/spec-kit-preset-cross-platform-governance
  Cross-platform scripting governance: Bash/PowerShell parity, dry-run/WhatIf parity, Unix man-page expectations, PowerShell comment-based help, and Verb-Noun Cmdlet discipline.

I smoke-tested each repository with Spec Kit 0.8.1 by installing from the GitHub ZIP URL, for example:

specify preset add --from https://github.com/hindermath/spec-kit-preset-security-governance/archive/refs/heads/main.zip --priority 10

I also smoke-tested the stacked preset setup with all six presets installed in priority order. Template composition and the wrapped speckit.specify, speckit.plan, and speckit.tasks commands worked as expected.

Would this repository-per-preset structure be suitable for the Spec Kit community catalog, or would you prefer a different metadata/catalog format before these are proposed for listing?

[mnriem]

Please submit each of them (one per PR) to our community catalog and we will get them in. Love seeing this. Note at the moment listing is a bit manual. We are working to make submission of extensions, presets and workflows easier!

[hindermath]

@mnriem Thank you for the guidance.

I have submitted the six presets as separate community catalog PRs, one PR per preset as requested:

• A11Y Governance: Add a11y-governance to community catalog #2381
• Agent Parity Governance: Add agent-parity-governance to community catalog #2382
• Architecture Governance: Add architecture-governance to community catalog #2383
• Cross-Platform Governance: Add cross-platform-governance to community catalog #2384
• iSAQB Architecture Governance: Add isaqb-architecture-governance to community catalog #2385
• Security Governance: Add security-governance to community catalog #2386

What I did before opening the PRs:

• Published each preset as a standalone public GitHub repository under https://github.com/hindermath/spec-kit-preset-*
• Created version tags and GitHub releases for the catalog download URLs:
  • v0.2.0 for security-governance, architecture-governance, and a11y-governance
  • v0.1.0 for isaqb-architecture-governance, agent-parity-governance, and cross-platform-governance
• Added one catalog entry per PR to presets/catalog.community.json
• Added one matching row per PR to docs/community/presets.md
• Kept every PR intentionally small and limited to those two catalog/documentation files

Testing performed with Spec Kit 0.8.1:

• Installed each preset from its GitHub tag ZIP URL using specify preset add --from
• Smoke-tested the full stacked setup with all six presets installed in priority order
• Verified preset list output
• Verified composed constitution-template resolution
• Verified standalone agent-guidance addendum template resolution
• Verified the wrapped speckit.specify, speckit.plan, and speckit.tasks command behavior during earlier local/dev smoke tests

Please let me know if this PR shape and metadata format are sufficient for the current manual community catalog process, or if you would like any adjustments such as different descriptions, tags, ordering, release URLs, or splitting/combining any of the entries differently.

[mnriem]

They are in the queue for review. Splendid work and precisely what presets are meant for!

[hindermath]

@mnriem Thank you very much for the kind words and for confirming that this is the intended use case for presets. I appreciate the guidance and the review queue update.

Small status update for the current catalog submissions:

• PR Add isaqb-architecture-governance to community catalog #2385 (isaqb-architecture-governance) had a merge conflict after upstream catalog changes.
• I rebased the branch onto the current github/spec-kit:main.
• The conflict in docs/community/presets.md is resolved.
• The upstream Fiction Book Writing entry is kept intact with 22 templates, 27 commands, 2 scripts.
• The iSAQB preset remains alphabetically placed between Fiction Book Writing and Jira Issue Tracking.
• presets/catalog.community.json validates as JSON.
• The final diff is intentionally minimal: one catalog entry, one documentation-table row, and the catalog updated_at change.
• GitHub now reports PR Add isaqb-architecture-governance to community catalog #2385 as mergeable again.

I will continue to keep each preset PR small and limited to the community catalog surfaces unless you prefer a different submission shape.

[mnriem]

We'll work through. Note sometimes this happens because of the other PRs in flight ;)