agentleFS
theyoungastronautstheyoungastronauts/polaris/skills/work-discipline/SKILL.md

work-discipline

Skill4 starsChanged 3 months agoMITView on GitHub

Execution discipline for implementing planned work: when to enter plan mode, how to timebox exploration, subagent strategy, verify-as-you-go, and when to stop and re-plan. Apply while implementing any phase or non-trivial change.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If something goes sideways mid-implementation, stop and re-plan — don't keep pushing a broken approach

    line 14
  2. Distinctive:

    Use plan mode for verification steps too, not just building

    line 15
  3. Distinctive:

    Write detailed specs upfront to reduce ambiguity

    line 16
  4. Distinctive:

    Use subagents liberally to keep the main context window clean

    line 20
  5. Distinctive:

    Never declare a task complete without proving it works

    line 28
  6. Distinctive:

    Run tests, check logs, demonstrate correctness after each meaningful change

    line 29
  7. Distinctive:

    Ask yourself: "Would this pass code review without revision?"

    line 31
  8. Distinctive:

    If a fix feels hacky, step back — knowing everything you know now, implement the clean solution

    line 38
  9. Distinctive:

    When given a bug report, gather evidence first: read the error, check the code, understand the cause

    line 44
  10. Distinctive:

    Don't shotgun-fix by trying multiple things at once — change one thing, test, iterate

    line 47
  11. Distinctive:

    If any of these happen, stop coding and re-enter plan mode:

    line 51

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

Skill: Work Discipline

Purpose

Behavioral guardrails for while you're actively implementing. This complements planning skills (what to build) and verification skills (did it work) with guidance on how to work.

1. Plan Mode Defaults

  • Enter plan mode for any non-trivial task (3+ steps or architectural decisions)
  • If something goes sideways mid-implementation, stop and re-plan — don't keep pushing a broken approach
  • Use plan mode for verification steps too, not just building
  • Write detailed specs upfront to reduce ambiguity

2. Subagent Strategy

  • Use subagents liberally to keep the main context window clean
  • Offload research, exploration, and parallel analysis to subagents
  • One task per subagent for focused execution
  • For complex problems, throw more compute at it via subagents rather than cramming everything into one context
  • Waiting on subagents for more than a few minutes? Arm a stall watchdog first (the "Arm the watchdog" step in /autopilot and /orchestrator). Silence must have a deadline; a hung agent otherwise blocks the lead forever

3. Verify As You Go

  • Never declare a task complete without proving it works
  • Run tests, check logs, demonstrate correctness after each meaningful change
  • Diff behavior between main and your changes when relevant
  • Ask yourself: "Would this pass code review without revision?"
  • This is lighter than /verify — just the habit of checking your own work before moving on

4. Simplicity and Minimal Impact

  • Make every change as simple as possible — impact minimal code
  • For non-trivial changes, pause and ask "is there a more elegant way?"
  • If a fix feels hacky, step back — knowing everything you know now, implement the clean solution
  • Skip this for simple, obvious fixes — don't over-engineer
  • Changes should only touch what's necessary — avoid introducing unrelated modifications

5. Bug Fixing

  • When given a bug report, gather evidence first: read the error, check the code, understand the cause
  • Point at logs, errors, failing tests — then resolve them
  • Fix root causes, not symptoms. No temporary workarounds masquerading as fixes
  • Don't shotgun-fix by trying multiple things at once — change one thing, test, iterate

6. Re-Plan Trigger

If any of these happen, stop coding and re-enter plan mode:

  • The plan's assumptions no longer match what you're seeing in the code
  • You've discovered a dependency the plan didn't account for
  • A task is turning out 3x more complex than expected
  • You're about to make changes outside the current phase scope

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.