The command follows a multi-step automated workflow to ensure copyright years are current without manual intervention:

1. Discovery: It identifies target repositories. If no specific repository is provided, it lists all non-archived repositories in the organization using gh repo list.
2. Inspection: It fetches the README.md content via the GitHub API and searches for copyright patterns like Copyright © YYYY or Copyright © YYYY-NNNN.
3. Transformation: If a match is found, it uses sed to update the end year of the range to the current year (e.g., 2026).
4. Branching & Committing: It creates a new branch named chore/update-copyright-{year} and commits the updated README.md content using the GitHub API.
5. Pull Request: It creates a Pull Request from the new branch to the repository's default branch.
6. Reporting: It outputs a summary table showing the repository name, the copyright change made, and the resulting PR URL (or a 'skipped' status if no update was required).

To maintain high signal quality, the following items are EXCLUDED from security reports:

• Denial of Service (DoS): Resource exhaustion, CPU/Memory exhaustion, or rate limiting issues.
• Secrets on Disk: Credentials stored on disk that are otherwise secured.
• Non-Critical Validation: Lack of input validation on non-security-critical fields.
• Infrastructure/Workflow: GitHub Action workflow sanitization (unless concrete), lack of audit logs, or insecure documentation.
• Language/Framework Specifics:
  • Memory safety issues in Rust or other memory-safe languages.
  • XSS in React/Angular unless using unsafe methods (e.g., dangerouslySetInnerHTML).
  • Command injection in shell scripts (unless a concrete attack path exists).
• Other: Theoretical race conditions, outdated third-party libraries, log spoofing (non-PII), and SSRF that only controls path (not host/protocol).

After creating a slide deck, follow these verification steps to ensure correctness:

1. Visual Check: Open the file and ensure the cover has the active class, the eyebrow number matches the chapter, and .meta shows the correct total slide count. Ensure tables/code blocks do not cause horizontal overflow (split into multiple slides if necessary).
2. TOC Check: Press O to verify that slides are correctly grouped by PART (check for label typos) and that every item has a title (ensure h2 is not missing).
3. Mode Check: Press D to ensure Document Mode correctly synchronizes vertical scrolling with the bottom bar.
4. Structure Check: If using SVG diagrams, ensure labels do not overlap elements, arrowheads are visible, and text stays within boxes.
5. Interaction Check: Verify .frag reveal order with \rightarrow, .term playback with clicks, and .tabs switching.

Use svg.dgm for complex layouts involving multiple boundaries (VPC, Accounts, Regions, Services). Do not use text bullets for these; use a diagram.

Technical Specifications:

• ViewBox: Must be fixed at 0 0 1180 452.
• Grid Layout (3 boundaries): x=12 / 432 / 816, widths 352 / 316 / 352. Nodes should be indented 26px from boundaries.
• Flows: Use only orthogonal lines (M...H...V...H...). Avoid diagonals.
• Text: Node names (.nt) should be 16px; subtitles (.ns) 13px. Do not shrink text; instead, shorten the wording.
• Text Positioning: 16px from the left of a box; first line 27px from the top; subsequent lines 20px apart.

Component Classes:

• .zone + .zt / .zc: Boundary box (dotted) and its name/subtitle.
• .nd / .nd.key / .nd.hub: Nodes (Standard / Highlighted / Central Hub).
• .nt / .ns: Node name / Subtitle.
• .fl + .fx: Flow arrows and labels. Use marker-end="url(#dgm-arrow)".
• .gone / .goneT: Deprecated/unused paths (red dotted lines).

Best Practices:

• Avoid Label Overlap: If flow labels overlap boundaries, shorten the label or move it to an SVG legend (<span class="fx">← meaning</span>) below the image.
• Unique IDs: If a deck has multiple diagrams, ensure marker IDs are unique.
• Accessibility: Include role="img" and an aria-label describing the diagram's purpose.

<svg viewBox="0 0 1180 452" role="img" aria-label="Architecture diagram showing VPC flow">
  <g class="zone"><text class="zt">VPC-A</text></g>
  <g class="nd key"><text class="nt">Main Service</text></g>
  <path class="fl" d="M 100 100 H 200 V 200" marker-end="url(#dgm-arrow)" />
  <text class="fx">← HTTPS</text>
</svg>

To enhance explanations that are difficult to describe statically, use one of the three interactive components. Use them sparingly: 2–4 per deck, and no more than 1 per slide.

Component Types

| Component | Use Case | Markup Structure | |---|---| sorry | | .frag (Sequential Reveal) | When the order of appearance is part of the explanation (e.g., pipeline steps, layering, problem $\rightarrow$ answer). | Add class="frag" to the element. Use data-frag="N" to group elements that should appear simultaneously. | | .term (Terminal Demo) | For CLI workflows where seeing the command execution is vital. Preferred over static pre.code blocks. | .term > .term-head(.term-play) + .term-body > .tl.cmd / .tl.out. Clicking plays the typing animation and shows output. | | .tabs (Tab Switching) | For comparing alternatives, scenarios, or before/after states within a single slide. | .tabs > .tabbar(.tab-btn) + .tab-panel. Add the on class to the first button/panel to set the default state. |

Behavior Rules

• Navigation: \rightarrow/Space reveals the next .frag in the current slide. Once all fragments are revealed, it advances the slide. \leftarrow rewinds the last fragment.
• Terminal: Clicking .term plays the sequence (command typing $\rightarrow$ output display). A \circlearrowleft reset button appears at the end. The .tl.cmd element automatically prepends a $ prompt.
• Document/Print Mode: In print (PDF) or Document Mode, all .frag, .tabs, and .term components are shown in their fully expanded state for reading.

<!-- Example .frag usage -->
<div class="frag" data-frag="1">Step 1</div>
<div class="frag" data-frag="2">Step 2</div>

<!-- Example .term usage -->
<div class="term">
  <div class="term-head"><button class="term-play"></button></div>
  <div class="term-body">
    <div class="tl cmd">ls -al</div>
    <div class="tl out">total 0...</div>
  </div>
</div>

<!-- Example .tabs usage -->
<div class="tabs">
  <div class="tabbar">
    <button class="tab-btn on">Option A</button>
    <button class="tab-btn">Option B</button>
  </div>
  <div class="tab-panel on">Content A</div>
  <div class="tab-panel">Content B</div>
</div>

Use the slidedeck skill to generate a single-file HTML slidedeck for presentations, concept explanations, or execution guides.

Core Constraints:

• Single File: The output must be a single HTML file. External resources are strictly limited to Google Fonts (IBM Plex Sans KR and IBM Plex Mono) which are already included in the template.
• No External Assets: Do not load external CSS, JS, or images. If offline, the template gracefully degrades to system fonts.
• Language: Use Korean (<html lang="ko">).
• Customization: Do not modify the template's CSS/JS structure or the bottom control interface (#chrome). Customization is limited to changing the --accent and --accent-soft CSS variables in :root to set the theme color.
• Mandatory Elements: Every slide must include an .eyebrow and an h1 or h2. The JavaScript uses these to automatically populate the Table of Contents (TOC) and the bottom navigation bar.
• Privacy: Never include sensitive or customer personal information. Use placeholders like ●●●●●●.

/* Customization example */
:root {
  --accent: #0F8A7A;      /* e.g., teal */
  --accent-soft: #DCF2EE;
}

This document defines a protocol for conducting a high-confidence security review of code changes on a current Git branch. The goal is to identify actionable, high-impact vulnerabilities (SQL injection, Command injection, XSS, etc.) while aggressively filtering out noise, theoretical issues, and low-impact findings like Denial of Service (DoS) or resource exhaustion.

Analysis Workflow

1. Context Research: Identify existing security frameworks, sanitization patterns, and the project's threat model using repository exploration tools.
2. Comparative Analysis: Compare new changes against established secure coding patterns in the codebase to identify deviations.
3. Vulnerability Assessment: Trace data flow from user inputs to sensitive operations and identify injection points or unsafe deserialization.

Required Output Format

Findings must be reported in Markdown using the following structure:

Vuln [Number]: [Category]: [file]:[line]

• Severity: [High/Medium/Low]
• Description: [Detailed explanation of the vulnerability]
• Exploit Scenario: [Step-by-step attack path]
• Recommendation: [Specific fix suggestion]

# Vuln 1: XSS: `foo.py:42`

* Severity: High
* Description: User input from `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS attacks
* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script> to execute JavaScript in victim's browser, enabling session hijacking or data theft
* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML