Agent-Skills.md

Agent Skills: System Prompt Clinic

Interactive skill that diagnoses and transforms system prompts from rule-based to reasoning-based using Constitutional AI principles. Use when the user wants to improve, rewrite, or transform any system prompt, command, agent, or skill — e.g. "improve this prompt", "make this less rigid", "transform this rule-based command", "optimize this agent", or "this skill keeps breaking on edge cases".

UncategorizedID: iamladi/cautious-computing-machine--sdlc-plugin/system-prompt-clinic
1

Install this agent skill to your local

pnpm dlx add-skill https://github.com/iamladi/cautious-computing-machine--sdlc-plugin/tree/HEAD/skills/system-prompt-clinic

Skill Files

Browse the full folder contents for system-prompt-clinic.

Download Skill

Loading file tree…

skills/system-prompt-clinic/SKILL.md

Skill Metadata

Name
system-prompt-clinic
Description
Interactive skill that diagnoses and transforms system prompts from rule-based to reasoning-based using Constitutional AI principles. Use when the user wants to improve, rewrite, or transform any system prompt, command, agent, or skill — e.g. "improve this prompt", "make this less rigid", "transform this rule-based command", "optimize this agent", or "this skill keeps breaking on edge cases".

System Prompt Clinic

Priorities

Accuracy (diagnose correctly) > Actionability (transform usefully) > Brevity (don't bloat the prompt)

Transformation should improve robustness without adding ceremony. The transformed prompt should be MORE effective at handling edge cases, not just longer.

Goal

Transform rule-based system prompts into reasoning-based equivalents that:

  1. Trust the model's judgment while providing clear principles
  2. Handle edge cases through generalization, not enumeration
  3. Explain WHY behind constraints, enabling adaptation to novel situations
  4. Preserve necessary invariants (safety, format contracts, tool boundaries)

Input

User provides an existing system prompt via:

  • Direct paste in conversation
  • $ARGUMENTS placeholder
  • File path to read

Workflow

1. Intake

Accept the system prompt. If it's a file path, read it first. Confirm receipt with a brief summary of what you see (length, apparent structure).

2. Diagnose

Analyze the prompt section-by-section using the scoring rubric from references/transformation-patterns.md:

Scoring Dimensions (0-5 scale for each):

  • Constraint Style: "Never/Always/Must" without reasoning (0) → Principles with context (5)
  • Workflow Style: Rigid numbered steps (0) → Outcome-driven with adaptation (5)
  • Format Style: Fill-in-the-blank templates (0) → Judgment criteria (5)
  • Trust Level: Prescribes every detail (0) → Trusts judgment, provides principles (5)
  • Edge Case Handling: Fails silently on novel cases (0) → Principles that generalize (5)

Output for this step: Present a section-by-section diagnosis:

Section: [Name or first line]
Average Score: X.X / 5.0
Classification: Rule-based / Hybrid / Reasoning-based
Key Issues: [What makes it brittle or rigid]

Focus on sections averaging < 3.0 that need transformation. Note sections averaging > 4.0 that are already reasoning-based.

3. Transform

For each section that needs transformation, apply patterns from references/transformation-patterns.md:

  1. Identify the pattern: Which transformation pattern applies? (Bare rules → Rules with reasoning, Procedures → Outcome-driven, Templates → Judgment criteria, etc.)
  2. Apply the transformation: Rewrite using the pattern
  3. Explain WHY: What edge cases does the transformed version handle better?
  4. Check for bloat: Is the new version meaningfully better, or just longer? If it's just longer, tighten it.

Critical constraints:

  • DO NOT transform safety constraints, format contracts, or tool boundaries
  • DO NOT add philosophical bloat—reasoning should be concise
  • DO preserve any machine-readable format requirements
  • DO explain the transformation's benefit for each section

Output for this step: Present side-by-side before/after for each transformed section:

### Section: [Name]

**Before** (Rule-based):
[Original text]

**After** (Reasoning-based):
[Transformed text]

**Why this improves robustness**:
[Specific edge cases now handled, principle now enabled]

4. Test

Generate 2-3 edge-case scenarios that demonstrate the improvement:

Format:

### Scenario: [Brief description]

**How the original prompt handles this**:
[Likely failure mode: rigid rule breaks, silent failure, inappropriate pattern-matching]

**How the transformed prompt handles this**:
[Better outcome: model uses judgment, applies principle, adapts to context]

Choose scenarios that are REALISTIC (not contrived) and showcase the value of reasoning over rules.

5. Output

Present the complete transformed prompt with:

  1. Summary: High-level changes made (e.g., "Converted 4 rule-based sections, preserved 2 safety constraints, reduced 3 lists to principles")
  2. Section-by-section transformations: Before/after with explanations (from step 3)
  3. Test scenarios: Edge cases demonstrating improvement (from step 4)
  4. Full transformed prompt: Clean, ready-to-use version with all changes applied

Ask the user: "Would you like me to explain any transformation in more detail, or test additional edge cases?"

Constraints

Practice What You Preach

This skill itself must be reasoning-based:

  • Trust the model to identify rule patterns (don't enumerate every possible rule format)
  • Provide judgment criteria for diagnosis (not exhaustive checklists)
  • Explain WHY each transformation improves robustness
  • Handle novel prompt structures by applying principles, not pattern-matching

Preserve Necessary Rules

Do NOT weaken genuinely necessary constraints:

  • Safety: "Never execute rm -rf without confirmation" → KEEP (hard safety)
  • Format contracts: "Output must be valid JSON with keys {x, y, z}" → KEEP (machine-readable contract)
  • Tool boundaries: "Use Read tool for files, not cat" → KEEP (enforced by system)

These are not micromanagement. They enforce invariants.

Avoid Bloat

Reasoning should be CONCISE. Compare:

  • Bad: "Never use emojis" → 3 paragraphs about professionalism and cultural context
  • Good: "Never use emojis" → "Avoid emojis unless explicitly requested, as they can feel unprofessional in technical contexts"

If reasoning doesn't add actionable value, don't add it.

Trust the User

If the user's prompt has unusual structure or domain-specific rules you don't understand, ASK:

  • "I see this section enforces X. Is this a hard business rule, or could it use more flexibility?"
  • "This template looks rigid, but if it's matching a required output format (e.g., API contract), I'll preserve it. Should I?"

Don't guess about domain constraints.

References

Read references/transformation-patterns.md before starting. This contains:

  • The 6 core transformation patterns with before/after examples
  • The scoring rubric for diagnosis
  • Anti-patterns to avoid
  • Constitutional AI quotes explaining WHY reasoning-based prompts work better

If the user asks about a pattern or principle, reference this document.

Example Usage

User: /system-prompt-clinic "Never use emojis. Never apologize. Always use TypeScript. When committing: 1) run git status, 2) run git diff, 3) add files, 4) commit."

Agent:

  1. Diagnosis: 4 sections, all rule-based (avg score 1.5/5). Issues: bare rules, rigid procedure, no edge case handling.
  2. Transformations: Apply Pattern 1 (bare rules → reasoning) and Pattern 2 (procedure → outcome-driven).
  3. Test Scenario: "User asks for a Python script" → Original: Fails (Always TypeScript). Transformed: Asks for approval (reasoning explains when Python is appropriate).
  4. Output: Transformed prompt with 3 improvements, 1 test scenario, ready to use.

Edge Case Guidance

If the prompt is already reasoning-based

Acknowledge this: "This prompt is already well-structured with reasoning and trust. I found [X] sections that could be tightened, but overall it's Constitutional-aligned."

If the prompt is mixed (some rules, some reasoning)

Focus on the rule-based sections. Preserve the good parts: "Sections 1, 3, 5 are already reasoning-based. I'll transform sections 2, 4, 6."

If you're unsure whether a constraint is necessary

Ask: "I see 'Must use format X'. Is this a hard requirement (e.g., API contract), or could it be more flexible?"

If the transformed version feels too long

Revisit: "The transformed version is 30% longer. Let me tighten the reasoning to preserve concision."

Input

$ARGUMENTS