workflow
Skill16 starsChanged 8 months agoMITView on GitHub
High-velocity solo development workflow. Idea to production same-day. 10 commands: plan, spike, ship, fix, review, spec-review, focus, done, drop, workflow. Auto-activates on: "plan", "spec", "ship", "spike", "fix", "debug", "repair", "spec-review", "review spec", "analyze spec", "challenge spec", "focus", "what should i do", "prioritize", "overwhelmed", "what should i work on", "done", "finish", "complete", "drop", "abandon", "workflow", "what's next", "whats next", "next step", "what now".
71 other projects use a version of this.
Adopted by
Most recently taken up by
- zaynram/scholartheir own version, first seen Nov 8, 2026
- codicis-ai/taskplextheir own version, first seen Nov 8, 2026
- notque/vexjoy-agenttheir own version, first seen Nov 7, 2026
- raphaeltm/simple-agent-managertheir own version, first seen Nov 7, 2026
- menot-you/n-soultheir own version, first seen Nov 1, 2026
- DaeSeokSong/oh-my-ouroborostheir own version, first seen Nov 1, 2026
Used with
Projects with it also use build-keil, can-debug and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ZhongYechengSkillbuild-keil
当需要通过 Keil MDK 命令行编译嵌入式工程,调用自带脚本解析工程文件、执行构建并定位固件产物时使用。
Also in 3 projects that use this
ZhongYechengSkillcan-debug
当需要调试 CAN 总线通信时使用,支持通过 USB-CAN 适配器监听、发送 CAN 帧和扫描节点。
Also in 3 projects that use this
iPlug2Skillbuild-cmake
Build an iPlug2 plugin project using CMake with Ninja, Xcode, or Visual Studio generators
Also in 3 projects that use this
- +9 more from ZhongYecheng
Other versions71 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 71
- openai/plugins★ 7.8ksame name
- vercel-labs/open-agents★ 5.8ksame name
- vercel/workflow★ 2.5ksame name
- orangehrm/orangehrm★ 1.1ksame name
- zhinkgit/embeddedskills★ 764same name
- waynesutton/markdown-site★ 628same name
- notque/claude-code-toolkit★ 448same name
- notque/vexjoy-agent★ 448same name
- brianlovin/claude-config★ 376same name
- vercel/vercel-plugin★ 328same name
61 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- llms-full.txtllms.txt
- llms.txtllms.txt
- analyzeSkill
- convexSkill
- githubSkill
- gitSkill
- oss-readinessSkill
- skill-builderSkill
- tmuxSkill
The file
We split this skill into the rules it gives an agent
11 rules. 0 are common, 9 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 55 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Fallback rule: If your agent lacks a capability, use the fallback.
- Distinctive: line 51
No flags needed. The agent auto-detects intent from context:
- Very specific: line 66
Don't know what to work on: focus
- Distinctive: line 70
Spec-first: All work needs a spec (creates one if missing)
- Distinctive: line 73
E2E-first testing: Default to E2E tests. Unit tests only for pure functions
- Distinctive: line 76
AC-driven coverage: Every Must Have + Error AC maps to an E2E test in the scenario registry
- Distinctive: line 78
Failure mode testing: Every HIGH/MED failure hypothesis gets a defensive E2E test
- Very specific: line 81
Own planning: Never use the host agent's built-in plan mode (EnterPlanMode, etc.).
- Distinctive: line 112
Loading rule: Read the action file BEFORE executing.
- Distinctive: line 116
No separate action file — logic is inline here.
- Distinctive: line 146
All behavior is configurable by editing the skill files directly.
“Common” is measured: kept by at least 6 in 10 of the 55 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Workflow
High-velocity solo development. Idea to production same-day.
Agent Capabilities
| Capability | Used For | Required | Fallback |
| File read/write | Specs, config, history | Yes | — |
| Code search (grep/glob) | Discovery, context | Yes | — |
| Shell/command execution | Quality gates (lint, build, test) | Yes | List commands for user to run |
Codebase intelligence (npx codebase-intelligence) | Structural analysis for TS/TSX projects (graph, metrics, blast radius) | No | grep/glob/read (manual exploration) |
| Task/todo tracking | Phase management | Recommended | Track in spec Progress section |
| User interaction | Stuck escalation, risk flags | Recommended | Log decisions in spec Notes |
| Web/doc search | Pattern lookup | No | Use embedded patterns |
Fallback rule: If your agent lacks a capability, use the fallback. Never skip the workflow step — adapt the method.
Commands
| Command | Action | Reference |
plan {idea} | Create spec | plan.md |
spike {question} | Time-boxed exploration | spike.md |
ship / ship {idea} | Implement + validate | ship.md |
fix / fix {bug} | Scientific debug + regression fix | fix.md |
review | Portable multi-perspective review spec with line-by-line + rule-by-rule coverage | review.md |
spec-review | Adversarial spec analysis | spec-review.md |
focus | Priority analysis + task proposals | focus.md |
done | Validate + retro + archive | done.md |
drop | Abandon, preserve learnings | drop.md |
workflow | Show state + suggest next | Status (below) |
No flags needed. The agent auto-detects intent from context:
- "review the spec" → manual review pause
- "skip tests" → skip test gate (documented)
- "fix this bug" → dedicated bug fix with regression test
- "emergency fix" → bypass spec ceremony
- "production ready" → production validation
Flow
Features: focus → plan {idea} → ship → [implement/review/fix loop] → done
Bug fixes: fix {bug} → [investigate/TDD/validate] → doneQuick mode (<2h): ship {idea} → done
Don't know what to work on: focus
Philosophy
- Spec-first: All work needs a spec (creates one if missing)
- Ship loop: Build → review → fix until clean
- Quality gates: lint → typecheck → build → test → E2E → coverage (auto-detected per project)
- E2E-first testing: Default to E2E tests. Unit tests only for pure functions
- TDD enforced: RED → GREEN → REFACTOR per AC. Tests written before implementation (BLOCKING)
- Mock boundary: Real systems preferred. Mock only third-party APIs without sandbox (last resort)
- AC-driven coverage: Every Must Have + Error AC maps to an E2E test in the scenario registry
- Anti-regression: Bug fixes require E2E regression test + anti-cascade diff (BLOCKING)
- Failure mode testing: Every HIGH/MED failure hypothesis gets a defensive E2E test
- Human controls deployment: Agent codes, you push/deploy
- Done same-day: Scope to what ships today
- Own planning: Never use the host agent's built-in plan mode (EnterPlanMode, etc.). This skill writes real spec files to
specs/active/.
Spec Tiers
| Tier | Size | Spec | Task Tracking |
| trivial | <5 LOC | None — just do it | No |
| micro | <30 LOC | Inline comment in code | No |
| mini | <100 LOC | Spec file, minimal | Yes (if available) |
| standard | 100+ LOC | Full spec with checklist | Yes (if available) |
Action Router
User input
│
├─ "plan", "spec", "design" → Load references/actions/plan.md
├─ "spike", "explore", "investigate" → Load references/actions/spike.md
├─ "ship", "implement", "build" → Load references/actions/ship.md
├─ "fix", "debug", "repair" → Load references/actions/fix.md
├─ "review", "check code" → Load references/actions/review.md
├─ "review spec", "analyze spec",
│ "challenge spec" → Load references/actions/spec-review.md
├─ "focus", "what should i do",
│ "prioritize", "overwhelmed" → Load references/actions/focus.md
├─ "done", "finish", "complete" → Load references/actions/done.md
├─ "drop", "abandon" → Load references/actions/drop.md
└─ "workflow", "what's next", "what now",
"what's up", "whats up", "status" → Status Action (below)Loading rule: Read the action file BEFORE executing. The action file contains all logic, task templates, and references needed.
Status Action
No separate action file — logic is inline here. Detect current state, suggest next action:
1. Check specs/active/ for active spec
2. Check git status for uncommitted work
3. Check task list for in-progress items
State → Suggestion:
No spec, no changes → "Ready. Run: plan {idea}"
Active spec, no code → "Spec ready. Run: ship"
Active spec, code WIP → "In progress. Run: ship (resumes)"
Active spec, code done → "Ready to close. Run: done"
No spec, dirty tree → "Uncommitted work. Run: ship (creates spec) or done"Output: Follow status-output.md.
Project Structure
specs/
active/ ← Current work (0-1 specs)
backlog/ ← Queued work from focus
shipped/ ← Completed features
dropped/ ← Abandoned with learnings
history.log ← One-line per feature shipped/droppedConfiguration
All behavior is configurable by editing the skill files directly.
| What to change | Edit |
| Action logic, gates, limits | references/actions/{action}.md |
| Output format | references/templates/{action}-output.md |
| Spec structure | references/spec-template.md |
| Quality gate commands/levels | references/quality-gates.md |
| Session resume, stuck detection | references/session-management.md |
References
Actions:
- Plan | Ship | Fix | Review | Spec Review | Focus | Done | Drop | Spike
Output templates:
- Plan + Spec Review | Ship | Fix | Review | Focus | Done | Drop | Spike | Status
Review standards:
- Core portable review spec | Executor patterns | Production Standards
The portable review spec is normative. Executor patterns are optional implementation guidance.
Specs & gates:
- Spec template | Quality gates | Session management | Memory update | Testing automation | E2E scenarios | Codebase intelligence
Patterns:
- Implementation | Planning | Debugging | Decisions | Decomposition | Regression testing
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

