My opinionated stack: Codex, Slack, GitHub and Google Drive
My pick for CFE is Codex, Slack, GitHub and Google Drive. I want a clear starting point for doing useful work with AI, with a straightforward job for each tool.
These are my defaults. A team with different tools can make different choices. What matters is knowing where work happens, where people coordinate, and where the result belongs.
Give each tool a job
- Codex does the work. This is where I want to bring a task, work through it with AI and review the result. The task still needs a defined scope, relevant context and clear limits on what can happen without asking me.
- Slack handles general coordination. It is the place for questions, updates and conversations across projects. A useful update should help someone understand what changed and point them to the work.
- GitHub holds code and versioned project knowledge. I want implementation details, project instructions and decisions that need to travel with the code close to that code. It is also the home I would use for a project’s Git Relay conversation.
- Google Drive holds human-facing documents, files and deliverables. Briefs, shared documents and the files people need to read or use belong here when Drive is their agreed home.
That gives CFE something concrete to document. CFE supplies conventions for using these tools together: what context to provide, how to hand work over, where to save it and what to verify. I do not want to rebuild all four tools inside another platform.
Choose a home, then link to it
The awkward part is usually the overlap. A project brief could be a Google Doc or a Markdown file. A decision could appear in Slack, a repository and a document. Without a convention, people end up maintaining three slightly different answers.
I would choose the authoritative home for each kind of information at the start of a project. For example, the working brief lives in Drive, implementation instructions live in GitHub, and Slack carries updates with links to both. The project’s short context note records those choices.
A summary is useful, but it should say what it summarizes and link to the original. If a deliverable is an export or a snapshot, label it that way. We should be able to tell which copy to edit and which one merely reflects an earlier state.
Linking also avoids copying a whole document into every conversation. A link does not grant access, though. The people and tools doing the work still need the right permissions.
Keep project context separate
Slack can connect people across several projects. The context for an AI task should stay much narrower: this project’s instructions, relevant files, current decision and authorized next step.
Git Relay fits inside that boundary. It gives separate sessions a project-scoped conversation through Git. I would not use one relay as a shared memory for unrelated projects, and I would not replace general Slack coordination with it.
The Git Relay story explains the reason for that shared conversation. The practical guide covers the handoff details.
Discussion and execution authority need to stay separate in either channel. A message can report a result, ask a question or propose a change. It cannot grant access or approve a consequential action just because an assistant received it.
A small example
Imagine a project to update a website from an agreed brief. The brief lives in Drive. The repository links to it and holds the code, project instructions and checks.
I ask Codex to prepare the change using that project’s context. If another session reviews the implementation, Git Relay can carry the question and review result within the project. The proposed change and its checks stay with the code.
A Slack update can then say what is ready, what still needs a decision and where to review it. The final human-facing handover goes in Drive, with a link to the relevant code version. Publishing still follows the approval boundary agreed for that task.
That is a workflow to set up deliberately, not a promise that installing these four tools automatically connects them.
Start with a useful division of work
This follows the same approach I described in deciding where AI belongs: use existing infrastructure for the jobs it already handles, and give the model the parts that need interpretation and judgment.
My stack gives each part a place. Codex for the work, Slack for coordination, GitHub for code and versioned project context, and Drive for the documents and files people share. CFE makes those choices easier to understand and repeat.