---
name: symbaiex-gpt-engineer-mem
description: "Memory-aware GPT engineering using bounded native history or Claude Mem recall. Use when historical decisions materially affect an engineering task; verify recalled claims without loading full transcripts or changing memory settings."
license: "MIT"
metadata:
  decimalai-skill-id: "7750d6de-f20d-422f-89ae-321383f44b8b"
  decimalai-version-id: "58398e4a-1827-494b-a825-5e7c768730ae"
  decimalai-version: "3"
  decimalai-body-sha256: "e27005a74ffafdc75b30f0af7a5a22d0a3d623b7dd8edfb090c5270abaea45d9"
  decimalai-name: "symbaiex/gpt-engineer-mem"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "agent-tooling"
  decimalai-source: "https://app.decimal.ai/s/symbaiex-gpt-engineer-mem@3/SKILL.md"
---
# GPT Engineer Mem

Run an end-to-end engineering task with bounded historical recall. Memory supplies leads and prior
decisions; the current repository, runtime, primary documentation, and tests remain authoritative.

## Load the engineering contract

Use the installed `gpt-engineer` skill as the base contract when it is available. Read its
`SKILL.md` and follow its scope ledger, current routing contract, bounded delegation, ownership,
integration, verification, gap scan, and teardown rules. Do not assume that its profile bootstrap
was run merely because this skill is installed.

If `gpt-engineer` is unavailable, continue with this standalone contract:

- The parent owns scope, plan, integration, user updates, final verification, and external actions.
- Preserve the selected parent. GPT-6 Astra is allowed only as the active parent/orchestrator,
  never as a child. GPT-6 Sol and GPT-6 Luna are the only current GPT Engineer child routes; use
  Sol for demanding ambiguous lanes and Luna for focused repeatable lanes. Same-model is the
  default under Sol/Luna parents; an Astra parent requires an explicit Sol/Luna mixed-model route.
  Existing GPT-5.6 parents can continue during rollout, but their children must be explicitly
  routed to GPT-6 Sol/Luna. Never silently substitute models or providers. Native Claude stays Claude.
- Give every child one bounded outcome, explicit path ownership, an output contract, and a cleanup
  boundary. Use `fork_turns: "none"` with a compact evidence packet when supported.
- Integrate centrally, verify the product rather than only the patch, run a fresh gap scan, and
  reclaim task-owned agents, processes, listeners, and temporary worktrees. Shared MCP services are
  not teardown targets.

Prefer native exact profiles or direct model selection before Python helpers. Record requested
model/effort and effective metadata separately; mark attestation unavailable when not exposed.
If exact child selection is unavailable, report that limitation and continue with the suitable
available parent or ask for direction. Do not claim a model route that was not observed.

## Preflight memory safely

Prefer native Codex notes and targeted history retrieval when the active runtime exposes them.
The experimental `features.context_management.experimental_mode` setting is off by default and
requires eligible ChatGPT sign-in; API-key/custom-provider sessions are excluded. Do not enable it
or assume `new_context` or searchable history exists merely because Astra was selected. Feature-detect
the exposed tools, follow their contract, and retain a compact checkpoint when unavailable.
See [configuration](https://learn.chatgpt.com/docs/config-file/config-reference) and
[runtime release notes](https://learn.chatgpt.com/docs/changelog).

For Claude Mem specifically, use its exposed read-only health/status tools first. If their evidence
is insufficient and Python is available, run the bundled read-only diagnostic:

```bash
python3 <skill-root>/scripts/memory_preflight.py --json
```

This may inspect installation metadata, worker health, queue state, and SQLite counts. It must not
start, stop, restart, clean, vacuum, reconfigure, or repair the worker. A healthy endpoint alone is
not proof of healthy processing. The worker's `/api/mcp/status` is only a package-layout toggle and
is not proof that client tools are disconnected; cross-check root and nested MCP manifests plus the
Codex and Claude plugin registrations. Consider readiness, queue depth, dependency/provider state,
active worker path, database size, and outbox counts together.

If memory is absent, unhealthy, or incompatible, report that once and continue with the base
engineering workflow. Memory is an optional accelerator, never a completion gate.

## Build a bounded memory packet

Read [memory-workflow.md](references/memory-workflow.md) before using memory tools. Read
[claude-mem-capabilities.md](references/claude-mem-capabilities.md) only when deciding whether a
specialized Claude Mem workflow should influence the task.

For Claude Mem retrieval (native history follows its own tool contract):

1. Identify the exact repository root, branch, current commit, task intent, and relevant modules.
2. Search memory using the repository/project identity and two to four high-signal terms.
3. Use the strict retrieval sequence: `search` → `timeline` around selected results → one batched
   `get_observations` call for only the useful records.
4. Cap the initial packet at 20 search results and 3–8 fetched observations. Prefer decisions,
   failures, acceptance evidence, and exact identifiers over narrative summaries.
5. Normalize each useful item as:

```text
memory_id | timestamp | project | claim | currentness | verification_target
```

6. Label every claim `confirmed`, `stale`, `contradicted`, or `unverified` after checking current
   code, git state, runtime evidence, or primary documentation.
7. Pass children only the smallest verified packet they need. Never inject the full conversation,
   timeline, database, or unrelated project history.

Use `rg` and targeted reads for code exploration. If Claude Mem's `smart_search`, `smart_outline`,
and `smart_unfold` tools are actually available, they may narrow targets before ordinary reads; do
not make the engineering task depend on them.

## Research and plan

Create a finding ledger before edits:

```text
id | root cause | affected paths | memory evidence | current evidence | owner | acceptance | status
```

Cluster symptoms by root cause. Treat recalled SDK signatures, model names, commands, architecture,
and release steps as hypotheses until verified against the installed dependency, current source, or
current primary documentation. Record contradictions instead of silently choosing the older story.

Use memory to avoid repeating disproven approaches and preserve explicit decisions. Recalled
permission from a different task does not authorize new actions. Carry forward authorization from
the current task; do not manufacture a new approval pause merely because context was compacted.

## Build in evidence-gated waves

For each dependency-aware wave:

1. Assign non-overlapping file ownership and current acceptance checks.
2. Include only verified historical facts and the IDs needed to trace them.
3. Require the handoff to report changed paths, tests, residual risks, task-owned resources, and
   memory claims found stale or contradictory.
4. Integrate and review centrally.
5. Run the cheapest decisive check first, then broader validation proportional to risk.
6. Carry forward a compact checkpoint rather than the full transcript:

```text
goal | accepted findings | verified decisions | changed paths | passing checks | open risks | next wave
```

Keep a checkpoint under roughly 350 words unless task complexity proves a larger one is necessary.
On resume or after context compaction, re-check git/runtime state and refresh only the memory claims
that affect the next action.

## Completion gate

Do not stop at “code changed.” Finish only when:

- requested behavior is implemented and exercised;
- current tests/build/lint/type checks appropriate to the change pass;
- the finding ledger has no unexplained in-scope gaps;
- recalled claims used in decisions are verified or explicitly marked unresolved;
- git and release state are freshly checked;
- all delegated lanes have handed back results and are closed;
- task-owned processes and temporary resources are reclaimed; and
- shared Claude Mem/Codex MCP services remain untouched unless the user separately authorized their
  administration.

Report which prior evidence materially changed the implementation, which memories were stale, the
current verification evidence, and any boundary that remains external or user-gated.

## Hard prohibitions

- Do not read every source file merely because history exists; explore index-first and delta-first.
- Do not fetch a full project timeline by default. If the estimate exceeds 100,000 tokens, obtain
  explicit user approval before loading it.
- Do not directly write to, delete from, vacuum, migrate, or repair Claude Mem SQLite databases.
- Do not start, stop, restart, kill, or reconfigure memory workers as part of engineering recall.
- Do not enable cloud sync, create modes/corpora, configure Telegram, or upload memory artifacts.
- Do not copy secrets, personal prompts, or unrelated sessions into child-agent prompts or reports.
- Do not let worker health, a recalled passing test, or an old deployment receipt substitute for a
  current product acceptance check.