Skills that I use

grill-me.md

name	grill-me
description	Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Grill Me

Interview the user relentlessly about every aspect of their plan until reaching a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. DISCOVER FIRST, CODE LATER - Your primary goal is to lay out discoveries, analysis, and findings in an organized way so the user can make informed decisions about what actions to take.

Usage

This skill is invoked when:

• The user wants to stress-test a plan
• The user wants to get grilled on their design
• The user mentions "grill me"
• The user wants thorough analysis before implementation

Critical Guidelines

🔍 DISCOVERY-FIRST APPROACH

• NEVER WRITE CODE - Focus strictly on understanding and analyzing. Do not write any implementation code, not even at the end.
• Keep asking questions recursively until you are fully satisfied with the robust design OR the user explicitly states they are satisfied and want to stop.
• Present findings in organized, actionable format
• Lay out the landscape of options, constraints, and implications
• Provide structured analysis that enables informed decision-making

📋 Discovery Process

1. Explore the codebase if questions can be answered by doing so
2. Document current state - What exists, how it works, what the constraints are
3. Identify gaps and issues - What's missing, what's problematic, what needs attention
4. Present multiple perspectives - Different approaches, trade-offs, consequences
5. Ask clarifying questions - One at a time, with your recommended answer

💡 Analysis Structure

When presenting discoveries, organize them as:

• Current State: What we have and how it works
• Issues/Gaps: What's problematic or missing
• Options Available: Different approaches to consider
• Trade-offs: Pros/cons of each option
• Dependencies: What needs to be resolved first
• Recommendations: Your suggested path forward

🎯 Question Framework

• Ask questions one at a time (or a small set of closely related questions).
• For each question, provide your recommended answer.
• WAIT FOR THE USER'S ANSWER before continuing to the next question. Do not assume their response or proceed without it.
• Resolve dependencies between decisions one-by-one.
• Walk down each branch of the design tree.
• Explore consequences and implications.
• CONTINUE INTERVIEWING until the user says they are satisfied.

🏁 Termination & Summary

• When the user explicitly states they are satisfied, STOP INTERVIEWING.
• Output a comprehensive final summary of the agreed-upon design and plan in the chat.
• Trigger the write-a-plan skill, providing it with your final summary. Instruct the write-a-plan skill to read any project guidelines in the project's ai-context/ directory (located in the current working directory where the user's code resides, NOT inside the .pi/agent/skills folder) and generate the PLAN.md and TODO.md files for you.
• DO NOT WRITE CODE under any circumstances (only the markdown planning files generated via the write-a-plan skill).

Output Format

Present your final summary and findings as structured analysis in the chat, and ensure you trigger the write-a-plan skill to generate PLAN.md and TODO.md.

## Discovery Summary

### Current State Analysis
[What exists, how it works, constraints]

### Issues & Gaps Identified
[What's problematic or missing]

### Options Analysis
[Different approaches with trade-offs]

### Dependencies to Resolve
[What needs to be addressed first]

### Recommendations
[Suggested next steps]

### Open Questions
[Things that need clarification]

This approach ensures we build shared understanding before taking any action.

write-a-plan.md

name	write-a-plan
description	Generate a comprehensive PLAN.md and a phased TODO.md based on the current chat context, a provided PRD, and project-specific reference materials in ai-context/. Use this skill to structure work before execution, or when delegated to by other skills.

write-a-plan

Description

Generate a comprehensive PLAN.md and a phased TODO.md based on the current chat context, a provided PRD, and project-specific reference materials. This skill is meant to be highly reusable and can be called by users directly or delegated to by other skills (like sonarqube-code-coverage-analyzer) to handle standard planning.

Triggers

Use this skill when the user asks to "write a plan", "create a development plan", "generate a plan and todo", or when another skill instructs you to use the write-a-plan skill.

Workflow

1. Context & Requirement Gathering:

   • Analyze the current chat context to understand the user's objective.
   • If the user or the delegating skill mentions a specific PRD or issue file, read it thoroughly.
   • Crucial Step: Always check for an ai-context/ directory in the current working directory/project root (e.g., using ls ai-context/). Ensure you are looking in the user's project, NOT inside the .pi/agent/skills folder. Read the relevant reference materials inside it (architecture rules, coding guidelines, component specs). Incorporate these guidelines strictly into the plan.

2. Drafting PLAN.md:

   • Write a detailed PLAN.md in the root directory (or the requested directory) containing:
     • Objective: Clear statement of what is being built, fixed, or analyzed.
     • Context & Constraints: Key takeaways from the chat context, the PRD, and specifically the rules gathered from the ai-context/ folder.
     • Technical Design: High-level approach, files to be modified, and architectural decisions.
     • Phases: A high-level description of the development phases.

3. Drafting TODO.md:

   • Based strictly on the generated PLAN.md, write a TODO.md file.
   • It must be organized by the defined development phases.
   • Use individual markdown checkboxes for atomic, actionable steps so progress can be tracked easily.

   Example TODO.md structure:

   # Development Tasks
   
   ## Phase 1: Preparation & Foundation
   - [ ] Read and understand existing component X.
   - [ ] Setup scaffolding for Y.
   
   ## Phase 2: Core Implementation
   - [ ] Implement feature A in `file.ts`.
   - [ ] Add unit tests for feature A.
   
   ## Phase 3: Review & Refine
   - [ ] Ensure all `ai-context/` guidelines are met.
   - [ ] Run linter and type checks.

4. Completion:

   • Briefly summarize the created files and invite the user to review the PLAN.md and TODO.md before proceeding with the execution (e.g., using the execute-plan skill).

write-a-prd.md

name	write-a-prd
description	Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.

Write a PRD

Create a Product Requirements Document (PRD) through a structured process of user interview, codebase exploration, and module design.

When to Use

• User wants to write a PRD
• User wants to create a product requirements document
• User wants to plan a new feature

Process

Step 1: Problem Understanding

Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.

Step 2: Codebase Exploration

Explore the repository to verify the user's assertions and understand the current state of the codebase.

Step 3: User Interview

Interview the user relentlessly about every aspect of their plan until reaching a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

Step 4: Module Design

Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.

A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.

Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.

Step 5: Write the PRD

Once you have a complete understanding of the problem and solution, write the PRD using the template below. Save the PRD as a markdown file to the ai-context/features/ folder inside the project.

PRD Template

# <Title of the feature>

**Status**: Progress 🚧
**Last Updated**: <current_date>
**Owner**: Frontend Team
**Location**: <filepath>

---

## 📋 Table of Contents

<Table_of_content>

## Problem Statement

The problem that the user is facing, from the user's perspective.

## Solution

The solution to the problem, from the user's perspective.

## User Stories

A LONG, numbered list of user stories. Each user story should be in the format of:

1. As an <actor>, I want a <feature>, so that <benefit>

<user-story-example>
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
</user-story-example>

This list of user stories should be extremely extensive and cover all aspects of the feature.

## Implementation Decisions

A list of implementation decisions that were made. This can include:

- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.

## Testing Decisions

A list of testing decisions that were made. Include:

- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)

## Out of Scope

A description of the things that are out of scope for this PRD.

## Further Notes

Any further notes about the feature.

---

**Last Updated**: <current_date>
**Maintained By**: Frontend Team
**Status**: Progress 🚧

Notes

You may skip steps if you don't consider them necessary.