Implement

You are a developer working on the sfdx-hardis project.

Implement the requested changes. If a prior /design conversation exists, follow that specification. Otherwise, derive the implementation plan from the user's request and the existing codebase - explore relevant files with Glob/Grep before writing any code.

Read .claude/rules/ for coding conventions, i18n rules, and translation rules before making changes.

Related agents: this skill mirrors the implement subagent (same conventions, on Opus for the core code). It stays inline so it can follow the prior /design conversation and orchestrate cheaper helper agents. Two recurring subtasks can be delegated to keep Opus focused on the code:

• i18n key propagation across the 9 locales -> the i18n-translate agent (Sonnet).
• The CHANGELOG entry -> the changelog agent (Haiku).

Delegate these only when running through this skill (the main loop). Run the core edits yourself.

Process

1. Understand what to implement: If a /design spec exists in the conversation, follow it. Otherwise, read the user's request, grep for relevant existing code, and form a clear implementation plan before writing anything.
2. Implement changes following project conventions:
   • Use .js import extensions
   • Use uxLog() with chalk for logging (no emojis at line start)
   • Use t() for all user-visible strings
   • Use native fs for file operations (or src/common/utils/fsUtils.ts for its extra helpers), never fs-extra
   • Use prompts() for user input
   • Follow the provider pattern for external integrations
   • In src/commands/** files, keep only the command class declaration in the file body; move interfaces, types, and helper functions to sibling utility modules.
   • Allowed exception: top-level Messages.importMessagesDirectoryFromMetaUrl(import.meta.url) and const messages = Messages.loadMessages(...) can remain in command files.
3. Extension side: When the design touches vscode-sfdx-hardis, load the vscode-sfdx-hardis skill and implement that part in ../vscode-sfdx-hardis, following that repository's CLAUDE.md and .claude/skills/implement/SKILL.md rather than the sfdx-hardis conventions. The CLI stays the engine: the extension passes flags, it does not duplicate CLI logic.
4. Add translations: If new i18n keys were introduced, add them to all 9 locale files (en, de, es, fr, it, ja, nl, pl, pt-BR), sorted alphabetically. For more than a couple of keys, delegate this to the i18n-translate agent (Sonnet) via the Agent tool - pass it the English keys and text.
5. Update command description: If you add, remove, or change the behavior of a command in src/commands/**, update its static description property to accurately reflect the new behavior. Follow the format in the documentation skill: ## Command Behavior section listing key features, and a <details>Technical explanations</details> block. If the command gains or loses an --agent flag, update the ### Agent Mode section accordingly and update docs/salesforce-agentic-automation.md.
6. Update JSON schema: If a config property is added or modified (anything read via getConfig()), update config/sfdx-hardis.jsonschema.json to match. Each property needs $id, description, title, type, and optionally default, enum, examples, docUrl.
7. Verify patterns: Ensure new code matches existing patterns in the codebase. 7b. Monitoring AGENTS.md: if the change touches what a monitoring repository's AGENTS.md describes (the backup output, the monitoring pipelines and commands, what is sent to Grafana, monitoring config keys, the CI/CD pipeline behavior, git provider APIs or token variables), load the monitoring-agents-md skill and update defaults/templates/monitoring/AGENTS.md in the same change. Nothing fails when it goes stale: coding agents just answer wrong.
8. Update CHANGELOG.md: Add a bullet under ## [beta] (main). Be radically concise: announce the feature in ONE short line per entry, nothing more. Readers who want details click the command's doc URL. You can delegate this single line to the changelog agent (Haiku) via the Agent tool - pass it a short description of the change and the command path if any.
   • One line per entry. No sub-bullets, no enumerations of flags / env vars / config keys / behavior details. Those live in the command's description and the auto-generated docs page.
   • Write for end users, not developers. State what they can now do (or what was fixed) - omit class names, method names, file paths, i18n keys, TypeScript types, flag names, default-value numbers, status codes, internal field names, Setup paths.
   • If a new command was added, include a link: [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/). If an existing command was modified, reference it the same way.
   • Avoid run-on sentences. If the entry needs commas or "and" three times, you are over-explaining - trim until it fits one line.
   • Example - good:

     - New [hardis:org:diagnose:mfa](https://sfdx-hardis.cloudity.com/hardis/org/diagnose/mfa/): Audit MFA configuration and prepare for Salesforce's July 1 2026 phishing-resistant MFA enforcement.

   • Example - too verbose (do NOT do this):

     - New [hardis:org:diagnose:mfa](...): Audit MFA.
       - Primary check: phishing-resistant MFA readiness via VerificationHistory.
       - Five additional checks: org-wide MFA enforcement, ...
       - New `--lookback-days`, `--ignore-users`, `--privileged-permissions` flags.
       - New `monitoringMfaIgnoreUsers` config key.
       - Wired into monitor:all at weekly frequency.

     All the bullets above belong in the command's description and the docs page, not the changelog.
   • Exception: a sub-bullet is acceptable ONLY when a single behavior change has a critical user-visible aspect that cannot wait for the docs (e.g. a breaking migration, a required follow-up action). Default to no sub-bullets.