10xProductivity: a local-first personal work assistant built on coding agents

The problem: you cannot get an automation platform approved

The README states the constraint plainly: most employees cannot install a new automation platform, register Slack or GitHub apps, add webhooks, or wait for IT approval every time they want an AI agent to help. That is the gap this project aims at. It is not aimed at platform teams who can stand up Airflow, n8n or a managed workflow service. It is aimed at one person with a laptop, an existing coding agent, and the credentials that person already holds.

The design premise is that coding agents stopped being only coding assistants. Cursor, Claude Code, Codex and Copilot can read files, run scripts, call APIs and drive a browser, so an agent session already sits inside your permission boundary. 10xProductivity does not add a service account or a bot identity. It treats your authenticated session as the integration layer, which is why the README insists on zero new infrastructure and no admin-approved Slack app. The cost of that choice is that everything runs as you, with your access, and nothing is centrally governed.

How the runtime, triggers and skills fit together

The README shows the flow as two entry paths that converge. A trigger or schedule enters the runtime host, and a laptop coding-agent session enters a workflow or skill directly. Both then reach tool connections, and the work lands in Slack, Jira, GitHub, docs, calendar, CRM or an internal portal. The repository layout matches that split: triggers/, runtime/ and workflows/ are separate top-level directories, with tool_connections/ holding the agent-readable setup guides.

The runtime is described as intentionally thin and local. Triggers notice app and service events, runtime handles execution mechanics (polling, scheduling, state, replies, coding-agent invocation), workflows define the work, and tool connections fetch or update external systems. Skills are the layer above tool recipes: the README lists triaging a Jira sprint, summarising an incident, drafting a PR description, preparing a customer call, writing a standup update and reviewing open follow-ups as examples. The stated loop is that repeated patterns become reusable skills, working sessions become persistent memory, and mistakes become better skills.

That last claim is where the documentation runs ahead of the code. The layer table marks learning and memory as Roadmap, described as planned but not complete. Scheduled reflection and capability learning are not available today. Treat the feedback loop as an intention, not a feature.

Installing 10xProductivity and running your first search

The package is Python and requires 3.11 or later, per pyproject.toml. Clone the repository, install it in editable mode so the three declared console scripts (10x-host, 10x-reply, 10x-standup-prep) resolve on your PATH, then install the pinned runtime dependencies from requirements.txt.

git clone https://github.com/ZhixiangLuo/10xProductivity.git
cd 10xProductivity
pip install -e .
pip install -r requirements.txt

After that, copy env.sample to your local environment file and fill in the values it lists; python-dotenv loads it at runtime. The README also points to setup.md and setup-python.md for environment setup, and to tool_connections/README.md for the connection philosophy and the per-tool guides.

The first real use is a search across your connected tools. The README describes enterprise search as available today, covering Slack, Confluence, Jira, GitHub, Linear, Notion and more. You run it from a coding-agent session on your laptop rather than from a server, because the agent needs your authenticated sessions to reach those tools. Open the repository in Cursor or Claude Code, pick the search skill, and ask a question in natural language. What you should see is the agent calling your connected tools and returning results, with the tool calls visible in the session transcript so you can correct it when it picks the wrong source.

The other entry point that exists today is stand-up prep, exposed as the 10x-standup-prep console script. Running it exercises the runtime rather than a single skill, so it is the quickest way to confirm the runtime, the scheduling path and your tool connections are wired together before you invest in coaching your own workflows.

Where 10xProductivity breaks down

The honest limitation is that the interesting half of the product is unfinished. The layer table labels triggers, runtime and reusable workflows as Early, and enterprise search and stand-up prep are the only workflows the README names as existing today. If you need a scheduled job that fires reliably at 07:00 and posts a brief, you are building on a runtime the README itself calls thin.

A second constraint is credential durability. Because the agent acts as you through browser sessions and desktop apps, anything that depends on a logged-in browser will break when the session expires, when SSO forces re-authentication, or when a corporate policy rotates tokens. requirements.txt lists playwright-stealth as an optional install that improves bot avoidance for browser sessions, which is an acknowledgement that some surfaces actively resist automation. That is a maintenance cost you carry indefinitely, and the README does not document a rollback path for a workflow that misfires.

Third, this is the wrong tool for anything multi-user. There is no shared queue, no audit trail, no approval gate. A skill that updates a Jira ticket runs with your name on it. For a team-wide process, a proper integration platform is the correct answer, and this project does not pretend otherwise.

Compared with n8n and Zapier

n8n and Zapier both assume you can register an app, obtain OAuth credentials and host or subscribe to a workflow engine. They give you a visual editor, retries, run history and shared credentials. The difference in approach is where execution happens and who owns the identity. Those platforms run as a service identity with its own scopes; 10xProductivity runs as you, inside a coding-agent session on your machine, and reaches tools through whatever surface they expose, including a browser when no API is available.

That makes 10xProductivity viable in organisations where a new OAuth app would need a security review, and it makes it a poor fit where you actually want central visibility. A Zapier task that fails is visible in a dashboard. A skill that fails in a local session is visible to you, in that session, and nowhere else. Pick based on whether your blocker is procurement or observability.

Licence and the cost of keeping it working

The repository is MIT licensed, with a LICENSE file at the top level and a separate LEGAL_NOTICE.md. MIT is permissive: you can modify and redistribute, and the licence text itself is the only obligation. That is a statement about the code, not about the tools you connect it to. Slack, Jira, Confluence, GitHub and Outlook each carry their own terms, and automating a browser session against a service may conflict with that service's acceptable use policy even when the code is MIT. Check your employer's policy before you point an agent at an internal portal.

The upgrade cost is the part to price carefully. The last push was on 2026-07-13, and v1.1.0 shipped on 2026-05-27 with the personal assistant agent direction. Dependencies in requirements.txt are pinned exactly (playwright==1.58.0, requests==2.32.5, msal==1.35.1, PyJWT==2.12.1), which protects you from surprise breakage but means security updates arrive only when you bump them yourself. Browser automation pins age fastest of all, because the sites you drive change without notice. Budget for re-running your skills after any dependency bump.

What to verify before you rely on it

Start with tool_connections/README.md, which the README points to for the connection philosophy and which holds the setup guides. If your tool is not in the pre-built set, add-new-tool.md is the playbook for connecting an internal or custom tool, and verified_connections.example.md shows the shape of a confirmed connection. env.sample is the template for local configuration, and setup.md and setup-python.md cover environment setup.

The tests directory exists and pytest is configured with testpaths = ["tests"], so you can run the suite locally before trusting a workflow.

pytest

What the README does not document is a rollback procedure, a dry-run mode, or a permissions model for limiting what a skill may touch. Before you let a skill write to Jira or post to Slack, run it in a scratch channel or a throwaway ticket and confirm the blast radius yourself. The runtime's thinness means the guardrails are your prompt and your supervision, not the framework.

Editorial conclusion

Adopt 10xProductivity if you already live in a coding-agent session and your org will not approve new automation infrastructure: the tool_connections recipes and the 10x-host runtime are the parts that exist today. Do not adopt it if you need unattended, audited automation across a team, because triggers, runtime and reusable workflows are still labelled Early and learning and memory is on the roadmap. Before committing, verify that your coding agent can hold an authenticated session for the specific tool you care about, and read tool_connections/README.md to confirm your tool is covered or that the add-new-tool.md playbook fits.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ZhixiangLuo/10xProductivity on GitHub