npm - create-yss-spec - Versions diffs - 2.1.10 → 2.1.11 - Mend

create-yss-spec 2.1.10 → 2.1.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (914) hide show

package/template/.cursor/skills/improve-codebase-architecture/HTML-REPORT.md ADDED Viewed

@@ -0,0 +1,123 @@
+# HTML Report Format
+The architectural review is rendered as a single self-contained HTML file in the OS temp directory. Tailwind and Mermaid both come from CDNs. Mermaid handles graph-shaped diagrams reliably; hand-built divs and inline SVG handle the more editorial visuals (mass diagrams, cross-sections). Mix the two — don't lean on Mermaid for everything, it'll start to look generic.
+## Scaffold
+```html
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <title>Architecture review — {{repo name}}</title>
+    <script src="https://cdn.tailwindcss.com"></script>
+    <script type="module">
+      import mermaid from "https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs";
+      mermaid.initialize({ startOnLoad: true, theme: "neutral", securityLevel: "loose" });
+    </script>
+    <style>
+      /* small custom layer for things Tailwind doesn't cover cleanly:
+         dashed seam lines, hand-drawn-feeling arrow heads, etc. */
+      .seam { stroke-dasharray: 4 4; }
+      .leak { stroke: #dc2626; }
+      .deep { background: linear-gradient(135deg, #0f172a, #1e293b); }
+    </style>
+  </head>
+  <body class="bg-stone-50 text-slate-900 font-sans">
+    <main class="max-w-5xl mx-auto px-6 py-12 space-y-12">
+      <header>...</header>
+      <section id="candidates" class="space-y-10">...</section>
+      <section id="top-recommendation">...</section>
+    </main>
+  </body>
+</html>
+```
+## Header
+Repo name, date, and a compact legend: solid box = module, dashed line = seam, red arrow = leakage, thick dark box = deep module. No introduction paragraph — straight into the candidates.
+## Candidate card
+The diagrams carry the weight. Prose is sparse, plain, and uses the glossary terms (from the `/codebase-design` skill) without ceremony.
+Each candidate is one `<article>`:
+- **Title** — short, names the deepening (e.g. "Collapse the Order intake pipeline").
+- **Badge row** — recommendation strength (`Strong` = emerald, `Worth exploring` = amber, `Speculative` = slate), plus a tag for the dependency category (`in-process`, `local-substitutable`, `ports & adapters`, `mock`).
+- **Files** — monospaced list, `font-mono text-sm`.
+- **Before / After diagram** — the centrepiece. Two columns, side by side. See patterns below.
+- **Problem** — one sentence. What hurts.
+- **Solution** — one sentence. What changes.
+- **Wins** — bullets, ≤6 words each. e.g. "Tests hit one interface", "Pricing logic stops leaking", "Delete 4 shallow wrappers".
+- **ADR callout** (if applicable) — one line in an amber-tinted box.
+No paragraphs of explanation. If the diagram needs a paragraph to be understood, redraw the diagram.
+## Diagram patterns
+Pick the pattern that fits the candidate. Mix them. Don't make every diagram look the same — variety is part of the point.
+### Mermaid graph (the workhorse for dependencies / call flow)
+Use a Mermaid `flowchart` or `graph` when the point is "X calls Y calls Z, and look at the mess." Wrap it in a Tailwind-styled card so it doesn't feel parachuted in. Style with classDef to colour leakage edges red and the deep module dark. Sequence diagrams work well for "before: 6 round-trips; after: 1."
+```html
+<div class="rounded-lg border border-slate-200 bg-white p-4">
+  <pre class="mermaid">
+    flowchart LR
+      A[OrderHandler] --> B[OrderValidator]
+      B --> C[OrderRepo]
+      C -.leak.-> D[PricingClient]
+      classDef leak stroke:#dc2626,stroke-width:2px;
+      class C,D leak
+  </pre>
+</div>
+```
+### Hand-built boxes-and-arrows (when Mermaid's layout fights you)
+Modules as `<div>`s with borders and labels. Arrows as inline SVG `<line>` or `<path>` elements positioned absolutely over a relative container. Reach for this when you want the "after" diagram to feel like one thick-bordered deep module with greyed-out internals — Mermaid won't render that with the right weight.
+### Cross-section (good for layered shallowness)
+Stack horizontal bands (`h-12 border-l-4`) to show layers a call passes through. Before: 6 thin layers each doing nothing. After: 1 thick band labelled with the consolidated responsibility.
+### Mass diagram (good for "interface as wide as implementation")
+Two rectangles per module — one for interface surface area, one for implementation. Before: interface rectangle is nearly as tall as the implementation rectangle (shallow). After: interface rectangle is short, implementation rectangle is tall (deep).
+### Call-graph collapse
+Before: a tree of function calls rendered as nested boxes. After: the same tree collapsed into one box, with the now-internal calls shown faded inside it.
+## Style guidance
+- Lean editorial, not corporate-dashboard. Generous whitespace. Serif optional for headings (`font-serif` works well with stone/slate).
+- Colour sparingly: one accent (emerald or indigo) plus red for leakage and amber for warnings.
+- Keep diagrams ~320px tall so before/after sits comfortably side by side without scrolling.
+- Use `text-xs uppercase tracking-wider` for module labels inside diagrams — they should read as schematic, not as UI.
+- The only scripts are the Tailwind CDN and the Mermaid ESM import. The report is otherwise static — no app code, no interactivity beyond Mermaid's own rendering.
+## Top recommendation section
+One larger card. Candidate name, one sentence on why, anchor link to its card. That's it.
+## Tone
+Plain English, concise — but the architectural nouns and verbs come straight from the `/codebase-design` skill. Concision is not an excuse to drift.
+**Use exactly:** module, interface, implementation, depth, deep, shallow, seam, adapter, leverage, locality.
+**Never substitute:** component, service, unit (for module) · API, signature (for interface) · boundary (for seam) · layer, wrapper (for module, when you mean module).
+**Phrasings that fit the style:**
+- "Order intake module is shallow — interface nearly matches the implementation."
+- "Pricing leaks across the seam."
+- "Deepen: one interface, one place to test."
+- "Two adapters justify the seam: HTTP in prod, in-memory in tests."
+**Wins bullets** name the gain in glossary terms: *"locality: bugs concentrate in one module"*, *"leverage: one interface, N call sites"*, *"interface shrinks; implementation absorbs the wrappers"*. Don't write *"easier to maintain"* or *"cleaner code"* — those terms aren't in the glossary and don't earn their place.
+No hedging, no throat-clearing, no "it's worth noting that…". If a sentence could be a bullet, make it a bullet. If a bullet could be cut, cut it. If a term isn't in the `/codebase-design` glossary, reach for one that is before inventing a new one.

package/template/.cursor/skills/improve-codebase-architecture/SKILL.md ADDED Viewed

@@ -0,0 +1,71 @@
+---
+name: improve-codebase-architecture
+description: Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
+disable-model-invocation: true
+---
+# Improve Codebase Architecture
+Surface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.
+This command is _informed_ by the project's domain model and built on a shared design vocabulary:
+- Run the `/codebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use these terms exactly in every suggestion — don't drift into "component," "service," "API," or "boundary."
+- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
+## Process
+### 1. Explore
+**Scope before you scan — YAGNI.** Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide *where* to look before you look:
+- If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.
+- Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.
+Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
+Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
+- Where does understanding one concept require bouncing between many small modules?
+- Where are modules **shallow** — interface nearly as complex as the implementation?
+- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?
+- Where do tightly-coupled modules leak across their seams?
+- Which parts of the codebase are untested, or hard to test through their current interface?
+Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.
+### 2. Present candidates as an HTML report
+Write a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from `$TMPDIR`, falling back to `/tmp` (or `%TEMP%` on Windows), and write to `<tmpdir>/architecture-review-<timestamp>.html` so each run gets a fresh file. Open it for the user — `xdg-open <path>` on Linux, `open <path>` on macOS, `start <path>` on Windows — and tell them the absolute path.
+The report uses **Tailwind via CDN** for layout and styling, and **Mermaid via CDN** for diagrams where a graph/flow/sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before/after visualisation**. Be visual.
+For each candidate, render a card with:
+- **Files** — which files/modules are involved
+- **Problem** — why the current architecture is causing friction
+- **Solution** — plain English description of what would change
+- **Benefits** — explained in terms of locality and leverage, and how tests would improve
+- **Before / After diagram** — side-by-side, custom-drawn, illustrating the shallowness and the deepening
+- **Recommendation strength** — one of `Strong`, `Worth exploring`, `Speculative`, rendered as a badge
+End the report with a **Top recommendation** section: which candidate you'd tackle first and why.
+**Use CONTEXT.md vocabulary for the domain, and the `/codebase-design` vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
+**ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
+See [HTML-REPORT.md](HTML-REPORT.md) for the full HTML scaffold, diagram patterns, and styling guidance.
+Do NOT propose interfaces yet. After the file is written, ask the user: "Which of these would you like to explore?"
+### 3. Grilling loop
+Once the user picks a candidate, run the `/grilling` skill to walk the decision tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.
+Side effects happen inline as decisions crystallize — run the `/domain-modeling` skill to keep the domain model current as you go:
+- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md`. Create the file lazily if it doesn't exist.
+- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
+- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones.
+- **Want to explore alternative interfaces for the deepened module?** Run the `/codebase-design` skill and use its design-it-twice parallel sub-agent pattern.

package/template/.cursor/skills/improve-codebase-architecture/agents/openai.yaml ADDED Viewed

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Improve Codebase Architecture"
+  short_description: "Find and grill architecture improvements"
+policy:
+  allow_implicit_invocation: false

package/template/.cursor/skills/lombok/SKILL.md ADDED Viewed

@@ -0,0 +1,351 @@
+---
+name: lombok
+description: |
+  Project Lombok for reducing Java boilerplate. Covers annotations for getters,
+  setters, constructors, builders, logging, and more. Based on production
+  patterns from castellino and gestionale-presenze projects.
+  USE WHEN: user mentions "lombok", "@Data", "@Builder", "@Slf4j", asks about
+  "boilerplate reduction", "getters/setters", "@RequiredArgsConstructor", "@Value"
+  DO NOT USE FOR: Java language features - use `java` skill instead
+  DO NOT USE FOR: MapStruct integration - use `mapstruct` skill
+  DO NOT USE FOR: Spring annotations - use `backend-spring-boot` skill
+allowed-tools: Read, Grep, Glob, Write, Edit
+---
+# Project Lombok
+> **Deep Knowledge**: Use `mcp__documentation__fetch_docs` with technology: `lombok` for comprehensive documentation.
+## YSS 阶段 7 执行结果
+- 消费批准后的 Slice Contract/work unit，只在允许路径内调整 POJO 样板和注解处理器配置。
+- 受控生成必须记录对象类型、选用/排除注解、实体关系和敏感字段风险、编译/测试实际结果。
+- 按 `yss-router` 的统一 Execution Result 返回 changed files、证据、偏离和新增影响；`@Data` 实体风险、处理器配置缺失或越界路径返回 `violation`。
+## Maven Configuration
+```xml
+<dependency>
+    <groupId>org.projectlombok</groupId>
+    <artifactId>lombok</artifactId>
+    <version>1.18.34</version>
+    <optional>true</optional>
+</dependency>
+<!-- For MapStruct compatibility -->
+<dependency>
+    <groupId>org.projectlombok</groupId>
+    <artifactId>lombok-mapstruct-binding</artifactId>
+    <version>0.2.0</version>
+</dependency>
+```
+## Common Annotations
+### @Data (All-in-One)
+```java
+@Data
+public class User {
+    private Long id;
+    private String name;
+    private String email;
+}
+// Generates:
+// - @Getter for all fields
+// - @Setter for all non-final fields
+// - @ToString
+// - @EqualsAndHashCode
+// - @RequiredArgsConstructor
+```
+### @Getter / @Setter
+```java
+public class User {
+    @Getter @Setter
+    private String name;
+    @Getter // Read-only
+    private final String email;
+    @Setter(AccessLevel.PROTECTED)
+    private String internalId;
+}
+```
+### @NoArgsConstructor / @AllArgsConstructor / @RequiredArgsConstructor
+```java
+@NoArgsConstructor
+@AllArgsConstructor
+public class User {
+    private Long id;
+    private String name;
+}
+@RequiredArgsConstructor
+public class UserService {
+    private final UserRepository userRepository; // Included in constructor
+    private final UserMapper userMapper;         // Included in constructor
+    private String cacheName;                    // NOT included
+}
+```
+### @Builder
+```java
+@Data
+@Builder
+public class User {
+    private Long id;
+    private String name;
+    private String email;
+    @Builder.Default
+    private UserStatus status = UserStatus.ACTIVE;
+}
+// Usage
+User user = User.builder()
+    .name("John")
+    .email("john@example.com")
+    .build();
+// With toBuilder for updates
+User updated = user.toBuilder()
+    .name("Jane")
+    .build();
+```
+### @Value (Immutable)
+```java
+@Value
+public class UserResponse {
+    Long id;
+    String name;
+    String email;
+    LocalDateTime createdAt;
+}
+// Generates:
+// - All fields are private final
+// - @AllArgsConstructor
+// - @Getter (no setters)
+// - @ToString
+// - @EqualsAndHashCode
+```
+## Entity Pattern
+```java
+@Entity
+@Table(name = "users")
+@Getter
+@Setter
+@NoArgsConstructor(access = AccessLevel.PROTECTED)
+@AllArgsConstructor(access = AccessLevel.PRIVATE)
+@Builder
+@EntityListeners(AuditingEntityListener.class)
+public class User {
+    @Id
+    @GeneratedValue(strategy = GenerationType.IDENTITY)
+    private Long id;
+    @Column(nullable = false)
+    private String name;
+    @Column(unique = true, nullable = false)
+    private String email;
+    @Enumerated(EnumType.STRING)
+    @Builder.Default
+    private UserStatus status = UserStatus.ACTIVE;
+    @CreatedDate
+    @Column(updatable = false)
+    private LocalDateTime createdAt;
+    @LastModifiedDate
+    private LocalDateTime updatedAt;
+    @ManyToOne(fetch = FetchType.LAZY)
+    @JoinColumn(name = "department_id")
+    private Department department;
+}
+```
+JPA/DDD entities must not default to `@Data`; choose equality and `toString` deliberately from stable identity and exclude lazy, relationship, and sensitive fields.
+## Service Pattern with Constructor Injection
+```java
+@Service
+@RequiredArgsConstructor
+@Slf4j
+public class UserServiceImpl implements UserService {
+    private final UserRepository userRepository;
+    private final UserMapper userMapper;
+    private final PasswordEncoder passwordEncoder;
+    @Override
+    public UserResponse create(CreateUserRequest dto) {
+        log.info("Creating user: {}", dto.getEmail());
+        User user = userMapper.toEntity(dto);
+        return userMapper.toResponse(userRepository.save(user));
+    }
+}
+```
+## Logging
+```java
+@Slf4j  // SLF4J logger
+public class UserService {
+    public void process() {
+        log.info("Processing...");
+        log.debug("Debug info: {}", data);
+        log.error("Error occurred", exception);
+    }
+}
+@Log4j2  // Log4j2 logger
+@CommonsLog  // Apache Commons Logging
+@JBossLog  // JBoss Logging
+```
+## DTO Pattern
+```java
+// Request DTO
+@Data
+public class CreateUserRequest {
+    @NotBlank
+    private String name;
+    @Email
+    private String email;
+    @Size(min = 8)
+    private String password;
+}
+// Response DTO (immutable)
+@Value
+@Builder
+public class UserResponse {
+    Long id;
+    String name;
+    String email;
+    UserStatus status;
+    LocalDateTime createdAt;
+}
+```
+## @Cleanup
+```java
+public void readFile(String path) throws IOException {
+    @Cleanup InputStream in = new FileInputStream(path);
+    // in.close() called automatically
+}
+```
+## @SneakyThrows
+```java
+@SneakyThrows  // Wraps checked exception
+public String readConfig() {
+    return Files.readString(Path.of("config.json"));
+}
+```
+## @Synchronized
+```java
+public class Counter {
+    @Synchronized
+    public void increment() {
+        // Thread-safe
+    }
+}
+```
+## @With (Immutable Updates)
+```java
+@Value
+@With
+public class Point {
+    int x;
+    int y;
+}
+Point p1 = new Point(1, 2);
+Point p2 = p1.withX(5);  // Point(5, 2)
+```
+## Key Annotations
+| Annotation | Purpose |
+|------------|---------|
+| `@Data` | Getter, Setter, ToString, Equals, Constructor |
+| `@Value` | Immutable class |
+| `@Builder` | Builder pattern |
+| `@RequiredArgsConstructor` | Constructor for final fields |
+| `@Slf4j` | Logger field |
+| `@ToString.Exclude` | Exclude from toString |
+| `@EqualsAndHashCode.Exclude` | Exclude from equals/hashCode |
+---
+## When NOT to Use This Skill
+| Scenario | Use Instead |
+|----------|-------------|
+| Java core language | `java` skill |
+| MapStruct mapping | `mapstruct` skill |
+| Spring annotations | `backend-spring-boot` skill |
+| JPA entities complex logic | Manual implementation |
+| Public API design | Explicit methods for clarity |
+---
+## Anti-Patterns
+| Anti-Pattern | Why It's Bad | Correct Approach |
+|--------------|--------------|------------------|
+| @Data on JPA entities | toString/equals issues | Use @Getter/@Setter selectively |
+| Not excluding lazy relations | LazyInitializationException | Use @ToString.Exclude |
+| @EqualsAndHashCode on entities | Proxy issues | Use @EqualsAndHashCode(onlyExplicitlyIncluded = true) |
+| @SneakyThrows everywhere | Hides exceptions | Use proper exception handling |
+| @Builder without @Default | Null fields | Add @Builder.Default |
+| @Value with mutable fields | Breaks immutability | Use only immutable types |
+| Mixing @Data and manual methods | Confusing API | Be consistent |
+| Not configuring in lombok.config | Inconsistent behavior | Use lombok.config file |
+---
+## Quick Troubleshooting
+| Issue | Cause | Solution |
+|-------|-------|----------|
+| "Cannot find symbol" for getters | IDE not processing | Enable annotation processing |
+| LazyInitializationException | toString on lazy relation | Add @ToString.Exclude |
+| MapStruct not working | Wrong processor order | Lombok before MapStruct |
+| Builder missing fields | No @Builder.Default | Add defaults or check config |
+| StackOverflowError in equals | Circular reference | Exclude relation fields |
+| IDE shows errors but compiles | IDE cache | Invalidate caches/restart |
+| @Slf4j logger not found | SLF4J not in classpath | Add SLF4J dependency |
+| Generated code not visible | delombok needed | Run delombok task |
+---
+## Reference Documentation
+- [Lombok Documentation](https://projectlombok.org/features/)
+- [Stable Features](https://projectlombok.org/features/all)
+- [Configuration](https://projectlombok.org/features/configuration)
+> **Deep Knowledge**: Use `mcp__documentation__fetch_docs` with technology: `lombok` for comprehensive documentation.

package/template/.cursor/skills/loop-me/SKILL.md ADDED Viewed

@@ -0,0 +1,32 @@
+---
+name: loop-me
+description: Grill me about specs for the workflows I want to build, within this workspace.
+disable-model-invocation: true
+argument-hint: "A workflow to design, or nothing to go find one"
+---
+Run a stateful `/grilling` session whose only output is **workflow** specs. Use the grilling discipline — relentless, one question at a time, a recommended answer attached to each — aimed at the vocabulary and goal below. Create, edit, and delete specs as the grilling resolves things.
+## The loop lens
+A **loop** is a recurring pattern in the user's life: their career, their week, their morning, a single repeated activity. Picturing a life as loops within loops reveals how predictable its activities really are — which is what makes them worth **delegating**. Use the lens to find loops worth specifying, and propose ones the user hasn't noticed.
+A **workflow** is the spec of one loop, made real. You run a workflow on a loop — the loop is its running instantiation. Workflows live in `workflows/*.md` and are the source of truth.
+## Vocabulary
+A shared language, reached for only when a workflow calls for it — never a checklist. **Mandate nothing structural**: a workflow needs no AI, no checkpoint, and no schedule unless the grilling shows it does.
+- **Trigger** — what fires each run: an **event** (a new email, a new issue) or a **schedule** (every morning). Event-triggering is usually the more efficient.
+- **Checkpoint** — a human-in-the-loop point where the user is asked to verify or decide. Some workflows have none and run autonomously; some use no AI at all.
+- **Push right** — defer the checkpoint as far as it will go. Do maximal work before involving the human, so they are asked once, late, with everything prepared.
+- **Brief** — what a checkpoint presents: a tight, decision-ready summary — what was produced, why, and a link down to the asset itself — never the raw output. The user reads a brief, not a draft. Speed of review is imperative.
+## Definition of done
+A workflow spec is done when an implementer agent could build it without asking a single question. Grill until then; nothing is done while a question remains.
+## The workspace
+- `workflows/*.md` — one spec per workflow.
+- `NOTES.md` — raw notes on the user's world: the tools they use, the channels they process, and their own terminology for both. When it is empty or thin, interview them about their world before specifying anything. Sharpen fuzzy terms into canonical ones as they surface, and record them here.

package/template/.cursor/skills/loop-me/agents/openai.yaml ADDED Viewed

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Loop Me"
+  short_description: "Spec the workflows you want to build"
+policy:
+  allow_implicit_invocation: false

package/template/.cursor/skills/maintaining-skills/SKILL.md ADDED Viewed

@@ -0,0 +1,25 @@
+---
+name: maintaining-skills
+description: Use when creating, modifying, validating, or retiring reusable Agent skills.
+---
+# Maintaining Skills
+Create skills that add useful, non-obvious guidance without constraining unrelated work.
+## Working Contract
+1. Inspect the skill's callers, ownership, projections, and validation policy before editing. Preserve user intent, authorization boundaries, supported runtimes, and existing metadata unless the requested change requires otherwise.
+2. Assume the Agent already has general reasoning and tool competence. Record only domain knowledge, decision criteria, fragile invariants, or repeatable operations that materially improve outcomes. Do not turn one example or past failure into a universal rule.
+3. Keep discovery precise: use a lowercase hyphenated name and a concise description that states the capability and when it applies. Avoid catchalls that attract unrelated requests.
+4. Keep `SKILL.md` as short as the task permits. Put conditional detail in `references/`, deterministic repeated operations in `scripts/`, and files intended for generated output in `assets/`. Create only resources with a concrete use.
+5. Match specificity and validation to risk. Prefer outcome and decision criteria when several approaches are valid; use fixed steps or absolute rules only for correctness, safety, permissions, or genuinely fragile workflows.
+6. Follow the repository's declared maintenance and review policy. If none exists, run structural validation plus focused checks of the behavior or invariant changed. Use independent forward testing only when complexity or risk makes it meaningful; do not require a failing baseline for every ordinary edit.
+7. After changes, validate frontmatter, naming, references, scripts, projections, locks, and affected callers. Retire obsolete names and resources unless the repository explicitly requires compatibility.
+## Boundaries
+- Project rules belong in the project's authoritative instructions, not duplicated inside a generic skill.
+- Platform-private skills or absolute local paths are not portable shared dependencies.
+- A validation command proves only what it checks; structural validation alone does not prove good Agent decisions.
+- Do not create README files, changelogs, examples, routers, or placeholder directories without a concrete requirement.