mstar-coding-behavior

Files (1)

• SKILL.md

SKILL.md (first lines)

# Coding Behavior

Start from the user's original outcome, not from the machinery already built.

## Workflow

1. **Plan from the need.** Identify the requested outcome, current acceptance criteria, non-goals, and actual constraints. Use first principles to separate what must be true from inherited implementation choices. State material assumptions; resolve questions from available evidence before asking for missing decisions.
2. **Read the affected flow.** Inspect the changed code, direct contracts, nearby behavior tests, and relevant project guidance. Before editing, map affected callers, tests, fixtures, configuration, and exports; identify data that could be destroyed or exposed and consumers that could break. Check API signatures against source or documentation. Existing artifacts are evidence, not additional requirements.
3. **Do the smallest complete change.** Choose the first fully working option in the reuse ladder below. Fix the root cause at the narrowest responsible point; finish affected consumers, tests, fixtures, configuration, exports, and documentation, removing paths made obsolete by the change. Preserve unrelated work and avoid opportunistic cleanup.
4. **Check the outcome.** Within the authorized verification scope, exercise the affected consumer behavior and meaningful boundaries. For a bug, use the reported failure or a minimal reproduction to guide diagnosis; change one causal factor at a time. Reuse unaffected evidence rather than rerunning unrelated checks.
5. **Act on evidence.** Compare results with acceptance criteria, diagnose any remaining failure, and refine only what is necessary. Assess review feedback against actual contracts and behavior; apply justified fixes or explain disagreement with evidence. Stop when the requested outcome is evidenced.

## Decision Rules

### Requirement-first simplicity

- Apply **Occam's razor and YAGNI**: prefer fewer concepts, moving parts, and assumptions that fully satisfy current requirements. Small does not mean incomplete, temporary, symptom-only, or cleverly compressed; a one-liner that needs decoding is not simpler. Between equally simple options, choose the one correct at the affected boundaries.
- Do not grow a design from existing layers just because they exist. Keep useful patterns, but replace a bad abstraction when the requested outcome requires it; do not preserve it solely for consistency.
- Never add imagined future features, extension frameworks, configuration knobs, compatibility wrappers, or speculative error handling. Each addition must answer a current requirement or a demonstrated risk in a supported workflow. Keep values in their existing form unless the contract requires conversion; do not add layers or wrappers merely to reshape them.
- Do not add validation, confirmation, or preflight gates for unsupported or hypothetical conditions. Retain trust-boundary validation, required authorization, security, data-loss prevention, accessibility, necessary hardware calibration, and requested behavior. Moving or merging code preserves its validation and error handling.
- Take the **first option that fully works**, not the shortest incomplete diff:
  1. Reuse a valid project helper, component, service, or pattern as surrounding code does; a suitable house component takes precedence over a native replacement.
  2. Use a standard-library or platform feature when no suitable house solution exists.
  3. Use an installed dependency; check its documentation and types before assuming it lacks the capability.
  4. Otherwise write the minimum readable direct solution. Add an established, well-maintained library only when it reduces overall complexity or improves reliability; check maintenance and size, and state the need in one sentence, not a new package for a few lines.
- Centralize and reuse sources of truth for prompts, contracts, and data instead of copying them; do not invent an abstraction framework to do so.
- Mark a deliberate bounded shortcut with `simplify:` and its ceiling/upgrade path. For an unavoidable workaround, explain why, label it `simplify:` or `temporary`, and record its removal path in the existing plan/status artifact before claiming completion. Temporary markers must cite that artifact.

### Agent-facing products

Treat ordinary agent mistakes as expected usage. Prioritize **discoverability, fault tolerance, and information fidelity**:

- Make commands, parameters, payload shapes, and recovery paths discoverable from help and errors. Verify what callers actually see: concrete invocations, parameters, and payload fields, not internal type names or generic capability claims. An undocumented capability is not a usable interface. Do not invent input modes unsupported by current requirements.
- Require only genuinely necessary input. Derive available facts and use safe defaults; ask for explicit target or authority when it cannot safely be inferred.
- Keep agent-authored content and mutations revisable through supported public operations. Avoid one-way restrictions or hidden manual repair; protect truly irreversible actions without making routine edits irreversible.
- Refusals must name the actual cause and exact supported recovery, not a generic block or an undocumented escape. When authority or an external prerequisite is missing, identify it honestly rather than inventing a bypass.
- Preserve real errors, distinctions, and partial outcomes. Never swallow or normalize away failures, fabricate success, or silently substitute a fallback that changes the meaning of the result.

### Surgical diagnosis and review

- Trace each changed region to the request, acceptance criteria, or a necessary integration fix. Follow callers only far enough to resolve the concrete affected behavior; do not restart repository-wide investigation.
- Read complete errors and relevant traces. Use observations to form a falsifiable cause, not a guessed patch. If reproduction is unavailable, disclose that limit and obtain the smallest missing evidence.
- Do not suppress an exception or special-case the failing input to make symptoms disappear. Correct the responsible invariant or flow and cover the demonstrated regression.
- Review suggestions are technical input, not automatic authorization. Prioritize correctness, security, and data loss; reject unrelated feature requests and ungrounded style changes rather than expanding scope.

## Evidence

Completion means the requested behavior meets its acceptance criteria, supported by the checks actually performed:

- For executable changes, retain the smallest relevant runnable check protecting consumer-visible behavior or a meaningful invariant. For bugs, demonstrate the regression and its correction when the available evidence and authorized checks permit.
- Test behavior, not source shape, prompt wording, forwarding echoes, or duplicated producer checks. Do not manufacture tests to satisfy a template.
- For non-executable policy changes, use scoped static or before/after evidence with observable criteria. Static lint does not establish model compliance or runtime behavior.
- Report the changed outcome and actual check commands/results concisely, including failures; never imply an unrun check passed. In the required report, use one or two closing lines for intentionally skipped work, material unverified behavior, and its user-facing risk. Separate observation from inference; a missing prerequisite is not a successful result.

## References

Standalone use requires no other Morning Star skill.

Only when working under Morning Star lifecycle or assignments, follow the existing authorities:

- `mstar-harness-core` — lifecycle, safeguards, gates, and Done ownership.
- `mstar-roles` — identity and Assignment skill-preset selection.
- `mstar-branch-worktree` / `mstar-dispatch-gates` — assigned checkout and delegation authority when applicable.

This skill does not waive those contracts, grant dispatch permission, or authorize Done.

From btspoony/mstar-harness, MIT.

More from btspoony/mstar-harness