# PersonalOS is a folder of markdown and one shell script, and the caps on its task list are the feature > A task system where the software is instructions rather than an application: you dump notes into a file, your assistant reads a template, and it writes prioritised tasks against a goals file the setup script generated by asking you questions. The licence forbids commercial sale. **amanaiproduct/personal-os** — Framework for a local AI agent powered task management system - Repository: https://github.com/amanaiproduct/personal-os - Stars: 566 · Forks: 105 - Language: Python - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/amanaiproduct-personal-os ## The whole system is one instruction template and a shell script The repository description is a framework for a task management system powered by a locally running AI agent, and the mechanism is worth understanding before you clone anything. There is no application. There is no server. There is no database. You write unstructured notes into a backlog file, you tell your assistant a sentence, and the assistant reads a markdown template that tells it how to turn those notes into prioritised tasks. That is the entire architecture, and it is a defensible choice rather than a limitation. A task list you maintain by hand in a text file survives every tool you will ever stop using. A task list inside an assistant's memory does not, because the assistant is a vendor and the memory is theirs. The setup is two steps. Clone it, then run one script: ```bash git clone https://github.com/amanaiproduct/personal-os.git cd personal-os ``` ```bash ./setup.sh ``` The script does four things: it creates the workspace directories, it asks you questions about your goals and priorities, it writes a personalised goals file from those answers, and it copies the templates into place. That goals file is the only genuinely personal artefact in the repository, and it is the file that makes prioritisation mean anything. Python is optional. It is needed only if you want to run the optional server interface, and the readme is explicit that the basic setup is pure shell. ## Caps of three and seven are the only opinion in the repository The priority scheme has four levels and two of them have limits attached. The top level means do it today and you may have at most three. The next means do it this week and you may have at most seven. The third is for scheduled work with no limit. The fourth is for someday, and it has no limit either. Look at what those two numbers are doing. A task system that cannot tell you no is a list. This one can, and it does so with two constants rather than with configuration. There is no setting for the limits, no per-project override, and no preference in the template file. If three is wrong for your week, you edit the template. That is a stronger position than it first appears, because the alternative is a prioritisation system with a slider. Every prioritisation tool that offers to tune how many things you should be doing at once offers you the chance to set the number to a value you already know you will not keep. Hard-coding it is the only version of the idea that survives contact with a real Tuesday. The daily rhythm the readme describes is built around the caps. In the morning you ask for today's priorities and pick one to three. During the day you dump notes and save documents. At the end you mark things done. Weekly, you process the backlog and clean up old tasks. That last step is the one people skip, and a system with no deletion path is a system that becomes a graveyard within a quarter. ## Five commands, all of them sentences There is no command syntax because there is no parser. The entire interface is five natural-language requests you type to your assistant, and the readme lists them as literal strings. Ask it to process your backlog and it turns the notes into tasks. Ask it what you should work on and it gives suggestions drawn from your goals file. Ask it to show your top-priority items. Ask it to mark a named task as done. That is the whole surface area, which means the behaviour is entirely determined by how good the instruction template is at describing what those five operations mean. Starting up is the same shape. After setup, the documented first thing to say is: ``` # In your AI assistant (Claude Code, etc.) "Read AGENTS.md and help me get organized" ``` That instruction is doing two jobs at once. It tells the assistant to read the template, and it tells it that your goal is to get organised rather than to answer a question. A different opening sentence produces a different session, which is worth knowing the first time it happens. The five commands are ordinary enough that they will feel underpowered for about a week. Then you notice that there is no notification system, no sync conflict, no mobile client to log into, and no queue of things the assistant wants to ask you about. For a personal system that is a feature, and it is the reason the caps work: nothing is pushing you toward doing eleven things. ## What git tracks and what it does not is the design The directory layout is the documentation, and one line in it carries more meaning than the rest. The reusable system lives in a core directory that is public. Your personal tasks live in a separate directory that is explicitly excluded from version control. The core directory holds four things: a directory of session evaluations, the optional server implementation, a templates directory containing the instruction template, a configuration template and an ignore template, and its own readme. The templates are the product. Everything else is plumbing. The ignore rule on your tasks is the decision that makes the rest safe to share. If your task list is not in git, then a repository you fork or reuse cannot leak your work, and you can keep the setup script and the instruction template under version control while your actual work stays local. That is the opposite of the usual arrangement, where the personal data is tracked and the configuration is ignored. The server implementation is a single file with one stated feature beyond serving: deduplication. When the assistant processes a backlog that contains three phrasings of the same task, the server collapses them. That is a small problem to solve, but it is the problem that makes repeated processing of the same file bearable, and it is the reason the server exists rather than a dozen more templates. ## Session evaluations, and what they are for One entry on the status table is session evaluations, and it is the least explained feature in the repository, which is a shame because it may be the most interesting one. Everything else in the system is a prompt or a script. Session evaluations sit at a different level: they are a mechanism for reviewing what happened during a session with the assistant and learning from it. That implies a loop where the record of an interaction becomes input to the next configuration, which is the difference between a template you wrote once and a system that adjusts. The readme lists it under features as being able to review and learn from assistant interactions, and there is no further documentation for it in the visible material. If that is the part that interests you, it is the part to investigate in the directory itself rather than assume. The status table at the top of the readme lists six capabilities with a checkmark each: task management, goal-driven prioritisation, a knowledge base, backlog processing, session evaluations, and the optional server. Every box is filled. That is worth noting as a signal about how to read the rest of the document: the readme is a project that marks things done when they work rather than a roadmap with aspirational entries. ## A non-commercial licence, and the contributor rules explain why The licence is a Creative Commons attribution, non-commercial, share-alike one, which is a genuinely unusual choice for something that looks like a dotfile repository, and the readme spells out what it permits in plain language. You may view, use, modify and share with attribution for non-commercial purposes. Commercial sale is not permitted. Internal use for work and business is permitted. That last sentence is the one that matters for most readers, and it is unusually clearly drawn. You can use this at your company. You cannot sell it. For a two-minute setup made of shell scripts and markdown templates, that reads as a deliberate choice by someone who wants the pattern to spread and does not want to sell it, rather than as a licensing oversight. The contributor rules in the reusable directory explain the same instinct from the other side. Contributions must not include personal information, must be generic and configurable, must include documentation, and must follow existing patterns. Do not include personal information is the rule that matters, because the whole safety argument above depends on the reusable half never containing anything specific to its author. Generic and configurable sits in slight tension with the hard-coded caps discussed earlier. One says make it configurable, the other deliberately refuses to be. If you contribute, that tension is the design question you will be asked about, and it is the right one to be asked. ## Conclusion Two things to decide before you adopt this. The first is the licence, which is a non-commercial one: internal use at work is explicitly allowed, selling it is not, and for a two-minute setup made of markdown that is a fair trade rather than a trap. The second is whether you want a system that refuses to let you have eleven things to do today. The priority caps are three and seven, and they are the only real opinion in the repository. Everything else is a template and a prompt. Judge it on whether your assistant actually honours the caps, because that is where the whole design lives, and where it will fail if the instruction template is too soft. The last recorded commit is from March 2026, so treat it as a pattern to copy rather than a dependency to version. ## FAQ ### What is PersonalOS? A task management framework for a locally running AI agent, and it is not an application. You write unstructured notes into a backlog file, you tell your assistant to process it, and it reads a markdown instruction template and writes prioritised tasks against a goals file. There is no server, no database and no interface beyond natural-language sentences. ### How do I set it up? Clone the repository and run one setup script, which the readme puts at about two minutes. The script creates the workspace directories, asks you questions about your goals and priorities, writes a personalised goals file from the answers, and copies the template files into place. Python is only needed if you want to run the optional server. ### What are the priority levels and how many tasks can I have? Four levels. The top one means do it today and is capped at three tasks. The second means do it this week and is capped at seven. The third is for scheduled work with no limit, and the fourth is for someday. The caps are hard-coded in the template rather than configurable, which is the only real opinion the repository has. ### Can I use PersonalOS at work? Yes. The licence is a Creative Commons attribution, non-commercial, share-alike one, and the readme states explicitly that internal use for work and business is permitted while commercial sale is not. If you intend to redistribute a modified version commercially, that is the part the licence rules out. ### Why are my tasks excluded from version control? So that the reusable half can be shared without your work going with it. The system lives in a public directory while your tasks live in a separate directory that is excluded, which is the opposite of the usual dotfile arrangement and is what makes forking the setup safe. ### What are session evaluations for? They are listed as a completed feature for reviewing what happened during a session with the assistant and learning from it, with a dedicated directory in the reusable system. The readme gives no further detail, so it is worth looking at that directory directly if reviewing past interactions is the part you care about. ## Sources - [amanaiproduct/personal-os on GitHub](https://github.com/amanaiproduct/personal-os) - [Issues](https://github.com/amanaiproduct/personal-os/issues) - [README](https://github.com/amanaiproduct/personal-os/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/amanaiproduct-personal-os