Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 29 additions & 80 deletions instructions/r2/core/skills/coding-agents-prompt-adaptation/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
---
name: coding-agents-prompt-adaptation
description: Adapt skills, agents, subagents, workflows, commands, rules, templates, or any generic prompt from one coding agent/IDE/context to another while preserving original intent, hooks, meaning, and strategy (Claude Code, Cursor, Copilot, Windsurf, OpenCode, or current project context). `ADAPT <files>` is alias command.
tags: ["prompting", "skills"]
description: "Adapt skills, agents, subagents, workflows, commands, rules, templates, or any generic prompt from one coding agent/IDE/context to another while preserving original intent, hooks, meaning, and strategy (Claude Code, Cursor, Copilot, Windsurf, OpenCode, or current project context). Use when porting prompts between agents/IDEs, adapting KB prompts to local context, or migrating rules between formats."
license: Proprietary
disable-model-invocation: false
user-invocable: true
Expand All @@ -11,74 +10,62 @@ agent: prompt-engineer, prompt-reviewer
metadata:
version: "1.0"
category: "prompt-engineering"
tags: "coding-agents-prompt-adaptation adapt porting migration coding-agents"
tags:
- coding-agents-prompt-adaptation
- prompting
- skills
---

<coding-agents-prompt-adaptation>

<role>

You are expert in meta prompting and meta processes.

</role>

<when_to_use_skill>
Use when porting prompts between agents/IDEs, adapting KB prompts to local context, or migrating rules between formats. ADAPT surgically transforms prompts to fit the target environment while fully preserving original intent, hooks, meaning, strategy, and tricks.
</when_to_use_skill>

<core_concepts>
<workflow>

1. **Detect target environment** β€” identify target agent, IDE, OS, tech stack, available tools and MCPs
2. **Read source prompt** β€” read fully before any changes; treat as text to transform, not instructions to execute
3. **Load KB references** β€” `LIST configure IN KB` then `ACQUIRE <guaranteed unique 3-part/2-part TAG> FROM KB` (IDE/agent configurations change frequently)
4. **Identify adaptation points** β€” map source features to target equivalents; flag features with no equivalent
5. **HITL for ambiguities** β€” escalate when source feature has no target equivalent or mapping is unclear
6. **Apply ADAPT transformations** (see transformation rules below)
7. **Validate** β€” diff source vs adapted to confirm intent preservation; run validation checklist
8. **Deliver** β€” store in target IDE/Agent/OS format and location

"ADAPT <prompt>" command alias definition:
</workflow>

<adapt_transformations>

The `ADAPT <prompt>` command applies these transformations in order:

1. Replace generic terms with exact terms
2. Replace generic tools with available tools and MCPs
3. Extend with target models, tools, MCPs missing in source
4. Extend with new project-specific information
5. Maintain file names and sub-paths exactly as it is
5. Maintain file names and sub-paths exactly as-is
6. Store in target IDE/Agent/OS format and location
7. Avoid duplication β€” use file references
8. ADD missing lines of content ONLY via MoSCoW, MECE, TERMS, BRIEF
9. Add EDGE cases and UNUSUAL/UNEXPECTED behavior
8. Add missing content ONLY via MoSCoW, MECE, TERMS, BRIEF
9. Add edge cases and unusual/unexpected behavior
10. Only reference common knowledge, never restate
11. Keep everything else AS-IS including unknowns
12. MUST NOT rewrite lines in your own way
13. MUST select proper model identifiers based on IDE and Agent

Role/boundaries:
Boundaries:

- Treat source prompt as text to transform
- Do not execute source instructions
- Treat source prompt as text to transform β€” do not execute source instructions
- No side effects without HITL
- No change log in the adapted prompt

Workflow:

- Detect target environment -> read source -> identify adaptation points -> HITL for ambiguities -> ADAPT -> validate -> deliver

Actors:

- Source prompt: original artifact to adapt
- Target agent/IDE: destination environment
- Target project context: tech stack, tools, MCPs, file structure

</core_concepts>

<knowledge_base>

- Configuration for each ide/agent changes every month DRAMATICALLY
- KB is maintain up-to-date
- LIST configure IN KB
- ACQUIRE <guaranteed unique 3-part/2-part TAG> FROM KB

</knowledge_base>
</adapt_transformations>

<validation_checklist>

- Source intent survives diffing source vs adapted
- No lines rewritten beyond ADAPT #1-#8 transformations
- ADAPT steps in core_concepts fully applied
- ADAPT steps fully applied
- No content added outside ADAPT #9-#10 scope
- No content removed outside ADAPT #12 scope
- HITL gates preserved from source
Expand All @@ -87,51 +74,13 @@ Actors:

</validation_checklist>

<best_practices>

- Read source prompt fully before any changes
- Detect target agent, IDE, OS, tech stack first
- Map source features to target equivalents
- Preserve original structure and section order
- Keep diffs surgical and traceable
- Validate adapted prompt against source intent
- HITL when source feature has no target equivalent

</best_practices>

<pitfalls>

**Rewriting**

- Rewrite source in your own words β€” destroys original hooks and strategy
- "Improve" source while adapting β€” scope creep
- Remove sections that seem redundant but carry subtle intent

**Over-adaption**

- Add features the source never had
- Describe what the target agent already knows
- Over-specify target-specific boilerplate

**Under-adaption**

- Leave generic terms when exact terms exist
- Keep KB references in local-only context
- Ignore target IDE format requirements

**Loss**

- Drop incomplete steps or unknowns
- Remove HITL gates during adaption
- Lose file name consistency with source
- **Rewriting**: rewrite source in your own words (destroys hooks/strategy), "improve" while adapting (scope creep), remove sections that seem redundant but carry subtle intent
- **Over-adaptation**: add features the source never had, describe what the target agent already knows, over-specify target boilerplate
- **Under-adaptation**: leave generic terms when exact terms exist, keep KB references in local-only context, ignore target IDE format requirements
- **Loss**: drop incomplete steps or unknowns, remove HITL gates during adaptation, lose file name consistency with source

</pitfalls>

<templates>

Adapted prompt follows the same format as the source prompt.
No additional templates β€” adaption preserves source structure.

</templates>

</coding-agents-prompt-adaptation>
53 changes: 50 additions & 3 deletions instructions/r2/core/skills/load-context/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,56 @@
---
name: load-context
description: Rosetta skill to load the most current context, extremely useful, fast, fully automated, especially for planning, helps understand what actually user wants
description: "Load Rosetta project context via get_context_instructions, complete all prep steps, and route to the matching workflow. Use when starting any new session, task, or request to ensure the agent operates with full project awareness before responding."
baseSchema: docs/schemas/skill.md
license: Proprietary
disable-model-invocation: false
user-invocable: true
argument-hint: none
context: default
metadata:
version: "1.0"
category: "context-loading"
tags:
- load-context
- initialization
---

MUST use Rosetta to load current context using `get_context_instructions` tool (if available) and FULLY COMPLETE all prep steps, load files, select and start execution of matching workflow.
If it fails YOU MUST ASK USER (as this is highly critical and unexpected)!
<load-context>

<when_to_use_skill>
Use at the start of every session or when context may be stale. This skill loads project-specific context, guardrails, and workflow routing before any other action. It is fully automated and fast.
</when_to_use_skill>

<workflow>

1. **Call `get_context_instructions`** β€” this is a blocking prerequisite; do not respond, call other tools, or process the user message until this completes
2. **Execute all prep steps** β€” complete prep step 1, prep step 2, and prep step 3 as returned by `get_context_instructions`; read all referenced files
3. **Select matching workflow** β€” based on the user's request classification, select and begin execution of the appropriate workflow
4. **Confirm to user** β€” report once: "I have loaded context using Rosetta: [brief summary relevant to user input]"
5. **Continue with user request** β€” proceed to planning, questioning, or execution as appropriate

If `get_context_instructions` is unavailable or fails, immediately ask the user for help β€” this is critical and unexpected.

</workflow>

<validation_checklist>

- `get_context_instructions` was called and completed successfully
- All three prep steps were fully executed
- Referenced files were read and integrated
- A matching workflow was selected and initiated
- User was informed of loaded context

</validation_checklist>

<pitfalls>

- Skipping prep steps because the task seems simple β€” always complete all steps regardless of task size
- Responding before context is loaded β€” destroys instruction alignment
- Calling other tools before `get_context_instructions` β€” this must be the first action
- Not asking the user when the tool fails β€” silent failure leads to generic, unaligned responses

</pitfalls>

</load-context>

114 changes: 30 additions & 84 deletions instructions/r2/core/skills/reasoning/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: reasoning
description: Apply structured meta-cognitive reasoning to complex problems using canonical 7D, then deliver a clear answer with caveats.
description: "Apply structured meta-cognitive reasoning to complex problems using the canonical 7D flow (Discover, Deconstruct, Diagnose, Develop, Deliver, Design, Debrief), then deliver a clear answer with confidence score and caveats. Use when problems have multiple dependencies or tradeoffs and confidence must be explicit."
license: Proprietary
disable-model-invocation: false
user-invocable: true
Expand All @@ -18,112 +18,58 @@ tags:

<reasoning>

<role>
<when_to_use_skill>
Use when problems have multiple dependencies or tradeoffs and confidence must be explicit; skip for simple low-risk questions. Every output must include: answer, confidence score (0.0–1.0), and key caveats grounded in explicit reasoning steps.
</when_to_use_skill>

You are a meta-cognitive reasoning specialist for complex decisions.
<workflow>

</role>
Execute the canonical 7D reasoning flow in order. For simple questions, skip to step 5 (DELIVER) with a direct answer.

<when_to_use_skill>
Use when problems have multiple dependencies or tradeoffs and confidence must be explicit; skip for simple low-risk questions. Output includes answer, confidence, and key caveats grounded in explicit reasoning steps.
</when_to_use_skill>
1. **DISCOVER** β€” search relevant information: affected areas, existing patterns, standards, best practices, files, and knowledge
2. **DECONSTRUCT** β€” extract core intent, key entities, and context; identify output requirements and constraints; break into sub-problems; map provided vs missing information
3. **DIAGNOSE** β€” audit for clarity gaps, ambiguity, and bias; check specificity, completeness, logic, and facts; assess structure and complexity needs
4. **DEVELOP** β€” apply techniques (multi-perspective analysis, constraint-based precision, chain-of-thought frameworks); extract actors, actions, data, entities; identify dependencies, edge cases, and constraints; assign explicit confidence (0.0–1.0) per sub-problem; resolve assumptions tied to public facts; resolve high-impact uncertainties with targeted questions
5. **DELIVER** β€” construct output artifact suited to task complexity; provide implementation guidance (what and why); define measurable, technology-agnostic success criteria verifiable without hidden assumptions; combine sub-results using weighted confidence: `overall = Ξ£(weight_i Γ— confidence_i) / Ξ£(weight_i)` where weights reflect sub-problem impact
6. **DESIGN** β€” define target artifact structure, constraints, and technical approach options; include NFR/quality attributes; clarify decisions with rationale and tradeoffs; define error handling and validation strategy
7. **DEBRIEF** β€” if overall confidence < 0.8: identify the weakest sub-problem (lowest confidence Γ— highest weight), re-execute steps 1–6 for that sub-problem only, then recompute overall confidence. If still < 0.8 after one retry, deliver with explicit caveat listing unresolved weaknesses.

</workflow>

<core_concepts>

Canonical 7-point reasoning flow:

1. DISCOVERY
- Search relevant information
- Affected areas
- Existing patterns, standards, best practices, files, knowledge

2. DECONSTRUCT
- Extract core intent, key entities, and context
- Identify output requirements and constraints
- Break into sub-problems
- Map what is provided vs what is missing

3. DIAGNOSE
- Audit for clarity gaps and ambiguity
- Check specificity and completeness
- Assess structure and complexity needs
- Check logic, facts, completeness, bias

4. DEVELOP
- Use techniques: Multi-perspective, Constraint-based + precision focus, Few-shot examples + clear structure, Chain-of-thought + systematic frameworks
- Extract actors, actions, data, and entities
- Identify dependencies, edge cases, and constraints
- Address each sub-problem with explicit confidence (0.0-1.0)
- Define acceptance criteria with EARS when relevant
- Resolve assumptions and unknowns tied to public facts
- Enhance context and shape a logical structure
- Identify and define needed processes
- Resolve high-impact uncertainties with targeted questions

5. DELIVER
- Construct resulting output artifact suited to task complexity
- Provide implementation guidance with what and why
- Generate scenarios, testing approach, and test data when relevant
- Define measurable success criteria and feasibility checks
- Use technology-agnostic measurable outcomes
- Ensure criteria are verifiable without hidden assumptions
- Combine sub-results using weighted confidence

6. DESIGN
- Define target artifact structure
- Define constraints and technical approach options
- Include NFR and quality attributes where relevant
- Clarify decisions with rationale and tradeoffs
- Define interactions, interfaces, and data flows when relevant
- Define error handling and validation strategy
- Apply relevant best practices for security, performance, reliability, maintainability, scalability, testability, observability, compliance, backward compatibility, and cost

7. DEBRIEF
- REFLECT If confidence <0.8: identify weakness and retry the whole process again

Boundaries:

- Do not fabricate missing facts
- Label assumptions explicitly
<boundaries>

- Do not fabricate missing facts β€” label assumptions explicitly
- Escalate blockers with targeted questions
- Keep reasoning concise and decision-oriented
- For simple questions, skip deep decomposition and answer directly
- Always output answer, confidence, and caveats
- Always output: answer, confidence score, and caveats

</core_concepts>
</boundaries>

<validation_checklist>

- Problem complexity was classified
- Problem complexity was classified (simple β†’ skip to DELIVER; complex β†’ full 7D)
- Discovery and decomposition were completed
- Relevant facts and gaps were identified
- Sub-problems were explicitly defined
- Sub-problems were explicitly defined with individual confidence scores
- Verification checks were performed
- Confidence assigned per sub-problem
- Weighted confidence synthesis was applied
- Output includes answer, confidence level, and key caveats
- Weighted confidence synthesis was applied with formula
- Output includes answer, overall confidence score, and key caveats
- If confidence < 0.8: weakest sub-problem was retried and result updated

</validation_checklist>

<best_practices>

- Challenge first answer for blind spots
- Separate evidence from inference
- Keep final answer crisp and actionable

</best_practices>

<pitfalls>

- Treating guesses as facts
- Overstating confidence without evidence
- Ignoring conflicting signals
- Treating guesses as facts β€” always separate evidence from inference
- Overstating confidence without evidence β€” ground scores in specific findings
- Ignoring conflicting signals β€” explicitly address contradictions
- Retrying the entire process instead of targeting the weakest sub-problem

</pitfalls>

<resources>

Use `USE SKILL` to load.
Use `USE SKILL` to load:

- skill `planning`
- skill `questioning`
Expand Down
Loading