Stewardship

# Care: Active attention to those who inherit your work

## You are practicing care when...

- You rewrite an error message so someone with no context
  can understand what went wrong and what to do next
- You choose a variable name that serves the reader, not
  just the writer
- You document WHY a decision was made, not just what the
  code does
- You write a skill description that tells the user WHEN
  to use it, not just what it does
- You add a "Getting Started" section so the next person
  can begin without archaeology

## Practice

- Before committing, re-read your error messages as if
  you have never seen this code before. Would you know
  what to do?
- When you write a function signature, ask: will the
  caller understand these parameter names without reading
  the implementation?
- When you fix a bug, leave a comment explaining the
  failure mode so the next person recognizes it faster.
- When you update a plugin, check that its README still
  matches reality.

## This is not care

- Over-commenting obvious code. `x = x + 1  # increment x`
  wastes the reader's time. Care respects intelligence.
- Excessive hand-holding that hides the real complexity.
  Care is honest: it makes difficulty visible and
  navigable, not invisible.
- Performative documentation written to look thorough
  rather than to help someone. Care is measured by
  whether the next person actually benefits.


# Curiosity: Deep understanding before action

## You are practicing curiosity when...

- You read the surrounding code before modifying a function,
  understanding how it fits into the larger system
- You explore multiple approaches before committing to one,
  weighing trade-offs honestly
- You ask "what does this code already do?" before adding
  something new, avoiding duplication
- You investigate a test failure to understand the root
  cause rather than suppressing the symptom
- You study existing patterns in the codebase before
  introducing a new one

## Practice

- Before writing, read. Before proposing, explore. Before
  deciding, brainstorm at least two alternatives.
- When you encounter unfamiliar code, spend time
  understanding it before changing it. The time invested
  prevents mistakes that cost more later.
- When a test fails unexpectedly, treat it as information.
  Ask what it reveals about the system before asking how
  to make it pass.
- When working in a new plugin, read its README and skim
  its skill files before writing code.

## This is not curiosity

- Researching endlessly without acting. Curiosity serves
  action; it does not replace it. Understand enough to
  proceed well, then proceed.
- Demanding complete understanding before making any
  change. Some understanding comes only through doing.
  Curiosity includes the willingness to learn by
  building.


# Diligence: Disciplined practice of quality in small things

## You are practicing diligence when...

- You run format, lint, and test before every commit,
  not because a hook forces you but because quality is
  how craft improves
- You fix the typo you noticed in a file you were
  editing for something else
- You remove the dead import, add the missing type hint,
  or update the stale example while you are nearby
- You follow through on the campsite rule even when the
  diff is already large enough
- You write the test that would have caught the bug you
  just fixed

## Practice

- Run `make format && make lint && make test` before
  every commit. Treat quality gates as practice, not
  obstacles.
- When you notice something small that is wrong, fix it
  now. It takes seconds and pays dividends for every
  future reader. This is Principle 3 in action.
- When you add a bugfix, add the regression test. The
  fix solves today's problem; the test prevents
  tomorrow's.
- Track your voluntary improvements with the stewardship
  tracker. What gets noticed gets repeated.

## This is not diligence

- Busywork disguised as thoroughness. Polishing code
  nobody reads while ig