Keep reusable coding instructions clear and easy to find.

Save the repeatable instruction

Save an instruction when its purpose repeats: implementing a bounded change, reviewing a diff or leaving a clear handoff. A whole conversation often contains decisions and assumptions that will be wrong next time. Extract the useful procedure instead of saving the transcript as a prompt.

Separate that procedure from the current repository, diff, acceptance criteria and next action. Supply those details when you reuse it. Remove credentials, private customer data, obsolete file paths and claims that a previous test run proves today’s change. Save project-specific instructions separately when they truly depend on that project.

Give a small collection a clear structure

Fictional example: a solo developer working on InvoiceAI extracts three instructions from scattered notes: “Implement one scoped change,” “Review a change with evidence” and “Update the project handoff.” The project, scenario and example instructions are illustrative; no execution or successful outcome is implied.

1. Name the job, not the conversation. Use a title you would search for later. Add a short description of when to use the instruction and what context it needs.
2. Use a few consistent labels. In StateConsole, the developer chooses Development, QA and Testing, and Project Management for these three entries, with tags such as implementation, review and handoff. A category describes the purpose; tags add terms useful to search. Avoid a new label for every minor variation.
3. Keep project associations intentional. Leave a general review instruction unassociated. Link a project-specific variant to the registered InvoiceAI project if that context matters. An association helps organize the saved entry; it does not supply repository context to a coding tool.

StateConsole can search saved titles, content, descriptions and tags and narrow the list with filters. Its tool labels organize entries; choosing a tool does not connect to that service. See the Prompt Library capabilities for the supported controls and local storage boundaries.

Three short instructions to adapt

These ordinary-text examples continue the fictional collection. Review and adapt them to your project and coding tool. Supply current context separately; StateConsole does not substitute variables or execute these instructions. They do not guarantee correct results.

Read the repository instructions and the current implementation first.
Use the goal, acceptance criteria and allowed scope I supply for this session.
Identify missing information before making a dependent change.
Implement only the agreed change using existing project patterns.
Run appropriate checks; report their actual results and anything untested.
Summarize changed files, remaining uncertainty and the next action.

Review the supplied diff against the current acceptance criteria.
Look for regressions, boundary cases and missing validation.
For each finding, explain the trigger, impact and supporting code location.
Distinguish code observations from checks you actually ran.
Report each check's scope and result; keep unrun checks visibly pending.
Do not infer that tests or deployment passed from a progress report.

Read the existing project report and the current changes first.
Preserve its supported format; do not replace facts with assumptions.
Record the current focus, next action and unresolved blockers or decisions.
Record only validation actually performed, with its scope, result and evidence location.
Keep unrun checks and remaining uncertainty explicit.
Update the report date when its content materially changes.
Do not claim that editing this report updates separate app tasks.

The handoff example is an instruction to update a report, not a complete parser-valid PROJECT_STATUS.md file. For StateConsole’s supported convention, use the complete validated template and setup guide. Reported progress still needs review against actual evidence; editing an app task does not rewrite the repository’s status file.

Before you reuse a saved prompt

• Confirm the instruction fits the current goal and allowed scope.
• Remove stale assumptions and sensitive details.
• Supply the current repository context and acceptance criteria.
• Review the text before copying it into your existing coding tool.
• Check the resulting work and record validation actually performed.

In the fictional example, the developer finds “Review a change with evidence,” checks its wording and uses Copy prompt. That action copies only the saved content, not its title or labels. The developer pastes it into their existing tool alongside the current diff and criteria. StateConsole does not send prompts to AI services or run tests; a response saying “done” is not independent proof that the work passed validation.

Keep useful prompts current

After using an instruction, note which wording was unclear or which context was missing. Edit the saved entry when a better instruction emerges, and delete obsolete duplicates. If you want to retain an older wording, keep an explicit separate note; do not rely on native version history in the Prompt Library.

Avoid treating a prompt as a project status report. Instructions describe how to approach work; the report records what actually happened and what remains uncertain. For recovering context across repositories, use the multiple-project workflow and update app tasks separately where appropriate.

Start with one instruction you already reuse

Extract its repeatable purpose, give it a clear name and try it with current context in your usual tools. You can start with a text file or notes. If you want a local Windows library for these saved instructions, explore StateConsole and check its current availability.

Purchasing is not available yet.