docs-workflow-security-review
Skill4 starsChanged 4 months agoApache-2.0View on GitHub
Security and PII scan of documentation drafts before publication. Runs the deterministic PII scanner, then applies the docs-review-security checklist for agent-based analysis. Iteration logic is owned by the orchestrator, not this skill.
In this repository53 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- action-commentsSkill
- article-extractorSkill
- docs-convert-gdoc-mdSkill
- docs-orchestratorSkill
- docs-review-content-qualitySkill
- docs-review-modular-docsSkill
- docs-review-securitySkill
- docs-review-styleSkill
- docs-review-technicalSkill
- docs-ticket-readinessSkill
- docs-workflow-code-analysisSkill
- docs-workflow-create-jiraSkill
- docs-workflow-create-merge-requestSkill
- docs-workflow-jira-readySkill
- docs-workflow-pipeline-diagnosticsSkill
- docs-workflow-planningSkill
- docs-workflow-pr-analysisSkill
- docs-workflow-quality-gateSkill
- docs-workflow-requirementsSkill
- docs-workflow-scope-req-auditSkill
- docs-workflow-startSkill
- docs-workflow-style-reviewSkill
- docs-workflow-tech-reviewSkill
- docs-workflow-writingSkill
- git-pr-readerSkill
- ibm-sg-audience-and-mediumSkill
- ibm-sg-language-and-grammarSkill
- ibm-sg-legal-informationSkill
- ibm-sg-numbers-and-measurementSkill
- ibm-sg-punctuationSkill
- ibm-sg-referencesSkill
- ibm-sg-structure-and-formatSkill
- ibm-sg-technical-elementsSkill
- jira-readerSkill
- jira-writerSkill
- learn-codeSkill
- lint-with-valeSkill
- mdita-writeSkill
- query-codeSkill
- redhat-docs-tocSkill
- rh-ssg-accessibilitySkill
- rh-ssg-formattingSkill
- rh-ssg-grammar-and-languageSkill
- rh-ssg-gui-and-linksSkill
- rh-ssg-legal-and-supportSkill
- rh-ssg-release-notesSkill
- rh-ssg-structureSkill
- rh-ssg-technical-examplesSkill
- rn-known-issuesSkill
- understand-pull-requestSkill
- validate-plugin-prereqsSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 48
Read the writing step's sidecar at ${BASE_PATH}/writing/step-result.json to determine the writing mode and file list.
- Distinctive: line 65
Check the exit code. The scanner uses these exit codes:
- Distinctive: line 77
Do NOT treat exit codes 0 or 1 as script failures — both produce valid JSON output.
- Distinctive: line 93
Start the review report with the scanner results:
- Very specific: line 136
After the agent completes, verify the review report exists at <OUTPUT_FILE>.
- Very specific: line 140
Do not hand-author the sidecar — a hand-written sidecar drifts from the schema.
- Distinctive: line 156
If the script exits non-zero, the sidecar was not written — fix the scanner-results path and re-run.
≈ “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
Security Review Step
Step skill for the docs-orchestrator pipeline. Follows the step skill contract: parse args → run scanner → apply checklist → write output.
Arguments
$1— JIRA ticket ID (required)--base-path <path>— Base output path (e.g.,.agent_workspace/proj-123)
Input
<base-path>/writing/Output
<base-path>/security-review/review.md
<base-path>/security-review/scanner-results.json
<base-path>/security-review/step-result.jsonExecution
1. Parse arguments
Extract the ticket ID and --base-path from the args string.
Set the paths:
OUTPUT_DIR="${BASE_PATH}/security-review"
OUTPUT_FILE="${OUTPUT_DIR}/review.md"
SCANNER_FILE="${OUTPUT_DIR}/scanner-results.json"
mkdir -p "$OUTPUT_DIR"2. Determine source files
Read the writing step's sidecar at ${BASE_PATH}/writing/step-result.json to determine the writing mode and file list.
If the sidecar exists and mode is "update-in-place" with a non-empty files array:
Build a file list from the files array.
Otherwise (draft mode, missing sidecar, or empty files array):
Set DRAFTS_DIR="${BASE_PATH}/writing" and glob for .adoc, .md, .dita, and .ditamap files.
3. Run PII scanner
python3 ${CLAUDE_PLUGIN_ROOT}/skills/docs-review-security/scripts/pii_scanner.py scan <file1> <file2> ... > "$SCANNER_FILE"
SCANNER_EXIT=$?Check the exit code. The scanner uses these exit codes:
- 0 — no critical findings (warnings such as URL patterns may still exist in the JSON output)
- 1 — critical findings detected (credentials, private keys — proceed but flag in report)
- 2 — script error (bad paths, unreadable files, invalid arguments)
if [ $SCANNER_EXIT -gt 1 ]; then
echo "ERROR: PII scanner failed (exit $SCANNER_EXIT). See output above." >&2
exit 1
fiDo NOT treat exit codes 0 or 1 as script failures — both produce valid JSON output. Exit 0 means no critical findings (but warnings may exist). Exit 1 means critical findings were detected.
Validate the JSON output is well-formed before parsing:
jq empty "$SCANNER_FILE" 2>/dev/null
if [ $? -ne 0 ]; then
echo "ERROR: Scanner produced invalid JSON output." >&2
exit 1
fiAlways parse the JSON to get finding counts — do NOT infer counts from the exit code. Read summary.total_findings, summary.by_severity.critical (default 0), and summary.by_severity.warning (default 0) from $SCANNER_FILE. These are the values to use in the report header.
4. Build report header
Start the review report with the scanner results:
# Security and PII Review — <TICKET>
## Automated scan results
**Scanner findings:** N total (C critical, W warnings)
[If findings > 0, list them grouped by severity]
## Agent analysis
[Apply the checklist from step 5 and add findings here]5. Dispatch the security-reviewer agent (Layer 2)
You MUST use the Agent tool to invoke the security-reviewer subagent. Do NOT read the checklist or apply it yourself — the agent reads the source files and the Layer 2 checklist in its own isolated context and appends findings directly to the report, so neither the doc content nor the checklist enters the orchestrator's context.
Agent tool parameters:
subagent_type:docs-skills:security-reviewerdescription:Security Layer 2 review for <TICKET>run_in_background:false(the orchestrator must wait for the reviewer to finish before verifying output)
Prompt (substitute <SOURCE_FILES> with the file list from step 2 and <OUTPUT_FILE> with the report path):
Apply the Layer 2 agent-analysis checklist to the documentation for ticket
<TICKET>.Source files — review each of these: <SOURCE_FILES>
Report file:
<OUTPUT_FILE>— this file already contains the report header and scanner results. Append your findings to its Agent analysis section by editing it in place. Do NOT overwrite the existing content and do NOT write to any other location.After appending all findings, do NOT print the report contents. Print ONLY these two lines:
Written <OUTPUT_FILE> Agent findings: N
6. Verify output
After the agent completes, verify the review report exists at <OUTPUT_FILE>.
7. Write step-result.json
Do not hand-author the sidecar — a hand-written sidecar drifts from the schema. Run the script,
which derives every scanner field from $SCANNER_FILE and sums context_size_bytes from the output
folder. Pass --agent-findings from the Agent findings: N line the security-reviewer agent
printed (do not read the full report back to recount):
python3 ${CLAUDE_SKILL_DIR}/scripts/write_step_result.py \
--ticket "<TICKET>" \
--scanner-results "$SCANNER_FILE" \
--agent-findings <N> \
--output-dir "$OUTPUT_DIR" \
--sidecar "${OUTPUT_DIR}/step-result.json"The script writes the conformant step-result.json with scanner_findings, critical_findings,
agent_findings, per-category counts, context_size_bytes, and a real wall-clock completed_at.
If the script exits non-zero, the sidecar was not written — fix the scanner-results path and re-run;
do not substitute a stub.
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.

