@oriro/orirocli 0.1.8 → 0.1.11

package/skills/craft/gpt-5-4-prompting/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 ORIRO.ai
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 ORIRO.ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/craft/gpt-5-4-prompting/SKILL.md

@@ -1,63 +1,63 @@
----
-watermark: ORIRO
-name: gpt-5-4-prompting
-provider: ORIRO.ai
-copyright: Copyright (c) 2026 ORIRO.ai
-description: Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin
-user-invocable: false
----
-
-# GPT-5.4 Prompting
-
-Use this skill when `codex:codex-rescue` needs to ask Codex or another GPT-5.4-based workflow for help.
-
-Prompt Codex like an operator, not a collaborator. Keep prompts compact and block-structured with XML tags. State the task, the output contract, the follow-through defaults, and the small set of extra constraints that matter.
-
-Core rules:
-
-- Prefer one clear task per Codex run. Split unrelated asks into separate runs.
-- Tell Codex what done looks like. Do not assume it will infer the desired end state.
-- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.
-- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.
-- Use XML tags consistently so the prompt has stable internal structure.
-
-Default prompt recipe:
-
-- `<task>`: the concrete job and the relevant repository or failure context.
-- `<structured_output_contract>` or `<compact_output_contract>`: exact shape, ordering, and brevity requirements.
-- `<default_follow_through_policy>`: what Codex should do by default instead of asking routine questions.
-- `<verification_loop>` or `<completeness_contract>`: required for debugging, implementation, or risky fixes.
-- `<grounding_rules>` or `<citation_rules>`: required for review, research, or anything that could drift into unsupported claims.
-
-When to add blocks:
-
-- Coding or debugging: add `completeness_contract`, `verification_loop`, and `missing_context_gating`.
-- Review or adversarial review: add `grounding_rules`, `structured_output_contract`, and `dig_deeper_nudge`.
-- Research or recommendation tasks: add `research_mode` and `citation_rules`.
-- Write-capable tasks: add `action_safety` so Codex stays narrow and avoids unrelated refactors.
-
-How to choose prompt shape:
-
-- Use built-in `review` or `adversarial-review` commands when the job is reviewing local git changes. Those prompts already carry the review contract.
-- Use `task` when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.
-- Use `task --resume-last` for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.
-
-Working rules:
-
-- Prefer explicit prompt contracts over vague nudges.
-- Use stable XML tag names that match the block names from the reference file.
-- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.
-- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.
-- Keep claims anchored to observed evidence. If something is a hypothesis, say so.
-
-Prompt assembly checklist:
-
-1. Define the exact task and scope in `<task>`.
-2. Choose the smallest output contract that still makes the answer easy to use.
-3. Decide whether Codex should keep going by default or stop for missing high-risk details.
-4. Add verification, grounding, and safety tags only where the task needs them.
-5. Remove redundant instructions before sending the prompt.
-
-Reusable blocks live in [references/prompt-blocks.md](references/prompt-blocks.md).
-Concrete end-to-end templates live in [references/codex-prompt-recipes.md](references/codex-prompt-recipes.md).
-Common failure modes to avoid live in [references/codex-prompt-antipatterns.md](references/codex-prompt-antipatterns.md).
+---
+watermark: ORIRO
+name: gpt-5-4-prompting
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin
+user-invocable: false
+---
+
+# GPT-5.4 Prompting
+
+Use this skill when `codex:codex-rescue` needs to ask Codex or another GPT-5.4-based workflow for help.
+
+Prompt Codex like an operator, not a collaborator. Keep prompts compact and block-structured with XML tags. State the task, the output contract, the follow-through defaults, and the small set of extra constraints that matter.
+
+Core rules:
+
+- Prefer one clear task per Codex run. Split unrelated asks into separate runs.
+- Tell Codex what done looks like. Do not assume it will infer the desired end state.
+- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.
+- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.
+- Use XML tags consistently so the prompt has stable internal structure.
+
+Default prompt recipe:
+
+- `<task>`: the concrete job and the relevant repository or failure context.
+- `<structured_output_contract>` or `<compact_output_contract>`: exact shape, ordering, and brevity requirements.
+- `<default_follow_through_policy>`: what Codex should do by default instead of asking routine questions.
+- `<verification_loop>` or `<completeness_contract>`: required for debugging, implementation, or risky fixes.
+- `<grounding_rules>` or `<citation_rules>`: required for review, research, or anything that could drift into unsupported claims.
+
+When to add blocks:
+
+- Coding or debugging: add `completeness_contract`, `verification_loop`, and `missing_context_gating`.
+- Review or adversarial review: add `grounding_rules`, `structured_output_contract`, and `dig_deeper_nudge`.
+- Research or recommendation tasks: add `research_mode` and `citation_rules`.
+- Write-capable tasks: add `action_safety` so Codex stays narrow and avoids unrelated refactors.
+
+How to choose prompt shape:
+
+- Use built-in `review` or `adversarial-review` commands when the job is reviewing local git changes. Those prompts already carry the review contract.
+- Use `task` when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.
+- Use `task --resume-last` for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.
+
+Working rules:
+
+- Prefer explicit prompt contracts over vague nudges.
+- Use stable XML tag names that match the block names from the reference file.
+- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.
+- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.
+- Keep claims anchored to observed evidence. If something is a hypothesis, say so.
+
+Prompt assembly checklist:
+
+1. Define the exact task and scope in `<task>`.
+2. Choose the smallest output contract that still makes the answer easy to use.
+3. Decide whether Codex should keep going by default or stop for missing high-risk details.
+4. Add verification, grounding, and safety tags only where the task needs them.
+5. Remove redundant instructions before sending the prompt.
+
+Reusable blocks live in [references/prompt-blocks.md](references/prompt-blocks.md).
+Concrete end-to-end templates live in [references/codex-prompt-recipes.md](references/codex-prompt-recipes.md).
+Common failure modes to avoid live in [references/codex-prompt-antipatterns.md](references/codex-prompt-antipatterns.md).

package/skills/craft/gpt-5-4-prompting/references/codex-prompt-antipatterns.md

@@ -1,101 +1,101 @@
-# Codex Prompt Anti-Patterns
-
-Avoid these when prompting Codex or GPT-5.4.
-
-## Vague task framing
-
-Bad:
-
-```text
-Take a look at this and let me know what you think.
-```
-
-Better:
-
-```xml
-<task>
-Review this change for material correctness and regression risks.
-</task>
-```
-
-## Missing output contract
-
-Bad:
-
-```text
-Investigate and report back.
-```
-
-Better:
-
-```xml
-<structured_output_contract>
-Return:
-1. root cause
-2. evidence
-3. smallest safe next step
-</structured_output_contract>
-```
-
-## No follow-through default
-
-Bad:
-
-```text
-Debug this failure.
-```
-
-Better:
-
-```xml
-<default_follow_through_policy>
-Keep going until you have enough evidence to identify the root cause confidently.
-</default_follow_through_policy>
-```
-
-## Asking for more reasoning instead of a better contract
-
-Bad:
-
-```text
-Think harder and be very smart.
-```
-
-Better:
-
-```xml
-<verification_loop>
-Before finalizing, verify that the answer matches the observed evidence and task requirements.
-</verification_loop>
-```
-
-## Mixing unrelated jobs into one run
-
-Bad:
-
-```text
-Review this diff, fix the bug you find, update the docs, and suggest a roadmap.
-```
-
-Better:
-
-- Run review first.
-- Run a separate fix prompt if needed.
-- Use a third run for docs or roadmap work.
-
-## Unsupported certainty
-
-Bad:
-
-```text
-Tell me exactly why production failed.
-```
-
-Better:
-
-```xml
-<grounding_rules>
-Ground every claim in the provided context or tool outputs.
-If a point is an inference, label it clearly.
-</grounding_rules>
-```
+# Codex Prompt Anti-Patterns
+
+Avoid these when prompting Codex or GPT-5.4.
+
+## Vague task framing
+
+Bad:
+
+```text
+Take a look at this and let me know what you think.
+```
+
+Better:
+
+```xml
+<task>
+Review this change for material correctness and regression risks.
+</task>
+```
+
+## Missing output contract
+
+Bad:
+
+```text
+Investigate and report back.
+```
+
+Better:
+
+```xml
+<structured_output_contract>
+Return:
+1. root cause
+2. evidence
+3. smallest safe next step
+</structured_output_contract>
+```
+
+## No follow-through default
+
+Bad:
+
+```text
+Debug this failure.
+```
+
+Better:
+
+```xml
+<default_follow_through_policy>
+Keep going until you have enough evidence to identify the root cause confidently.
+</default_follow_through_policy>
+```
+
+## Asking for more reasoning instead of a better contract
+
+Bad:
+
+```text
+Think harder and be very smart.
+```
+
+Better:
+
+```xml
+<verification_loop>
+Before finalizing, verify that the answer matches the observed evidence and task requirements.
+</verification_loop>
+```
+
+## Mixing unrelated jobs into one run
+
+Bad:
+
+```text
+Review this diff, fix the bug you find, update the docs, and suggest a roadmap.
+```
+
+Better:
+
+- Run review first.
+- Run a separate fix prompt if needed.
+- Use a third run for docs or roadmap work.
+
+## Unsupported certainty
+
+Bad:
+
+```text
+Tell me exactly why production failed.
+```
+
+Better:
+
+```xml
+<grounding_rules>
+Ground every claim in the provided context or tool outputs.
+If a point is an inference, label it clearly.
+</grounding_rules>
+```

package/skills/craft/gpt-5-4-prompting/references/codex-prompt-recipes.md

@@ -1,150 +1,150 @@
-# Codex Prompt Recipes
-
-Use these as starting templates for Codex task prompts or other Codex/GPT-5.4 prompt construction.
-Copy the smallest recipe that fits the task, then trim anything you do not need.
-In `codex:codex-rescue`, run diagnosis and fix-oriented recipes in write mode by default unless the user explicitly asked for read-only behavior.
-
-## Diagnosis
-
-```xml
-<task>
-Diagnose why the failing test or command is breaking in this repository.
-Use the available repository context and tools to identify the most likely root cause.
-</task>
-
-<compact_output_contract>
-Return a compact diagnosis with:
-1. most likely root cause
-2. evidence
-3. smallest safe next step
-</compact_output_contract>
-
-<default_follow_through_policy>
-Keep going until you have enough evidence to identify the root cause confidently.
-Only stop to ask questions when a missing detail changes correctness materially.
-</default_follow_through_policy>
-
-<verification_loop>
-Before finalizing, verify that the proposed root cause matches the observed evidence.
-</verification_loop>
-
-<missing_context_gating>
-Do not guess missing repository facts.
-If required context is absent, state exactly what remains unknown.
-</missing_context_gating>
-```
-
-## Narrow Fix
-
-```xml
-<task>
-Implement the smallest safe fix for the identified issue in this repository.
-Preserve existing behavior outside the failing path.
-</task>
-
-<structured_output_contract>
-Return:
-1. summary of the fix
-2. touched files
-3. verification performed
-4. residual risks or follow-ups
-</structured_output_contract>
-
-<default_follow_through_policy>
-Default to the most reasonable low-risk interpretation and keep going.
-</default_follow_through_policy>
-
-<completeness_contract>
-Resolve the task fully before stopping.
-Do not stop after identifying the issue without applying the fix.
-</completeness_contract>
-
-<verification_loop>
-Before finalizing, verify that the fix matches the task requirements and that the changed code is coherent.
-</verification_loop>
-
-<action_safety>
-Keep changes tightly scoped to the stated task.
-Avoid unrelated refactors or cleanup.
-</action_safety>
-```
-
-## Root-Cause Review
-
-```xml
-<task>
-Analyze this change for the most likely correctness or regression issues.
-Focus on the provided repository context only.
-</task>
-
-<structured_output_contract>
-Return:
-1. findings ordered by severity
-2. supporting evidence for each finding
-3. brief next steps
-</structured_output_contract>
-
-<grounding_rules>
-Ground every claim in the repository context or tool outputs.
-If a point is an inference, label it clearly.
-</grounding_rules>
-
-<dig_deeper_nudge>
-Check for second-order failures, empty-state handling, retries, stale state, and rollback paths before finalizing.
-</dig_deeper_nudge>
-
-<verification_loop>
-Before finalizing, verify that each finding is material and actionable.
-</verification_loop>
-```
-
-## Research Or Recommendation
-
-```xml
-<task>
-Research the available options and recommend the best path for this task.
-</task>
-
-<structured_output_contract>
-Return:
-1. observed facts
-2. reasoned recommendation
-3. tradeoffs
-4. open questions
-</structured_output_contract>
-
-<research_mode>
-Separate observed facts, reasoned inferences, and open questions.
-Prefer breadth first, then go deeper only where the evidence changes the recommendation.
-</research_mode>
-
-<citation_rules>
-Back important claims with explicit references to the sources you inspected.
-Prefer primary sources.
-</citation_rules>
-```
-
-## Prompt-Patching
-
-```xml
-<task>
-Diagnose why this existing prompt is underperforming and propose the smallest high-leverage changes to improve it for Codex or GPT-5.4.
-</task>
-
-<structured_output_contract>
-Return:
-1. failure modes
-2. root causes in the current prompt
-3. a revised prompt
-4. why the revision should work better
-</structured_output_contract>
-
-<grounding_rules>
-Base your diagnosis on the prompt text and the failure examples provided.
-Do not invent failure modes that are not supported by the examples.
-</grounding_rules>
-
-<verification_loop>
-Before finalizing, make sure the revised prompt resolves the cited failure modes without adding contradictory instructions.
-</verification_loop>
-```
+# Codex Prompt Recipes
+
+Use these as starting templates for Codex task prompts or other Codex/GPT-5.4 prompt construction.
+Copy the smallest recipe that fits the task, then trim anything you do not need.
+In `codex:codex-rescue`, run diagnosis and fix-oriented recipes in write mode by default unless the user explicitly asked for read-only behavior.
+
+## Diagnosis
+
+```xml
+<task>
+Diagnose why the failing test or command is breaking in this repository.
+Use the available repository context and tools to identify the most likely root cause.
+</task>
+
+<compact_output_contract>
+Return a compact diagnosis with:
+1. most likely root cause
+2. evidence
+3. smallest safe next step
+</compact_output_contract>
+
+<default_follow_through_policy>
+Keep going until you have enough evidence to identify the root cause confidently.
+Only stop to ask questions when a missing detail changes correctness materially.
+</default_follow_through_policy>
+
+<verification_loop>
+Before finalizing, verify that the proposed root cause matches the observed evidence.
+</verification_loop>
+
+<missing_context_gating>
+Do not guess missing repository facts.
+If required context is absent, state exactly what remains unknown.
+</missing_context_gating>
+```
+
+## Narrow Fix
+
+```xml
+<task>
+Implement the smallest safe fix for the identified issue in this repository.
+Preserve existing behavior outside the failing path.
+</task>
+
+<structured_output_contract>
+Return:
+1. summary of the fix
+2. touched files
+3. verification performed
+4. residual risks or follow-ups
+</structured_output_contract>
+
+<default_follow_through_policy>
+Default to the most reasonable low-risk interpretation and keep going.
+</default_follow_through_policy>
+
+<completeness_contract>
+Resolve the task fully before stopping.
+Do not stop after identifying the issue without applying the fix.
+</completeness_contract>
+
+<verification_loop>
+Before finalizing, verify that the fix matches the task requirements and that the changed code is coherent.
+</verification_loop>
+
+<action_safety>
+Keep changes tightly scoped to the stated task.
+Avoid unrelated refactors or cleanup.
+</action_safety>
+```
+
+## Root-Cause Review
+
+```xml
+<task>
+Analyze this change for the most likely correctness or regression issues.
+Focus on the provided repository context only.
+</task>
+
+<structured_output_contract>
+Return:
+1. findings ordered by severity
+2. supporting evidence for each finding
+3. brief next steps
+</structured_output_contract>
+
+<grounding_rules>
+Ground every claim in the repository context or tool outputs.
+If a point is an inference, label it clearly.
+</grounding_rules>
+
+<dig_deeper_nudge>
+Check for second-order failures, empty-state handling, retries, stale state, and rollback paths before finalizing.
+</dig_deeper_nudge>
+
+<verification_loop>
+Before finalizing, verify that each finding is material and actionable.
+</verification_loop>
+```
+
+## Research Or Recommendation
+
+```xml
+<task>
+Research the available options and recommend the best path for this task.
+</task>
+
+<structured_output_contract>
+Return:
+1. observed facts
+2. reasoned recommendation
+3. tradeoffs
+4. open questions
+</structured_output_contract>
+
+<research_mode>
+Separate observed facts, reasoned inferences, and open questions.
+Prefer breadth first, then go deeper only where the evidence changes the recommendation.
+</research_mode>
+
+<citation_rules>
+Back important claims with explicit references to the sources you inspected.
+Prefer primary sources.
+</citation_rules>
+```
+
+## Prompt-Patching
+
+```xml
+<task>
+Diagnose why this existing prompt is underperforming and propose the smallest high-leverage changes to improve it for Codex or GPT-5.4.
+</task>
+
+<structured_output_contract>
+Return:
+1. failure modes
+2. root causes in the current prompt
+3. a revised prompt
+4. why the revision should work better
+</structured_output_contract>
+
+<grounding_rules>
+Base your diagnosis on the prompt text and the failure examples provided.
+Do not invent failure modes that are not supported by the examples.
+</grounding_rules>
+
+<verification_loop>
+Before finalizing, make sure the revised prompt resolves the cited failure modes without adding contradictory instructions.
+</verification_loop>
+```