diff --git a/tasks_for_hammer.md b/tasks_for_hammer.md
new file mode 100644
index 0000000..f37099c
--- /dev/null
+++ b/tasks_for_hammer.md
@@ -0,0 +1,60 @@
+# Todos for Hammer
+
+Many of these are train of though.
+
+## Moltbot Authentication and Authorization for new users
+
+Moltbot isn't easy to share with other people.
+I want to give other people access but i don't want them to be able to access sensitive info like bitwarden passwords or change code in repos that they shouldn't have access to.
+
+Moltbot needs more than just skills. It needs authorizition with those skills too with mulitple users.
+
+If I think of moltbot as a SaaS, as the admin, i want to give many people access. I want to control what they can do with their moltbot.
+
+Moltbot shouldn't have skills. It should probably connect to an MCP that give it access controls.
+
+## Moltbot Best Practices
+
+- Prompt injection is the biggest and easiest security risk.
+- If Moltbot has an email, it must have a whitelist.
+- Moltbot should use MCPs with access control. It should be building its own MCPs with access control dashboard
+
+## Systematize App building
+
+When i ask moltbot to build an app, it should follow a procedure. It might go something like this:
+
+- Ideation: get an Idea of what it's building
+- When prototyping, it should use the same architecture everytime.
+  - SPA, Postgres, React, Dokploy, etc
+- Many apps use the same external services. need a process for giving claudbot access to the same test API key so it can use the same ones over an over
+- At somepoint, the app need to be a "production" app even if i'm the only user.
+- What are the phases of development?
+  - Ideation
+  - Development
+  - Test Deployment
+  - Verification by user
+    - if user likes it, go to Prod deployment
+    - if the user wants things changed, go back to development
+  - Prod Deployment
+  - after prod deployment user might want new features.
+    - what's the protocol? probably the user goes back to the test env and works on changes until they like it.
+    - the biggest chanllenges i see are DB migration.
+  - what happens it the rollout breaks?
+    - should probably have a staging env that periodically syncs with prod.
+  - if something breaks it prod, what't roll back protocol? what are the processing for rolling back?
+- what should always be in an application?
+  - logging
+  - testing
+  - metrics
+  - what tools are out there? what's best practice?
+  - user bug reporting? feature requests?
+  - partial feature rollouts?
+  - some of these features above will only be needed if i plan to make the app public.
+
+- I've never used stripe for payment. are there other options? what's easiest?
+- how to i protect myself legally? i know there are apps like termly but it seems expensive. What does pieter levels use?
+
+## Moltbot visibility
+
+Sometimes i'm working on many things in the telegram and it loses context.
+Moltbot needs different task context and needs to have a queue of task that i can see. If moltbot is like a single threaded CPU, it needs schedule and process with their own context. want to see this queue of tasks and be able to control what task get done in which order. For example, this document has many task, each of which has its own context and should be done sequetially (or in parrallel if possible).