agentleFS
bntvllntbntvllnt/agent-skills/workflow/SKILL.md

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

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.
  • ZhongYechengSkill

    build-keil

    当需要通过 Keil MDK 命令行编译嵌入式工程,调用自带脚本解析工程文件、执行构建并定位固件产物时使用。

    Also in 3 projects that use this

  • ZhongYechengSkill

    can-debug

    当需要调试 CAN 总线通信时使用,支持通过 USB-CAN 适配器监听、发送 CAN 帧和扫描节点。

    Also in 3 projects that use this

  • iPlug2Skill

    build-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

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
  1. Distinctive:

    Fallback rule: If your agent lacks a capability, use the fallback.

    line 34
  2. Distinctive:

    No flags needed. The agent auto-detects intent from context:

    line 51
  3. Very specific:

    Don't know what to work on: focus

    line 66
  4. Distinctive:

    Spec-first: All work needs a spec (creates one if missing)

    line 70
  5. Distinctive:

    E2E-first testing: Default to E2E tests. Unit tests only for pure functions

    line 73
  6. Distinctive:

    AC-driven coverage: Every Must Have + Error AC maps to an E2E test in the scenario registry

    line 76
  7. Distinctive:

    Failure mode testing: Every HIGH/MED failure hypothesis gets a defensive E2E test

    line 78
  8. Very specific:

    Own planning: Never use the host agent's built-in plan mode (EnterPlanMode, etc.).

    line 81
  9. Distinctive:

    Loading rule: Read the action file BEFORE executing.

    line 112
  10. Distinctive:

    No separate action file — logic is inline here.

    line 116
  11. Distinctive:

    All behavior is configurable by editing the skill files directly.

    line 146

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Workflow

High-velocity solo development. Idea to production same-day.

Agent Capabilities

CapabilityUsed ForRequiredFallback
File read/writeSpecs, config, historyYes—
Code search (grep/glob)Discovery, contextYes—
Shell/command executionQuality gates (lint, build, test)YesList commands for user to run
Codebase intelligence (npx codebase-intelligence)Structural analysis for TS/TSX projects (graph, metrics, blast radius)Nogrep/glob/read (manual exploration)
Task/todo trackingPhase managementRecommendedTrack in spec Progress section
User interactionStuck escalation, risk flagsRecommendedLog decisions in spec Notes
Web/doc searchPattern lookupNoUse embedded patterns

Fallback rule: If your agent lacks a capability, use the fallback. Never skip the workflow step — adapt the method.

Commands

CommandActionReference
plan {idea}Create specplan.md
spike {question}Time-boxed explorationspike.md
ship / ship {idea}Implement + validateship.md
fix / fix {bug}Scientific debug + regression fixfix.md
reviewPortable multi-perspective review spec with line-by-line + rule-by-rule coveragereview.md
spec-reviewAdversarial spec analysisspec-review.md
focusPriority analysis + task proposalsfocus.md
doneValidate + retro + archivedone.md
dropAbandon, preserve learningsdrop.md
workflowShow state + suggest nextStatus (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] → done

Quick 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

TierSizeSpecTask Tracking
trivial<5 LOCNone — just do itNo
micro<30 LOCInline comment in codeNo
mini<100 LOCSpec file, minimalYes (if available)
standard100+ LOCFull spec with checklistYes (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/dropped

Configuration

All behavior is configurable by editing the skill files directly.

What to changeEdit
Action logic, gates, limitsreferences/actions/{action}.md
Output formatreferences/templates/{action}-output.md
Spec structurereferences/spec-template.md
Quality gate commands/levelsreferences/quality-gates.md
Session resume, stuck detectionreferences/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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.