Help
Claude Code plugin: tech-lead interview -> multi-file execution plan -> sprint-by-sprint execution -> zero-trust audit -> handoff. Guarded against both lazy shortcuts and over-engineering.
npx -y skills add Zhen-Bo/request-devflow-plan --skill helpAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Interactive orientation for the request-devflow-plan workflow — inspects the current repo (existing plan? documentation base? progress state?) and recommends the exact next command, with a map of the full lifecycle. Use when the user asks how to use request-devflow-plan, where to start, which command to run next, or wants a guided tour. Triggers: help, getting started, where do I start, 怎麼用, 怎麼開始, 教學, 入門.
SKILL.md
2.8 KB, as published. Nobody here has run it
request-devflow-plan:help
Orient the user in under a minute: inspect the repo, tell them where they are in the lifecycle, and recommend the exact next command. Strictly read-only — never modify anything. Answer in the user's conversation language.
Flow
Step 1 — Inspect (quick, read-only)
- Is there a DevFlow plan folder? (
docs/*/containing a doc-map README beside00-iron-rules.md) → read itsPROGRESS.mdandaudit-log.mdfor state - Is there a documentation base? (
docs/SPEC/,docs/diagrams/,docs/SPEC/WORKFLOW.md) - Is this a git repo at all? Are tests/gates present?
Step 2 — Say where they are, then recommend
State the detected situation in one sentence, then lead with exactly ONE recommended command (full form, actual unit numbers where a plan exists, /clear advisory when it needs a fresh context). Alternatives after it, one line each:
| Detected situation | Recommend |
|---|---|
| No git repo / brand-new idea | initialize the repo first, then /request-devflow-plan:plan |
| Repo without docs, user wants documentation only | /request-devflow-plan:foundation |
| Repo (documented or not), user wants planned work | /request-devflow-plan:plan — recon handles a missing foundation via Sprint 0 |
| Plan exists, units unfinished | /request-devflow-plan:kickoff sprint <next unsigned unit> — or continue sprint <n> when one is half-done |
| All feature units signed off, no audit round yet | /request-devflow-plan:audit (fresh session) |
| Latest audit round: PASS | /request-devflow-plan:handoff |
| Latest audit round: FAIL | /request-devflow-plan:plan — remediation mode picks the report up |
| Small bug, no plan involved | fix it directly, oriented by the foundation docs — no command needed (see the usage guide's bug scenario) |
Step 3 — Show the map
Close with a compact lifecycle overview (plan → kickoff/review loop → built-in acceptance audit → PASS / PASS WITH FINDINGS / FAIL routing → handoff), the six commands with one line each, and where the full guides live: docs/USAGE.md and docs/USAGE.zh-TW.md in the plugin repository (https://github.com/Zhen-Bo/request-devflow-plan) — also present in the installed plugin's own folder.
Never
- Modify any file
- Start lifecycle work from here — help orients; the recommended command does the work