Skip to main content

ask-dev-loop

Ask which Dev Loop skill or flow fits the current situation. A router over the flagship idea-to-ship path.

소스 정보

저장소
shipshitdev/skills
최근 소스 활동
2026년 10월 5일 17:45
감지된 SKILL.md 언어
영어
스타
37
포크
3

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
3 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
ask-dev-loop
description
Ask which Dev Loop skill or flow fits the current situation. A router over the flagship idea-to-ship path.
user-invocable
false
license
MIT
metadata
{"version":"2.2.2","tags":"dev-loop, router, planning, dispatch","author":"Ship Shit Dev"}
when_to_use
which skill, what should I run, ask-dev-loop, how do I start, idea to ship, which flow
# Ask Dev Loop The human does not remember every skill. Ask. This is an **advisory router**: name the skill to type next and why, then stop. Execution routers can invoke reusable engines within an authorized task, but this skill only recommends. `grilling`, `domain-modeling`, `tdd`, and `debug` may be named as what the chosen workflow will run. ## Contract Inputs: - A situation in plain language (an idea, a bug, a PR, a foggy large effort, a setup question, or "I don't know where to start") Outputs: - The recommended skill to type, one sentence of why, and the next step after that - Neighbours when two skills are easy to confuse Creates/Modifies: - None External Side Effects: - None Confirmation Required: - None. Advisory only. Delegates To: - None. Name the skill; the human types it. ## Precondition If `docs/agents/issue-tracker.md` is missing, recommend `/setup-agent-routing` first. The other engineering skills read that routing block. ## The main flow: idea → ship The route most work travels. 1. **`/interview`** — sharpen the idea. Repo-grounded; runs `grilling` and `domain-modeling`; leaves an interview brief. Start here whenever the working directory is a real repo. 2. **Branch — does a design question need a runnable answer?** Detour through `/prototype` (throwaway code that answers one question), then return to the brief. 3. **Branch — is this a multi-session build?** - **Yes** → `/prd write` (`prd-writer`) then `/prd intake` (`feature-intake`) or `writing-plans` on the issue, then `/loop` / `executing-plans` per ticket. - **No** → `writing-plans` in this session, then `executing-plans` (or just implement with `/tdd`). 4. **When a PR is written** → `github-pr-publish` (its body template: Summary with a visual, Evidence, Merge danger), so the reviewer sees the point fast. 5. **When the run ends** → `/retro` if it was harder than it should have been, so the friction becomes a check, a pointer or a skill edit. Keep grilling, spec, and tickets in **one unbroken context window**: the answers to the grilling are the spec's raw material. Each `/loop` / `executing-plans` run starts fresh from the ticket. Phase boundaries below decide the rest. ## Phase boundaries A phase ends when its artifact is written (brief, spec, plan, ticket, PR). Decide what happens to the context at that boundary, not mid-phase. Ordered; the first yes wins: 1. **Continue** when the next phase's primary source is already in this window and the window is still in the smart zone (about 150k tokens). 2. **`/clear`** when everything the next phase needs lives in files or issues and this context is disposable. 3. **`/handoff`** only when the work moves to a new harness, a new directory or repository, a colleague, or forks a side task mid-phase. It is the narrow branch, not the default. 4. **Subagent** when the work is scoped tightly enough to run AFK and return one summary. 5. **`/compact`** when nothing above fits. Pass an instruction naming what to keep. ## On-ramps - **Bugs and incoming requests piling up** → `/prd intake` (`feature-intake`) or `github-inbox`. Tickets that `prd-task-creator` already wrote are agent-ready; do not re-intake them. - **Something's broken** → `/debug` (it escalates on its own when previous fixes failed). Tight red loop first; no theory without a loop. Afterwards `/retro` asks what would have prevented it. - **A huge, foggy effort** (too big for one session, decisions still unmade) → `/wayfinder`: a map of decision tickets resolved one per session, then merge onto the main flow at `/prd prepare`. Do not skip the collapse into a buildable PRD. (`roadmap-analyzer` and `roadmap-to-milestones` rank ICP and revenue; they do not map decisions. For one large run whose decisions are already made, use `figure-it-out`.) - **A decision only someone else can answer** → `/interview send`: a questionnaire for that person. - **An outside issue or PR to evaluate** → `github-inbox` with `triage <ref>`. - **A fact to look up from primary sources** → `research` (a cited note). ## Codebase health Not feature work — upkeep. - **`/codebase-advisor`** — survey, produce plans for another agent. Read-only on source. - **`/tech-debt`** — ranked debt register (interest over principal). - **`codebase-design`** — deep-module vocabulary when the question is the *shape* of a module, not an inventory. ## Review - **`/review`** (`review-dispatch`) — pick the review depth and target. - **`code-review`** — correctness and security gate, plus spec fidelity against the originating issue. - **`/retro`** — a session was harder than it should have been; turn its friction into checks, pointers and skill edits. Also the follow-up to `/debug` and the end of the main flow. ## Standalone - **`/handoff`** — a phase must continue in a new harness, directory, repo or colleague's hands; writes one file a fresh agent can pick up. Narrow branch of Phase boundaries, not a default. - **`/wait-what`** — the last message did not land; re-pitch it. - **`grilling`** — the interview primitive with no wrapper. Reach for it only when the interview itself is the whole ask. - **`domain-modeling`** — the words are the problem (fuzzy term, overloaded "account", missing ADR). - **`/wizard`** — steps only a human can perform (dashboards, secrets, cutovers). - **`fix-merge-conflicts`** — already mid-merge or rebase. ## Prompt wording - **`pstack`** — when the question is how to word the request itself, name the `pstack` skill's prompting reference: goal, a done check that can fail, the proof to show, and what to leave out. ## How to answer Match the user's situation to one row above. Reply with: 1. The skill to type (slash name when it has a command). 2. Why this one, in one sentence. 3. The neighbour they might have meant, if any. 4. What happens after that skill finishes. If two flows both fit, ask one question that splits them, then recommend.
GitHub에서 보기