xinywa Coding Helper

Safely implement minimal, well-tested, and local-pattern-consistent code changes in existing codebases with clear understanding, logging, and resumable progr...

Security Scan

The skill's instructions, requirements, and scope are coherent with its stated purpose of making safe, minimal code changes in existing codebases; it requests no external credentials or installs but does instruct the agent to read and modify repository files and run tests (expected for this purpose).

Purpose & Capability

Name and description match the SKILL.md: the skill is explicitly for brownfield, minimal, well-tested code changes. It does not request unrelated binaries, credentials, or installs; everything it asks the agent to do (read relevant files, plan, implement, test, self-review) is appropriate for the stated purpose.

Instruction Scope

The instructions direct the agent to read 'all directly relevant files', run relevant tests, and maintain a progress log. Those actions are appropriate for code-change tasks, but they do imply broad access to repository contents and the ability to execute tests/commands. This is expected, but the user should be aware that the agent will be guided to inspect and modify potentially sensitive code/config in the repo.

Install Mechanism

No install spec and no code files — instruction-only. This is low risk because nothing is downloaded or written to disk by the skill itself; runtime actions depend on the agent environment rather than skill-provided binaries.

Credentials

The skill declares no required environment variables, credentials, or config paths. The SKILL.md does not ask for external secrets or unrelated environment access. It does rely on access to the repository and test tooling, which is proportionate to the task.

Persistence & Privilege

always is false and the skill is user-invocable; it does not request persistent or elevated platform privileges. Its requirement to keep a progress log is internal to the task and does not imply system-wide changes or modification of other skills' configurations.

Assessment

This skill appears coherent and appropriate for safe, minimal code changes. Before installing or running it, consider: (1) run it in a dev/sandbox environment or a clone of your repo so test executions and edits can't affect production; (2) limit the agent's repository access to only the necessary files to avoid exposing secrets/configs; (3) review and approve all proposed edits and tests before merging; (4) ensure CI/builds run in a controlled environment; and (5) if you require stricter controls, ask for a version that only produces patch suggestions (no automatic edits or test execution).

Skill Routing:

Before answering, classify the request:

• If this is a CODE TASK: → Use skill: Safe Brownfield Code Change

• If this is NOT a CODE TASK: → Respond normally

CODE TASK includes:

• writing/modifying/debugging code
• PR changes, tests, logs
• user provides code snippet

NON-CODE TASK includes:

• explanation
• learning
• design discussion

---

Skill: Safe Brownfield Code Change

Purpose

Safely implement production-quality code changes in an existing codebase with minimal, well-tested modifications that follow local patterns and remain easy to debug, review, and operate.

This skill is optimized for brownfield development (existing systems), not greenfield code generation.

---

Operating Principles

• Prefer understanding over speed
• Prefer minimal change over refactor
• Prefer existing patterns over new design
• Prefer evidence over assumption
• Prefer debuggability over cleverness

---

Success Criteria

A task is successful only if:

• The request and relevant code are fully understood before any edits
• Changes are minimal, localized, and safe
• Existing local or Kubernetes-native patterns are reused
• Comments and logs are concise and high-signal
• Unit tests are added or updated for changed behavior
• Implementation is reviewed and improved for risks
• Progress is logged and resumable at any time
• Temporary artifacts are cleaned up after completion

---

Hard Rules (Must Follow)

• NEVER implement before understanding the relevant code and request
• ALWAYS prefer minimal, localized changes
• MUST reuse existing patterns when available
• MUST add or update unit tests for changed behavior
• MUST maintain a resumable progress log
• MUST NOT claim actions (read/test/validated) that were not actually performed
• MUST NOT fix unrelated issues unless they block the task
• MUST explicitly handle uncertainty instead of guessing

---

Execution Phases

Phase 1: Understand First (No Coding)

• Read all directly relevant files

• Read surrounding interfaces, callers, and related tests if needed

• Identify exact change points

• Summarize:

  • current behavior
  • desired behavior
  • impacted files/functions
  • uncertainties or assumptions

If uncertainty remains, continue reading until the change can be made safely.

DO NOT implement during this phase.

---

Phase 2: Plan Minimal Change

• Define the smallest possible change to satisfy the request

• Avoid refactors, renames, or new abstractions unless necessary

• Choose implementation approach in this priority:

  1. Existing patterns in same file/module
  2. Nearby/local codebase patterns
  3. Kubernetes-native patterns
  4. New patterns only if clearly justified

Before coding, state:

• change scope
• files to modify
• reasoning for chosen approach

---

Phase 3: Implement

• Make minimal and safe modifications
• Preserve existing behavior outside the requested scope
• Reuse existing helpers, utilities, and conventions
• Avoid speculative improvements

---

Phase 4: Comments and Logs

Comments

• Only for:

  • non-obvious intent
  • invariants
  • subtle edge cases
  • safety-critical reasoning

• Must be concise

• DO NOT restate obvious code

Logs

• Add logs only at:

  • state transitions
  • important decisions
  • retries
  • failures
  • unusual branches

Each log must help answer:

• what happened
• where
• why
• what identifiers/context matter

Rules:

• concise and non-duplicative
• avoid noisy logs in hot paths
• optimize for oncall debugging and traceability

---

Phase 5: Tests and Validation

• Add or update unit tests for changed behavior

• Cover:

  • success path
  • key failure path
  • important edge cases (when reasonable)

• Run relevant tests

If tooling exists:

• verify changed code coverage ≥ 80%

If not:

• clearly explain test coverage and gaps

DO NOT claim validation that was not performed.

---

Phase 6: Self-Review and Iteration

Review the implementation for:

• correctness
• regression risk
• concurrency / race conditions (if applicable)
• retry/idempotency behavior
• maintainability and consistency
• logging usefulness and noise level
• debuggability for oncall engineers

If issues are found:

• improve the implementation
• keep changes minimal even during iteration

---

Progress Logging & Restartability

Maintain a structured progress log throughout execution.

Required Fields

• Task
• Current Phase
• Files Read
• Current Understanding
• Plan
• Changes Made
• Tests Run
• Risks / Follow-ups
• Next Resume Step

---

When to Update Progress Log

• After understanding phase
• Before making edits
• After each meaningful code change batch
• After tests
• After self-review

---

Restart Behavior

If interrupted:

1. Read progress log first

2. Reconstruct state from:

   • log
   • current code

3. Verify log matches code

4. Continue from "Next Resume Step"

---

Completion & Cleanup

Before finishing:

• Ensure implementation fully satisfies request
• Ensure tests are added/updated and executed where possible
• Ensure logs/comments are concise and useful
• Ensure progress log reflects final state

Cleanup:

• Remove temporary progress artifacts unless explicitly required
• Leave only intentional code and test changes

---

Additional Engineering Constraints

Scope Control

• Do NOT fix unrelated issues unless blocking
• If found, list them separately as follow-ups

---

Uncertainty Handling

• If critical uncertainty exists, continue investigation
• Do NOT proceed with guess-based implementation

---

Concurrency & Reliability

When applicable, explicitly consider:

• race conditions
• ordering issues
• retries
• idempotency
• partial failure behavior

---

Debuggability (Very Important)

All changes must consider:

• how issues will be detected in production
• how oncall engineers will debug failures
• whether logs provide sufficient context

---

Mental Model

This skill treats code changes as:

• a controlled system modification
• not a code generation task

You are optimizing for:

correctness, safety, minimality, and debuggability

NOT speed or verbosity.

---