create-yss-spec 1.1.4 → 2.0.0

package/template/.agents/skills/mapstruct/SKILL.md

@@ -0,0 +1,328 @@
+---
+name: mapstruct
+description: |
+  MapStruct Java mapping framework. Covers basic mappers, update mappings,
+  nested objects, collections, custom methods, and Lombok integration.
+  Based on castellino and gestionale-presenze production patterns.
+
+  USE WHEN: user mentions "mapstruct", "@Mapper", "@Mapping", asks about
+  "DTO mapping", "entity conversion", "@MappingTarget", "nested mapping"
+
+  DO NOT USE FOR: Java language - use `java` skill instead
+  DO NOT USE FOR: Lombok - use `lombok` skill instead
+  DO NOT USE FOR: JPA entities - use JPA-specific skills
+allowed-tools: Read, Grep, Glob, Write, Edit
+---
+# MapStruct Object Mapping
+
+> **Deep Knowledge**: Use `mcp__documentation__fetch_docs` with technology: `mapstruct` for comprehensive documentation.
+
+## Basic Mapper
+
+```java
+@Mapper(componentModel = "spring", unmappedTargetPolicy = ReportingPolicy.IGNORE)
+public interface UserMapper {
+
+    UserResponse toResponse(User user);
+
+    List<UserResponse> toResponseList(List<User> users);
+
+    @Mapping(target = "id", ignore = true)
+    @Mapping(target = "createdAt", ignore = true)
+    @Mapping(target = "updatedAt", ignore = true)
+    @Mapping(target = "password", ignore = true)
+    User toEntity(CreateUserRequest dto);
+}
+```
+
+## Update Mapping
+
+```java
+@Mapper(componentModel = "spring", unmappedTargetPolicy = ReportingPolicy.IGNORE)
+public interface UserMapper {
+
+    // Partial update - ignores null values
+    @BeanMapping(nullValuePropertyMappingStrategy = NullValuePropertyMappingStrategy.IGNORE)
+    void updateEntity(UpdateUserRequest dto, @MappingTarget User user);
+
+    // Full update - sets all fields including nulls
+    void updateEntityFull(UpdateUserRequest dto, @MappingTarget User user);
+}
+```
+
+## Field Mapping
+
+```java
+@Mapper(componentModel = "spring")
+public interface OrderMapper {
+
+    // Different field names
+    @Mapping(source = "customer.name", target = "customerName")
+    @Mapping(source = "customer.email", target = "customerEmail")
+    @Mapping(source = "items", target = "orderItems")
+    OrderResponse toResponse(Order order);
+
+    // Constant values
+    @Mapping(target = "status", constant = "PENDING")
+    @Mapping(target = "createdAt", expression = "java(java.time.LocalDateTime.now())")
+    Order toEntity(CreateOrderRequest dto);
+
+    // Expression
+    @Mapping(target = "fullName", expression = "java(user.getFirstName() + \" \" + user.getLastName())")
+    UserResponse toResponse(User user);
+
+    // Date formatting
+    @Mapping(source = "createdAt", target = "createdDate", dateFormat = "yyyy-MM-dd")
+    OrderResponse toResponse(Order order);
+}
+```
+
+## Nested Objects
+
+```java
+@Mapper(componentModel = "spring", uses = {AddressMapper.class, ItemMapper.class})
+public interface OrderMapper {
+
+    // Uses AddressMapper for address field
+    // Uses ItemMapper for items collection
+    OrderResponse toResponse(Order order);
+}
+
+@Mapper(componentModel = "spring")
+public interface AddressMapper {
+    AddressResponse toResponse(Address address);
+}
+
+@Mapper(componentModel = "spring")
+public interface ItemMapper {
+    ItemResponse toResponse(Item item);
+}
+```
+
+## Enum Mapping
+
+```java
+@Mapper(componentModel = "spring")
+public interface StatusMapper {
+
+    @ValueMappings({
+        @ValueMapping(source = "ACTIVE", target = "ENABLED"),
+        @ValueMapping(source = "INACTIVE", target = "DISABLED"),
+        @ValueMapping(source = MappingConstants.ANY_REMAINING, target = "UNKNOWN")
+    })
+    ExternalStatus toExternalStatus(InternalStatus status);
+}
+```
+
+## Custom Methods
+
+```java
+@Mapper(componentModel = "spring")
+public abstract class UserMapper {
+
+    @Autowired
+    protected RoleRepository roleRepository;
+
+    public abstract UserResponse toResponse(User user);
+
+    @Mapping(target = "roles", source = "roleIds")
+    public abstract User toEntity(CreateUserRequest dto);
+
+    // Custom mapping method
+    protected Set<Role> mapRoles(Set<Long> roleIds) {
+        if (roleIds == null) return new HashSet<>();
+        return roleIds.stream()
+            .map(id -> roleRepository.findById(id)
+                .orElseThrow(() -> new ResourceNotFoundException("Role", "id", id)))
+            .collect(Collectors.toSet());
+    }
+}
+```
+
+## Collection Mapping
+
+```java
+@Mapper(componentModel = "spring")
+public interface ProductMapper {
+
+    ProductResponse toResponse(Product product);
+
+    List<ProductResponse> toResponseList(List<Product> products);
+
+    Set<ProductResponse> toResponseSet(Set<Product> products);
+
+    // Page mapping
+    default Page<ProductResponse> toResponsePage(Page<Product> products) {
+        return products.map(this::toResponse);
+    }
+}
+```
+
+## After/Before Mapping
+
+```java
+@Mapper(componentModel = "spring")
+public abstract class UserMapper {
+
+    @AfterMapping
+    protected void afterMapping(@MappingTarget UserResponse response, User user) {
+        response.setDisplayName(user.getFirstName() + " " + user.getLastName().charAt(0) + ".");
+    }
+
+    @BeforeMapping
+    protected void beforeMapping(CreateUserRequest dto) {
+        if (dto.getEmail() != null) {
+            dto.setEmail(dto.getEmail().toLowerCase().trim());
+        }
+    }
+}
+```
+
+## Conditional Mapping
+
+```java
+@Mapper(componentModel = "spring")
+public abstract class UserMapper {
+
+    @Condition
+    public boolean isNotEmpty(String value) {
+        return value != null && !value.trim().isEmpty();
+    }
+
+    // Only maps non-empty strings
+    UserResponse toResponse(User user);
+}
+```
+
+## Maven Configuration
+
+```xml
+<properties>
+    <mapstruct.version>1.6.2</mapstruct.version>
+    <lombok.version>1.18.30</lombok.version>
+</properties>
+
+<dependencies>
+    <dependency>
+        <groupId>org.mapstruct</groupId>
+        <artifactId>mapstruct</artifactId>
+        <version>${mapstruct.version}</version>
+    </dependency>
+
+    <dependency>
+        <groupId>org.projectlombok</groupId>
+        <artifactId>lombok</artifactId>
+        <version>${lombok.version}</version>
+        <optional>true</optional>
+    </dependency>
+</dependencies>
+
+<build>
+    <plugins>
+        <plugin>
+            <groupId>org.apache.maven.plugins</groupId>
+            <artifactId>maven-compiler-plugin</artifactId>
+            <version>3.13.0</version>
+            <configuration>
+                <source>17</source>
+                <target>17</target>
+                <annotationProcessorPaths>
+                    <!-- Order matters: Lombok first -->
+                    <path>
+                        <groupId>org.projectlombok</groupId>
+                        <artifactId>lombok</artifactId>
+                        <version>${lombok.version}</version>
+                    </path>
+                    <path>
+                        <groupId>org.mapstruct</groupId>
+                        <artifactId>mapstruct-processor</artifactId>
+                        <version>${mapstruct.version}</version>
+                    </path>
+                    <path>
+                        <groupId>org.projectlombok</groupId>
+                        <artifactId>lombok-mapstruct-binding</artifactId>
+                        <version>0.2.0</version>
+                    </path>
+                </annotationProcessorPaths>
+                <compilerArgs>
+                    <arg>-Amapstruct.defaultComponentModel=spring</arg>
+                </compilerArgs>
+            </configuration>
+        </plugin>
+    </plugins>
+</build>
+```
+
+## Key Annotations
+
+| Annotation | Purpose |
+|------------|---------|
+| `@Mapper` | Define mapper interface/abstract class |
+| `@Mapping` | Field-level mapping configuration |
+| `@MappingTarget` | Update existing object |
+| `@BeanMapping` | Bean-level mapping settings |
+| `@AfterMapping` | Post-processing method |
+| `@BeforeMapping` | Pre-processing method |
+| `@Condition` | Conditional mapping |
+| `@ValueMapping` | Enum value mapping |
+
+## Best Practices
+
+1. Use `componentModel = "spring"` for Spring injection
+2. Use `unmappedTargetPolicy = ReportingPolicy.IGNORE` for DTOs with fewer fields
+3. Always exclude `id`, `createdAt`, `updatedAt` when mapping from DTOs
+4. Use `@MappingTarget` for partial updates
+5. Order annotation processors: Lombok → MapStruct → Binding
+6. Use abstract classes instead of interfaces for custom logic
+7. Use `@Condition` for conditional mapping logic
+
+---
+
+## When NOT to Use This Skill
+
+| Scenario | Use Instead |
+|----------|-------------|
+| Java language features | `java` skill |
+| Lombok annotations | `lombok` skill |
+| Spring configuration | `backend-spring-boot` skill |
+| JPA entity operations | JPA-specific skills |
+| Simple copying | Manual mapping or BeanUtils |
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It's Bad | Correct Approach |
+|--------------|--------------|------------------|
+| Mapping entities to entities | Breaks change tracking | Map DTO to entity |
+| Not using @MappingTarget | Inefficient updates | Use for partial updates |
+| Complex logic in expressions | Hard to test | Use custom methods |
+| Ignoring all unmapped | Misses fields silently | Use WARN or ERROR policy |
+| Not excluding audit fields | Overwrites metadata | Exclude id, timestamps |
+| Circular references | StackOverflowError | Break cycles with custom mapping |
+| Using interfaces for custom logic | Can't inject dependencies | Use abstract classes |
+| Not testing mappers | Runtime mapping errors | Write mapper tests |
+
+---
+
+## Quick Troubleshooting
+
+| Issue | Cause | Solution |
+|-------|-------|----------|
+| "Cannot find implementation" | Annotation processing failed | Check processor configuration |
+| Lombok fields not found | Wrong processor order | Lombok before MapStruct |
+| Mapper not autowired | Wrong componentModel | Use componentModel = "spring" |
+| Circular dependency | Mappers reference each other | Use @Lazy or refactor |
+| UnmappedTargetProperty warning | Missing mapping | Add @Mapping or ignore policy |
+| NullPointerException in mapping | Null source | Add null checks or NullValuePropertyMappingStrategy |
+| Custom method not called | Wrong signature | Match method parameters exactly |
+| Generated code not updated | IDE cache | Clean and rebuild project |
+
+---
+
+## Reference Documentation
+- [MapStruct Reference](https://mapstruct.org/documentation/stable/reference/html/)
+- [Spring Integration](https://mapstruct.org/documentation/stable/reference/html/#spring)
+- [Lombok Integration](https://mapstruct.org/faq/#can-i-use-mapstruct-together-with-project-lombok)
+
+> **Deep Knowledge**: Use `mcp__documentation__fetch_docs` with technology: `mapstruct` for comprehensive documentation.

package/template/.agents/skills/prototype/LOGIC.md

@@ -36,7 +36,7 @@ The right shape depends on the question:
 
 Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a TUI. Keep it pure: no I/O, no terminal code, no `console.log` for control flow. The TUI imports it and calls into it; nothing flows the other direction.
 
-This is what makes the prototype useful past its own lifetime. When the question's been answered, the validated reducer / machine / function set can be lifted into the real module — the TUI shell gets deleted.
+This is what makes the prototype useful past its own lifetime: when the question's been answered, the validated reducer / machine / function set can be lifted into the real module on its own.
 
 ### 4. Build the smallest TUI that exposes the state
 
@@ -66,9 +66,9 @@ If the host project has no task runner, just put the command at the top of the p
 
 Give the user the run command. They'll drive it themselves; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions added, add them. Prototypes evolve.
 
-### 7. Capture the answer
+### 7. Capture the answer and the prototype
 
-When the prototype has done its job, the answer to the question is the only thing worth keeping. If the user is around, ask what it taught them. If not, leave a `NOTES.md` next to the prototype so the answer can be filled in (or filled in by you, if you've watched the session) before the prototype gets deleted.
+Once the prototype has answered its question, capture the answer, then capture the prototype the way the [SKILL](SKILL.md) describes. The logic-specific mapping: the validated reducer / machine / function set lifts into the real module (the decision, absorbed); the TUI shell rides along to the throwaway branch that keeps the prototype as a primary source.
 
 ## Anti-patterns
 

package/template/.agents/skills/prototype/SKILL.md

@@ -21,10 +21,6 @@ The two branches produce very different artifacts — getting this wrong wastes
 1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
 2. **One command to run.** Whatever the project's existing task runner supports — `pnpm <name>`, `python <path>`, `bun <path>`, etc. The user must be able to start it without thinking.
 3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
-4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast and then delete it.
+4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
 5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
-6. **Delete or absorb when done.** When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo.
-
-## When done
-
-The _answer_ is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a `NOTES.md` next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype.
+6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too — the verdict and the question it settled — in the issue or a commit. The main branch keeps only the validated decision.

package/template/.agents/skills/prototype/UI.md

@@ -97,12 +97,12 @@ Surface the URL (and the `?variant=` keys). The user will flip through whenever
 
 ### 6. Capture the answer and clean up
 
-Once a variant has won, write down which one and why (commit message, ADR, issue, or a `NOTES.md` next to the prototype if running AFK and the user hasn't responded yet). Then:
+Once a variant has won, capture the answer — which variant and why — then capture the prototype the way the [SKILL](SKILL.md) describes. Fold the winner into the real code and move the rest onto the throwaway branch, not into main:
 
-- **Sub-shape A** — delete the losing variants and the switcher; fold the winner into the existing page.
-- **Sub-shape B** — promote the winning variant to a real route, delete the throwaway route and the switcher.
+- **Sub-shape A** — fold the winner into the existing page; drop the losing variants and the switcher from main.
+- **Sub-shape B** — promote the winning variant to a real route; drop the throwaway route and the switcher from main.
 
-Don't leave variant components or the switcher lying around. They rot fast and confuse the next reader.
+The full set of variants is the primary source, so it lands on the throwaway branch, not the bin — variant components and the switcher left in the main branch rot fast and confuse the next reader.
 
 ## Anti-patterns
 

package/template/.agents/skills/prototype/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Prototype"
+  short_description: "Prototype to answer a design question"

package/template/.agents/skills/research/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Research"
+  short_description: "Research from high-trust sources"

package/template/.agents/skills/resolving-merge-conflicts/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Resolving Merge Conflicts"
+  short_description: "Resolve merge and rebase conflicts"

package/template/.agents/skills/setup-matt-pocock-skills/SKILL.md

@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 Scaffold the per-repo configuration that the engineering skills assume:
 
-- **Issue tracker** — where issues live (GitHub by default; local markdown is also supported out of the box)
+- **Ticket tracker** — where Tickets live (GitHub by default; local markdown is also supported out of the box)
 - **Triage labels** — the strings used for the five canonical triage roles
 - **Domain docs** — where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
 
@@ -26,16 +26,18 @@ Look at the current repo to understand its starting state. Read whatever exists;
 - `docs/adr/` and any `src/*/docs/adr/` directories
 - `docs/agents/` — does this skill's prior output already exist?
 - `.scratch/` — sign that a local-markdown issue tracker convention is already in use
+- Is the `triage` skill installed? (a `triage` skill folder alongside this one, or `triage` in your available skills.) This decides whether Section B runs at all.
+- Monorepo signals — a `pnpm-workspace.yaml`, a `workspaces` field in `package.json`, or a populated `packages/*` with its own `src/`. Present only in a genuinely large multi-package repo; their absence means single-context, which is almost every repo.
 
 ### 2. Present findings and ask
 
-Summarise what's present and what's missing. Then walk the user through the three decisions **one at a time** — present a section, get the user's answer, then move to the next. Don't dump all three at once.
+Summarise what's present and what's missing. Then take the sections in order — one section, one answer, then the next.
 
-Assume the user does not know what these terms mean. Each section starts with a short explainer (what it is, why these skills need it, what changes if they pick differently). Then show the choices and the default.
+Lead each section with the recommended answer so the user can accept it in a word. Give a one-line explainer only when the choice genuinely branches; skip the section entirely when exploration already settled it (Section B when `triage` isn't installed, Section C when there's no monorepo).
 
-**Section A — Issue tracker.**
+**Section A — Ticket tracker.**
 
-> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-issues`, `triage`, `to-prd`, and `qa` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
+> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-tickets`, `triage`, `to-spec`, and `qa` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
 
 Default posture: these skills were designed for GitHub. If a `git remote` points at GitHub, propose that. If a `git remote` points at GitLab (`gitlab.com` or a self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:
 
@@ -44,41 +46,26 @@ Default posture: these skills were designed for GitHub. If a `git remote` points
 - **Local markdown** — issues live as files under `.scratch/<feature>/` in this repo (good for solo projects or repos without a remote)
 - **Other** (Jira, Linear, etc.) — ask the user to describe the workflow in one paragraph; the skill will record it as freeform prose
 
-If — and only if — the user picked **GitHub** or **GitLab**, ask one follow-up:
+Record the choice in `docs/agents/issue-tracker.md`. The GitHub and GitLab templates carry a "PRs as a request surface" flag, defaulted **off** — leave it off and don't raise it; a user who wants external PRs in the triage queue can flip the flag in the file later.
 
-> Explainer: Open-source repos often receive feature requests as pull requests, not just issues — a PR is an issue with attached code. If you turn this on, `/triage` pulls *external* PRs into the same queue and runs them through the same labels and states as issues (collaborators' in-flight PRs are left alone). Leave it off if PRs aren't a request surface for you.
+**Section B — Triage label vocabulary.** Skip this section entirely if the `triage` skill isn't installed (exploration told you) — an uninstalled skill needs no labels.
 
-- **PRs as a request surface** — yes / no (default: no). Record the answer in `docs/agents/issue-tracker.md`. For local-markdown and other trackers, skip this question — there are no PRs.
+If it is installed, ask exactly one question:
 
-**Section B — Triage label vocabulary.**
+> Do you want to keep the default triage labels? (recommended: **yes**)
 
-> Explainer: When the `triage` skill processes an incoming issue, it moves it through a state machine — needs evaluation, waiting on reporter, ready for an AFK agent to pick up, ready for a human, or won't fix. To do that, it needs to apply labels (or the equivalent in your issue tracker) that match strings *you've actually configured*. If your repo already uses different label names (e.g. `bug:triage` instead of `needs-triage`), map them here so the skill applies the right ones instead of creating duplicates.
+The defaults are the five canonical roles, each label string equal to its name: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. On **yes**, write them as-is. Only if the user says no — usually because their tracker already uses other names (e.g. `bug:triage` for `needs-triage`) — collect the overrides so `triage` applies existing labels instead of creating duplicates.
 
-The five canonical roles:
+**Section C — Domain docs.** Default to **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. This fits almost every repo; write it without asking.
 
-- `needs-triage` — maintainer needs to evaluate
-- `needs-info` — waiting on reporter
-- `ready-for-agent` — fully specified, AFK-ready (an agent can pick it up with no human context)
-- `ready-for-human` — needs human implementation
-- `wontfix` — will not be actioned
-
-Default: each role's string equals its name. Ask the user if they want to override any. If their issue tracker has no existing labels, the defaults are fine.
-
-**Section C — Domain docs.**
-
-> Explainer: Some skills (`improve-codebase-architecture`, `diagnosing-bugs`, `tdd`) read a `CONTEXT.md` file to learn the project's domain language, and `docs/adr/` for past architectural decisions. They need to know whether the repo has one global context or multiple (e.g. a monorepo with separate frontend/backend contexts) so they look in the right place.
-
-Confirm the layout:
-
-- **Single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. Most repos are this.
-- **Multi-context** — `CONTEXT-MAP.md` at the root pointing to per-context `CONTEXT.md` files (typically a monorepo).
+Offer **multi-context** — a root `CONTEXT-MAP.md` pointing to per-context `CONTEXT.md` files — only when exploration found monorepo signals. Then confirm which layout they want.
 
 ### 3. Confirm and edit
 
 Show the user a draft of:
 
 - The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
-- The contents of `docs/agents/issue-tracker.md`, `docs/agents/triage-labels.md`, `docs/agents/domain.md`
+- The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed)
 
 Let them edit before writing.
 
@@ -99,9 +86,9 @@ The block:
 ```markdown
 ## Agent skills
 
-### Issue tracker
+### Ticket tracker
 
-[one-line summary of where issues are tracked, plus whether external PRs are a triage surface]. See `docs/agents/issue-tracker.md`.
+[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.
 
 ### Triage labels
 
@@ -112,12 +99,14 @@ The block:
 [one-line summary of layout — "single-context" or "multi-context"]. See `docs/agents/domain.md`.
 ```
 
-Then write the three docs files using the seed templates in this skill folder as a starting point:
+Include the `### Triage labels` sub-block, and write `docs/agents/triage-labels.md`, only when `triage` is installed and Section B ran. When it isn't, both are omitted.
+
+Then write the docs files using the seed templates in this skill folder as a starting point:
 
 - [issue-tracker-github.md](./issue-tracker-github.md) — GitHub issue tracker
 - [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) — GitLab issue tracker
 - [issue-tracker-local.md](./issue-tracker-local.md) — local-markdown issue tracker
-- [triage-labels.md](./triage-labels.md) — label mapping
+- [triage-labels.md](./triage-labels.md) — label mapping (only if `triage` is installed)
 - [domain.md](./domain.md) — domain doc consumer rules + layout
 
 For "other" issue trackers, write `docs/agents/issue-tracker.md` from scratch using the user's description.

package/template/.agents/skills/setup-matt-pocock-skills/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Setup Matt Pocock Skills"
+  short_description: "Configure a repo for the skills"
+policy:
+  allow_implicit_invocation: false

package/template/.agents/skills/setup-matt-pocock-skills/issue-tracker-github.md

@@ -1,6 +1,6 @@
-# Issue tracker: GitHub
+# Ticket tracker: GitHub
 
-Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
+Tickets and Specs for this repo live as GitHub Issues. Use the `gh` CLI for all operations.
 
 ## Conventions
 

package/template/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md

@@ -1,6 +1,6 @@
-# Issue tracker: GitLab
+# Ticket tracker: GitLab
 
-Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
+Tickets and Specs for this repo live as GitLab Issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
 
 ## Conventions
 

package/template/.agents/skills/setup-matt-pocock-skills/issue-tracker-local.md

@@ -1,12 +1,12 @@
-# Issue tracker: Local Markdown
+# Ticket tracker: Local Markdown
 
-Issues and PRDs for this repo live as markdown files in `.scratch/`.
+Tickets and Specs for this repo live as markdown files in `.scratch/`.
 
 ## Conventions
 
 - One feature per directory: `.scratch/<feature-slug>/`
-- The PRD is `.scratch/<feature-slug>/PRD.md`
-- Implementation issues are `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01`
+- The spec is `.scratch/<feature-slug>/spec.md`
+- Implementation tickets are one file per ticket at `.scratch/<feature-slug>/tickets/<NN>-<slug>.md`, numbered from `01` — never a single combined tickets file
 - Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
 - Comments and conversation history append to the bottom of the file under a `## Comments` heading
 
@@ -23,8 +23,8 @@ Read the file at the referenced path. The user will normally pass the path or th
 Used by `/wayfinder`. The **map** is a file with one **child** file per ticket.
 
 - **Map**: `.scratch/<effort>/map.md` — the Notes / Decisions-so-far / Fog body.
-- **Child ticket**: `.scratch/<effort>/issues/NN-<slug>.md`, numbered from `01`, with the question in the body. A `Type:` line records the ticket type (`research`/`prototype`/`grilling`/`task`); a `Status:` line records `claimed`/`resolved`.
+- **Child ticket**: `.scratch/<effort>/tickets/NN-<slug>.md`, numbered from `01`, with the question in the body. A `Type:` line records the ticket type (`research`/`prototype`/`grilling`/`task`); a `Status:` line records `claimed`/`resolved`.
 - **Blocking**: a `Blocked by: NN, NN` line near the top. A ticket is unblocked when every file it lists is `resolved`.
-- **Frontier**: scan `.scratch/<effort>/issues/` for files that are open, unblocked, and unclaimed; first by number wins.
+- **Frontier**: scan `.scratch/<effort>/tickets/` for files that are open, unblocked, and unclaimed; first by number wins.
 - **Claim**: set `Status: claimed` and save before any work.
 - **Resolve**: append the answer under an `## Answer` heading, set `Status: resolved`, then append a context pointer (gist + link) to the map's Decisions-so-far in `map.md`.

package/template/.agents/skills/setup-matt-pocock-skills/triage-labels.md

@@ -6,8 +6,8 @@ The skills speak in terms of five canonical triage roles. This file maps those r
 | -------------------------- | -------------------- | ---------------------------------------- |
 | `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
 | `needs-info`               | `needs-info`         | Waiting on reporter for more information |
-| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
-| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
+| `ready-for-agent`          | `ready-for-agent`    | Unblocked vertical-slice ticket whose required gates passed |
+| `ready-for-human`          | `ready-for-human`    | Spec, design, draft contract, or other item needing human judgment or access |
 | `wontfix`                  | `wontfix`            | Will not be actioned                     |
 
 When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.

package/template/.agents/skills/tdd/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "TDD"
+  short_description: "Test-driven red-green-refactor"

package/template/.agents/skills/teach/GLOSSARY-FORMAT.md

@@ -0,0 +1,35 @@
+# GLOSSARY.md Format
+
+`GLOSSARY.md` is the canonical language for this teaching workspace. All explainers, exercises, and learning records should adhere to its terminology. Building it is itself part of learning: compressing a concept into a tight definition is evidence the user understands it.
+
+## Structure
+
+```md
+# {Topic} Glossary
+
+{One or two sentence description of the topic this glossary covers.}
+
+## Terms
+
+**Hypertrophy**:
+Muscle growth driven by mechanical tension and metabolic stress over repeated training sessions.
+_Avoid_: Bulking, getting big
+
+**Progressive overload**:
+Systematically increasing the demand on a muscle over time — via load, volume, or intensity.
+_Avoid_: Pushing harder, levelling up
+
+**RPE (Rate of Perceived Exertion)**:
+A 1–10 self-rating of how hard a set felt, where 10 is failure and 8 means two reps left in the tank.
+_Avoid_: Effort score, intensity rating
+```
+
+## Rules
+
+- **Add a term only when the user understands it.** The glossary is a record of compressed knowledge, not a dictionary the user reads to learn. If the user has just been introduced to a concept, wait until they can use it correctly before promoting it here.
+- **Be opinionated.** When several words exist for the same concept, pick the best one and list the rest as aliases to avoid. This is how language compresses.
+- **Keep definitions tight.** One or two sentences. Define what the term IS, not what it does or how to do it.
+- **Use the glossary's own terms inside definitions.** Once a term is in the glossary, prefer it everywhere — including inside other definitions. This is what makes complex terms easier to grasp later.
+- **Group under subheadings** when natural clusters emerge (e.g. `## Anatomy`, `## Programming`). A flat list is fine when terms cohere.
+- **Flag ambiguities explicitly.** If a term is used loosely in the wider field, note the resolution: "In this workspace, 'set' always means a working set — warm-ups are tracked separately."
+- **Revise as understanding deepens.** A definition the user wrote in week one may be wrong by week six. Update in place; do not leave stale entries.