role-developer

Provides: An implementation workflow, standards routing, guardrails, and a done-check for production code changes.

Quick Reference

Flow: Understand → Load standards → Plan the seam → Implement → Test → Verify → Report

Bias: smallest useful change, existing conventions, early verification

Never: mask errors to get green results, or start implementing while requirements are ambiguous

Load Standards

Always load standards-code before changing production code, plus the language skill for the files being edited.

Load these when relevant:

These skills are the maintained source, not this one. standards-code owns the language-neutral rules and the language skill owns syntax and naming, standards-security owns the controls, standards-testing owns the conventions including tiered coverage targets. Load them rather than implementing from memory of what this skill used to say, because they may have moved on.

When a task references stored specifications and the host provides store tools, load tool-store. If store tools are unavailable, keep requirements in the task list or the conversation and omit [store:id] references rather than inventing repository files to stand in for them.

Workflow

1. Understand

• Restate the requested behavior and the acceptance criteria.
• Inspect nearby code and project conventions before editing.
• Ask only blocking questions; otherwise state your assumptions and proceed.

2. Plan the seam

• Choose the smallest change location that achieves the behavior.
• Identify the verification command before writing code. If you cannot name it, you do not yet know what "done" means.
• Add a task list only for genuinely multi-step work.

3. Implement

• Keep the diff focused and avoid drive-by refactors.
• Preserve public contracts unless changing them is the task.
• Validate inputs at boundaries and keep errors actionable.
• When the task is a refactor, confirm tests already cover the current behavior before changing anything. If they do not, add them first: without them you cannot tell a refactor from a regression. Keep the suite green between increments rather than only at the end.

4. Test

• Work test-first where the behavior is well specified: write the failing test, make it pass, then clean up.
• Prefer a failing regression test before a bug fix where practical.
• Cover changed behavior, edge cases, and the error paths this change affects.

5. Verify

• Run the narrowest relevant check first, then broaden if it passes.
• Capture long output to a file and quote only the relevant lines.

6. Report

• Summarize what changed, which files were touched, and the verification results.

Guardrails

• Do not start implementing when requirements or destructive actions are ambiguous. Ask first.
• Do not mask errors or weaken tests to get a green result.
• Do not introduce a new dependency without a stated reason.
• Do not assume a delegated agent shares your loaded skills or store context. State both explicitly in the delegation.

Checklist

Before declaring the work done:

• The required standards were loaded for every domain touched
• The code follows local conventions in the area changed
• Relevant tests, build, and lint ran, or skipped checks are explained
• The diff contains no unrelated refactors or leftover debug code
• The final response lists changed files and verification evidence

Integration with Other Skills

With role-architect: decide structure before implementing across module boundaries.

With role-qa-engineer: expand test coverage beyond the changed behavior.

With role-code-review: self-review the diff before submitting.

With role-security-auditor: get an independent pass on security-critical code.

With workflow-debugging: establish cause before fixing an unexplained failure.