skills I believed were committed

.pi/skills/propagate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: propagate
-description: "Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires."
+description: 'Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.'
 disable-model-invocation: true
 license: MIT
 metadata:
@@ -76,25 +76,27 @@ For deterministic obligations: field presence, enum membership, transition valid
 ### 2. Property-based tests
 
 For invariants and rule properties. Each expression-bearing invariant becomes a PBT property:
+
 - Generate a valid entity state using the generator spec
 - Apply a sequence of rules (following the transition graph when declared, or deriving valid sequences from rules alone)
 - Check the invariant holds at every step
 
 Use the project's PBT framework:
 
-| Language | Framework | Discovery |
-|----------|-----------|-----------|
-| TypeScript | fast-check | `package.json` |
-| Python | Hypothesis | `pyproject.toml` |
-| Rust | proptest | `Cargo.toml` |
-| Go | rapid | `go.mod` |
-| Elixir | StreamData | `mix.exs` |
+| Language   | Framework  | Discovery        |
+| ---------- | ---------- | ---------------- |
+| TypeScript | fast-check | `package.json`   |
+| Python     | Hypothesis | `pyproject.toml` |
+| Rust       | proptest   | `Cargo.toml`     |
+| Go         | rapid      | `go.mod`         |
+| Elixir     | StreamData | `mix.exs`        |
 
 Fall back to assertion-based tests if no PBT framework is present.
 
 ### 3. State machine tests
 
 For entities with status enums. When a transition graph is declared, walk every path through the graph. When no graph is declared, derive valid transitions from rules.
+
 - Verify transitions succeed via witnessing rules
 - Verify rejected transitions fail
 - Verify state-dependent fields are present or absent at each state per their `when` clauses
@@ -103,6 +105,7 @@ For entities with status enums. When a transition graph is declared, walk every
 State machine tests require an **action map**: a function per transition edge that takes the entity in the source state and produces it in the target state by calling the actual implementation code. Without this map, the test framework can describe valid paths through the graph but cannot execute them.
 
 To build the action map:
+
 1. For each edge in the transition graph, find the witnessing rule in the spec
 2. Find the code implementing that rule (the implementation bridge)
 3. Write a test action that sets up the preconditions (`requires` clauses), invokes the code, and returns the entity in the target state
@@ -117,6 +120,7 @@ You correlate spec constructs with implementation code, the same way the weed sk
 ### For surface tests
 
 Map surfaces to their implementation:
+
 - API surfaces map to endpoints (REST routes, GraphQL resolvers, gRPC services)
 - UI surfaces map to components or pages
 - Integration surfaces map to message handlers or SDK methods
@@ -126,6 +130,7 @@ Discover the mapping by reading the codebase. Look for naming patterns, route de
 ### For internal tests
 
 For each rule in the spec:
+
 1. Find the code implementing the rule (service method, event handler, state machine transition)
 2. Determine how to instantiate the entities involved (factories, builders, fixtures)
 3. Determine how to invoke the rule (API call, method call, event dispatch)
@@ -142,6 +147,7 @@ Before attempting temporal tests, check whether the component accepts an injecte
 When a rule emits a trigger that another spec's rule receives (e.g. the Arbiter emits `ClerkReceivesEvent`, the Clerk handles it), testing the chain requires multiple components wired together.
 
 Before generating cross-module tests:
+
 1. Trace the trigger emission graph from the plan output: which rules emit triggers, and which rules in other specs receive them
 2. Check whether the codebase has an existing integration test fixture that wires the participating components (a pipeline test, an end-to-end test helper, a test harness class)
 3. If a fixture exists, reuse it. Cross-module tests should compose existing wiring, not rebuild it