[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73F9G282Y4YF4NSDK4ZP74Y":3,"skill-same:01M73F9G282Y4YF4NSDK4ZP74Y":52},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":33,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":51},"01M73F9G282Y4YF4NSDK4ZP74Y","purple-team-report",null,"Synthesize red team findings and blue team fixes into a structured security report. Use when the user wants a consolidated security report after red-team-check and blue-team-fix have been run, or when presenting security findings to stakeholders. Produces: executive summary, finding table with evidence, fix status, and open items.","Horonomos-laps\u002FYana-AI","Horonomos-laps","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F355299122?v=4","01M76B3QPXE88ET2SQPDPVATZT"," Horonomos-laps","01M72ZQRJPCYPSSWT4D00VJR2A",13,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fpurple-team-report\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: purple-team-report\ndescription: >\n  Synthesize red team findings and blue team fixes into a structured security report.\n  Use when the user wants a consolidated security report after red-team-check and\n  blue-team-fix have been run, or when presenting security findings to stakeholders.\n  Produces: executive summary, finding table with evidence, fix status, and open items.\norigin: yamtam\nversion: 1.0.0\ncompatibility: >\n  Expects red-team-check output and blue-team-fix output as input.\n  Report is text-based (Markdown). Does not write to external systems.\n---\n\n\u003C!-- Concept inspired by Strix (Apache 2.0) — security report synthesis pattern.\n     All content written original for YAMTAM. No code ported. -->\n\n## When to Use\n\n- After red-team-check AND blue-team-fix have completed for a session\n- When user asks for a security report, security summary, or pentest report\n- Before a production release that had security review as a requirement\n- When sharing security status with a team or stakeholder\n\nDo NOT use:\n- Without red-team-check output — the report is only as good as the scan input\n- As a substitute for showing actual evidence — evidence must be present in the report\n\n## How It Works\n\n### Step 1 — Collect Inputs\n\nGather from the current session:\n- Full finding list from red-team-check (including category coverage table)\n- Fix status from blue-team-fix (fixed \u002F proposed \u002F skipped per finding)\n- Scan mode used (quick \u002F targeted \u002F deep)\n- Target confirmed via security-scope-gate\n\nIf any input is missing, note it explicitly:\n```\n⚠ INPUT INCOMPLETE: blue-team-fix output not found.\n  Report will show findings but fix status will be UNKNOWN for all items.\n  Run blue-team-fix first for complete report.\n```\n\n### Step 2 — Build the Report\n\nOutput the report in this exact structure:\n\n---\n\n```markdown\n# Security Report — [Target Name]\n\n**Date:** YYYY-MM-DD\n**Scan Mode:** quick \u002F targeted \u002F deep\n**Scope Confirmed:** yes (logged to .claude\u002Fstate\u002Fsecurity-scope-confirmations.log)\n**Scanned by:** red-team-check v1.0.0 + blue-team-fix v1.0.0\n\n---\n\n## Executive Summary\n\n[2–4 sentences. Non-technical. Cover: what was scanned, how many findings,\noverall risk level, how many are fixed. Example:]\n\nA [mode] security scan of [target] identified [N] vulnerabilities across\n[M] OWASP categories. [X] findings are CRITICAL or HIGH severity.\n[Y] findings have been fixed with tests added. [Z] remain open.\nOverall risk: HIGH \u002F MEDIUM \u002F LOW.\n\n---\n\n## Category Coverage\n\n| OWASP Category | Status | Findings |\n|----------------|--------|---------|\n| A01 Broken Access Control | SCANNED | N |\n| A02 Cryptographic Failures | SCANNED | N |\n| A03 Injection | SCANNED | N |\n| A04 Insecure Design | SCANNED | N |\n| A05 Security Misconfiguration | SCANNED | N |\n| A06 Vulnerable Components | SCANNED \u002F SKIPPED | N |\n| A07 Auth Failures | SCANNED | N |\n| A08 Data Integrity Failures | SCANNED | N |\n| A09 Logging Failures | SCANNED | N |\n| A10 SSRF | SCANNED | N |\n\n---\n\n## Finding Table\n\n| # | Severity | Category | Title | Fix Status | Evidence |\n|---|----------|----------|-------|-----------|---------|\n| 1 | CRITICAL | A02 | Hardcoded DB password | FIXED | diff shown in session |\n| 2 | HIGH | A01 | IDOR on \u002Fapi\u002Fusers\u002F:id | FIXED | diff shown in session |\n| 3 | MEDIUM | A05 | Debug mode in prod config | OPEN | test not yet written |\n| 4 | LOW | A09 | Auth failures not logged | OPEN — backlog | — |\n\nEvidence column MUST reference where evidence was shown.\nMUST NOT be empty for FIXED items.\n\n---\n\n## Open Items\n\nItems that are not yet fixed:\n\n| # | Severity | Title | Reason not fixed | Recommended action |\n|---|----------|-------|-----------------|-------------------|\n| 3 | MEDIUM | Debug mode in prod config | Skipped by user | Fix before next deploy |\n| 4 | LOW | Auth failures not logged | Deferred to backlog | Create tracking issue |\n\n---\n\n## Fix Evidence Summary\n\nFor each FIXED item, confirm evidence exists:\n\n**Finding #1 — Hardcoded DB password (CRITICAL)**\n- Fix: moved to environment variable\n- Diff: shown in blue-team-fix output above\n- Test: test\u002Fsecurity\u002Ftest_secrets.py — assertion: `assert \"password\" not in source_code`\n- Status: FIXED — evidence present\n\n**Finding #2 — IDOR on \u002Fapi\u002Fusers\u002F:id (HIGH)**\n- Fix: added ownership check before returning resource\n- Diff: shown in blue-team-fix output above\n- Test: test\u002Fapi\u002Ftest_users_auth.py — assertion: `assert response.status_code == 403`\n- Status: FIXED — evidence present\n\n---\n\n## Recommendations\n\n1. [Specific action from highest severity open item]\n2. [Second recommendation]\n3. Add `red-team-check` to CI pipeline to catch regressions (see docs\u002Fsecurity-scan-modes.md)\n```\n\n---\n\n### Step 3 — Anti-Fake-Pass Checklist\n\nBefore outputting the report, verify:\n\n- [ ] Category coverage table is complete (all 10 categories listed)\n- [ ] Every FIXED item has an evidence reference\n- [ ] Evidence column is not empty for any FIXED item\n- [ ] Open items table includes reason and recommended action\n- [ ] Executive summary numbers match the finding table counts\n\n## Gotchas\n\n- If blue-team-fix was not run, mark all fix statuses as UNKNOWN — do not guess\n- Evidence column must reference where in the session the evidence appeared — \"see above\" is acceptable if it's clear; \"shown earlier\" without context is not\n- Do not include raw credentials, tokens, or PII in the report even if found in scan\n- Severity counts in executive summary must match the finding table exactly\n\n## Anti-Fake-Pass Rules\n\nBefore claiming the report is complete, you MUST show:\n- [ ] Category coverage table with status for all 10 OWASP categories\n- [ ] Finding table with evidence column populated for FIXED items\n- [ ] Open items table (even if empty — show \"No open items\")\n- [ ] Executive summary numbers match finding table\n\nMUST NOT say \"report complete\" if evidence column has empty cells for FIXED items.\nMUST NOT say \"all fixed\" if open items table has any rows.\nMUST NOT omit the category coverage table even for quick scans.\n","\u003C!-- Concept inspired by Strix (Apache 2.0) — security report synthesis pattern.\n     All content written original for YAMTAM. No code ported. -->\n\n## When to Use\n\n- After red-team-check AND blue-team-fix have completed for a session\n- When user asks for a security report, security summary, or pentest report\n- Before a production release that had security review as a requirement\n- When sharing security status with a team or stakeholder\n\nDo NOT use:\n- Without red-team-check output — the report is only as good as the scan input\n- As a substitute for showing actual evidence — evidence must be present in the report\n\n## How It Works\n\n### Step 1 — Collect Inputs\n\nGather from the current session:\n- Full finding list from red-team-check (including category coverage table)\n- Fix status from blue-team-fix (fixed \u002F proposed \u002F skipped per finding)\n- Scan mode used (quick \u002F targeted \u002F deep)\n- Target confirmed via security-scope-gate\n\nIf any input is missing, note it explicitly:\n```\n⚠ INPUT INCOMPLETE: blue-team-fix output not found.\n  Report will show findings but fix status will be UNKNOWN for all items.\n  Run blue-team-fix first for complete report.\n```\n\n### Step 2 — Build the Report\n\nOutput the report in this exact structure:\n\n---\n\n```markdown\n# Security Report — [Target Name]\n\n**Date:** YYYY-MM-DD\n**Scan Mode:** quick \u002F targeted \u002F deep\n**Scope Confirmed:** yes (logged to .claude\u002Fstate\u002Fsecurity-scope-confirmations.log)\n**Scanned by:** red-team-check v1.0.0 + blue-team-fix v1.0.0\n\n---\n\n## Executive Summary\n\n[2–4 sentences. Non-technical. Cover: what was scanned, how many findings,\noverall risk level, how many are fixed. Example:]\n\nA [mode] security scan of [target] identified [N] vulnerabilities across\n[M] OWASP categories. [X] findings are CRITICAL or HIGH severity.\n[Y] findings have been fixed with tests added. [Z] remain open.\nOverall risk: HIGH \u002F MEDIUM \u002F LOW.\n\n---\n\n## Category Coverage\n\n| OWASP Category | Status | Findings |\n|----------------|--------|---------|\n| A01 Broken Access Control | SCANNED | N |\n| A02 Cryptographic Failures | SCANNED | N |\n| A03 Injection | SCANNED | N |\n| A04 Insecure Design | SCANNED | N |\n| A05 Security Misconfiguration | SCANNED | N |\n| A06 Vulnerable Components | SCANNED \u002F SKIPPED | N |\n| A07 Auth Failures | SCANNED | N |\n| A08 Data Integrity Failures | SCANNED | N |\n| A09 Logging Failures | SCANNED | N |\n| A10 SSRF | SCANNED | N |\n\n---\n\n## Finding Table\n\n| # | Severity | Category | Title | Fix Status | Evidence |\n|---|----------|----------|-------|-----------|---------|\n| 1 | CRITICAL | A02 | Hardcoded DB password | FIXED | diff shown in session |\n| 2 | HIGH | A01 | IDOR on \u002Fapi\u002Fusers\u002F:id | FIXED | diff shown in session |\n| 3 | MEDIUM | A05 | Debug mode in prod config | OPEN | test not yet written |\n| 4 | LOW | A09 | Auth failures not logged | OPEN — backlog | — |\n\nEvidence column MUST reference where evidence was shown.\nMUST NOT be empty for FIXED items.\n\n---\n\n## Open Items\n\nItems that are not yet fixed:\n\n| # | Severity | Title | Reason not fixed | Recommended action |\n|---|----------|-------|-----------------|-------------------|\n| 3 | MEDIUM | Debug mode in prod config | Skipped by user | Fix before next deploy |\n| 4 | LOW | Auth failures not logged | Deferred to backlog | Create tracking issue |\n\n---\n\n## Fix Evidence Summary\n\nFor each FIXED item, confirm evidence exists:\n\n**Finding #1 — Hardcoded DB password (CRITICAL)**\n- Fix: moved to environment variable\n- Diff: shown in blue-team-fix output above\n- Test: test\u002Fsecurity\u002Ftest_secrets.py — assertion: `assert \"password\" not in source_code`\n- Status: FIXED — evidence present\n\n**Finding #2 — IDOR on \u002Fapi\u002Fusers\u002F:id (HIGH)**\n- Fix: added ownership check before returning resource\n- Diff: shown in blue-team-fix output above\n- Test: test\u002Fapi\u002Ftest_users_auth.py — assertion: `assert response.status_code == 403`\n- Status: FIXED — evidence present\n\n---\n\n## Recommendations\n\n1. [Specific action from highest severity open item]\n2. [Second recommendation]\n3. Add `red-team-check` to CI pipeline to catch regressions (see docs\u002Fsecurity-scan-modes.md)\n```\n\n---\n\n### Step 3 — Anti-Fake-Pass Checklist\n\nBefore outputting the report, verify:\n\n- [ ] Category coverage table is complete (all 10 categories listed)\n- [ ] Every FIXED item has an evidence reference\n- [ ] Evidence column is not empty for any FIXED item\n- [ ] Open items table includes reason and recommended action\n- [ ] Executive summary numbers match the finding table counts\n\n## Gotchas\n\n- If blue-team-fix was not run, mark all fix statuses as UNKNOWN — do not guess\n- Evidence column must reference where in the session the evidence appeared — \"see above\" is acceptable if it's clear; \"shown earlier\" without context is not\n- Do not include raw credentials, tokens, or PII in the report even if found in scan\n- Severity counts in executive summary must match the finding table exactly\n\n## Anti-Fake-Pass Rules\n\nBefore claiming the report is complete, you MUST show:\n- [ ] Category coverage table with status for all 10 OWASP categories\n- [ ] Finding table with evidence column populated for FIXED items\n- [ ] Open items table (even if empty — show \"No open items\")\n- [ ] Executive summary numbers match finding table\n\nMUST NOT say \"report complete\" if evidence column has empty cells for FIXED items.\nMUST NOT say \"all fixed\" if open items table has any rows.\nMUST NOT omit the category coverage table even for quick scans.\n",{"name":5,"origin":24,"version":25,"description":26,"compatibility":27},"yamtam","1.0.0","Synthesize red team findings and blue team fixes into a structured security report. Use when the user wants a consolidated security report after red-team-check and blue-team-fix have been run, or when presenting security findings to stakeholders. Produces: executive summary, finding table with evidence, fix status, and open items.\n","Expects red-team-check output and blue-team-fix output as input. Report is text-based (Markdown). Does not write to external systems.","main","481dcd7dd2e288b9d627a2bd017db70e64e6c6fa","core\u002Fskills\u002Fpurple-team-report",2,"https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI","https:\u002F\u002Fyana.vutam.link\u002F","https:\u002F\u002Fgithub.com\u002FHoronomos-laps","https:\u002F\u002Fyana.vutam.link","An open-source governed runtime & execution environment for multi-agent AI systems.","2026-11-14 13:24:09",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add Horonomos-laps\u002FYana-AI --skill purple-team-report",{"tool":44,"command":45},"bunx","bunx skills add Horonomos-laps\u002FYana-AI --skill purple-team-report",{"tool":47,"command":48},"pnpm","pnpm dlx skills add Horonomos-laps\u002FYana-AI --skill purple-team-report","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fpurple-team-report\u002FSKILL.md",true,[],[53,61,68,76,84,92],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":57,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M735GKET5YVYKAY62W2P5YXB","openai--sentry--sentry","Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.","MIT","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenai--sentry--sentry\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M73DCAP83T17HY7SMGK7MGFE","ito-basket-compare","Compare Itô prediction-market baskets against a user's knowledge base, portfolio notes, financial context, watchlist, or research thesis. Use for read-only basket comparison and gap analysis without investment advice or live trading.","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fito-basket-compare\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":72,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M734CYEMZFDR3KH6SW0JP8TD","implementing-network-traffic-baselining","Build network traffic baselines from NetFlow\u002FIPFIX data using Python pandas for statistical analysis, z-score anomaly detection, and hourly\u002Fdaily traffic pattern profiling","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":80,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M73ASZ6NJRJM44Z2P84NGQ3Q","detecting-evasion-techniques-in-endpoint-logs","Detects defense evasion techniques used by adversaries in endpoint logs including log tampering, timestomping, process injection, and security tool disabling. Use when investigating suspicious endpoint behavior, building detection rules for evasion tactics, or conducting threat hunting for stealthy adversary activity. Activates for requests involving evasion detection, defense evasion analysis, log tampering detection, or MITRE ATT&CK TA0005.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":88,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M734AFNXD06Z78QRK0VKGT7Q","implementing-microsegmentation-with-guardicore","Implementing microsegmentation using Akamai Guardicore Segmentation to map application dependencies, create granular network policies, visualize east-west traffic flows, and enforce least-privilege communication between workloads across data centers and cloud.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M736TK27QMCXK0DVCH25SJN5","ramdisk-tmpfs-patterns","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Framdisk-tmpfs-patterns\u002FSKILL.md",[],[]]