סקיל to-issues

פקודת התקנה

ההתקנה מתבצעת דרך מנהל החבילות הרשמי של הסקילים בפקודה אחת. הסקיל הוא קובץ Markdown פתוח מהמאגר של מאט פוקוק, ומופעל במפורש כפקודה. אפשר להוריד ולבדוק את הקוד דרך הכפתורים שבראש העמוד.

מה הסקיל כולל?

הסקיל מתעד תהליך מסודר: איסוף ההקשר, חקירת הקוד אם צריך, ניסוח פרוסות אנכיות, אישור מולכם של רמת הפירוק והתלויות, ופרסום המשימות במערכת בסדר הנכון.

קוד הסקיל המלא

---
name: to-issues
description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
disable-model-invocation: true
---

# To Issues

Break a plan into independently-grabbable issues using vertical slices (tracer bullets).

The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.

## Process

### 1. Gather context

Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.

### 2. Explore the codebase (optional)

If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.

Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."

### 3. Draft vertical slices

Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.

<vertical-slice-rules>

- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
- A completed slice is demoable or verifiable on its own
- Any prefactoring should be done first

</vertical-slice-rules>

### 4. Quiz the user

Present the proposed breakdown as a numbered list. For each slice, show:

- **Title**: short descriptive name
- **Blocked by**: which other slices (if any) must complete first
- **User stories covered**: which user stories this addresses (if the source material has them)

Ask the user:

- Does the granularity feel right? (too coarse / too fine)
- Are the dependency relationships correct?
- Should any slices be merged or split further?

Iterate until the user approves the breakdown.

### 5. Publish the issues to the issue tracker

For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.

Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.

<issue-template>
## Parent

A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).

## What to build

A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.

Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.

## Acceptance criteria

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Blocked by

- A reference to the blocking ticket (if any)

Or "None - can start immediately" if no blockers.

</issue-template>

Do NOT close or modify any parent issue.

מה זה to-issues ולמה הסקיל הזה שונה?

to-issues פותר את השלב שבו תוכניות טובות נתקעות: יש מסמך אפיון מצוין, אבל אף אחד לא יודע מאיפה להתחיל כי הכול נראה גוש אחד גדול. הסקיל מפרק את הגוש הזה למשימות קטנות, עצמאיות ומוגדרות היטב, כך שמפתח או סוכן יכול לתפוס כל אחת מהן ולהתקדם בלי להמתין לשאר.

מה שמייחד אותו הוא שיטת הפרוסות האנכיות. רוב האנשים מפרקים עבודה לפי שכבות: קודם כל בסיס הנתונים, אחר כך השרת, אחר כך הממשק. הבעיה היא ששום דבר לא עובד עד שהכול מוכן. הסקיל מפרק אחרת: כל משימה היא חתך דק שעובר דרך כל השכבות יחד, ולכן בסיומה יש משהו אמיתי שאפשר להדגים. הוא גם ממפה תלויות בין המשימות ומאשר איתכם את רמת הפירוק לפני שהוא מפרסם משהו, כך שאתם בשליטה מלאה.

ההבדל מורגש בקצב ההתקדמות. במקום שבועיים שבהם כלום לא רץ, מקבלים ערך מודגם כבר אחרי המשימה הראשונה. בשילוב עם סקיל to-prd נסגר מעגל שלם: השיחה הופכת לאפיון, והאפיון מתפרק אוטומטית למשימות מוכנות לעבודה. בעבודות האוטומציה שאני בונה, הזרימה הזאת מקצרת דרמטית את הדרך מרעיון לקוד רץ.

מה to-issues נותן לקלוד קוד?

הסקיל מוסיף לקלוד את היכולת לתרגם תוכנית גדולה לרשימת משימות שאפשר באמת להתחיל לעבוד לפיה, בלי שאף משימה תהיה תלויה בהכול.

ארבע היכולות הופכות תוכנית סטטית לרשימת משימות חיה. בעבודות שלי, הסקיל הזה הפך את הפער בין "יש לנו תוכנית" לבין "התחלנו לעבוד" מימים של ארגון ידני לדקות.

למי הסקיל הזה מתאים?

מובילי פיתוח ומנהלי פרויקט: זה הקהל המובהק. הסקיל הופך תוכנית גדולה לרשימת משימות שאפשר לחלק לצוות מיד, עם תלויות ברורות. השילוב עם סקיל brainstorming מחבר את שלב הרעיון לשלב הפירוק לביצוע.

צוותים שעובדים עם סוכני AI: כל פרוסה אנכית עצמאית היא בדיוק מה שסוכן צריך כדי לעבוד לבד. הסקיל מייצר משימות שמוכנות לתפיסה על ידי סוכן, וכך אפשר להריץ כמה סוכנים במקביל על אותו פרויקט.

יזמים שצריכים להתחיל לבנות: אחרי שיש אפיון, השאלה היא מאיפה מתחילים. הסקיל נותן את התשובה: רשימת משימות מסודרת לפי תלות, כך שאפשר לראות ערך מודגם כבר מהמשימה הראשונה במקום להמתין שהכול יהיה מוכן.

פרילנסרים וסוכנויות: פירוק ברור למשימות מאפשר לתמחר, לתזמן ולעדכן לקוח על התקדמות בצורה מדויקת. גם בעבודות קידום אורגני שלי, פירוק נכון של פרויקט למשימות עצמאיות מקל על ניהול הציפיות מול הלקוח.

מפתחי סולו: גם כשעובדים לבד, רשימת משימות עצמאיות עוזרת לשמור על מומנטום ולסיים דברים שלמים, במקום להיתקע בחצי שכבה.

מי שפחות יתאים: משימה אחת קטנה וברורה לא צריכה פירוק. הסקיל מבריק דווקא כשיש תוכנית גדולה או אפיון מורכב שצריך להפוך לצעדים שאפשר לתפוס אחד-אחד.

איך to-issues עזר לי בפרויקטים אמיתיים

ארבעת המקרים מראים שהסקיל לא רק מארגן עבודה, הוא משנה את הדינמיקה של פרויקט: מתוצאה שמגיעה רק בסוף, להתקדמות מודגמת לאורך כל הדרך. פירוק נכון למשימות הוא לעיתים ההבדל בין פרויקט שזז לבין פרויקט שתקוע.

סיכום

סקיל to-issues הוא החוליה שמחברת בין תכנון לביצוע. הוא הופך תוכנית או אפיון לרשימת משימות עצמאיות בשיטת הפרוסות האנכיות, עם מיפוי תלויות ואישור מולכם, כך שכל משימה מוכנה לתפיסה ומסתיימת בתוצאה מודגמת.

אם אתם מתחילים, קחו תוכנית או מסמך אפיון קיים והפעילו את הסקיל. הוא יציע פירוק לפרוסות, יאשר איתכם, ויפרסם משימות מסודרות. משם, ההתקדמות הופכת למוחשית: סוגרים משימה, רואים ערך, וממשיכים לבאה.

בפוסטים הבאים אמשיך לסקור סקילים שמשדרגים את תהליך הפיתוח. האתר של דביר נעמן מרכז את כל הכלים, השיטות והליווי שאני מציע לעסקים שרוצים לעבוד חכם עם בינה מלאכותית.