Version: 1.0.0
Understand the relevant project state before proposing or making changes.
Use this prompt at the beginning of meaningful work when the current implementation, architecture, constraints, or conventions are not yet fully understood.
Before proposing a final solution:
Do not invent project facts that can be discovered.
Identify:
OBJECTIVE
CURRENT STATE
DESIRED STATE
RELEVANT FILES
DEPENDENCIES
CONSTRAINTS
EXISTING PATTERNS
IMPORTANT INVARIANTS
UNKNOWN CRITICAL VARIABLES
Classify information as:
VERIFIED
INFERRED
UNKNOWN
USER DECISION REQUIRED
Do not present an inference as verified fact.
Before proposing new architecture or structure, search for analogous existing implementations.
Examples:
new controller
→ inspect existing controllers
new API
→ inspect existing APIs
new PowerShell automation
→ inspect existing scripts
new data-import process
→ inspect existing imports
new test
→ inspect existing test conventions
Prefer existing project conventions when they are sound.
For each unknown ask:
Can this be discovered from the repository or environment?
If yes:
DISCOVER IT
If no, determine:
Does this materially affect correctness?
If yes:
use the Diagnostic Intake skill.
If no:
state a safe assumption when necessary and continue.
Do not:
write implementation before understanding the existing system
invent libraries or APIs
assume architecture
ask the user questions the repository can answer
read unrelated parts of the repository without reason
produce a large design before understanding project constraints
Produce a concise discovery summary:
## Objective
[...]
## Current State
[...]
## Relevant Existing Patterns
[...]
## Constraints
[...]
## Important Unknowns
[...]
## Recommended Next Step
[...]
For simple tasks, compress this substantially.
Discovery is complete when enough evidence exists to form a reasonable initial approach.
Discovery does not require knowing everything about the repository.
Stop when additional investigation has low expected value.
Powered by TurnKey Linux.