Alternative profile
GSD Core × Deep Work Plan
A planning system with a .planning directory, requirement ids, phase plans, fresh-context execution and a verification pass against the user-observable deliverables extracted from each plan, purpose-built to fight context rot by running research, planning and execution in disposable subagents and catching stale verification with content-fingerprint checks.
Solo developers and small teams who want context engineering and verification with little ceremony.
Last reviewed:
Compared with Deep Work Plan
Where it fits
A planning system with a .planning directory, requirement ids, phase plans, fresh-context execution and a verification pass against the user-observable deliverables extracted from each plan, purpose-built to fight context rot by running research, planning and execution in disposable subagents and catching stale verification with content-fingerprint checks.
Solo developers and small teams who want context engineering and verification with little ceremony.
What Deep Work Plan brings
-
Tool-agnostic and repository-native
The harness and the plan are files in your repository, read by any agent that follows the AGENTS.md and Agent Skills standards. Switching agents does not lose the plan.
-
Validation selected from what each task touched
Every task declares its touched surface and runs the tests of the changed behavior and its consumers, widening to the full suite when the impact cannot be bounded. Zero selected tests is never a pass.
-
One Final Review with a security pass
A plan closes with a security review of the accumulated change set, including a required local review of the diff, and a validation of the final state. Critical findings block completion.
Where it fits: Developers and teams who hand multi-session work to any coding agent and need it to finish verified.
Capability snapshot
| Capability | Deep Work Plan | GSD Core |
|---|---|---|
| Works with any coding agent The same repository files drive Claude Code, Codex, Cursor, Gemini CLI and others. | Built in | Built in |
| Writes the agent harness into the repository Instructions, docs, skills and commands live in the repository, not in one tool's settings. | Built in | Optional or via extension |
| Acceptance criteria per task Each task states observable conditions for being done. | Built in | Built in |
| Validation gate per task Each task names the commands that must pass, selected from what it touched. | Built in | Built in |
| Resumable state on disk Progress survives a session reset and can be picked up by another agent or a teammate. | Built in | Built in |
| Mandatory closing review with a security pass The plan cannot complete without a security review of the full change set and validation of the final state. | Built in | Optional or via extension |
| Executable conformance checker A script verifies the repository and its plans against the standard, with a CI-friendly exit code. | Built in | Optional or via extension |
| Published instruction-load measurement The bytes each flow loads are measured by a committed script and published with their limits. | Built in | Not in scope |
| Onboarding that scaffolds documentation A first run writes the repository's agent-facing documentation and kit. | Built in | Built in |
| Living product specs for existing systems A canonical specification describes the product’s current behavior, accepts change deltas and is updated as each change is implemented. | Not in scope | Optional or via extension |
| Persistent agent memory across projects Memory follows the agent across different repositories and sessions, not just one plan’s on-disk state. | Not in scope | Not in scope |
| Distinct specialized agent roles Named personas (such as analyst, architect or reviewer) divide the work, rather than one agent running every step. | Optional or via extension | Not in scope |
| Ships as its own IDE or editor The tool is an integrated development environment in its own right, not an add-on to an existing coding agent. | Not in scope | Not in scope |