workflow
Skill80 starsChanged 8 months agoMITView on GitHub
Run the complete 5-step development workflow: focus problem → prevent over-development → test-first (TDD) → document → smart commit. Use when starting a new feature, or when the user runs /workflow or asks for the full development flow.
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 54 edited versions we read keep these.
2
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
- Very specific: line 41
Before dispatch, preserve the bounded exploration request and expected result.
- Very specific: line 42
If Claude's Agent tool is unavailable or withheld, or Codex's spawn_agent interface is unavailable or withheld, the maximum depth is …
- Distinctive: line 66
Goal: Ensure minimal viable implementation (YAGNI principle).
- Distinctive: line 108
Goal: Ensure code is understandable.
“Common” is measured: kept by at least 6 in 10 of the 54 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
Development Workflow
A structured approach to software development that emphasizes understanding, minimal implementation, testing, documentation, and clean commits.
Overview
Step 1: Focus Problem → Understand before coding
Step 2: Prevent Overdev → Only build what's needed (YAGNI)
Step 3: Test First → Red-Green-Refactor
Step 4: Document → Keep it clear and current
Step 5: Smart Commit → Conventional CommitsStep 1: Focus Problem (/focus-problem)
Goal: Thoroughly understand the problem before writing code.
Checklist
- What is the user need? (Who / What / Why)
- What defines success? (How to verify completion?)
- What are the boundaries? (What NOT to do?)
- What files/modules are affected?
- Is there existing similar functionality?
Use Explore Agent
(Use the active provider's native dispatcher; Claude pseudo-code is shown below.)
Before dispatch, preserve the bounded exploration request and expected result.
If Claude's Agent tool is unavailable or withheld, or Codex's spawn_agent
interface is unavailable or withheld, the maximum depth is reached, or a
concurrency limit rejects the call, do not retry or substitute assumptions.
Return an incomplete dispatch_request and do not advance the workflow.
Choose exactly one provider-native form:
- Claude Code:
Agent(subagent_type="Explore", model="haiku", prompt="<bounded prompt>") - Codex CLI:
spawn_agent(agent_type="explorer", task_name="workflow_explore", message="<bounded prompt>")
Agent(subagent_type="Explore", model="haiku", prompt="""
Explore the codebase for: [feature name] (thoroughness: medium)
Find related files, similar implementations, and test patterns.
""")In Codex, send the same exploration request through spawn_agent(...); do not
invoke the Claude example as a second dispatch.
Step 2: Prevent Overdev
Goal: Ensure minimal viable implementation (YAGNI principle).
Red Flags
"We might need this later..." → Don't build it now
"Just in case..." → YAGNI
"Let's make it generic..." → Solve current problem only
"We should create a framework..." → Write concrete implementationChecklist
- Is there immediate need for this?
- Is this over-abstracted?
- Can this be simpler?
- Are we adding unnecessary dependencies?
Step 3: Test First (/test-first)
Goal: Strict TDD (Red-Green-Refactor).
Red Phase (Write Failing Test)
- Write a test for expected behavior
- Run test, confirm it fails
- Failure message clearly indicates the issue
Green Phase (Minimal Implementation)
- Write minimum code to pass test
- Don't optimize yet
- Run test, confirm it passes
Refactor Phase
- Clean up code (keep tests passing)
- Remove duplication
- Improve naming
- Simplify logic
Step 4: Document
Goal: Ensure code is understandable.
Checklist
- README describes purpose and usage
- Public APIs have docstrings
- Complex logic has comments explaining "why"
- No obvious-comment clutter
Step 5: Smart Commit (/smart-commit)
Goal: Clean version history with Conventional Commits.
Format
<type>(<scope>): <description>Types
feat- New featurefix- Bug fixdocs- Documentationtest- Testsrefactor- Code restructure
Quick Start
# Run full workflow
/workflow
# Or individual steps
/focus-problem "implement user login"
/test-first
/smart-commitRelated Skills
| Skill | Purpose |
/focus-problem | Step 1: Problem analysis |
/test-first | Step 3: TDD cycle |
/smart-commit | Step 5: Create commit |
/plan | Break down complex tasks |
Other versions69 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 69
- openai/plugins★ 7.4ksame 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★ 444same name
- notque/vexjoy-agent★ 444same name
- brianlovin/claude-config★ 376same name
- vercel/vercel-plugin★ 323same name
59 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.
Used alongsideProjects 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
In this repository36 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- changelog-observerSkill
- agent-checkSkill
- agentsSkill
- agent-templateSkill
- auto-loopSkill
- changelogSkill
- check-environmentSkill
- claude-md-checkSkill
- claude-md-templateSkill
- code-reviewerSkill
- debuggerSkill
- director-modeSkill
- doc-writerSkill
- evolving-loopSkill
- evolving-statusSkill
- focus-problemSkill
- getting-startedSkill
- handoff-claudeSkill
- handoff-codexSkill
- handoff-geminiSkill
- handoff-grokSkill
- hooks-checkSkill
- hook-templateSkill
- interop-routerSkill
- mcp-checkSkill
- planSkill
- project-health-checkSkill
- project-initSkill
- session-relaySkill
- skill-checkSkill
- skillsSkill
- skill-templateSkill
- smart-commitSkill
- test-firstSkill
- test-runnerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

