- Introduced a human-in-the-loop script for bug diagnosis to capture user feedback. - Created ADR and CONTEXT formats to standardize architectural decision records and domain context documentation. - Developed a domain modeling skill to refine terminology and maintain a shared language. - Enhanced the improve-codebase-architecture skill to provide visual reports and deepening opportunities. - Consolidated grilling and handoff skills for better user interaction and documentation. - Updated existing skills to improve clarity and consistency in descriptions and functionality.
1.5 KiB
Commands vs skills
Every SKILL.md in this repo is one of two kinds. The test for "is it a skill" is: could the model usefully reach for this autonomously? Reuse is the reason to extract a skill, not the test.
- Command — always user-invoked. Set
disable-model-invocation: truein the frontmatter. Thedescriptionis human-facing: a one-line summary read by a person browsing slash-commands. Strip trigger lists ("Use when the user says…") from command descriptions. A command may invoke skills, but never another command. - Skill — invocable by model or user. The
descriptionis model-facing and keeps rich trigger phrasing ("Use when the user wants…, mentions…, asks for…") so auto-invocation fires. Do not setdisable-model-invocation.
Bucket README.mds and the top-level README.md group entries into Commands and Skills.
Dependencies between them
Dependencies are expressed as /skill-style prose invocation ("Run the /grilling skill"), not deep ../other-skill/FILE.md cross-references. Shared reference docs live inside the skill that owns them; other skills reach that material by invoking the skill, not by linking across folders.
Passive vs active domain work
Merely reading CONTEXT.md for vocabulary is a one-line prose pointer, not the domain-modeling skill. Only the active build/sharpen discipline (challenge terms, edge-case scenarios, write ADRs, update CONTEXT.md inline) is domain-modeling.