pi-usereq 0.11.0 → 0.13.0

package/src/resources/prompts/references.md

@@ -1,64 +0,0 @@
----
-description: "Write a REFERENCES.md using the project's source code"
-argument-hint: "No arguments utilized by the prompt logic"
-usage: >
-  Select this prompt ONLY for docs-maintenance of %%DOC_PATH%%/REFERENCES.md, when that file is missing/outdated and you need to regenerate the repository navigation/index from evidence (entrypoints, modules, dependencies) and commit that doc change. Do NOT select if any other file (requirements, workflow, source, tests) must change; use /req-change, /req-new, /req-fix, /req-refactor, /req-cover, /req-implement, /req-create, or /req-recreate for those workflows. Do NOT select for read-only analysis/audits (use /req-analyze or /req-check).
----
-
-# Write a REFERENCES.md using the project's source code
-
-## Purpose
-Maintain a machine-usable reference index (`%%DOC_PATH%%/REFERENCES.md`) derived from repository evidence so downstream LLM Agents MUST quickly discover entrypoints, modules, dependencies, and other navigational anchors during SRS-driven work.
-
-## Scope
-In scope: generate/update only `%%DOC_PATH%%/REFERENCES.md` in English using the `references-generation` tool and commit that doc change. Out of scope: changes to requirements, workflow docs, source code, or tests.
-
-## Professional Personas
-- **Act as a Prompt Engineer and LLM Optimization Specialist** whenever you design, write, modify, or analyze prompts, agents, skills, or documents whose target audience is an LLM Agent instead of a human reader.
-- **Act as a Senior System Engineer** when analyzing source code and directory structures to understand the system's architecture and logic.
-- **Act as a Technical Writer** when producing the final reference index, ensuring clarity, technical precision, and structured formatting.
-
-## Absolute Rules, Non-Negotiable
-- **CRITICAL**: When instructions generate shell commands, they MUST generate only linear shell commands compatible with restrictive filtering systems, MUST verify and apply correct quoting, escaping, or option termination for literal arguments that could be parsed as options or flags, MUST use explicit option termination for `rg` and `grep` patterns beginning with `-` or `--`, MUST NOT rely on quoting or backslash escaping alone for those patterns, and MUST NOT use command substitution (`$()` or backticks), complex variable expansion, nested substitution, shell-derived helper composition, nested shell logic, or nested pipelines.
-- **CRITICAL**: NEVER write, modify, edit, or delete files outside of the active repository directory, except under `/tmp`.
-- You can read, write, or edit `%%DOC_PATH%%/REFERENCES.md`.
-- Treat static analysis as safe. Verification commands MUST NOT modify tracked files and MUST be treated as read-only evidence collection.
-- **CRITICAL**: Do not modify any project files except creating/updating `%%DOC_PATH%%/REFERENCES.md`.
-
-## Behavior
-- Do not perform unrelated edits.
-- If `.venv/bin/python` exists in the project root, use it for Python executions (eg, `PYTHONPATH=src .venv/bin/python -m <program name>`).
-- Non-Python tooling should use the project's standard commands.
-- Use filesystem/shell tools to read/write/delete files as needed (e.g., `cat`, `sed`, `perl -pi`, `printf > file`, `rm -f`, ...), but only to read project files and to write/update `%%DOC_PATH%%/REFERENCES.md`. Avoid in-place edits on any other path. Prefer read-only commands for analysis.
-
-
-## Execution Protocol (Global vs Local)
-You must manage the execution flow using two distinct methods:
--  **Global Roadmap** (*check-list*): 
-   - You MUST maintain a *check-list* internally with `3` Steps (one item per Step).
-   - **Do NOT** use the *task-list tool* for this high-level roadmap.
--  **Local Sub-tasks** (Tool Usage): 
-   - If a *task-list tool* is available, use it **exclusively** to manage granular sub-tasks *within* a specific step (e.g., in Step X: "1. Edit file A", "2. Edit file B"; or in Step Y: "1. Fix test K", "2. Fix test L").
-   - Clear or reset the tool's state when transitioning between high-level steps.
-
-## Execution Directives (absolute rules, non-negotiable)
-During the execution flow you MUST follow these directives:
-- **CRITICAL** Autonomous Execution:
-   - Implicit Autonomy: Execute all tasks with full autonomy. Do not request permission, confirmation, or feedback. Make executive decisions based on logic and technical best practices.
-   - Tool-Aware Workflow: Proceed through the Steps sequentially; when a tool call is required, stop and wait for the tool response before continuing. Never fabricate tool outputs or tool results. Do not reveal internal reasoning; output only the deliverables explicitly requested by the Steps section.
-   - Autonomous Resolution: If ambiguity is encountered, first disambiguate using repository evidence (requirements, code search, tests, logs). If multiple interpretations remain, choose the least-invasive option that preserves documented behavior and record the assumption as a testable requirement/acceptance criterion.
-   - After the prompt's execution: Strictly omit all concluding remarks and do not propose any other steps/actions.
-- **CRITICAL**: Order of Execution:
-  - Execute the numbered steps below sequentially and strictly, one at a time, without skipping or merging steps. Create and maintain a *check-list* internally while executing the Steps. Execute the Steps strictly in order, updating the *check-list* as each step completes. 
-- **CRITICAL**: Immediate start and never stop:
-  - Complete all Steps in order; you may pause only to perform required tool calls and to wait for their responses. Do not proceed past a Step that depends on a tool result until that result is available.
-  - Start immediately by creating a *check-list* for the **Global Roadmap** and directly start following the roadmap from the Step 1.
-
-
-## Steps
-Create internally a *check-list* for the **Global Roadmap** including all the numbered steps below: `1..3`, and start following the roadmap at the same time, executing the instructions of Step 1. If a tool call is required in Step 1, invoke it immediately; otherwise proceed to Step 1 without additional commentary. Do not add extra intent-adjustment checks unless explicitly listed in the Steps section.
-1. Update `%%DOC_PATH%%/REFERENCES.md` references file
-   -  Create/update `%%DOC_PATH%%/REFERENCES.md` with the `references-generation` tool.
-2. %%COMMIT%%
-3. Present results
-   - PRINT, in the response, the results for a human reader using clear, easily understandable sentences and readable Markdown formatting that highlight key findings, file paths, and concise evidence. Use the fixed report schema: ## **Outcome**, ## **Requirement Delta**, ## **Design Delta**, ## **Implementation Delta**, ## **Verification Delta**, ## **Evidence**, ## **Assumptions**, ## **Next Workflow**. Final line MUST be exactly: STATUS: OK or STATUS: ERROR.