From 1665a73f6d302c9a97f9676f749835d5c7807779 Mon Sep 17 00:00:00 2001 From: alexion Date: Sat, 17 Oct 2026 19:54:17 -0400 Subject: [PATCH] refactor(skills): remove drafting and grilling skills --- .pi/skills/grill | 1 - .pi/skills/to-document | 1 - src/skills/grill/SKILL.md | 88 ----------------------- src/skills/to-document/DOCUMENT-FORMAT.md | 62 ---------------- src/skills/to-document/SKILL.md | 64 ----------------- 5 files changed, 216 deletions(-) delete mode 120000 .pi/skills/grill delete mode 120000 .pi/skills/to-document delete mode 100644 src/skills/grill/SKILL.md delete mode 100644 src/skills/to-document/DOCUMENT-FORMAT.md delete mode 100644 src/skills/to-document/SKILL.md diff --git a/.pi/skills/grill b/.pi/skills/grill deleted file mode 120000 index 2806aae..0000000 --- a/.pi/skills/grill +++ /dev/null @@ -1 +0,0 @@ -../../src/skills/grill \ No newline at end of file diff --git a/.pi/skills/to-document b/.pi/skills/to-document deleted file mode 120000 index 6b2e42d..0000000 --- a/.pi/skills/to-document +++ /dev/null @@ -1 +0,0 @@ -../../src/skills/to-document \ No newline at end of file diff --git a/src/skills/grill/SKILL.md b/src/skills/grill/SKILL.md deleted file mode 100644 index 2811337..0000000 --- a/src/skills/grill/SKILL.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -name: grill -description: Stress-test a plan, decision, or design through a one-question-at-a-time interview. Use when the user asks to grill, stress-test, pressure-test, challenge, interrogate, or poke holes in a plan. ---- - -# grill - -Interview the user until the session has no open or blocked questions. -Open questions define the ending condition for the grill session. -Blocked questions track known decisions with unsettled prerequisites. - -Do not begin implementation during or after grill without an explicit user instruction. -A completed grill summary is not an instruction to build. - -## Run the interview - -1. Prepare the grill. - Read the conversation, files, and docs that can settle facts or reveal constraints. - Resolve factual questions yourself when tools can answer them. - Do not ask the user for facts you can find. - Build the required-question set from the known plan or idea. - Put ready questions under `Open questions:`. - Put known questions with unsettled prerequisites under `Blocked questions:`. - - Finish when both sections contain every known required question. - -2. Start the interview. - Show `Open questions:` and `Blocked questions:` in short form. - Include titles only, not full question bodies. - Use Markdown list items in both sections. - Mark each initial item with `- [ ]`. - Ask exactly one numbered question in the same turn. - The question title must match an item under `Open questions:`. - - Finish when the interview has started with exactly one numbered question. - -3. Process the answer. - Account for the user's answer before asking another question. - Resolve, update, remove, unblock, or add questions as the answer requires. - Use `- [ ]` for unchanged unresolved questions. - Use `- [+]` for questions added by the latest answer. - Use `- [u]` for questions updated by the latest answer. - Use `- [x]` for questions resolved by the latest answer. - Use `- [-]` for questions removed by the latest answer. - Include a cause note for each `- [+]`, `- [u]`, and `- [-]` change. - Indent cause notes by two spaces under the changed question. - Show `- [+]`, `- [u]`, `- [x]`, and `- [-]` for one turn only. - After that turn, keep an updated question visible as `- [ ]`. - After that turn, remove resolved and removed questions from the visible list. - Move unblocked questions from `Blocked questions:` to `Open questions:` with `- [u]`. - Do not use `- [+]` for unblocked questions because they are not new. - Add questions only when the latest answer directly causes them. - When the user extends scope instead of answering, account for the new question before pursuing it. - Do not add optional follow-up questions to either section. - Put optional follow-up questions in the final summary instead. - Resolve newly answerable facts yourself. - - Finish when every list change has an explicit marker and required cause note. - -4. Ask the next question. - Show `Open questions:` and `Blocked questions:` on every active grill turn. - Keep `- [ ]` items visible every turn. - Preserve agent judgment when the user reframes or invalidates a question. - Show the resulting list change instead of following a rigid reframe algorithm. - If the user catches incorrect accounting, briefly explain the error. - Then show the corrected question sections. - Ask exactly one numbered question when `Open questions:` contains an unresolved item. - The question title must match an item currently shown under `Open questions:`. - Give concrete options with trade-offs. - Label options with `A.`, `B.`, `C.`, and later letters. - Use the same labels in the recommendation. - Give a recommendation and rationale. - Probe vague words, overloaded terms, and hidden assumptions. - Use concrete scenarios to test concept boundaries and edge cases. - When code contradicts the user's claim, quote both the claim and the code behavior. - If the turn includes a correction, file edit, apology, or explanation, still end with the next numbered question. - - Finish when the turn ends with the next numbered question. - -5. Close or pause. - Close when `Open questions:` and `Blocked questions:` are empty. - Output a concise summary of every decision reached. - Include optional follow-up questions that were not added to either section. - Do not act on the summary unless the user gives a new implementation instruction. - If the user changes tasks, state that grill is paused. - End the turn with the final decision summary or the pause statement. - - Finish when the summary is delivered or grill is explicitly paused. diff --git a/src/skills/to-document/DOCUMENT-FORMAT.md b/src/skills/to-document/DOCUMENT-FORMAT.md deleted file mode 100644 index e31cdbf..0000000 --- a/src/skills/to-document/DOCUMENT-FORMAT.md +++ /dev/null @@ -1,62 +0,0 @@ -# Document Format - -## Template - -```md -## 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 - -An extensive, numbered list of user stories, covering all aspects of the feature. Each user story should be in the format of: - -1. As an , I want a , so that - - -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 - - -## 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 - -## 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, that is, similar tests in the codebase - -## Out of Scope - -A description of the things that are out of scope for this spec. - -## Further Notes - -Any further notes about the feature. -``` - -## Rules - -- **Do not include specific file paths or code snippets.** - They can become outdated quickly. - Exception: include a prototype snippet when it records a decision more precisely than prose. - Examples include a state machine, reducer, schema, or type shape. - Inline the snippet in the relevant implementation decision. - Note briefly that the snippet came from a prototype. - Trim the snippet to the decision-rich parts. - Do not include a working demo. diff --git a/src/skills/to-document/SKILL.md b/src/skills/to-document/SKILL.md deleted file mode 100644 index 2257383..0000000 --- a/src/skills/to-document/SKILL.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -name: to-document -description: Draft a requested summary, specification, plan, decision record, or similar document from conversation and repository context. ---- - -Do not start with an interview when the conversation gives a usable subject. -Ask before drafting only when the conversation lacks a usable subject. - -Do not put draft contents in the chat response. -Always persist the draft to a file. - -Do not implement the draft contents unless the operator gives a separate instruction. -Treat a completed draft as documentation, not an instruction to build. - -## Process - -1. Identify the subject. - Use the conversation as the primary source. - If the conversation lacks a usable subject, ask what the document is about. - Do not ask clarifying questions before drafting when a usable subject exists. - - Finish when you have a subject or a question that requests the missing subject. - -2. Gather repository facts that the draft needs. - Inspect files when repository details matter. - Do not invent modules, paths, commands, flows, contracts, or conventions. - Distinguish confirmed facts from assumptions. - - Finish when each repository-specific claim has support or an explicit assumption marker. - -3. Choose the document shape. - Infer the document type and title from context. - Load [DOCUMENT-FORMAT.md](DOCUMENT-FORMAT.md) when the operator requests no specific format. - Adapt the structure only when the requested document type needs different sections. - Preserve useful sections for decisions, testing, scope, and notes. - - Finish when the draft has a title and section plan that fit the requested document. - -4. Write the draft. - Capture known context accurately. - Mark assumptions and gaps explicitly. - Include decisions that the conversation settled. - Include open questions only as gaps, not as an interview. - Keep the document focused on the operator's problem and intended use. - - Finish when the draft contains the relevant facts, decisions, assumptions, gaps, and scope. - -5. Persist the draft. - Use `docs/00 INBOX/ai` as the default destination. - Use the operator's requested path when one exists. - Derive a kebab-case slug from the inferred title. - Create the destination directory when it does not exist. - If the target file exists, summarize the expected change. - Confirm before overwriting an existing file. - Do not print the draft in chat instead of writing it. - - Finish when the draft is written or overwrite confirmation is pending. - -6. Finish with the result. - Report the written path. - Do not include the draft contents in the response. - Do not continue into implementation without an explicit instruction. - - Finish when the operator can find the written draft.