@docyrus/docyrus 0.0.40 → 0.0.42

package/resources/pi-agent/skills/grill-me/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: grill-me
+description: >
+  Interview the user relentlessly about a plan, architecture, or data model design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+
+**Triggers — use this skill when:**
+- User says "grill me", "stress test this", "challenge my design"
+- User asks to "poke holes", "find gaps", "review my thinking"
+- User wants to validate a plan before implementing
+- User says "interview me about this", "question my decisions"
+- Used after `/architect` or `/plan` when the user wants to pressure-test the output
+---
+
+# 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.
+
+## How It Works
+
+Ask questions **one at a time**. For each question, provide your recommended answer based on what you know about the codebase and the Docyrus platform.
+
+If a question can be answered by exploring the codebase or the discovery snapshot, explore it yourself instead of asking.
+
+## Question Domains
+
+Work through these domains systematically, but adapt the order based on what matters most for the specific plan:
+
+### Data Model
+
+- Why this data source and not an extension of an existing one?
+- What is the expected record volume? Does the schema hold up at 10x scale?
+- Are there fields that should be computed (formulas) instead of stored?
+- Could any proposed data source be replaced by a custom query instead?
+- Are slug and naming choices consistent with existing tenant conventions?
+
+### Field Design
+
+- Is this the right field type? (e.g., `field-select` vs `field-radioGroup`, `field-text` vs `field-richText`)
+- Should this field be required, optional, or have a default value?
+- Are validation rules sufficient? Too strict? Missing edge cases?
+- For relation fields: is the cardinality correct? Should it be bidirectional?
+- Are there fields that will rarely be used and could be deferred?
+
+### Enumerations
+
+- Are enum options exhaustive? What happens when a new option is needed later?
+- Should this be an enum or a separate data source with its own lifecycle?
+- Are enum values and labels clear and consistent?
+- Is the ordering intentional?
+
+### Relations and Dependencies
+
+- What is the dependency graph between data sources? Are there cycles?
+- What happens when a related record is deleted?
+- Are there implicit relations that should be explicit?
+- Does the creation order in the apply plan respect all dependencies?
+
+### Access Control and Security
+
+- Who should be able to read/write/delete these records?
+- Are there tenant-level vs app-level permission considerations?
+- Should any fields be hidden or read-only for certain roles?
+
+### Edge Cases and Failure Modes
+
+- What happens with empty states? First record ever created?
+- What if the user enters unexpected data?
+- Are there race conditions in concurrent record creation?
+- What if a bulk import has partial failures?
+
+### Implementation Feasibility
+
+- Can this be built with existing Docyrus field types, or does it require platform changes?
+- Are there known limitations in the current API that affect this design?
+- Is the proposed migration path realistic?
+
+## Interview Protocol
+
+1. Start by reading the plan or architecture artifacts (PLAN.md, DATA_SOURCES.md, discovery snapshot, or whatever is available).
+2. Identify the most critical or uncertain decision in the plan.
+3. Ask one focused question about it, with your recommended answer.
+4. Based on the user's response, either drill deeper into that branch or move to the next decision.
+5. Track resolved decisions and open questions as you go.
+6. When all major branches are resolved, summarize the final shared understanding.
+
+## Output on Completion
+
+When the interview is complete, produce a summary:
+
+```markdown
+## Resolved Decisions
+
+- [Decision 1]: [Resolution]
+- [Decision 2]: [Resolution]
+...
+
+## Changes to the Plan
+
+- [Change 1]
+- [Change 2]
+...
+
+## Remaining Open Questions
+
+- [Question 1]
+...
+```
+
+If the plan artifacts exist on disk (PLAN.md, data-sources.plan.json), offer to update them with the resolved decisions.