Documentation
Prompts, context, and background Git in PM7 Code
PM7 Code uses a layered prompt system. System, Group, Project, Session, and Interview prompts each have a specific job, a clear inheritance order, and visible CView labels so you can understand exactly what reached the agent.
Prompt context
The PM7 Code prompt flow
PM7 Code does not treat every prompt field as the same thing. Some prompts describe stable behavior, some describe the current project, and some are temporary instructions for one session or one interview turn.
User prompt
What you type now
Session prompt
Added after every user prompt
Interview prompt
Only when Interview-me is active
The practical result is simple: the agent starts with the most relevant inherited context, then receives what you typed, and then receives the Session prompt as a per-turn suffix.
Inheritance
Lower layers can override higher layers
Each layer inherits from the layer above it. When a lower layer enables an override, that value becomes the effective prompt for everything below it. If the override is enabled but left empty, that prompt is intentionally disabled for that branch.
| Prompt | Edited in | What it controls | Override rule |
|---|---|---|---|
| System | App / global settings | Stable behavior for the agent: how it should work, communicate, and respect PM7 Code conventions. | Can be overridden by Group, Project, and Session. An enabled empty override disables the System prompt for that lower layer. |
| Group | Group settings | Shared context for a customer, team, business area, or collection of related projects. | Can be overridden by Project and Session. A Project override becomes the Group prompt inherited by sessions in that Project. |
| Project | Project settings | Project-specific operating manual: goals, architecture, conventions, constraints, and important decisions. | Can be overridden by Session. This lets a single session suppress or replace project context temporarily. |
| Session | Session settings | Temporary instructions for the current topic. This prompt is added after every user prompt in that session. | Session can also override System, Group, and Project startup prompts for that one session. |
| Interview | Interview-me toggle | A temporary follow-up mode. It is only added when the Interview-me button is active. | Not inherited. It is a one-turn active suffix that turns off again after sending. |
Injection
When prompts are sent with your message
PM7 Code sends startup context only when a session still needs it. After that, normal turns stay lean: your user prompt plus the Session prompt, and optionally the Interview prompt.
First user prompt in a session
Startup context- 1Effective System prompt
- 2Effective Group prompt
- 3Effective Project prompt
- 4User prompt
- 5Session prompt
- 6Interview prompt, only when Interview-me is active
Next user prompts
Normal turn- 1User prompt
- 2Session prompt
- 3Interview prompt, only when Interview-me is active
Startup context is one-shot
System, Group, and Project are sent at the start of a new session or after settings changes mark startup context pending again.
Session prompt is per turn
The Session prompt is appended after every user prompt in that session. Use it for temporary but repeated instructions.
Interview is optional
Interview prompt is added only when Interview-me is active. It is meant for guided follow-up questions.
Settings
Where to edit and inspect prompts
Group, Project, and Session settings all have a Prompts tab. Each tab shows the prompt layers that make sense at that level.
Group settings
Use this for context shared across projects in the group. Group can override System.
Project settings
Use this for project-specific context. Project can override System and Group.
Session settings
Use this for one active topic. Session can override startup context and adds its own per-turn prompt.
Suggest prompt
The Suggest prompt button uses a hidden background request to propose a prompt for the exact field you are editing. It can use the current folder, inherited prompts, project files, git context, and recent session history. The result appears in a preview with Original prompt, User prompt, and Suggested prompt tabs before you replace or append anything.
CView makes prompt injection visible
When PM7 Code injects prompt context, CView shows a Prompt Context card. Each row is labeled with its kind and source: Inherited, Group override, Project override, Session override, Disabled, Session, or Active.
Projects sidebar
Filter by project, group, or session
The Projects search field supports qualifiers when you want to narrow the sidebar before applying normal text search. Use this when a word appears in many projects but you only want results from one exact project, group, or session.
Exact qualifier names
The value after project:, group:, or session: must match the full name exactly. Matching is not case-sensitive.
Quotes for spaces
Wrap names with spaces in quotes, such as project:"this is a test".
Text still narrows results
Any remaining words are used as the normal search text inside the qualified scope.
| Search | Result |
|---|---|
| project:pm7-code | Shows only the project named pm7-code. |
| project:pm7-code test | Shows only matching topics inside pm7-code, and searches for test inside that project. |
| project:"this is a test" | Shows only the project whose exact name is this is a test. |
| group:clients waiting | Shows matching projects and topics inside the group named clients. |
| session:"Release notes" deploy | Shows only the session named Release notes when it also matches deploy. |
| p:pm7-code g:internal s:debug css | Combines the short forms and then searches for css inside the narrowed result set. |
Short forms
project: can be written as p:, group: as g:, and session: as s:. Long and short forms behave the same way.
Detail search uses the same scope
When you open the session-detail search from the Projects search field, the same qualifiers restrict which sessions are searched.
Git Service
How the Git Service works
At the end of a coding turn, a Codex or Claude Code session can emit a fenced GitServiceRequest block. PM7 Code detects that block in the conversation, creates a visible Git Service card, and enqueues a background Git job in the main process.
The important detail is that the request is asynchronous from the user's point of view. Once PM7 Code has accepted the request, the agent session is free to continue with testing, inspection, or the next task while commit and push run separately.
Session finishes files
The agent records the exact files it changed in this session.
PM7 Code enqueues Git
The app validates the request and creates a background job.
Work continues
The Git Service commits and pushes while the session can move on.
User interface
What you see in PM7 Code
A GitServiceRequest appears as a dedicated card in CView. The card shows the job state, the repository path, the files included in the request, and any error returned by the Git Service.
| Status | Meaning |
|---|---|
| Queued | PM7 Code accepted the request and placed it in the Git Service queue. |
| Validating | PM7 Code checks the exact files, working tree state, and request shape before touching Git. |
| Staging | Only the files listed in the request are staged. Directories and broad pathspecs are rejected. |
| Committing | The Git Service creates the commit with the message supplied by the session. |
| Pushing | The commit is pushed while the agent session can already continue with other work. |
| Succeeded | The requested files were committed and pushed. |
| Failed | The request was stopped before completion. The card shows the reason and no hidden retry is performed. |
Safety
What PM7 Code protects
The Git Service is intentionally strict. It is designed to commit exactly the files from the finished session and to stop when the repository state no longer matches the request.
Exact file list
The request must list concrete files. Directories and broad patterns are rejected so a session cannot accidentally commit unrelated work.
Snapshot validation
PM7 Code records the file state when the request is enqueued and checks that the same content is staged before committing.
No mixed staged work
Existing staged changes that do not belong to the request are a reason to fail, not a reason to create a mixed commit.
Visible failures
Conflicts, drift, hook failures, and push errors are surfaced on the Git Service card for the user to inspect.
Advanced
GitServiceRequest format
Most users do not need to write this block by hand. The PM7 Code skills for Codex and Claude Code emit it automatically at the end of a turn when files changed. Advanced users and agent authors can use this shape:
```GitServiceRequest
{
"cwd": "/Users/patrickmast/Dev/pm7-code",
"files": [
"site/app/docs/page.tsx",
"site/app/page.tsx"
],
"scope": "docs",
"commitMessage": "docs: document Git Service"
}
```Troubleshooting
When a Git Service job fails
A failed job means PM7 Code deliberately stopped before completing the commit or push. Use the card message as the source of truth and send a fresh request after fixing the cause.
| Problem | What to do |
|---|---|
| A file changed after the request was made | Ask the agent to inspect the latest file state and send a new GitServiceRequest. |
| Another session touched the same file | Resolve which session owns the file, then let one session create a fresh request. |
| There are unrelated staged changes | Unstage or commit those changes separately. The Git Service will not mix them into this job. |
| The push failed | Check the visible error in the card. Typical causes are auth, network, or a remote branch update. |
| Nothing changed | No commit is needed. A well-behaved session should silently skip the request. |