agentleFS
Sign inStart free
thesawdawgthesawdawg/agent-skills/workflow-rules/SKILL.md

workflow-rules

Skill2 starsChanged 57 days agoMITView on GitHub

Sawyer's personal workflow, git, and engineering rules. Apply whenever writing, reviewing, or refactoring code; running git commands or generating commits; or starting any non-trivial task. Advises never git push, co-author-only-on-approval, proportionate clarification, DRY/modular OOP design, full typehints and docstrings, and clean-over-verbose code. Includes on-demand language and commit conventions.

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Co-authoring requires explicit approval: Do not add a Co-Authored-By trailer automatically.

    line 20
  2. Distinctive:

    Keep things simple. Favor clean, maintainable code over clever or verbose code.

    line 28
  3. Very specific:

    Check for an existing helper/class/module before writing a new one.

    line 31
  4. Distinctive:

    Comments explain why, not what: Keep them current.

    line 41
  5. Distinctive:

    Ask only for missing information that changes the result.

    line 47
  6. Very specific:

    When relevant, consult and update persistent memory — see the memory skill.

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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 & Engineering Rules

These are the user's (Sawyer / "Sawdawg") standing preferences. Apply them by default on every coding and git task. For language-specific style (PEP 8, Conventional Commits format, Flask patterns), defer to the style reference.

Git — Hard Rules

  • Never run git push. Pushing is the user's job, always. Stage, commit, and report status — but stop before pushing, no exceptions.
  • Commits follow Conventional Commits. See the style reference for the full type/scope/format spec.
  • Commit message tone: simple and to the point. Avoid verbose language; optimize for readability.
  • Co-authoring requires explicit approval. Do not add a Co-Authored-By trailer automatically. Only the committer set in git config user.* appears unless the user explicitly asks for a co-author.
  • Branch by feature or fix (feat/add-login, fix/db-timeout); keep commits small and focused.

Engineering Philosophy

Keep things simple. Favor clean, maintainable code over clever or verbose code.

  • DRY — reuse existing functionality; never re-implement what already exists. Check for an existing helper/class/module before writing a new one.
  • Object-oriented & modular — implement features as classes designed for object usage. Structure for modularity, and lift shared behavior into a common parent class where it fits (e.g. an authenticated-client base, a db-connection base).
  • Maintainability first — code must be understandable in 6 months by any other developer. Prefer clarity over brevity.
  • Typehints everywhere — every function signature and class attribute.
  • Full docstrings for every function: description, Args, and Returns (and Raises when non-obvious).
  • Comments explain why, not what. Keep them current.
  • Docs — update the relevant README / docs whenever behavior or interfaces change.

Working Style

  • Ask only for missing information that changes the result. Reuse earlier answers and approved artifacts; do not repeat interviews or permission gates.
  • When relevant, consult and update persistent memory — see the memory skill.

These are advisory skill instructions. Installation does not register always-on rules. For enforcement, explicitly configure the relevant project AGENTS.md or host rules; never rewrite personal rules as a side effect of using this skill.

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.

Check your setup, free