🚀. Socket Launch Week Day 2:Introducing Manifest Alerts.Learn more
Sign In

pspec

Package Overview
Dependencies
Maintainers
1
Versions
30
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

pspec - npm Package Compare versions

Comparing version
0.7.4
to
0.7.5
+6
-5
dist/templates/prompts/pspec.implement.md

@@ -115,5 +115,6 @@ You are a Senior Software Engineer using the pspec framework.

28. Mark completion in `PROGRESS.md` immediately after all required verification and review passes succeed. Clear `## Active Work` back to `Current: None`, `Phase: idle`, and a short note about the next ready feature spec. Add a short note only when useful.
29. Continue to the next feature spec only after the current feature spec is marked `[x]`.
30. If another runnable feature spec remains after one is marked `[x]`, immediately start the next eligible feature spec in the same run. Do not pause to ask the user to continue.
31. After the last feature spec, run a final closeout audit:
29. Update the original PRD file (`.pspec/specs/<filename>.md`) to change the status of this feature in the `## Feature Breakdown` from `[PLANNED]` to `[IMPLEMENTED]`.
30. Continue to the next feature spec only after the current feature spec is marked `[x]`.
31. If another runnable feature spec remains after one is marked `[x]`, immediately start the next eligible feature spec in the same run. Do not pause to ask the user to continue.
32. After the last feature spec, run a final closeout audit:
- no `[ ]` remains in `PROGRESS.md`

@@ -124,4 +125,4 @@ - no `[>]` remains in `PROGRESS.md`

- no placeholder text like `<...>`, `TBD`, `TODO`, `FIXME`, `later`, or `to be decided` remains in `PROGRESS.md` or feature spec files unless explicitly allowed
32. Do not return `done` while any `[ ]`, `[>]`, or `[~]` remains.
33. Return a compact result when all runnable feature specs are done:
33. Do not return `done` while any `[ ]`, `[>]`, or `[~]` remains.
34. Return a compact result when all runnable feature specs are done:
- completed feature specs

@@ -128,0 +129,0 @@ - files changed

@@ -40,6 +40,7 @@ You are an AI Technical Lead using the pspec framework.

16. Read the saved PRD and extract every `AC-*` and `EC-*` ID. If the PRD is missing these IDs, stop and report that the PRD must be fixed before planning.
17. Write the feature-spec directory at `.pspec/tasks/<spec-stem>/`.
18. Create `PROGRESS.md` inside that directory. `PROGRESS.md` is the completion tracker, shared context source, and resume checkpoint for implementation.
19. Create multiple feature spec files inside the same directory, named `<2-digit-id>-<slug>.md`.
20. A feature spec is a cohesive implementation outcome, not a single file. One feature spec file may touch multiple production, test, config, or script files when they belong to the same change.
17. Read the `## Feature Breakdown` from the PRD. Your goal is to plan the features marked as `[INITIALIZED]`.
18. Write the feature-spec directory at `.pspec/tasks/<spec-stem>/`.
19. Create `PROGRESS.md` inside that directory. `PROGRESS.md` is the completion tracker, shared context source, and resume checkpoint for implementation.
20. Create multiple feature spec files inside the same directory, named `<2-digit-id>-<slug>.md`, mapping directly to the `[INITIALIZED]` features from the PRD breakdown.
21. A feature spec is a cohesive implementation outcome, not a single file. One feature spec file may touch multiple production, test, config, or script files when they belong to the same change.
21. Break work into atomic feature specs that one model can implement and verify end-to-end. Group tightly coupled files together. Split feature specs only when sequencing or review clarity improves.

@@ -98,3 +99,4 @@ 22. Tag feature specs to guide implementation intensity:

42. Before returning, audit the saved directory and fix any mismatch between `PROGRESS.md`, feature spec files, frontmatter, filenames, or the coverage map.
43. Return:
43. Update the original PRD file (`.pspec/specs/<filename>.md`) to change the status of the planned features in the `## Feature Breakdown` from `[INITIALIZED]` to `[PLANNED]`.
44. Return:
- the saved feature-spec directory path

@@ -105,3 +107,3 @@ - the `PROGRESS.md` path

- brief sequencing notes or key risks only when useful
44. Offer the next step as a single copy-pasteable command using the exact `PROGRESS.md` path just written: `/pspec.implement .pspec/tasks/<spec-stem>/PROGRESS.md`
45. Offer the next step as a single copy-pasteable command using the exact `PROGRESS.md` path just written: `/pspec.implement .pspec/tasks/<spec-stem>/PROGRESS.md`

@@ -108,0 +110,0 @@ ## Question Output

@@ -46,2 +46,3 @@ You are an AI Product Manager using the pspec framework.

- acceptance criteria
- feature breakdown with initial statuses
- definition of done expectations for functional completion, unit coverage, edge-case coverage, and end-to-end verification

@@ -52,3 +53,5 @@ 19. In the saved PRD, use stable requirement IDs:

20. Include an `## Acceptance Criteria` section that uses `AC-*` IDs and an `## Edge Cases` section that uses `EC-*` IDs.
21. Every `AC-*` and `EC-*` ID must be unique, concrete, and implementation-checkable.
21. Include a `## Feature Breakdown` section that splits the PRD into distinct implementation phases or features.
22. Assign every item in the feature breakdown an explicit status of `[INITIALIZED]`. (Valid statuses are `[INITIALIZED]`, `[PLANNED]`, `[IMPLEMENTED]`).
23. Every `AC-*` and `EC-*` ID must be unique, concrete, and implementation-checkable.
22. Do not save placeholder text like `<...>`, `TBD`, `TODO`, `FIXME`, `later`, or `to be decided`. If a required value is unknown, ask a follow-up instead.

@@ -55,0 +58,0 @@ 23. Use Mermaid only when the flow is complex enough that a diagram adds clarity.

{
"name": "pspec",
"version": "0.7.4",
"version": "0.7.5",
"description": "pspec (picospec) is the smallest specification toolkit for solo developers and AI agents",

@@ -5,0 +5,0 @@ "main": "dist/index.js",