first-fluke · github-actions · Jul 27, 2026
@@ -26,17 +26,7 @@ Do NOT activate for:
 
 ### Step 1: Hypothesize
 
-Generate 2-3 alternative approaches using the **Exploration Decision** reasoning template (see `reasoning-templates.md` #6):
-
-```
-=== Exploration Decision ===
-Problem: {what needs to be solved}
-Current Score: {quality score}
-Attempts So Far: {count and outcomes}
-
-Hypothesis A: ...
-Hypothesis B: ...
-```
+Generate 2-3 alternative approaches that differ in mechanism, not just in wording — if two hypotheses would touch the same code the same way, they are one hypothesis. For each, state the approach, which score dimensions it is expected to move, and the files it would touch. Keep the scope of each experiment to at most 3 files so failures stay attributable.
 
 ### Step 2: Experiment
 
@@ -160,6 +150,5 @@ Same CRITICAL/HIGH issue persists after fix attempt
 | **Quality Score** | Provides measurement for hypothesis comparison |
 | **Experiment Ledger** | Records all hypotheses (kept and discarded) |
 | **Phase Gates** | Repeated gate failure triggers exploration |
-| **Reasoning Templates** | #6 Exploration Decision provides structured format |
 | **Context Loading** | Loaded conditionally, only when triggered |
 | **Memory Protocol** | Uses same memory tools for experiment recording |
@@ -1,6 +1,6 @@
 {
-  "version": "11.0.3",
+  "version": "11.1.1",
   "schemaVersion": 2,
   "mode": "project",
-  "installedAt": "2026-07-25T10:21:16.867Z"
+  "installedAt": "2026-07-27T12:13:46.129Z"
 }
@@ -164,21 +164,18 @@ Then choose Diagnostic, Recommendation, Design-Twice, ATAM-style, CBAM-style, or
 
 ## References
 Follow `resources/execution-protocol.md` step by step.
-See `resources/examples.md` for output examples.
 Use `resources/methodology-selection.md` to select the right method.
 Use `resources/stakeholder-synthesis.md` when stakeholder consultation is needed.
 Use `resources/output-templates.md` to format the final artifact.
 Before submitting, run `resources/checklist.md`.
 - Execution steps: `resources/execution-protocol.md`
 - Checklist: `resources/checklist.md`
-- Examples: `resources/examples.md`
 - Method selection: `resources/methodology-selection.md`
 - Stakeholder protocol: `resources/stakeholder-synthesis.md`
 - Output templates: `resources/output-templates.md`
 - API evolution patterns (versioning, deprecation, lifecycle guarantees): `resources/api-evolution.md`
 - Migration/transition patterns (strangler fig, branch by abstraction, expand-contract): `resources/migration-patterns.md`
 - Context loading: `../_shared/core/context-loading.md`
 - Difficulty guide: `../_shared/core/difficulty-guide.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification protocol: `../_shared/core/clarification-protocol.md`
 - Quality principles: `../_shared/core/quality-principles.md`
@@ -188,18 +188,15 @@ Router (HTTP) → Service (Business Logic) → Repository (Data Access) → Mode
 ## References
 
 Follow `resources/execution-protocol.md` step by step.
-See `resources/examples.md` for input/output examples.
 Use `resources/orm-reference.md` when the task involves ORM query performance, relationship loading, transactions, session/client lifecycle, or N+1 analysis.
 Before submitting, run `resources/checklist.md`.
 Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.
 Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - Execution steps: `resources/execution-protocol.md`
-- Code examples: `resources/examples.md`
 - Checklist: `resources/checklist.md`
 - ORM reference: `resources/orm-reference.md`
 - Error recovery: `resources/error-playbook.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification: `../_shared/core/clarification-protocol.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Lessons learned: `../_shared/core/lessons-learned.md`

@@ -162,7 +162,6 @@ Vendor-specific execution protocols are injected automatically by `oma agent:spa
 Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - TRIZ-lite (optional Step 3 seeding): `resources/triz-lite.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification protocol: `../_shared/core/clarification-protocol.md`
 - Quality principles: `../_shared/core/quality-principles.md`
 - Skill-to-agent mapping: `../_shared/core/skill-routing.md`
@@ -38,7 +38,6 @@ Guide manual multi-agent coordination for complex work that spans PM, frontend,
 
 ### Dependencies
 - PM, frontend, backend, mobile, QA, and orchestrator skills
-- `resources/examples.md`
 - CLI `oma agent:spawn` and progress/result memory conventions
 
 ### Control-flow features
@@ -166,4 +165,3 @@ For fully automated execution without manual spawning, use the **orchestrator**
 
 ## References
 
-- Workflow examples: `resources/examples.md`
@@ -193,7 +193,6 @@ Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - ISO control guide: `resources/iso-controls.md`
 - Error recovery: `resources/error-playbook.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification: `../_shared/core/clarification-protocol.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Lessons learned: `../_shared/core/lessons-learned.md`

@@ -133,19 +133,16 @@ Then run the smallest reproduction command first, add a regression test, and re-
 
 ## References
 Follow `resources/execution-protocol.md` step by step.
-See `resources/examples.md` for input/output examples.
 Before submitting, run `resources/checklist.md`.
 Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.
 Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - Execution steps: `resources/execution-protocol.md`
-- Code examples: `resources/examples.md`
 - Checklist (pre-submit self-verification): `resources/checklist.md`
 - Error recovery: `resources/error-playbook.md`
 - Bug report template: `resources/bug-report-template.md`
 - Common patterns: `resources/common-patterns.md`
 - Debugging checklist (investigation guide, used during Steps 1-2): `resources/debugging-checklist.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Lessons learned: `../_shared/core/lessons-learned.md`
 - Observability handoff: `../oma-observability/SKILL.md` §Integrations — traces/logs by `trace_id`, 6-dim forensics
@@ -8,8 +8,7 @@
 3. **Clarify requirements**: follow `../../_shared/core/clarification-protocol.md`
    - Check **Uncertainty Triggers**: security/auth related bugs, existing code conflict potential?
    - Determine level: LOW → proceed | MEDIUM → present options | HIGH → ask immediately
-4. **Use reasoning templates**: for Complex bugs, use `../../_shared/core/reasoning-templates.md` (hypothesis loop, execution trace)
-5. **Budget context**: follow `../../_shared/core/context-budget.md` (use find_symbol, not read_file)
+4. **Budget context**: follow `../../_shared/core/context-budget.md` (use find_symbol, not read_file)
 
 **Intelligent Escalation**: When uncertain, escalate early. Don't blindly proceed.
 

@@ -211,7 +211,6 @@ Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - Checklist: `resources/checklist.md`
 - Error recovery: `resources/error-playbook.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification: `../_shared/core/clarification-protocol.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Lessons learned: `../_shared/core/lessons-learned.md`

@@ -134,12 +134,10 @@ Then run the project's mobile verification commands, typically unit/widget tests
 
 ## References
 Follow `resources/execution-protocol.md` step by step.
-See `resources/examples.md` for input/output examples.
 Before submitting, run `resources/checklist.md`.
 Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.
 Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - Execution steps: `resources/execution-protocol.md`
-- Code examples: `resources/examples.md`
 - Code snippets (Swift): `variants/swift-ios/snippets.md`
 - Code snippets (Flutter): `variants/flutter/snippets.md`
 - Code snippets (React Native): `variants/react-native/snippets.md`
@@ -157,7 +155,6 @@ Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - API service template (React Native): `variants/react-native/api-template.ts`
 - Variant registry: `variants/README.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification: `../_shared/core/clarification-protocol.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Lessons learned: `../_shared/core/lessons-learned.md`

@@ -29,7 +29,7 @@ Each `variants/{platform}/` directory contains:
 ## resources/ is shared meta only
 
 The sibling `resources/` directory holds **only** cross-platform, protocol, and
-meta documents shared by every variant: `execution-protocol.md`, `examples.md`,
+meta documents shared by every variant: `execution-protocol.md`,
 `checklist.md`, `error-playbook.md`, `tech-stack.md` (the variant index +
 cross-platform guidance), and the screen templates. Platform-specific stack
 narrative and snippets belong in the variant, not in `resources/`.

@@ -319,7 +319,6 @@ At session end, if CD >= 50:
 - API contract template (SSOT): `../_shared/core/api-contracts/template.md`; read generated contracts from `.agents/results/api-contracts/` (run artifact) or `docs/plans/contracts/` (durable spec)
 - Context loading: `../_shared/core/context-loading.md`
 - Difficulty guide: `../_shared/core/difficulty-guide.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification protocol: `../_shared/core/clarification-protocol.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Lessons learned: `../_shared/core/lessons-learned.md`
@@ -6,9 +6,8 @@
 2. **Clarify requirements**: follow `../../_shared/core/clarification-protocol.md` (critical for PM)
    - Check **Uncertainty Triggers**: business logic, security/auth, existing code conflicts?
    - Determine level: LOW → proceed | MEDIUM → present options | HIGH → ask immediately
-3. **Use reasoning templates**: for architecture decisions, use `../../_shared/core/reasoning-templates.md` (decision matrix)
-4. **Check lessons**: read cross-domain section in `../../_shared/core/lessons-learned.md`
-5. **If governance, risk, or formal planning matters**: read `resources/iso-planning.md`
+3. **Check lessons**: read cross-domain section in `../../_shared/core/lessons-learned.md`
+4. **If governance, risk, or formal planning matters**: read `resources/iso-planning.md`
 
 **Intelligent Escalation**: When uncertain, escalate early. Don't blindly proceed.
 

@@ -36,7 +36,7 @@ Review and verify software quality with priority on security, performance, acces
 - Verification summary and residual risks
 
 ### Dependencies
-- `resources/execution-protocol.md`, examples, ISO guide, checklist, and self-check
+- `resources/execution-protocol.md`, ISO guide, and checklist
 - Automated tools such as `npm audit`, `bandit`, `lighthouse`, linters, tests, and coverage tools when applicable
 
 ### Control-flow features
@@ -88,7 +88,7 @@ Review and verify software quality with priority on security, performance, acces
 
 ### Tools and instruments
 - Security, lint, coverage, performance, accessibility, and test tools
-- ISO quality guide, checklist, self-check, and examples
+- ISO quality guide and checklist
 
 ### Canonical command path
 ```bash
@@ -127,16 +127,12 @@ Run only the tools that match the detected stack and available target. Add proje
 
 ## References
 Follow `resources/execution-protocol.md` step by step.
-See `resources/examples.md` for input/output examples.
 Use `resources/iso-quality.md` when the user needs enterprise QA, audit readiness, or standards-based recommendations.
-Before submitting, run `resources/self-check.md`.
 Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.
 Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - Execution steps: `resources/execution-protocol.md`
-- Report examples: `resources/examples.md`
 - ISO quality guide: `resources/iso-quality.md`
 - QA checklist: `resources/checklist.md`
-- Self-check: `resources/self-check.md`
 - Error recovery: `resources/error-playbook.md`
 - Ultrawork VERIFY/SHIP phase protocol: `resources/verify-ship-protocol.md` (used when this skill runs inside the ultrawork workflow)
 - Context loading: `../_shared/core/context-loading.md`

@@ -169,9 +169,6 @@ Generate structured report with:
   - missing test design / traceability / exit criteria
 
 ## Step 4: Verify
-- Run `resources/self-check.md` to verify your own review quality
-- Ensure no false positives (each finding is real and reproducible)
-- Confirm remediation suggestions are correct and complete
 - Run `../../_shared/core/common-checklist.md` for general quality
 
 ## On Error

@@ -153,7 +153,9 @@ Create, revise, and validate OMA skills using the SSL-lite Markdown structure de
 7. Include resource scope and resource targets for filesystem, codebase, process, credentials, network, user data, or memory.
 8. Include effects and side effects, especially for commands, network calls, credentials, destructive actions, generated files, and long-running processes.
 9. Add one canonical path inline so an agent can execute or reason without loading every resource file.
-10. Put long variant-specific details in `resources/`, not in the main skill body.
+10. Put long variant-specific details in `resources/`, not in the main skill body. Keep the SKILL.md body under 500 lines; `oma skills lint` warns as `body-too-long` past that.
+10a. Write examples only when the output format is a contract someone parses — a CLI's result block, a schema, a LAW-validated document. Worked input/output pairs that merely show "what a good report looks like" narrow the model's exploration space to the example's shape, so state the requirement instead and let the model choose the form. Per-task shape belongs in the task, not the skill.
+10b. Do not add instructions to double-check, re-verify, or self-review before answering — current models already do this, and the instruction compounds into over-verification. Deterministic validators the skill can actually run (`oma verify`, a lint script, a schema check) are the exception and should stay: they are feedback loops, not re-reading.
 11. Do not create extra README, changelog, or installation docs inside a skill.
 12. Do not overwrite unrelated user edits.
 13. Enforce the three utility-predictive content dimensions — failure mechanism encoding, actionable specificity, high-risk action blacklist — per the Utility Content Checks in `resources/validation-checklist.md` (SkillLens, arXiv:2605.23899).

@@ -72,7 +72,9 @@ not — a well-written skill can still fail `oma skills eval`.
 ## Reference Checks
 
 - `References` points only to files that exist or are intentionally planned.
-- Long examples and provider-specific variants are in `resources/`, not duplicated inline.
+- Provider-specific variants are in `resources/`, not duplicated inline.
+- Any examples that remain document a parsed output contract, not a preferred report shape.
+- No instruction tells the agent to re-verify or self-review its own answer; only runnable validators.
 - Reference files are one hop from `SKILL.md`; avoid deep reference chains.
 
 ## Suggested Commands

@@ -200,7 +200,6 @@ Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
 - ISO controls: `resources/iso-42001-infra.md`
 - Error recovery: `resources/error-playbook.md`
 - Context loading: `../_shared/core/context-loading.md`
-- Reasoning templates: `../_shared/core/reasoning-templates.md`
 - Clarification: `../_shared/core/clarification-protocol.md`
 - Context budget: `../_shared/core/context-budget.md`
 - Difficulty assessment: `../_shared/core/difficulty-guide.md`

@@ -209,7 +209,7 @@ Rebuild from meaning **as the assigned persona**, following target language norm
 
 #### Stage 4: Verification Gate (blocking; do not emit output until every item is confirmed)
 
-This stage is mandatory. Skipping any item is a bug, not a shortcut. Before producing the final translation, run the mechanical checks first, then the rubric.
+Run the mechanical checks first, then the rubric.
 
 **A. Mechanical checks (run before rubric, must all pass):**
 
@@ -243,16 +243,6 @@ If any mechanical check fails, revise and re-run. Do not proceed to the rubric u
 14. Were all metaphors/idioms handled per the classify decision (interpret/substitute/retain)?
 15. Do figurative expressions read naturally in the target language, not as literal calques?
 
-**E. Pre-emit gate (must answer in writing before output):**
-
-Before emitting the translation, write 1–2 sentences answering each:
-
-1. **"Why is Stage 5 reflection ON or OFF for this content?"**: must cite the specific classification rule from the "When to run Stage 5–7" section. If the target qualifies for both ON and OFF lists (e.g., README table cell as both a short string AND documentation), default ON wins.
-2. **"Does my draft match the sibling patterns in the target context?"**: must reference at least one specific sibling and the matched (or unmatched) pattern dimension.
-3. **"Is any source-language structural artifact (em dash, colon-after-X, parentheses-after-noun) merely substituted rather than restructured?"**: must answer No, with evidence.
-
-If any answer is missing, hand-wavy, or "I think so" without evidence, run Stage 5 anyway before emitting.
-
 ### Translator's Notes Guidelines
 
 When adding explanatory notes for terms, cultural references, or concepts that target readers may struggle with:
@@ -271,10 +261,6 @@ When adding explanatory notes for terms, cultural references, or concepts that t
 - Don't annotate self-explanatory terms or widely recognized loanwords
 - If a comprehension challenge was identified in Stage 1, use the pre-planned explanation
 
-### Reflection Mode (default for non-trivial content)
-
-Reflection passes (Stage 5–7) are the default (not optional) for any content that is more than a short snippet. Skipping reflection on non-trivial content is the most common cause of translationese complaints.
-
 ### When to run Stage 5–7
 
 Default ON for:
@@ -299,9 +285,7 @@ Default OFF (Stage 4 verification only) for:
 | Skill description in registry | short noun phrase but commits to git-tracked source | ON: registry descriptions are documentation, not UI locale values |
 | Tooltip in i18n file | <10 words AND in `messages/` | OFF: UI string in locale file |
 
-Reflection cost is acceptable; post-merge revision cost is not.
-
-When in doubt, run reflection. The cost is roughly 1.5–2× tokens; the quality gain on body-text fragments and Europeanized patterns is large.
+When in doubt, run reflection: roughly 1.5–2× tokens, against a post-merge revision that costs more. Skipping it on non-trivial content is the most common source of translationese complaints.
 
 ### Extended workflow
 
@@ -431,11 +415,6 @@ Why:
 | Target language requires gendered forms | Follow source text intent; prefer gender-neutral forms when available in target language |
 | Tone shifts across a long document | Re-read end-to-end after translating; normalize register to the dominant tone |
 
-### How to Execute
-
-Follow the translation method (Stage 1-4) step by step.
-Before submitting, verify against `resources/translation-rubric.md` and `resources/anti-ai-patterns.md`.
-
 ### Execution Protocol (CLI Mode)
 
 Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.