Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

weekly-snippet

Estrellas7

Forks3

Actualizado16 de marzo de 2026 a las 03:00

Generate a weekly activity snippet from GitHub. Use when the user asks for a weekly summary, weekly snippet, status update, or "what did I do this week".

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

kuhar

kuhar/agent-workspace

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	weekly-snippet
description	Generate a weekly activity snippet from GitHub. Use when the user asks for a weekly summary, weekly snippet, status update, or "what did I do this week".

Weekly Snippet Generator

Generate a concise weekly activity summary grouped by project and task, using the my-activity script.

Data Collection

Run the activity script to get structured JSON:

/home/jakub/jakub-env/agent-workspace/scripts/my-activity --days 7 --json --detailed

If the user specifies a different time range, adjust --days accordingly.

Output Format

Organize output by project, then by task/theme within each project. Order tasks within each project by impact (most impactful first), then chronologically within the same impact tier.

Structure

## This week:

### <Project Name (e.g., IREE, LLVM/MLIR)>

* **<Task/theme summary>** <optional-issue-url>
  - <Executive summary if the task has notable quantitative outcomes>
  - <One-line description focusing on motivation/outcome>: <url>
  - ...

* **<Short single-item task>:** <url>

### <Next Project>
...

---

**Code reviews:** <count> PRs reviewed across <N> repos (<repo list>)

**GitHub activity:** https://github.com/kuhar?tab=overview&from=<start-date>&to=<end-date>

## Next week:

Rules

Group related PRs under a shared task heading (e.g., multiple PRs fixing the same bug across dialects belong together).
Cross-project tasks should live where they logically belong. For example, cherry-picking an LLVM fix into IREE stays under the LLVM heading.
One-line descriptions should focus on the motivation or outcome, not just restate the PR title. Use past tense (e.g., "Auto-enabled abi3 for CPython 3.12+" not "Auto-enable abi3").
Single-item tasks that need no sub-bullets should be kept on one line: * **Summary:** <url>. Do not create a sub-bullet when there is only one item and no executive summary.
Ordering within a task should be by impact first, then chronologically (earliest first) within the same impact level.
Code reviews go at the bottom as a single aggregate line. Use total_review_count from the JSON (includes private repos) for the total, and list the repos from the reviews array. Do not list individual reviews under each project.
Issues should be inlined under the relevant task if one exists, not in a separate section.
Direct commits (fork branches without PRs) should be mentioned only if they represent work not already covered by a listed PR.
Skip projects where nothing interesting happened beyond reviews.
Executive summaries are warranted when a task has notable quantitative results (e.g., size reduction, performance improvement). Pull data from linked issues/PRs if needed. Keep to one line.
Open PRs needing review should be marked with (needs review).
GitHub activity link should always be appended at the very end, using the from and to dates matching the snippet's time range (YYYY-MM-DD format).

Example

## This week:

### IREE

* **Reduce Python release size via Stable ABI (abi3) enablement** https://github.com/iree-org/iree/issues/23646
  - Combined with dropping py3.9, release size went from 1.74 GB to 1.16 GB (-33%, -573 MB), also giving us py3.14+ support for free.
  - Auto-enabled abi3 for CPython 3.12+ with GIL: https://github.com/iree-org/iree/pull/23629
  - Fixed release validation installing wrong package versions: https://github.com/iree-org/iree/pull/23634
  - Stopped building redundant cp313 wheels on MacOS and Windows: https://github.com/iree-org/iree/pull/23640

* **Add `iree_codegen.constraints` op for autotuner:** https://github.com/iree-org/iree/pull/23687 (needs review)

### LLVM/MLIR

* **Fixed the notorious double-space bug in ODS-generated op printers**
  - Root cause fix in the ODS printer generator: https://github.com/llvm/llvm-project/pull/184253
  - Cherry-picked fix into IREE and updated downstream tests: https://github.com/iree-org/iree/pull/23690

---

**Code reviews:** 21 PRs reviewed across 5 repos (llvm/llvm-project, iree-org/iree, llvm/mlir-www, nod-ai/amd-shark-ai)

**GitHub activity:** https://github.com/kuhar?tab=overview&from=2026-03-03&to=2026-03-09

## Next week:

Más de este repositorio

mismo repositorio

peanut-review

kuhar/agent-workspace

Orchestrate structured multi-agent code review for local changes or GitHub PRs using the peanut-review CLI, and curate existing peanut-review sessions. Use when starting or managing review sessions, or when asked to deduplicate, shorten, validate, dismiss, filter, or decide whether agent review comments are worth pushing.

2026-07-147

mark-and-recall

kuhar/agent-workspace

Read and write marks.md files to navigate codebases efficiently. Use when a marks.md file exists in the workspace, after significant codebase exploration, or when the user asks to document important code locations. Also use when the user says "mark it/them", "mark me", "mark this/these", "add a mark", "bookmark this/these", "save as marks", "save to marks", or otherwise asks to remember/mark code locations.

2026-03-107

populate-project-map

kuhar/agent-workspace

Creates or updates a human-readable directory map for the currently active workspace. Use when onboarding to a new project or when the workspace layout has changed.

2026-02-057

add-clang-tidy-check

kuhar/agent-workspace

Creates a new Clang Tidy check in the LLVM project.

2026-01-317

Weekly Snippet Generator

Generate a concise weekly activity summary grouped by project and task, using the my-activity script.

Data Collection

Run the activity script to get structured JSON:

/home/jakub/jakub-env/agent-workspace/scripts/my-activity --days 7 --json --detailed

If the user specifies a different time range, adjust --days accordingly.

Output Format

Organize output by project, then by task/theme within each project. Order tasks within each project by impact (most impactful first), then chronologically within the same impact tier.

Structure

## This week: ### <Project Name (e.g., IREE, LLVM/MLIR)> * **<Task/theme summary>** <optional-issue-url> - <Executive summary if the task has notable quantitative outcomes> - <One-line description focusing on motivation/outcome>: <url> - ... * **<Short single-item task>:** <url> ### <Next Project> ... --- **Code reviews:** <count> PRs reviewed across <N> repos (<repo list>) **GitHub activity:** https://github.com/kuhar?tab=overview&from=<start-date>&to=<end-date> ## Next week:

Rules

Group related PRs under a shared task heading (e.g., multiple PRs fixing the same bug across dialects belong together).

Cross-project tasks should live where they logically belong. For example, cherry-picking an LLVM fix into IREE stays under the LLVM heading.

One-line descriptions should focus on the motivation or outcome, not just restate the PR title. Use past tense (e.g., "Auto-enabled abi3 for CPython 3.12+" not "Auto-enable abi3").

Single-item tasks that need no sub-bullets should be kept on one line: * **Summary:** <url>. Do not create a sub-bullet when there is only one item and no executive summary.

Ordering within a task should be by impact first, then chronologically (earliest first) within the same impact level.

Code reviews go at the bottom as a single aggregate line. Use total_review_count from the JSON (includes private repos) for the total, and list the repos from the reviews array. Do not list individual reviews under each project.

Issues should be inlined under the relevant task if one exists, not in a separate section.

Direct commits (fork branches without PRs) should be mentioned only if they represent work not already covered by a listed PR.

Skip projects where nothing interesting happened beyond reviews.

Executive summaries are warranted when a task has notable quantitative results (e.g., size reduction, performance improvement). Pull data from linked issues/PRs if needed. Keep to one line.

Open PRs needing review should be marked with (needs review).

GitHub activity link should always be appended at the very end, using the from and to dates matching the snippet's time range (YYYY-MM-DD format).

Example

## This week: ### IREE * **Reduce Python release size via Stable ABI (abi3) enablement** https://github.com/iree-org/iree/issues/23646 - Combined with dropping py3.9, release size went from 1.74 GB to 1.16 GB (-33%, -573 MB), also giving us py3.14+ support for free. - Auto-enabled abi3 for CPython 3.12+ with GIL: https://github.com/iree-org/iree/pull/23629 - Fixed release validation installing wrong package versions: https://github.com/iree-org/iree/pull/23634 - Stopped building redundant cp313 wheels on MacOS and Windows: https://github.com/iree-org/iree/pull/23640 * **Add `iree_codegen.constraints` op for autotuner:** https://github.com/iree-org/iree/pull/23687 (needs review) ### LLVM/MLIR * **Fixed the notorious double-space bug in ODS-generated op printers** - Root cause fix in the ODS printer generator: https://github.com/llvm/llvm-project/pull/184253 - Cherry-picked fix into IREE and updated downstream tests: https://github.com/iree-org/iree/pull/23690 --- **Code reviews:** 21 PRs reviewed across 5 repos (llvm/llvm-project, iree-org/iree, llvm/mlir-www, nod-ai/amd-shark-ai) **GitHub activity:** https://github.com/kuhar?tab=overview&from=2026-03-03&to=2026-03-09 ## Next week: