Menu
Experiment with model capabilities — HTML reports, embedded questionnaires, proactive research, multi-step reasoning
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Verify understanding after implementation with targeted quizzes
Clarify requirements through targeted questions — uncovers unknown unknowns in specs
Remove AI-generated code patterns that don't match codebase style
Review code for quality, security, and best practices — read-only analysis
Create clear documentation for code and APIs
Audit code for security vulnerabilities — read-only analysis
| name | capability-experiments |
| description | Experiment with model capabilities — HTML reports, embedded questionnaires, proactive research, multi-step reasoning |
| license | MIT |
| compatibility | cline, claude, opencode, amp, codex, gemini, cursor, pi |
| hint | Use for rich outputs, interactive forms, or exploring what next-gen models can do |
| user-invocable | true |
Use this skill when:
Teaches techniques for leveraging advanced model capabilities — HTML generation, embedded interactive elements, proactive research, and multi-step reasoning. These patterns showcase what's newly possible with next-generation models and should be used freely.
Advanced models can generate rich, self-contained HTML. This is useful for:
Generate structured HTML reports for complex findings:
<!DOCTYPE html>
<html>
<head><style>
body { font-family: system-ui; max-width: 800px; margin: 2rem auto; }
.finding { border-left: 4px solid #e74c3c; padding: 1rem; margin: 1rem 0; }
.finding.fixed { border-color: #2ecc71; }
.severity { font-weight: 600; font-size: 0.85rem; }
</style></head>
<body>
<h1>Code Review: PR #288</h1>
<div class="finding">
<span class="severity">🔴 Critical</span>
<p>Hardcoded path in config...</p>
</div>
...
</body></html>
Use HTML reports when:
Generate HTML questionnaires for spec interviews and quizzes:
<form id="quiz">
<div class="question">
<p>1. Why did we choose GitHub App Installation flow?</p>
<label><input type="radio" name="q1" value="a"> OAuth is deprecated</label>
<label><input type="radio" name="q1" value="b"> Org-level access ✓</label>
</div>
<button type="button" onclick="checkAnswers()">Check</button>
</form>
<script>
function checkAnswers() {
const correct = { q1: 'b', q2: 'c' };
// ... scoring logic
}
</script>
These work well with Fable's ability to render and execute embedded HTML in responses.
Use HTML/CSS to visualize decision processes:
<div class="decision-tree">
<div class="node root">Feature Change</div>
<div class="branch">
<div class="node">Familiar code?</div>
<div class="yes">→ Standard pattern</div>
<div class="no">→ /blindspots first</div>
</div>
</div>
<style>
.decision-tree { font-family: monospace; }
.node { background: #f0f0f0; padding: 8px; margin: 4px; }
.yes { color: #2ecc71; }
.no { color: #e74c3c; }
</style>
Let the agent self-direct exploration rather than waiting for instructions:
Instead of asking the user what to look at, proactively scan the codebase:
1. Scan recent changes with `fff` and `git log`
2. Identify areas of concern or interest
3. Analyze patterns and potential issues
4. Report findings with actionable recommendations
Before starting work, proactively look for gotchas:
1. Search git history for past bugs in related areas
2. Check qmd for relevant learnings
3. Search ctx for past agent discussions
4. Review existing ADRs for architectural context
5. Report findings before proposing implementation
When faced with a complex task, probe what's possible:
1. Generate multiple approaches (not just the obvious one)
2. For each approach, assess feasibility
3. Consider approaches that were hard with older models
4. Recommend the best approach with rationale
Break complex decisions into structured analysis:
## Analysis: Authentication Strategy
### Dimensions to Consider
1. Security requirements (OAuth 2.0, org-level access)
2. User experience (login flow, token management)
3. Maintenance (token refresh, error handling)
4. Scalability (multiple orgs, rate limits)
### Trade-offs
| Approach | Security | UX | Maintenance | Scalability |
|----------|----------|----|-------------|-------------|
| OAuth App | Medium | High | Low | Low |
| GitHub App | High | Medium | Medium | High |
| PAT | Low | Low | High | Medium |
For each promising approach, gather evidence:
## Research: GitHub App Installation
### Findings
- ✓ Org-level repo access (required)
- ✓ Webhook-based events
- ✓ Token caching supported
- ✗ More complex setup
- ✗ Requires webhook endpoint
### Past Context
- Previous PR #123 attempted similar approach
- ADR-005 discusses webhook infrastructure
- qmd has learnings about token caching
## Recommendation
**Approach**: GitHub App Installation Flow
**Rationale**:
1. Required for org-level access (blocker for OAuth App)
2. Token caching addresses UX concerns
3. Existing webhook infrastructure from PR #123
4. ADR-005 confirms architectural fit
**Risks**:
- Webhook endpoint needs high availability
- Token refresh handling adds complexity
Interactive questionnaires improve spec interviews and knowledge verification:
Generate structured questions with HTML forms:
<h3>Architecture Questions</h3>
<div class="question">
<p><strong>Q1:</strong> Should we use a single shared database or per-tenant databases?</p>
<details>
<summary>Context</summary>
<p>Current system uses shared DB. Per-tenant improves isolation but adds operational complexity.</p>
</details>
<textarea rows="2" placeholder="Your thinking..."></textarea>
</div>
Generate self-assessment quizzes:
<h3>Implementation Quiz</h3>
<form id="quiz">
<div class="q">
<p>1. What caching strategy did we use for installation tokens?</p>
<label><input type="radio" name="q1" value="r"> Redis with TTL</label>
<label><input type="radio" name="q1" value="w"> In-memory cache</label>
</div>
<button type="button" onclick="grade()">Check Understanding</button>
</form>
When to Use Each Pattern:
┌──────────────────────────────┬──────────────────────────┐
│ Situation │ Use Pattern │
├──────────────────────────────┼──────────────────────────┤
│ Complex analysis to present │ HTML report │
│ Spec is vague │ Embedded questionnaire │
│ Large, unfamiliar codebase │ Proactive research scan │
│ Hard architectural decision │ Multi-step reasoning │
│ After implementation │ Embedded quiz │
│ Exploring options │ Capability probe │
└──────────────────────────────┴──────────────────────────┘