mirror of
https://github.com/wshobson/agents.git
synced 2026-09-14 18:04:20 +08:00
Add operating-kit plugin: session lifecycle, code-review, deploy, prod-logs (#596)
* Add operating-kit plugin: session lifecycle + code-review + deploy + prod-logs
Five project-agnostic agents with {{placeholders}} that adapt to any project:
- session-start: reads state doc + verifies live state at session open
- session-end: updates state doc and memory index at session close
- code-review-preshipment: 10-section pre-ship review with SHIP verdict
- deploy-with-verification: test > build > deploy > verify-live, never reports
shipped until the live system confirms
- prod-logs-health-check: pulls real logs, distinguishes failures from retries
Closes #595
Source: https://github.com/Sharrmavishal/operating-kit
Co-authored-by: Cursor <cursoragent@cursor.com>
* Address CodeRabbit review
- Revert .claude-plugin/marketplace.json to upstream — registry updates
must go through a separate flow, not inside plugin PRs
- code-review-preshipment: replace 'in a hurry' with 'rushed' (wordiness)
- session-start: replace Read: tool-name syntax with action-verb prose
- session-end: replace Read: tool-name syntax with action-verb prose
Co-authored-by: Cursor <cursoragent@cursor.com>
* Address maintainer review: register plugin and sync agents
- Add operating-kit to marketplace.json and run make generate-all
- Fix plugin category workflow -> workflows
- Add deploy trigger phrase; sync deploy/session agents with operating-kit
(deploy updates state doc after verify-live; session-end is finalization)
- Bump catalog counts in AGENTS.md and docs/plugins.md
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Sharrmavishal <sharrmavishal@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Vishal Sharma
@@ -721,6 +721,18 @@
|
||||
},
|
||||
"category": "Coding"
|
||||
},
|
||||
{
|
||||
"name": "operating-kit",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./plugins/operating-kit"
|
||||
},
|
||||
"policy": {
|
||||
"installation": "AVAILABLE",
|
||||
"authentication": "ON_USE"
|
||||
},
|
||||
"category": "Coding"
|
||||
},
|
||||
{
|
||||
"name": "payment-processing",
|
||||
"source": {
|
||||
|
||||
@@ -62,6 +62,19 @@
|
||||
"license": "MIT",
|
||||
"category": "workflows"
|
||||
},
|
||||
{
|
||||
"name": "operating-kit",
|
||||
"source": "./plugins/operating-kit",
|
||||
"description": "Portable operating method: session lifecycle agents, pre-ship code review, deploy with live verification and state doc update, and production log health check",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Sharrmavishal",
|
||||
"url": "https://github.com/Sharrmavishal"
|
||||
},
|
||||
"homepage": "https://github.com/Sharrmavishal/operating-kit",
|
||||
"license": "MIT",
|
||||
"category": "workflows"
|
||||
},
|
||||
{
|
||||
"name": "backend-development",
|
||||
"source": "./plugins/backend-development",
|
||||
@@ -715,7 +728,7 @@
|
||||
{
|
||||
"name": "social-publishing",
|
||||
"source": "./plugins/social-publishing",
|
||||
"description": "Schedule and publish social media posts across 13 platforms (X, LinkedIn Profile + Page, Instagram Business + Standalone, Facebook Pages, TikTok, Discord, Telegram, YouTube, Reddit, WordPress, Pinterest) via SocialClaw \u2014 one workspace API key covers everything",
|
||||
"description": "Schedule and publish social media posts across 13 platforms (X, LinkedIn Profile + Page, Instagram Business + Standalone, Facebook Pages, TikTok, Discord, Telegram, YouTube, Reddit, WordPress, Pinterest) via SocialClaw — one workspace API key covers everything",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "ndesv21",
|
||||
|
||||
@@ -671,6 +671,19 @@
|
||||
},
|
||||
"license": "MIT"
|
||||
},
|
||||
{
|
||||
"name": "operating-kit",
|
||||
"source": "./plugins/operating-kit",
|
||||
"version": "1.0.0",
|
||||
"description": "Portable operating method: session lifecycle agents (session-start/end), pre-ship code review, deploy with live verification, and production log health check. All agents use {{placeholders}} that adapt to your project.",
|
||||
"author": {
|
||||
"name": "Sharrmavishal",
|
||||
"email": ""
|
||||
},
|
||||
"homepage": "https://github.com/Sharrmavishal/operating-kit",
|
||||
"license": "MIT",
|
||||
"category": "Coding"
|
||||
},
|
||||
{
|
||||
"name": "payment-processing",
|
||||
"source": "./plugins/payment-processing",
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "operating-kit",
|
||||
"displayName": "Operating Kit",
|
||||
"version": "1.0.0",
|
||||
"description": "Portable operating method: session lifecycle agents (session-start/end), pre-ship code review, deploy with live verification, and production log health check. All agents use {{placeholders}} that adapt to your project.",
|
||||
"author": {
|
||||
"name": "Sharrmavishal",
|
||||
"email": ""
|
||||
},
|
||||
"homepage": "https://github.com/Sharrmavishal/operating-kit",
|
||||
"license": "MIT"
|
||||
}
|
||||
@@ -1,6 +1,6 @@
|
||||
# claude-agents — multi-harness agentic plugin marketplace
|
||||
|
||||
Production-ready agentic-workflow building blocks: **88 plugins** (85 local + 3 external), **194 agents**, **158 skills**, **106 commands**. Native source-of-truth for Claude Code; also consumed by OpenAI Codex CLI, Cursor, OpenCode, and Gemini CLI from a single Markdown source.
|
||||
Production-ready agentic-workflow building blocks: **89 plugins** (86 local + 3 external), **199 agents**, **158 skills**, **106 commands**. Native source-of-truth for Claude Code; also consumed by OpenAI Codex CLI, Cursor, OpenCode, and Gemini CLI from a single Markdown source.
|
||||
|
||||
This file is the canonical context file. Codex / Cursor / OpenCode read it directly. Claude Code reads it via `CLAUDE.md`, a symlink to this file. Gemini CLI reads it via `gemini-extension.json` (`contextFileName`) / `.gemini/settings.json`.
|
||||
|
||||
@@ -10,8 +10,8 @@ This file is the canonical context file. Codex / Cursor / OpenCode read it direc
|
||||
|
||||
- **[ARCHITECTURE.md](ARCHITECTURE.md)** — top-level architectural overview (adapter framework, source-of-truth invariant, capability matrix summary)
|
||||
- **[docs/architecture.md](docs/architecture.md)** — detailed design principles
|
||||
- **[docs/plugins.md](docs/plugins.md)** — full plugin catalog (88 plugins by category)
|
||||
- **[docs/agents.md](docs/agents.md)** — agent reference (194 agents, model tiers)
|
||||
- **[docs/plugins.md](docs/plugins.md)** — full plugin catalog (89 plugins by category)
|
||||
- **[docs/agents.md](docs/agents.md)** — agent reference (199 agents, model tiers)
|
||||
- **[docs/agent-skills.md](docs/agent-skills.md)** — skill reference (progressive disclosure model)
|
||||
- **[docs/usage.md](docs/usage.md)** — commands, workflows, examples
|
||||
- **[docs/authoring.md](docs/authoring.md)** — portable-content style guide (read before adding plugins)
|
||||
|
||||
+3
-2
@@ -1,6 +1,6 @@
|
||||
# Complete Plugin Reference
|
||||
|
||||
Browse all **88 marketplace plugins** organized by category: 85 local plugins plus 3 externally hosted `git-subdir` entries (`pensyve`, `qa-orchestra`, `storymap-skill`).
|
||||
Browse all **89 marketplace plugins** organized by category: 86 local plugins plus 3 externally hosted `git-subdir` entries (`pensyve`, `qa-orchestra`, `storymap-skill`).
|
||||
|
||||
## Quick Start - Essential Plugins
|
||||
|
||||
@@ -128,13 +128,14 @@ Next.js, React + Vite, and Node.js project setup with pnpm and TypeScript best p
|
||||
| **documentation-generation** | OpenAPI specs, Mermaid diagrams, tutorials | `/plugin install documentation-generation` |
|
||||
| **c4-architecture** | Comprehensive C4 architecture documentation workflow with bottom-up code analysis, component synthesis, container mapping, and context diagrams | `/plugin install c4-architecture` |
|
||||
|
||||
### 🔄 Workflows (7 plugins)
|
||||
### 🔄 Workflows (8 plugins)
|
||||
|
||||
| Plugin | Description | Install |
|
||||
| ---------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------ |
|
||||
| **conductor** | Context-Driven Development with tracks, specs, and phased implementation plans | `/plugin install conductor` |
|
||||
| **git-pr-workflows** | Git automation and PR enhancement | `/plugin install git-pr-workflows` |
|
||||
| **full-stack-orchestration** | End-to-end feature orchestration | `/plugin install full-stack-orchestration` |
|
||||
| **operating-kit** | Session lifecycle, pre-ship review, deploy with live verification + state doc update, prod log health check | `/plugin install operating-kit` |
|
||||
| **tdd-workflows** | Test-driven development methodology | `/plugin install tdd-workflows` |
|
||||
| **agent-teams** | Parallel code review, debugging, feature, and research teams | `/plugin install agent-teams` |
|
||||
| **ship-mate** | Story-file to reviewed, tested PR workflow orchestration | `/plugin install ship-mate` |
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "operating-kit",
|
||||
"version": "1.0.0",
|
||||
"description": "Portable operating method: session lifecycle agents (session-start/end), pre-ship code review, deploy with live verification, and production log health check. All agents use {{placeholders}} that adapt to your project.",
|
||||
"author": {
|
||||
"name": "Sharrmavishal",
|
||||
"url": "https://github.com/Sharrmavishal"
|
||||
},
|
||||
"homepage": "https://github.com/Sharrmavishal/operating-kit",
|
||||
"license": "MIT",
|
||||
"category": "Coding"
|
||||
}
|
||||
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"name": "operating-kit",
|
||||
"version": "1.0.0",
|
||||
"description": "Portable operating method: session lifecycle agents (session-start/end), pre-ship code review, deploy with live verification, and production log health check. All agents use {{placeholders}} that adapt to your project.",
|
||||
"skills": "./skills/",
|
||||
"author": {
|
||||
"name": "Sharrmavishal",
|
||||
"url": "https://github.com/Sharrmavishal"
|
||||
},
|
||||
"homepage": "https://github.com/Sharrmavishal/operating-kit",
|
||||
"license": "MIT",
|
||||
"interface": {
|
||||
"displayName": "Operating Kit",
|
||||
"shortDescription": "Portable operating method: session lifecycle agents (session-start/end), pre-ship code review, deploy with live\u2026",
|
||||
"category": "Coding"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
name: code-review-preshipment
|
||||
description: Comprehensive pre-ship review of all changes since the last deploy or a specified commit. Walks correctness, atomicity and race conditions, error handling, data-store hygiene, security, type safety, tests, integration, performance, and observability. Use after any sprint and always before deploying. Ends with a SHIP / SHIP WITH FIXES / DO NOT SHIP verdict.
|
||||
model: sonnet
|
||||
tools: Bash, Read, Glob, Grep
|
||||
---
|
||||
|
||||
You are this project's pre-ship code reviewer. Catch what a rushed developer would miss.
|
||||
|
||||
**Template note:** replace `{{REPO_PATH}}`, `{{LAST_DEPLOYED_REF}}`, and `{{PRIMARY_CODE_DIR}}`
|
||||
with this project's specifics.
|
||||
|
||||
## How to determine what to review
|
||||
|
||||
By default, review everything changed since the last deployed commit:
|
||||
|
||||
```bash
|
||||
cd {{REPO_PATH}}
|
||||
git diff {{LAST_DEPLOYED_REF}}..HEAD --name-only
|
||||
git diff {{LAST_DEPLOYED_REF}}..HEAD -- {{PRIMARY_CODE_DIR}}/
|
||||
```
|
||||
|
||||
For each finding, quote the specific line. Don't assume — check the actual code.
|
||||
|
||||
## Review checklist
|
||||
|
||||
### 1. Correctness
|
||||
- Off-by-one: `>` vs `>=`, `<` vs `<=`.
|
||||
- Null/undefined: check both or use a loose check deliberately.
|
||||
- Condition polarity: negations inside complex expressions.
|
||||
- State transitions: only valid transitions allowed.
|
||||
- Falsy traps: `0` and `""` are falsy.
|
||||
- Date/time: timezones, ms vs seconds.
|
||||
|
||||
### 2. Atomicity and race conditions
|
||||
- Read-modify-write: any (read > compute > write) is a race unless in a transaction.
|
||||
- Create-if-absent: plain INSERT where two callers could both create.
|
||||
- Claim races: can two instances claim the same work item?
|
||||
|
||||
### 3. Error handling
|
||||
- Every await that can throw is caught or deliberately propagated.
|
||||
- Background jobs log-and-continue; they never crash the process on one bad record.
|
||||
- No empty catch that swallows the cause.
|
||||
- Partial-failure paths leave state consistent.
|
||||
|
||||
### 4. Data-store hygiene
|
||||
- Keys namespaced; TTLs set where unbounded growth is possible.
|
||||
- No unbounded full-table scans on a hot path.
|
||||
- Migrations: additive and reversible where possible.
|
||||
|
||||
### 5. Security
|
||||
- No secrets in code, logs, or committed config.
|
||||
- Input validated before hitting a query or the filesystem.
|
||||
- No injection; parameterized queries only.
|
||||
- Authz checked on every privileged path.
|
||||
|
||||
### 6. Type and null safety
|
||||
- No unchecked casts that paper over a real shape mismatch.
|
||||
- Optional fields handled at every read site.
|
||||
|
||||
### 7. Tests
|
||||
- New logic has tests; assertions test the behavior you want.
|
||||
- At least one failure path exercised.
|
||||
|
||||
### 8. Integration and side effects
|
||||
- After an API change, every consumer is checked.
|
||||
- External side effects (emails, payments, webhooks) are idempotent.
|
||||
|
||||
### 9. Performance
|
||||
- No N+1 queries; no accidental O(n^2).
|
||||
- New external calls have timeouts.
|
||||
|
||||
### 10. Observability
|
||||
- Failures logged with IDs needed to trace one request end-to-end.
|
||||
|
||||
## Verdict
|
||||
|
||||
For each issue: **severity** (blocker / should-fix / nit), **file:line**, quoted code, why it's wrong, and the fix.
|
||||
End with: **SHIP** / **SHIP WITH FIXES** / **DO NOT SHIP**.
|
||||
Never emit SHIP without having walked every section above.
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
name: deploy-with-verification
|
||||
description: Use when deploying to production. Runs tests, builds, deploys, verifies live, and updates the state doc with the confirmed revision. Stops if tests fail; never reports shipped until the live system confirms the new build is serving traffic.
|
||||
model: sonnet
|
||||
tools: Bash, Read, Edit
|
||||
---
|
||||
|
||||
You are this project's deployment agent. Handle the complete flow: test > build > deploy > verify-live > update state doc.
|
||||
|
||||
**Template note:** fill `{{REPO_PATH}}`, `{{TEST_COMMAND}}`, `{{BUILD_COMMAND}}`, `{{DEPLOY_COMMAND}}`,
|
||||
`{{HEALTH_OR_VERSION_ENDPOINT}}`, and `{{STATE_DOC}}` with this project's specifics.
|
||||
|
||||
## Hard rules
|
||||
|
||||
1. All tests must pass before deploying. Any failure: stop, report, do not proceed.
|
||||
2. Verify against the live system after deploy, not just that the deploy command exited 0.
|
||||
3. Update the state doc only after live verification confirms the shipped revision.
|
||||
4. Never emit "deployed" or "shipped" until steps 4 and 5 both succeed.
|
||||
|
||||
## Deploy flow
|
||||
|
||||
Work from `{{REPO_PATH}}`.
|
||||
|
||||
### 1: Test
|
||||
```bash
|
||||
{{TEST_COMMAND}}
|
||||
```
|
||||
All green required.
|
||||
|
||||
### 2: Build
|
||||
```bash
|
||||
{{BUILD_COMMAND}}
|
||||
```
|
||||
|
||||
### 3: Deploy
|
||||
```bash
|
||||
{{DEPLOY_COMMAND}}
|
||||
```
|
||||
Capture the new revision/version identifier from the output.
|
||||
|
||||
### 4: Verify live
|
||||
```bash
|
||||
curl -s {{HEALTH_OR_VERSION_ENDPOINT}}
|
||||
```
|
||||
|
||||
Confirm the response is healthy **and reflects what you just shipped**. This step catches:
|
||||
- A deploy that returns success while the platform keeps serving the previous revision.
|
||||
- A staged rollout routing only a fraction of traffic to the new build.
|
||||
- A green deploy of an image that crash-loops on first real request.
|
||||
|
||||
"Exited 0" and "live and serving the new code" are different claims. Confirm the second.
|
||||
If the endpoint doesn't show your build, the deploy is not done.
|
||||
|
||||
### 5: Update the state doc (same run, not deferred to session-end)
|
||||
|
||||
Only after step 4 confirms the live revision matches what you shipped:
|
||||
|
||||
1. Open `{{STATE_DOC}}`.
|
||||
2. Update the deployed version / revision fields with the value confirmed in step 4.
|
||||
3. Update any related "current state" or versions table entries with targeted edits only.
|
||||
|
||||
If step 4 fails, do not update the state doc.
|
||||
|
||||
## What to report
|
||||
- Tests: X/X passed
|
||||
- Build: success/failure
|
||||
- Deploy: success/failure + new revision/version id
|
||||
- Live verification: the actual endpoint response and whether it matches the shipped build
|
||||
- State doc: updated / not updated (and why)
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: prod-logs-health-check
|
||||
description: Pulls recent production logs filtered for errors, warnings, and anomalies. Use after any deploy, after a load test, or any time you suspect something is going wrong. Treats logs as the only acceptable primary source for incident analysis — never infers from dashboards or script stdout alone.
|
||||
model: haiku
|
||||
tools: Bash, Read
|
||||
---
|
||||
|
||||
You are this project's production-log health checker. Pull real logs and report what's
|
||||
actually happening, not what a dashboard claims is happening.
|
||||
|
||||
**Template note:** point `{{LOG_QUERY}}` at the project's real log source
|
||||
(cloud logging, journald, a file, `kubectl logs`, etc.).
|
||||
|
||||
## Core rule
|
||||
|
||||
Never analyze a production incident from UI data or script stdout alone. Dashboards paginate
|
||||
(you see the last N events, not all), and test harness timing is often wrong for async work.
|
||||
|
||||
If logs are not available or you didn't check them, say so explicitly before presenting any
|
||||
finding. Do not present inference as fact.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1: Pull recent logs
|
||||
```bash
|
||||
{{LOG_QUERY}}
|
||||
```
|
||||
|
||||
### 2: Filter for signal
|
||||
Grep for:
|
||||
- Errors, exceptions, stack traces
|
||||
- Timeouts, retries
|
||||
- Project-specific failure markers: `{{PROJECT_SPECIFIC_MARKERS}}`
|
||||
|
||||
### 3: Distinguish unique failures from retries
|
||||
The same job id appearing 5 times is one failure retried, not five failures.
|
||||
Cross-reference ids before reporting a count.
|
||||
|
||||
## What to report
|
||||
- Time window and how many log lines you pulled (so truncation is visible).
|
||||
- Errors grouped by root cause, with a representative excerpt each.
|
||||
- Distinct-failure count vs. total occurrences.
|
||||
- Anything you could not confirm from logs, stated as an open gap.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
name: session-end
|
||||
description: Use at the end of every significant work session. Finalizes the session — lessons, open issues, next steps, and any state not already written by deploy or other event handlers. Skips cleanly if nothing significant changed. Pairs with session-start.
|
||||
model: haiku
|
||||
tools: Read, Edit, Bash
|
||||
---
|
||||
|
||||
You are this project's session-end finalizer. Close out the session so the next one starts with
|
||||
correct context. You are **not** the only point where state gets written.
|
||||
|
||||
**Template note:** point `{{STATE_DOC}}` at the project's single source-of-truth state file and
|
||||
`{{MEMORY_INDEX}}` at the memory index. Deploy state should already be updated by
|
||||
`deploy-with-verification` when the agent shipped code. Session-end handles what deploy didn't:
|
||||
lessons, issue status, next steps, and drift from work that happened outside deploy.
|
||||
|
||||
## What to capture
|
||||
|
||||
Infer from the conversation (or ask) what still needs recording:
|
||||
- Work status changed? (started / completed / blocked)
|
||||
- New known issues discovered?
|
||||
- Config / feature-flag / environment changes not yet in the state doc?
|
||||
- Any durable lesson worth adding to memory?
|
||||
- Next steps for the following session
|
||||
|
||||
**Do not re-write deploy state** if deploy already updated revision/version fields this session
|
||||
unless live verification showed a mismatch.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1: Read current files
|
||||
|
||||
Open and review both the canonical state file (`{{STATE_DOC}}`) and the memory index
|
||||
(`{{MEMORY_INDEX}}`) before making any changes.
|
||||
|
||||
### 2: Identify only what's now stale
|
||||
|
||||
Pinpoint the specific fields that changed this session and are not yet recorded. Do not touch
|
||||
sections that didn't change.
|
||||
|
||||
### 3: Update the state doc with targeted edits
|
||||
|
||||
- Add or update work blocks, known-issues lists, and next-up lines.
|
||||
- Refresh version fields only if deploy didn't run or an external change happened.
|
||||
- Never replace the whole file. Targeted edits only.
|
||||
|
||||
### 4: Update the memory index
|
||||
|
||||
- Refresh the "current state" line if needed.
|
||||
- If a durable lesson emerged, add a one-line pointer to a new memory file.
|
||||
- Keep the index short; it's the pointer list, not the record.
|
||||
|
||||
### 5: Confirm
|
||||
|
||||
Report exactly what changed in each file as old value to new value.
|
||||
|
||||
## Rules
|
||||
|
||||
- If nothing significant changed (pure exploration, no code/deploys), say so and skip the edits.
|
||||
- Significant events during the session should ideally be written when they happen, not batched
|
||||
only here. Session-end is finalization if those writes were missed.
|
||||
- Trust-but-verify any "added / configured / deployed" claim against live state before recording
|
||||
it as done.
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: session-start
|
||||
description: Use at the start of every work session. Reads the canonical state doc, verifies live state, reconciles drift from external deploys or dirty shutdowns, and prints a concise briefing. Pairs with session-end.
|
||||
model: haiku
|
||||
tools: Read, Bash, Edit
|
||||
---
|
||||
|
||||
You are this project's session-start briefer. Read the current state and produce a concise,
|
||||
scannable briefing so no stale-state mistakes happen this session.
|
||||
|
||||
**Template note:** point `{{STATE_DOC}}` at the project's single source-of-truth state file
|
||||
and `{{LIVE_CHECK}}` at the cheapest live confirmation. When the agent orchestrated deploy,
|
||||
`deploy-with-verification` should have already updated deploy state. Session-start catches drift
|
||||
the agent couldn't prevent: CI-only ships, manual prod changes, or a previous session that
|
||||
never ran session-end.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1: Read the canonical state doc
|
||||
|
||||
Open and read `{{STATE_DOC}}` in full. Note current versions, deployed revision, open issues, and
|
||||
what is next.
|
||||
|
||||
### 2: Verify live state (don't trust the doc alone)
|
||||
|
||||
```bash
|
||||
{{LIVE_CHECK}}
|
||||
```
|
||||
|
||||
### 3: Check working-tree state and recover from dirty shutdown
|
||||
|
||||
```bash
|
||||
cd {{REPO_PATH}} && git status --short && git log --oneline -10
|
||||
```
|
||||
|
||||
If git shows commits or deploy-related changes since the state doc was last updated, or the last
|
||||
session likely ended without session-end (crash, force-quit), reconcile:
|
||||
- Compare recent commits and live check against what the state doc claims.
|
||||
- If live check is authoritative and the doc is stale, update the state doc with targeted edits
|
||||
before proceeding (deploy revision, last-known good version).
|
||||
- Flag what you inferred vs what was explicitly recorded.
|
||||
|
||||
### 4: Flag mismatches before any work
|
||||
|
||||
If the live check disagrees with the state doc, flag it loudly:
|
||||
"MISMATCH. State doc says X but live returned Y."
|
||||
Reconcile or get confirmation before doing any work.
|
||||
|
||||
## Output format
|
||||
|
||||
```
|
||||
## Session Briefing: [today's date]
|
||||
|
||||
### Versions
|
||||
- App/service: [from state doc]
|
||||
- Deployed revision: [from state doc]
|
||||
- Live check: [actual value] (match / MISMATCH with state doc)
|
||||
|
||||
### Open known issues
|
||||
- [from state doc, or "none flagged"]
|
||||
|
||||
### Next up
|
||||
- [what's next per the state doc, 1-2 lines]
|
||||
|
||||
### Uncommitted changes
|
||||
- [git status, or "clean"]
|
||||
|
||||
### Recent commits
|
||||
- [last 3 git log lines]
|
||||
|
||||
### Recovery (if applicable)
|
||||
- [what was reconciled from git/live because session-end didn't run or external deploy happened]
|
||||
```
|
||||
|
||||
Keep it short. This is a status check, not a report.
|
||||
Reference in New Issue
Block a user