@use-the-fork/spindle 0.0.1 → 0.1.0

package/build/Assets/Blueprints/skills/ref-php-laravel-saloon-api-integrations/references/data-transfer-objects.md

@@ -0,0 +1,104 @@
+# Data Transfer Objects
+
+A data transfer object (DTO) gives typed fields to API data.
+Define response mapping on the request, or on the connector when all requests share that mapping.
+Retrieve the DTO from the response.
+
+## Define the DTO and mapping
+
+```php
+final class Product
+{
+    public function __construct(
+        public readonly int $id,
+        public readonly string $name,
+        public readonly int $priceCents,
+    ) {}
+}
+```
+
+```php
+use Saloon\Http\Request;
+use Saloon\Http\Response;
+
+class GetProductRequest extends Request
+{
+    // method, constructor, and endpoint ...
+
+    public function createDtoFromResponse(Response $response): Product
+    {
+        $data = $response->json();
+
+        return new Product(
+            id: $data['id'],
+            name: $data['name'],
+            priceCents: $data['price_cents'],
+        );
+    }
+}
+```
+
+## Retrieve the DTO
+
+```php
+$response = $connector->send(new GetProductRequest(42));
+
+$product = $response->dtoOrFail(); // throws LogicException if the response failed
+$product = $response->dto();       // always maps, even for failed responses
+```
+
+Use `dtoOrFail()` for success-only DTOs. It prevents mapping an error body into `Product`.
+Use `dto()` only when the mapping handles error payloads.
+"Failed" follows `hasRequestFailed()`; see [Handling failures](handling-failures.md).
+
+`dto()` returns `mixed`. For static analysis, annotate it with `/** @var Product $product */`, or call the typed method directly: `$request->createDtoFromResponse($response)`.
+
+## DTOs in requests
+
+Accept a DTO in a request constructor to build the request body.
+
+```php
+use Saloon\Contracts\Body\HasBody;
+use Saloon\Enums\Method;
+use Saloon\Traits\Body\HasJsonBody;
+
+class UpdateProductRequest extends Request implements HasBody
+{
+    use HasJsonBody;
+
+    protected Method $method = Method::PUT;
+
+    public function __construct(protected readonly Product $product) {}
+
+    public function resolveEndpoint(): string
+    {
+        return '/products/' . $this->product->id;
+    }
+
+    protected function defaultBody(): array
+    {
+        return [
+            'name' => $this->product->name,
+            'price_cents' => $this->product->priceCents,
+        ];
+    }
+}
+```
+
+## Keep the source response
+
+Implement `WithResponse` and use `HasResponse` to attach the original response to the DTO.
+
+```php
+use Saloon\Contracts\DataObjects\WithResponse;
+use Saloon\Traits\Responses\HasResponse;
+
+final class Product implements WithResponse
+{
+    use HasResponse;
+
+    // constructor ...
+}
+
+$product->getResponse()->status();
+```

package/build/Assets/Blueprints/skills/ref-php-laravel-saloon-api-integrations/references/handling-failures.md

@@ -0,0 +1,95 @@
+# Handling Failures
+
+Saloon separates two kinds of failure:
+
+- **HTTP failure**: the API returned 4xx/5xx. Synchronous `send()` returns a `Response` with `failed()` set to `true`, unless throwing is enabled.
+- **Connection failure**: the API returned no response, such as a DNS error or connection timeout. Saloon throws `FatalRequestException`.
+
+```php
+$response = $connector->send(new CreateProductRequest('Widget', 999));
+
+if ($response->failed()) {
+    $errors = $response->json('errors'); // e.g. a 422 validation payload
+}
+```
+
+## Throwing on HTTP failures
+
+Call `throw()` to throw on a failed response. It returns the response on success.
+
+```php
+$product = $connector->send(new GetProductRequest(42))->throw()->json();
+```
+
+For every request on a connector, add `AlwaysThrowOnErrors`.
+
+```php
+use Saloon\Traits\Plugins\AlwaysThrowOnErrors;
+
+class InventoryConnector extends Connector
+{
+    use AlwaysThrowOnErrors;
+}
+```
+
+## Exception hierarchy
+
+Catch the most specific type the application needs. `RequestException` exposes the response through `getResponse()`.
+
+```
+SaloonException
+├── FatalRequestException            connection errors, no response
+└── RequestException                 HTTP 4xx/5xx
+    ├── ClientException              4xx
+    │   ├── UnauthorizedException (401), PaymentRequiredException (402)
+    │   ├── ForbiddenException (403), NotFoundException (404)
+    │   ├── MethodNotAllowedException (405), RequestTimeOutException (408)
+    │   └── UnprocessableEntityException (422), TooManyRequestsException (429)
+    └── ServerException              5xx
+        └── InternalServerErrorException (500), ServiceUnavailableException (503), GatewayTimeoutException (504)
+```
+
+```php
+use Saloon\Exceptions\Request\Statuses\UnprocessableEntityException;
+
+try {
+    $connector->send(new CreateProductRequest('', 0))->throw();
+} catch (UnprocessableEntityException $e) {
+    $errors = $e->getResponse()->json('errors');
+}
+```
+
+## Async and pools
+
+Promises from `sendAsync()` and pools reject on HTTP and connection failures.
+Handle both in `otherwise` or the pool's exception handler. Calling `throw()` is unnecessary.
+For callback examples, read [Sending requests](sending-requests.md) or [Concurrency and pools](concurrency-and-pools.md).
+
+## Custom failure detection
+
+Some APIs return 200 with an error in the body. Override `hasRequestFailed()` on the connector or request; returning `null` falls back to the status-code check.
+
+```php
+use Saloon\Http\Response;
+
+public function hasRequestFailed(Response $response): ?bool
+{
+    return $response->json('status') === 'error';
+}
+```
+
+This changes `failed()`, `throw()`, `dtoOrFail()`, and `AlwaysThrowOnErrors`.
+
+## Custom exception
+
+Override `getRequestException()` on the connector or request to throw an application exception. A request's override wins over the connector's.
+
+```php
+use Saloon\Http\Response;
+use Throwable;
+
+public function getRequestException(Response $response, ?Throwable $senderException): ?Throwable
+{
+    return new InventoryApiException($response->json('message', 'Inventory API error'), $response->status(), $senderException);
+}
+```

package/build/Assets/Blueprints/skills/ref-php-laravel-saloon-api-integrations/references/requests.md

@@ -0,0 +1,111 @@
+# Requests
+
+Create a request class for each endpoint operation.
+Saloon appends the endpoint to the connector's base URL.
+Keep request classes beside their connector.
+
+## Minimal request
+
+Extend `Saloon\Http\Request`, set `$method`, and implement `resolveEndpoint()`.
+
+```php
+use Saloon\Enums\Method;
+use Saloon\Http\Request;
+
+class ListProductsRequest extends Request
+{
+    protected Method $method = Method::GET;
+
+    public function resolveEndpoint(): string
+    {
+        return '/products';
+    }
+}
+```
+
+With the Laravel plugin installed, `php artisan saloon:request` scaffolds one.
+
+## Constructor arguments
+
+Pass identifiers and inputs through the constructor.
+
+```php
+class GetProductRequest extends Request
+{
+    protected Method $method = Method::GET;
+
+    public function __construct(protected readonly int $id) {}
+
+    public function resolveEndpoint(): string
+    {
+        return '/products/' . $this->id;
+    }
+}
+```
+
+## Query parameters
+
+Override `defaultQuery()`, or add to an instance with `$request->query()->add('page', 2)`.
+
+```php
+protected function defaultQuery(): array
+{
+    return [
+        'sort' => 'name',
+        'filter[active]' => 'true',
+    ];
+}
+```
+
+Saloon builds query strings with `http_build_query`.
+
+## Headers
+
+Override `defaultHeaders()`; these merge with the connector's headers. Instance changes use `$request->headers()->add(...)`.
+
+```php
+protected function defaultHeaders(): array
+{
+    return ['Accept' => 'application/json'];
+}
+```
+
+## JSON body
+
+Implement `HasBody`, use `HasJsonBody`, and override `defaultBody()`.
+
+```php
+use Saloon\Contracts\Body\HasBody;
+use Saloon\Enums\Method;
+use Saloon\Http\Request;
+use Saloon\Traits\Body\HasJsonBody;
+
+class CreateProductRequest extends Request implements HasBody
+{
+    use HasJsonBody;
+
+    protected Method $method = Method::POST;
+
+    public function __construct(
+        protected readonly string $name,
+        protected readonly int $priceCents,
+    ) {}
+
+    public function resolveEndpoint(): string
+    {
+        return '/products';
+    }
+
+    protected function defaultBody(): array
+    {
+        return [
+            'name' => $this->name,
+            'price_cents' => $this->priceCents,
+        ];
+    }
+}
+```
+
+## Timeouts
+
+For endpoint-specific timeouts, use the trait and properties shown in [Timeouts](connectors.md#timeouts) on the request.

package/build/Assets/Blueprints/skills/ref-php-laravel-saloon-api-integrations/references/responses.md

@@ -0,0 +1,56 @@
+# Responses
+
+Synchronous `send()` returns a `Saloon\Http\Response`.
+For HTTP and connection failure behavior, read [Handling failures](handling-failures.md).
+
+## Reading a response
+
+```php
+$response = $connector->send(new GetProductRequest(42));
+
+$response->status();             // 200
+$response->header('Content-Type');
+$response->body();               // raw string
+$response->json();               // decoded array
+$response->json('data.name');    // nested key (dot notation)
+$response->json('missing', 'x'); // default when absent
+$response->object();             // stdClass
+$response->collect('data');      // Laravel Collection (requires illuminate/collections)
+```
+
+## Useful methods
+
+| Method                                                                             | Purpose                                                                    |
+| ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
+| `status()`, `headers()`, `header($name)`                                           | Status code and headers                                                    |
+| `body()`, `json()` / `array()`, `object()`, `collect()`                            | Body as string, array, object, or Collection                               |
+| `stream()`, `saveBodyToFile($path)`                                                | Large or binary bodies                                                     |
+| `xmlReader()`, `dom()`                                                             | XML (needs `saloonphp/xml-wrangler`) or HTML (needs `symfony/dom-crawler`) |
+| `ok()`, `successful()`, `redirect()`, `failed()`, `clientError()`, `serverError()` | Status checks; `failed()` is customizable                                  |
+| `throw()`                                                                          | Throw if the response is considered failed                                 |
+| `dto()`, `dtoOrFail()`                                                             | Convert to a DTO; see [Data Transfer Objects](data-transfer-objects.md)    |
+| `getPendingRequest()`, `getPsrRequest()`, `getPsrResponse()`                       | The built request and the raw PSR-7 messages                               |
+
+## Custom response class
+
+Extend `Response` to add API-specific helpers.
+Register the class on the connector for all requests, or on a request for that request only.
+
+```php
+use Saloon\Http\Response;
+
+class InventoryResponse extends Response
+{
+    public function nextPage(): ?int
+    {
+        return $this->json('meta.next_page');
+    }
+}
+
+class InventoryConnector extends Connector
+{
+    protected ?string $response = InventoryResponse::class;
+}
+```
+
+Override `resolveResponseClass(): string` instead of the property when the class must be chosen dynamically.

package/build/Assets/Blueprints/skills/ref-php-laravel-saloon-api-integrations/references/sending-requests.md

@@ -0,0 +1,42 @@
+# Sending Requests
+
+Pass a request to its connector to send it.
+
+## Synchronous
+
+```php
+$connector = new InventoryConnector($baseUrl, $token);
+
+$response = $connector->send(new ListProductsRequest);
+
+$products = $response->json('data');
+```
+
+`send()` returns a `Saloon\Http\Response`. A 4xx/5xx status does **not** throw by default; see [Handling Failures](handling-failures.md).
+
+## Asynchronous
+
+`sendAsync()` returns a Guzzle `PromiseInterface`.
+Successful responses reach `then`. HTTP and connection failures reject the promise and reach `otherwise`.
+
+```php
+use Saloon\Exceptions\Request\FatalRequestException;
+use Saloon\Exceptions\Request\RequestException;
+use Saloon\Http\Response;
+
+$promise = $connector->sendAsync(new ListProductsRequest);
+
+$promise
+    ->then(function (Response $response) {
+        // handle success
+    })
+    ->otherwise(function (FatalRequestException|RequestException $exception) {
+        // RequestException: the API returned 4xx/5xx; use $exception->getResponse()
+        // FatalRequestException: no response, e.g. connection failure
+    });
+
+$promise->wait(); // resolve the promise
+```
+
+For concurrent batches, read [Concurrency and pools](concurrency-and-pools.md).
+For failure classification and custom exceptions, read [Handling failures](handling-failures.md).

package/build/Assets/Blueprints/skills/ref-php-laravel-saloon-api-integrations/references/testing.md

@@ -0,0 +1,119 @@
+# Testing
+
+Keep test runs offline. Use `MockClient` with fake responses or existing fixtures.
+Assert the outgoing request and the application's handling of success and failure responses, including 401, 422, and 500.
+
+## Block network access
+
+Block requests without a mock client and prevent automatic recording when a fixture is missing.
+For Pest, add this setup to `tests/Pest.php`.
+For PHPUnit, run it in the base `TestCase::setUp()` after `parent::setUp()`.
+
+```php
+use Saloon\Config;
+use Saloon\MockConfig;
+
+Config::preventStrayRequests();
+MockConfig::throwOnMissingFixtures();
+```
+
+`preventStrayRequests()` alone does not stop fixture recording when a mock client is attached.
+`throwOnMissingFixtures()` throws `FixtureMissingException` instead of recording a missing fixture.
+
+## Fake responses
+
+`MockResponse::make(body, status, headers)` builds a response. An array body is encoded as JSON.
+
+```php
+use Saloon\Http\Faking\MockClient;
+use Saloon\Http\Faking\MockResponse;
+
+$mockClient = new MockClient([
+    ListProductsRequest::class => MockResponse::make(['data' => [['id' => 1, 'name' => 'Widget']]], 200),
+    CreateProductRequest::class => MockResponse::make(['errors' => ['name' => ['Required']]], 422),
+]);
+```
+
+Mock keys can also be:
+
+- URL patterns with `*` wildcards: `'inventory.example.com/api/v1/products/*' => MockResponse::make(...)`.
+- An unkeyed list, returned in sequence regardless of the request: `[MockResponse::make('first'), MockResponse::make('second')]`.
+- A closure: `fn (PendingRequest $pendingRequest) => MockResponse::make(...)`.
+
+## Attach the mock
+
+**Local**: attach the mock to a connector or request you control.
+
+```php
+$connector = new InventoryConnector('https://inventory.example.com/api/v1', 'test-token');
+$connector->withMockClient($mockClient);
+```
+
+**Global**: mock requests sent deep inside application code.
+
+```php
+$mockClient = MockClient::global([
+    ListProductsRequest::class => MockResponse::make(['data' => []], 200),
+]);
+```
+
+Without the Laravel plugin, reset global mocks between tests with `MockClient::destroyGlobal()` in `beforeEach` or `setUp`.
+The Laravel plugin resets them automatically.
+
+## Assertions
+
+```php
+use Saloon\Http\Request;
+use Saloon\Http\Response;
+
+$mockClient->assertSent(ListProductsRequest::class);
+$mockClient->assertNotSent(CreateProductRequest::class);
+$mockClient->assertSentCount(1);
+$mockClient->assertSentCount(1, ListProductsRequest::class);
+```
+
+These are separate assertion examples. Use `assertNothingSent()` when no request should leave the application.
+For a connector configured with `test-token`, assert the actual bearer header rather than a masked placeholder:
+
+```php
+$token = 'test-token';
+
+$mockClient->assertSent(function (Request $request, Response $response) use ($token) {
+    return $request instanceof CreateProductRequest
+        && $request->body()->all() === ['name' => 'Widget', 'price_cents' => 999]
+        && $response->getPsrRequest()->getHeaderLine('Authorization') === ('Bearer ' . $token);
+});
+```
+
+## Complete example: a failure path
+
+```php
+it('reports validation errors when the inventory API rejects a product', function () {
+    $mockClient = MockClient::global([
+        CreateProductRequest::class => MockResponse::make(['errors' => ['name' => ['Required']]], 422),
+    ]);
+
+    $result = app(ProductSync::class)->create(name: '', priceCents: 0);
+
+    expect($result->errors)->toBe(['name' => ['Required']]);
+
+    $mockClient->assertSent(fn (Request $request) => $request instanceof CreateProductRequest
+        && $request->body()->get('name') === '');
+});
+```
+
+A synchronous 422 returns a response rather than throwing.
+If the code under test calls `throw()` or uses `AlwaysThrowOnErrors`, assert the exception instead.
+See [Handling failures](handling-failures.md).
+
+## Fixtures
+
+`MockResponse::fixture('inventory/products')` replays `tests/Fixtures/Saloon/inventory/products.json` when the file exists.
+With the setup above, a missing file fails the test without contacting the API.
+Change the directory with `MockConfig::setFixturePath('tests/fixtures/http')`.
+
+Record fixtures only through an explicitly authorized process outside normal test runs and CI.
+That process must omit `throwOnMissingFixtures()` and use credentials restricted to recording.
+Without that guard, a missing fixture triggers a real API call and saves the response.
+Use lowercase fixture paths. Redact secrets before committing fixture files.
+To refresh a fixture, delete only its file in the recording process.

package/build/Assets/Blueprints/skills/{author-design → sdd-author-design}/SKILL.md

@@ -1,17 +1,25 @@
 ---
-name: author-design
+name: sdd-author-design
 description: "Use when a user asks to author a design for a feature, workflow, or behavior that has important product decisions to settle."
 disable-model-invocation: true
 user-invocable: true
 metadata:
   spindle:
-    version: 1.1.1
+    version: 1.1.2
 ---
 
 # Authoring a Design
 
 Help the user clarify what they want before turning an idea into a design. A design is optional; when one is created, it is authored and approved before its spec, and tickets follow the spec. Use this for product and project decisions, not as a gate for a clear, bounded task or a user who wants a spec without a design.
 
+## Required skills
+
+Before drafting or editing, read:
+
+- **REQUIRED:** `asd-ste100`
+
+Apply the clarity rules from the `asd-ste100` skill. Include a before/after table only when the user requests one.
+
 ## Process
 
 1. **Check the brief.** Identify the user's goal, why it matters, what success means, and which important decisions remain open. In an existing project, inspect relevant code and docs first; do not ask for facts the project already answers. If the user asks for a design and the request is specific with no consequential decision open, proceed to the design without unnecessary questioning. **Complete when** the brief is actionable or a concrete unresolved decision is identified.
@@ -21,7 +29,7 @@ Help the user clarify what they want before turning an idea into a design. A des
 3. **Compare approaches.** Present two or three viable approaches grounded in the project and clarified goal, explain their main trade-offs, recommend one, and ask the user to choose. If only one approach fits, explain why alternatives do not. Wait for the choice before drafting. **Complete when** the user has selected an approach or delegated the choice.
 
 4. **Create or select the SDD feature workspace.**
-   - For a new feature, choose a concise title and author identity, then run `spindle sdd create --title "<feature title>" --author "<author>" --with-design`. Use the returned workspace and spec paths; `design.md` is beside `spec.md`. The command creates both template files, but fill and approve the design before filling the spec.
+   - For a new feature, choose a concise title and author identity, then run `{{ computed.spindle_package_manager }} spindle sdd create --title "<feature title>" --author "<author>" --with-design`. Use the returned workspace and spec paths; `design.md` is beside `spec.md`. The command creates both template files, but fill and approve the design before filling the spec.
    - For an existing numbered SDD feature workspace, reuse it. If `design.md` already exists, preserve it and edit it only as requested. If it is missing, first confirm `spec.md` is still the untouched template; then copy the design template from the Spindle installation's `build/Assets/Templates/sdd/design.md` into that workspace without overwriting existing files. In a source checkout, use `src/Assets/Templates/sdd/design.md`.
    - If the existing spec has substantive content, stop before adding or revising a design: that would put design after spec. Explain the conflict and ask whether the user wants to continue as an explicit exception or keep the feature spec-only.
    - Do not create a dated feature directory or a second SDD workspace for the same feature.
@@ -30,7 +38,7 @@ Help the user clarify what they want before turning an idea into a design. A des
 
 5. **Write the design.** Use the existing `design.md` scaffold, replacing its `[PLACEHOLDER]` fields with the selected intent, success criteria, scope and constraints, considered approaches and trade-offs, chosen direction, and assumptions or open decisions. Write success criteria as observable outcomes that show the design achieves its intent; include measurable targets where practical without inventing precision. Leave detailed requirements and acceptance scenarios to the subsequent spec. Preserve unresolved decisions explicitly. **Complete when** the design represents the conversation, states observable success outcomes, and distinguishes user decisions from recommendations.
 
-6. **Get approval.** Share the design path and its content for user approval or correction. Do not begin spec drafting until the user approves the design. If the user opts out of brainstorming or asks for a spec without design, respect that choice; do not create a design as a gate. After approval, ask the user to invoke `/to-spec` to create the spec in the same feature workspace; do not invoke it automatically. **Complete when** the design is approved, corrected for another review, or the user has chosen the spec-only path.
+6. **Get approval.** Share the design path and its content for user approval or correction. Do not begin spec drafting until the user approves the design. If the user opts out of brainstorming or asks for a spec without design, respect that choice; do not create a design as a gate. After approval, ask the user to invoke `/sdd-to-spec` to create the spec in the same feature workspace; do not invoke it automatically. **Complete when** the design is approved, corrected for another review, or the user has chosen the spec-only path.
 
 ## Keep the conversation useful
 

package/build/Assets/Blueprints/skills/{grill-design → sdd-grill-design}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: grill-design
+name: sdd-grill-design
 description: "Challenge and refine an existing design through an interview, updating the design and relevant domain documentation."
 argument-hint: "[design.md path or feature directory]"
 disable-model-invocation: true

package/build/Assets/Blueprints/skills/{implement-spec → sdd-implement-spec}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: implement-spec
-description: "Implement the result of /to-spec and /to-tickets in code."
+name: sdd-implement-spec
+description: "Implement the result of /sdd-to-spec and /sdd-to-tickets in code."
 disable-model-invocation: true
 metadata:
   spindle:
@@ -9,7 +9,7 @@ metadata:
 
 # Implement a Spec
 
-Deliver the supplied spec and all associated tickets in the existing checkout. Require configured tracker guidance; if absent, request `/setup-project`.
+Deliver the supplied spec and all associated tickets in the existing checkout. Require configured tracker guidance; if absent, request `/spindle-project-setup`.
 
 ## Required Skills
 

package/build/Assets/Blueprints/skills/{to-spec → sdd-to-spec}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: to-spec
+name: sdd-to-spec
 description: "Turn an agreed feature request or approved design into a spec in its SDD feature workspace, then publish it to the configured ticket tracker."
 argument-hint: "[design file path]"
 disable-model-invocation: true
@@ -30,7 +30,7 @@ An optional design file path may be supplied. Read the entire file before drafti
 
 2. **Select or create the SDD feature workspace.**
    - Reuse the existing numbered `.scratch/<feature-id>-<slug>/` workspace when the selected design or spec belongs to one. Use its `spec.md`; do not create a second workspace for the same feature.
-   - Otherwise, derive a concise feature title from the agreed request and choose an author identity for this run. Run `spindle sdd create --title "<feature title>" --author "<author>"`; add `--with-design` when the selected design must be retained in the new workspace. If using a design outside `.scratch`, copy that approved source into the newly created `design.md`, replacing only the fresh template. Save the returned `spec` path and continue in that workspace.
+   - Otherwise, derive a concise feature title from the agreed request and choose an author identity for this run. Run `{{ computed.spindle_package_manager }} spindle sdd create --title "<feature title>" --author "<author>"`; add `--with-design` when the selected design must be retained in the new workspace. If using a design outside `.scratch`, copy that approved source into the newly created `design.md`, replacing only the fresh template. Save the returned `spec` path and continue in that workspace.
    - When the workspace has `design.md`, read it fully and use it as the requirements source. If it still contains `[PLACEHOLDER]` markers or has not been approved, pause and ask the user to finish or approve the design before drafting the spec.
    - The selected SDD workspace's pre-created `spec.md` is the output. Replace its template content with the completed spec; do not create a dated folder or a second spec.
 
@@ -48,6 +48,6 @@ An optional design file path may be supplied. Read the entire file before drafti
    - Give each important user story a concise, observable acceptance outcome or example scenario focused on user-visible behavior. Leave implementation-slice completion criteria to tickets; no fixed scenario format is required.
    - Use domain glossary terms. Do not include file paths or code snippets unless a prototype captures a decision more clearly than prose.
    - Publish the completed spec according to the configured ticket-tracker guidance. Ask before publishing if the destination or status is unclear.
-   - Once the spec is published, ask the user to invoke `/to-tickets` for planning. Do not invoke it automatically or start implementation here.
+   - Once the spec is published, ask the user to invoke `/sdd-to-tickets` for planning. Do not invoke it automatically or start implementation here.
 
    **Complete when:** the spec is published at the feature workspace's `spec.md` path, tracker publication is resolved, and no blocking ambiguity is hidden.

package/build/Assets/Blueprints/skills/{to-tickets → sdd-to-tickets}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: to-tickets
+name: sdd-to-tickets
 description: "Break an approved feature spec into tracer-bullet tickets with explicit blockers, then publish them to the configured ticket tracker."
 argument-hint: "[spec path or tracker reference]"
 disable-model-invocation: true
@@ -20,7 +20,7 @@ An optional argument is one spec path or tracker reference. Read the full spec a
    - Use the spec's existing feature workspace. In Spindle's local tracker, this is a numbered `.scratch/<feature-id>-<slug>/` directory containing `spec.md`, `sdd.json`, and `tickets/`. Never create a dated folder or a second workspace for the same feature.
    - If `design.md` exists in the feature workspace, read it and confirm it was completed and approved before the spec. If the spec is not approved or a present design is unfinished, stop and resolve that before ticket planning.
    - A design is optional. Do not require or create one when the approved spec was intentionally written without a design.
-   - For local SDD tracker work, use the feature's `spec.md` path with `spindle sdd` ticket commands. Otherwise follow the configured tracker's documented conventions.
+   - For local SDD tracker work, use the feature's `spec.md` path with `{{ computed.spindle_package_manager }} spindle sdd` ticket commands. Otherwise follow the configured tracker's documented conventions.
 
    **Complete when:** one approved spec and its tracker destination are identified; any existing design precedes it and is approved.
 
@@ -41,7 +41,7 @@ An optional argument is one spec path or tracker reference. Read the full spec a
    **Complete when:** the user approves the ticket breakdown and blocker relationships.
 
 5. **Publish the tickets.**
-   - For a local Spindle SDD tracker, create each ticket in dependency order with `spindle sdd ticket create --spec <absolute-spec-path>`. Supply its title, reporter, category (`bug` or `enhancement`), and author. Fill the generated ticket's Requirements and Acceptance Criteria using the tracker guidance. After creation, use `spindle sdd ticket update --spec <absolute-spec-path> --ticket <id> --blocked-by <blocker-ids...> --author <author>` to record each dependency; omit `--blocked-by` when there are no blockers. Keep the approved spec and feature ledger authoritative.
+   - For a local Spindle SDD tracker, create each ticket in dependency order with `{{ computed.spindle_package_manager }} spindle sdd ticket create --spec <absolute-spec-path>`. Supply its title, reporter, category (`bug` or `enhancement`), and author. Fill the generated ticket's Requirements and Acceptance Criteria using the tracker guidance. After creation, use `{{ computed.spindle_package_manager }} spindle sdd ticket update --spec <absolute-spec-path> --ticket <id> --blocked-by <blocker-ids...> --author <author>` to record each dependency; omit `--blocked-by` when there are no blockers. Keep the approved spec and feature ledger authoritative.
    - For an external ticket tracker, create one ticket per approved ticket in dependency order and use native blocking relationships when available; otherwise record blockers in each ticket. If the source was an existing ticket, create sub-tickets as required by the tracker.
    - Apply a status only when the project documents it or the user requests it. Do not close or modify a parent ticket.
    - Publishing ends here. Tell the user that delivery begins through the project's documented implementation workflow; do not start implementation.