create-pathfinder 3.1.0 → 4.0.0

package/skills/feature/actions/load.md

@@ -1,45 +0,0 @@
-# Feature: Load
-
-Prepare one Feature for execution.
-
-1. Select the Feature the human named. Being invoked on it is the approval to
-   prepare it for execution, so its spec does not already have to say `Ready`.
-   Its spec is `NN-feature-name.md` in the spec source, and `NN` is its Feature
-   number.
-2. Read the Feature spec.
-3. Read only the files or context needed for the current work.
-4. Inspect the current Git state.
-5. Stop if a required human decision or explicit dependency blocks the work.
-6. Record the approval in the Feature spec's `## Status`, which holds the
-   durable lifecycle state:
-   - `Proposed` becomes `Ready`. That is the only value this action writes.
-   - `Ready` or `In Progress` is left exactly as it is. Reloading a Feature
-     mid-work is normal and must not rewrite its state.
-   - `Complete`, `Cancelled`, or `Superseded` blocks the load. Report it and
-     stop. Reopening terminal work is the human's decision.
-
-   Do this only once steps 1-5 found no blocker, and before the next step, so a
-   blocked load never leaves a promoted spec behind.
-7. Create or update `context/current-feature.md` — it does not ship, so the
-   first load writes it — with:
-   - Feature number, name, and spec path
-   - active delivery chunk
-   - Git state
-   - blocker, if any
-   - next action
-
-   Do not record the lifecycle status here. This file is transient workspace
-   state belonging to one session on one machine; the spec carries the durable
-   status.
-8. If `context/tracker.md` exists, name the tracked item for this Feature —
-   its key is that Feature number. Do nothing here if it does not.
-9. Present a short readiness summary.
-
-Do not implement the Feature. That is `/feature start`.
-
-Do not scan unrelated repository areas, load history or roadmap by default, or
-silently resolve `TBD` decisions.
-
-Do not rewrite the Feature's substance — its Goal, Context, Requirements, Out of
-Scope, Delivery Chunks, or Acceptance Criteria. `## Status` is the one field this
-action maintains.

package/skills/feature/actions/review.md

@@ -1,32 +0,0 @@
-# Feature: Review
-
-Review the actual diff and behavior, not only the developer's summary.
-
-## Check
-
-- acceptance criteria
-- regressions and important edge cases
-- security/privacy when relevant
-- accessibility, performance, compatibility, and operations when relevant
-- tests and verification
-- scope creep
-- documentation accuracy
-
-Use the project's quality priorities and existing standards where relevant.
-
-## Output
-
-Report:
-
-- `PASS`, or findings by severity
-- file/location and impact for each finding
-- what was actually verified
-- anything important that remains unverified
-
-Do not modify the implementation unless the human explicitly asks.
-
-Do not invent findings or treat passing tests as automatic acceptance.
-
-Do not write the Feature's `## Status`. Review is workflow activity, not
-lifecycle state, and a reviewed Feature stays `In Progress` until it is
-completed.

package/skills/feature/actions/start.md

@@ -1,33 +0,0 @@
-# Feature: Start
-
-Implement the active delivery chunk.
-
-1. Read only the context needed for the current work.
-2. Restate the pre-implementation summary the project's agent guide requires,
-   and wait for it to be answered where it names a human decision. Do not edit
-   any file before this step is done.
-3. Record the Feature spec's `## Status` as `In Progress`, before the first file
-   edit of the first chunk:
-   - `Ready` becomes `In Progress`. That is the only value this action writes.
-   - `In Progress` is left exactly as it is. Continuing a Feature across
-     sessions and chunks is normal and must not rewrite its state.
-   - Any other status stops the session. Report it. A Feature that was never
-     loaded is not approved for execution, and terminal work is the human's to
-     reopen.
-4. Follow the Feature and existing project conventions.
-5. Make the smallest complete change.
-6. Verify the behavior you changed.
-7. Keep the repository stable.
-8. Create or update `context/current-feature.md` with the current state and next
-   action. Do not record the lifecycle status there; the spec carries it.
-
-## Rules
-
-- Stay inside the approved scope.
-- Stop if implementation requires a human decision or material scope change.
-- Do not silently add dependencies or adopt prototype code.
-- Follow the project's approval and Git rules.
-- Do not decide that your own work is accepted.
-
-When the chunk is done, report what changed, what was verified, and anything
-unresolved.

package/skills/sync-tracker/SKILL.md

@@ -1,81 +0,0 @@
----
-name: sync-tracker
-description: Project Feature specs onto the configured work tracker.
----
-
-# Sync Tracker
-
-Sync project Features to the tracker configured in `context/tracker.md`.
-
-The repository is canonical.
-Tracker state never changes Pathfinder state.
-
-## Process
-
-1. If `context/tracker.md` does not exist, report that tracking is not
-   configured and stop. Do not propose configuring one.
-2. Read the tracker configuration. It names the tracker, how to reach it, the
-   spec source, and how a published item records its Pathfinder key. Stop if it
-   does not say how the key is recorded — without it a re-run cannot recognise
-   what it published last time, and would duplicate every item.
-3. Read the approved Feature specs from the spec source. A config that names
-   none means `context/features/`. If the named source does not exist, report
-   it and stop rather than falling back.
-4. Build one item per Feature: key, title, and body, composed only from the
-   spec.
-5. Show the proposed writes.
-6. Ask before the first write that leaves this repository. One approval covers
-   the run. A projection onto files inside the repository is an ordinary file
-   write and is not gated.
-7. Create or update only the items that changed.
-8. Report created, updated, and unchanged as counts of writes, not as final
-   tracker state.
-
-## Identity
-
-Each Feature has one stable key derived from the number in its spec filename.
-`to-specs` names every spec `NN-feature-name.md`, so
-`27-export-saved-searches.md` is `pathfinder:feature/27` in whichever directory
-it sits — moving specs orphans nothing.
-
-Read the number from the basename only. Never from the directory above it, the
-title inside it, or the order the specs happen to be read in.
-
-Match published items on that key alone. Titles are edited by humans.
-
-Skip a spec whose filename carries no number and report it by name. Do not
-assign one — numbering is `to-specs`' job, and inventing one here would publish
-an item that the next run cannot recognise.
-
-## Idempotency
-
-A second run over unchanged Features must issue **zero writes** — not writes
-that happen to be no-ops.
-
-- Compose the body as a pure function of the spec: fixed section order, no
-  timestamps, no counters, nothing derived from the run.
-- Compare normalized, never raw bytes. Strip trailing whitespace per line and
-  collapse trailing blank lines, on both sides. A tracker is not obliged to
-  return a body byte-for-byte, and a naive comparison then rewrites every item
-  forever while looking like working sync.
-- Where the config defines tags, compare them as sets, not ordered lists.
-- Edit in place. Never close, reopen, delete, or recreate an item.
-- Leave any item whose key is absent from this run completely alone.
-
-`3 items, 0 changes` is the expected second run and the most important line of
-output.
-
-## Rules
-
-- Do not decompose Features into tickets.
-- Do not derive dependency edges, ordering, or a graph from a spec. A Feature
-  may mention a dependency under `## Notes / Decisions` for a human to read;
-  it is prose, not structure, and this skill does not parse or orchestrate it.
-- Do not infer labels, tags, status, or other metadata.
-- Do not modify Feature specs from tracker state.
-- Do not read tracker state back into anything.
-- Do not delete tracker items automatically.
-- Do not rewrite unchanged items.
-- Local Markdown tracking is an ordinary repository/file write.
-- External trackers require human approval before writing.
-- Stop and report when the config, the specs, and the tracker disagree.