nist-plan
Skill1 starsChanged 4 months agoApache-2.0View on GitHub
Walk NIST SSDF Phase 1 (Plan & Requirements) and file GitHub epics for the five "Prepare the Organization" practices — PO.1 security requirements, PO.2 roles and responsibilities, PO.3 supporting toolchains, PO.4 criteria for security checks, PO.5 secure development environments. Use when starting a new product or a major feature planning cycle, when setting up secure-SDLC governance for a repo, or when the user mentions NIST SSDF, SP 800-218, SSDF phase 1, or the PO practices.
In this repository13 other files it gives its agents.
- feature-development-workflowSkill
- gh-release-train-mergeSkill
- github-project-boardSkill
- implement-issueSkill
- nist-buildSkill
- nist-designSkill
- nist-releaseSkill
- nist-respondSkill
- nist-testSkill
- plan-to-issueSkill
- prettifySkill
- pr-from-branchSkill
- release-candidate-reviewSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Before code is written, the organization sets the conditions for secure development: the security requirements that software must meet, the …
- Very specific: line 40
Follow the phase walkthrough protocol in references/protocol.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
NIST SSDF Phase 1 — Plan & Requirements
Phase label: nist-phase-1-plan
This skill files GitHub issues. It does not write code.
What this phase is about
Before code is written, the organization sets the conditions for secure development: the security requirements that software must meet, the people and roles accountable for meeting them, the toolchains that automate them, the criteria for checking them, and the protected environments in which development happens. NIST groups all of these under "Prepare the Organization" (PO).
Practices
Walk these in order — each one assumes the previous has landed. Read a practice's reference file only when you reach it, not up front.
| Practice | Name | Reference |
| PO.1 | Define Security Requirements for Software Development | references/po1.md |
| PO.2 | Implement Roles and Responsibilities | references/po2.md |
| PO.3 | Implement Supporting Toolchains | references/po3.md |
| PO.4 | Define and Use Criteria for Software Security Checks | references/po4.md |
| PO.5 | Implement and Maintain Secure Environments for Software Development | references/po5.md |
How to run
Follow the phase walkthrough protocol in
references/protocol.md. Substitutions:
<PHASE_N>=1<PHASE_NAME>=Plan & Requirements<PHASE_LABEL>=nist-phase-1-plan<PRACTICES>=PO.1,PO.2,PO.3,PO.4,PO.5
Phase epic title: [NIST Phase 1] Plan & Requirements.
The protocol confirms scope with the user, finds or creates the phase epic, then walks each practice — checking for an existing epic, asking whether to file, link, or skip, and updating the phase epic checklist as it goes. It never creates an issue without confirmation.
Adapting to the repo
The implementation notes in each reference file are deliberately generic, because
this skill is meant to run against any repository. Before drafting an epic, look
at what the repo actually has — CI workflows, package manifests, branch
protection, existing security docs — and rewrite the notes to name real files and
real gaps. An epic that says "branch protection on main has no required status
checks" is worth more than one that says "configure branch protection".
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

