Update to GodPrompt

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,63 +1,63 @@
----
-name: god-prompt
-description: |
-  Use when the user wants you to execute or review a software-engineering task in a
-  codebase and expects disciplined scoping, implementation, verification, and delivery
-  evidence. Suitable for building, debugging, refactoring, code review, release
-  preparation, and engineering automation. Do not use for general knowledge, casual
-  writing, translation, or simple lookups unless the user explicitly asks to apply the
-  GodPrompt engineering workflow.
----
-
-# GodPrompt - Scoped Production Engineering Workflow
-
-Apply this workflow only after the request matches the software-engineering scope in the
-skill description or the user explicitly invokes GodPrompt. The user's current request and
-higher-priority instructions always control scope and authority.
-
-## 1. Understand the requested outcome
-
-- Identify the concrete engineering outcome, repository or artifact in scope, and any
-  constraints already supplied by the user or repository instructions.
-- Inspect relevant code and configuration before proposing a mutation.
-- Treat external writes, deployments, credentials, billing, destructive operations, and
-  third-party actions as separate authority questions. Do not infer permission merely from
-  permission to edit code.
-- If a missing fact prevents a safe or correct result, ask for it. Otherwise make the
-  smallest reasonable assumption and state it when it affects the result.
-
-## 2. Bound the work
-
-- Keep changes inside the requested outcome. Preserve unrelated existing work.
-- Prefer the smallest change that fixes the root cause or satisfies the requirement.
-- For review or analysis requests, do not modify files unless the user also asked for a
-  fix or implementation.
-
-## 3. Execute proportionally
-
-- Use the repository's documented conventions and checks when available.
-- For bugs, establish the failure mode before changing code.
-- For refactors, preserve externally observable behavior unless the user requested a
-  behavior change.
-- For risky or irreversible actions, stop unless the current request explicitly authorizes
-  them.
-
-## 4. Verify before claiming success
-
-- Run the checks that are relevant to the changed behavior: focused tests first, then
-  broader build, lint, type, or integration checks when warranted.
-- Read the actual output. A command invocation is not evidence unless its result supports
-  the claim.
-- If verification cannot run, report the limitation and do not describe the result as
-  verified.
-
-## 5. Deliver evidence
-
-Report concisely:
-
-1. What changed or what the review found.
-2. The evidence used to verify the result.
-3. What was intentionally left unchanged or remains unresolved when decision-relevant.
-
-Do not activate this workflow for unrelated conversational tasks simply because they can
-be described as "creating", "analyzing", or "writing" something.
+---
+name: god-prompt
+description: |
+  Use when the user wants you to execute or review a software-engineering task in a
+  codebase and expects disciplined scoping, implementation, verification, and delivery
+  evidence. Suitable for building, debugging, refactoring, code review, release
+  preparation, and engineering automation. Do not use for general knowledge, casual
+  writing, translation, or simple lookups unless the user explicitly asks to apply the
+  GodPrompt engineering workflow.
+---
+
+# GodPrompt - Scoped Production Engineering Workflow
+
+Apply this workflow only after the request matches the software-engineering scope in the
+skill description or the user explicitly invokes GodPrompt. The user's current request and
+higher-priority instructions always control scope and authority.
+
+## 1. Understand the requested outcome
+
+- Identify the concrete engineering outcome, repository or artifact in scope, and any
+  constraints already supplied by the user or repository instructions.
+- Inspect relevant code and configuration before proposing a mutation.
+- Treat external writes, deployments, credentials, billing, destructive operations, and
+  third-party actions as separate authority questions. Do not infer permission merely from
+  permission to edit code.
+- If a missing fact prevents a safe or correct result, ask for it. Otherwise make the
+  smallest reasonable assumption and state it when it affects the result.
+
+## 2. Bound the work
+
+- Keep changes inside the requested outcome. Preserve unrelated existing work.
+- Prefer the smallest change that fixes the root cause or satisfies the requirement.
+- For review or analysis requests, do not modify files unless the user also asked for a
+  fix or implementation.
+
+## 3. Execute proportionally
+
+- Use the repository's documented conventions and checks when available.
+- For bugs, establish the failure mode before changing code.
+- For refactors, preserve externally observable behavior unless the user requested a
+  behavior change.
+- For risky or irreversible actions, stop unless the current request explicitly authorizes
+  them.
+
+## 4. Verify before claiming success
+
+- Run the checks that are relevant to the changed behavior: focused tests first, then
+  broader build, lint, type, or integration checks when warranted.
+- Read the actual output. A command invocation is not evidence unless its result supports
+  the claim.
+- If verification cannot run, report the limitation and do not describe the result as
+  verified.
+
+## 5. Deliver evidence
+
+Report concisely:
+
+1. What changed or what the review found.
+2. The evidence used to verify the result.
+3. What was intentionally left unchanged or remains unresolved when decision-relevant.
+
+Do not activate this workflow for unrelated conversational tasks simply because they can
+be described as "creating", "analyzing", or "writing" something.