I Wrote the Rules Down. The Agent Stopped Guessing.

Monday again. I opened Telegram, typed "run the deploy recap like last week," and watched Hermes ask me what deploy recap meant. Same question it asked the Monday before. And the Monday before that. I had explained the chore four times in three weeks like I was onboarding a contractor who kept forgetting the employee handbook existed somewhere in a drawer I never labeled.

That was the moment ai agent skills setup solo founder work stopped feeling optional for me. Not the VPS install. Not the BotFather token. Not the hermes setup --portal wizard I wrote about in my always-on agent overview. The boring layer on top: skills for repeat chores, SOUL.md for voice and boundaries, and tool permissions narrow enough that I could review diffs without pretending I read TypeScript like Max does.

I am Imani. I build micro-SaaS with AI tools and agents, not a computer science degree. I run Hermes on a twelve-dollar VPS and talk to it from my phone while I do other human things. The product does not care who wrote the code. It cares whether someone pays. Agents help with the middle only when you stop re-teaching them your rules every week.

This article is the deep room behind that overview post. If you have not installed an agent yet, start there. If you installed one and it keeps "improving" things you did not ask for, stay here. We are going to talk about the handbook, not the hero sprint.

Some examples below are illustrative. I will say when they are hypothetical. I am not going to pretend perfect agent configuration made me rich. It made repeat chores cheaper. That is a different and more honest claim.

If you already read my always-on agent post, think of this as the second floor. That piece answers whether you need an agent and how to stand one up. This piece answers why your agent still feels like a gifted stranger who keeps rearranging your kitchen. The stranger is not evil. The stranger never got the house rules in writing.

AI agent skills setup solo founder: why I stopped re-teaching Monday

The gap between "agent installed" and "agent useful" is not intelligence. It is memory with boundaries. Chat windows forget. Raw agents remember too much and guess too boldly. Skills and SOUL.md are how you turn an always-on co-builder into something closer to a contractor who read the onboarding doc.

When I say ai agent skills setup solo founder, I mean three layers working together. Tools decide what the agent can touch: files, shell, deploy hooks, APIs you explicitly allow. Skills are named workflows for chores you repeat: support theming, deploy recap, error translation. SOUL.md is the standing contract: how you want work done, what never gets touched without asking, how errors get explained to a tired non-coder at 11 p.m.

Miss any layer and you get a familiar failure mode. Tools only, no soul: confident chaos. Soul file full of poetry, no skills: polite re-explanations every Monday. Skills without narrow tools: workflows that can wander into production because nothing stopped them.

I learned this after my first month of agent hype. I gave Hermes wide permissions because wide felt like progress. It edited fast. It deployed once without me fully understanding the recap. Nothing catastrophic happened, which is almost worse, because I almost kept going. Almost is how non-coders ship regressions.

The fix was not a smarter model. It was operator paperwork. Boring. Effective. The same kind of boring that makes good build prompts work: constraints, stop rules, one job per message. Agents just need those constraints to persist across days.

If you are still validating whether strangers want your product, this article is premature. Close it. Open a notebook. Agents eat repeat maintenance. Validation eats courage. Do not swap them.

The Monday morning problem that skills actually fix

Monday morning problems are rarely dramatic. They are cumulative insults. You re-paste support emails. You re-explain that staging means staging. You re-state that live Stripe is not a suggestion box. You re-type the same ENV tags. By coffee number two you are not building. You are performing onboarding theater for software you pay to run on a server.

Skills fix the repetition part. Not the thinking part. A skill is a saved workflow: inputs, steps, outputs, and stop conditions. In Hermes terms, it is how you stop writing the same multi-paragraph instruction every time you want a deploy recap or a support theme summary.

Here is what a Monday looked like before skills. I pasted five support emails into Telegram. I asked for themes, not fixes. Hermes delivered themes. Good. Wednesday I pasted five more emails with a slightly different ask: smallest copy change only, do not code yet. Hermes coded anyway because I forgot to say that on Wednesday. Thursday I asked for themes again and got a redesign suggestion because the thread context was muddy. None of this was malicious. It was memory without a contract.

Here is what Monday looks like after a support-theming skill exists. I type the skill name. I paste emails. The skill already knows: themes first, no code without explicit second message, American English, plain error tone, stop if more than one file would change. The agent still might be wrong. It is wrong in a narrower box.

Say you run a twelve-dollar reminder tool with forty users. Support themes might repeat: timezone confusion, cancel button anxiety, export format requests. Those are skill candidates because they are weekly and text-heavy. "Should I pivot to agencies?" is not a skill candidate. That is a walk.

Skills also reduce emotional friction. Chat makes you perform competence. Skills let you text like a manager: short, specific, a little rude if needed. "Run deploy recap. Hold prod." That tone belongs in SOUL.md too, but skills carry the chore shape.

The Monday problem is a tax on attention. Solo founders do not run out of ideas. We run out of focus. Every re-explanation is focus leaked. Skills are plugs for known leaks. You still have to find new leaks yourself.

I keep a note called "agent eligible" on my phone. If a task happened twice in two weeks and fits one sentence, it is a skill candidate. If it happened once, it stays in chat. That note prevents me from building a skill library that impresses me and helps nobody.

There is another Monday problem people do not talk about: shame. You feel dumb re-explaining the same thing to software you configured. So you shorten messages. You skip context. You type "you know what I mean" like the agent is a friend who was at the same meeting. It was not. It was a process on a VPS eating tokens and guessing. Skills remove that shame spiral because the spec lives outside your head. You are not failing at communication. You are running a named workflow.

Compare that to how I prompt Bolt or Cursor when I am building. I split scaffold from feature. I write stop rules. I ask for plain summaries before I accept billing changes. Skills are that same discipline, frozen for chores that repeat after the repo exists. If you have not read my prompt AI to build micro saas piece, the mental model is identical: boring constraints beat brilliant vagueness.

SOUL.md is not a vibe document — it is your operator contract

Early SOUL.md attempts of mine read like Instagram captions for a productivity guru. "Be helpful, be proactive, be innovative." Innovative is how my agent added a fourth onboarding step I did not want. Helpful is how it rewrote error messages to sound like a yoga instructor congratulating you for a failed payment.

SOUL.md is not a vibe document. It is an operator contract you would leave for a new contractor who has shell access and no context about your customers. Short sentences. Plain American English. Explicit never-touch zones. Deploy gates. How to explain errors when I am tired. How to recap changes when I cannot read the whole diff.

Think of three buckets inside the file. Voice rules: no hype words, no corporate warmth, apologize once then fix, explain jargon like I googled "what is an API" in 2023. Boundary rules: never touch Stripe live mode without explicit message, never add onboarding steps without request, never delete data, stop if more than N files change. Recap rules: list files touched, list manual tests I must run, hold production if tests not confirmed.

My SOUL.md is ugly on purpose. It is not literature. It is enforceable preferences. "Never use the word seamless." "Ask before deploy." "If task is vague, ask one clarifying question and stop." That last rule saved me from midnight refactors more than any model upgrade.

SOUL.md also carries identity the agent cannot infer from code. I am a non-coder operator. I need plain summaries. I need risk called out in support-email tone, not engineer tone. When Hermes writes "refactored middleware," I need a follow-up sentence that says what users will notice. If that sentence does not exist, I should not deploy.

Update SOUL.md after every mistake that cost an hour. Agent added a signup field? New rule. Agent used cheerful failure copy? New rule. I keep a tiny changelog at the bottom with date, rule, why. "2026-03-12: never add onboarding steps without explicit request — vague improve onboarding message." That entry hurt once. It paid rent after.

Do not copy someone else's SOUL.md wholesale. Their risk tolerance is not yours. Their customers are not yours. Read mine for shape, not scripture. Your contract should sound like notes you would leave yourself at 11 p.m., not like a manifesto for a conference talk.

SOUL.md works best when it matches how you already write build prompts. Same operator voice. Same impatience with vagueness. The agent is not a different species. It is the same intern across days. Treat the file like HR paperwork for that intern.

One warning. SOUL.md cannot replace product judgment. It will not pick your ICP. It will not tell you to kill a bad idea. It keeps execution inside guardrails once you have an agenda. Agenda is still your job.

I used to think SOUL.md was optional personality fluff because the word "soul" sounds like something you write after yoga. Rename it in your head if that helps. Call it CONTRACT.md. Call it RULES.txt. The filename matters less than the function. You are externalizing decisions you cannot afford to re-make every session. Non-coders benefit disproportionately because we cannot skim git history and infer intent. We need the intent written in English a tired version of us can understand.

When Hermes disagrees with SOUL.md, SOUL.md wins. I revert the output, paste the violated rule back, and run again. Arguing with the model about whether cheerleading error copy was "more engaging" is a waste of the forty dollars a month I pay for infrastructure. Users want clarity when checkout fails, not encouragement.

How I structure a Hermes skill from a chore I hate

I do not start from skill syntax. I start from a chore I hate. Deploy recap is my canonical example. After every staging deploy I want the same output: files changed, user-visible effects, manual tests, hold production until I confirm. I was typing that request in slightly different words every time. The agent was guessing which parts mattered.

Earn the skill manually first

Run the chore with the agent three times without a skill. Screen-record mentally. What do you paste every time? What do you forget sometimes? What mistake happened when you forgot? For deploy recap I always pasted ENV=staging. I always forgot to say hold prod on the third week because I was optimistic.

Name it like a job, not a poem

Good: deploy-recap, support-theme, error-plain. Bad: mega-deploy-wizard, customer-empathy-engine. Names are for you at 7 a.m., not for Twitter.

Write inputs, steps, outputs, stops

Inputs are what you provide: commit range, pasted emails, error log, file path. Steps are what the agent does: summarize, propose smallest diff, run tests in staging, draft changelog. Outputs are what you need back: bullet recap, test checklist, explicit hold flag. Stops are non-negotiable: if more than two files, stop and ask; if task touches billing, stop; if tests fail, stop.

Here is a simplified shape I use in notes before I codify:

Skill: deploy-recap
Input: ENV tag, optional commit range
Steps: list files, plain summary, test checklist
Output: recap message + HOLD or OK for prod
Stop: >2 files, any auth/billing touch, failing tests

Your actual Hermes skill file will follow whatever format your setup docs specify. The shape matters more than the syntax. If you cannot write inputs and stops on a sticky note, you are not ready to codify.

Attach the skill to narrow tools

A deploy recap skill should not imply production deploy rights. Pair skills with permissions. The skill says what to do. Tools say what is allowed. When those disagree, tools win. I learned that the hard way when a recap skill casually included a prod deploy step because an old thread suggested it.

Review after every run for two weeks

Skills are living. My deploy recap skill gained a line about mobile Safari after a bug only appeared on phones. Skills are not trophies. They are maintained workflows.

Document the skill in plain language outside Hermes too. I keep a one-paragraph note in my ops doc: what it does, when to run it, what good output looks like. If the skill file is the only copy, you will forget the intent during a stressful week and blame the agent for following outdated instructions you never updated.

I spent four days once building a skill for a workflow I ran twice and never ran again. The agent was patient. I was not. Now I use the three-run rule religiously. Twice might be coincidence. Three times is a chore.

Say you have a PDF export tool. A fair skill might be export-error-translate: paste error, get plain English, suggest whether it is user error or bug, do not code until second message. An unfair skill is improve-export because that is a product meeting pretending to be automation.

Skills are how you package operational clarity. The same clarity that makes debugging AI code work: symptoms, steps, expected versus actual, smallest fix. A skill is debugging prevention for repeat tasks.

Tool permissions: the part nobody wants to configure

hermes tools is the command nobody wants to run because it feels like saying no to yourself. Wide tool access feels like progress. Narrow access feels like distrust. Good. You should distrust a system that can touch money, users, and production when you cannot read every line it changes.

Permissions are the real product decision. Not model brand. Not Telegram versus Slack aesthetics. What can run shell? What can write which paths? What can hit deploy hooks? What can read logs with customer email addresses in them?

How I stage permission expansion

Week one: read-only plus explain errors. Week two: staging write on known paths only. Week three: one chore skill with tests. Week four: deploy to staging via script, still hold prod. Revenue threshold: when MRR crosses a line where a broken checkout day would hurt, I re-read permissions and tighten anything that feels lucky rather than understood.

Short leash always includes Stripe live mode, auth provider settings, DNS, row-level visibility changes, deleting data, anything with customer PII I have not mapped, production deploy without recap approval. Longer leash includes copy in known files, components following existing patterns, staging tests, log summaries without raw emails, SQL drafts for me to review.

Map permissions to files, not vibes

"Write access" without paths is how agents wander. I tie write permissions to directories I understand at a product level: settings page folder, marketing copy, specific API route patterns. If I cannot name the folder, the agent should not write there yet.

Separate read logs from act on logs

Reading logs to summarize themes is useful. Running arbitrary shell because a log looked weird is how you delete the wrong cache at 1 a.m. Summarize first. Act second. Different messages, different days, if needed.

Telegram is not security

Your phone is the UI. It is not a permission model. Losing your phone should not mean losing your company. Gateway tokens rotate. VPS access is gated. SOUL.md says hold prod. Tools enforce paths. None of that is glamorous. All of it beats explaining to customers that checkout broke because you were tired and the agent was helpful.

Permissions also need calendar boundaries. I do not approve prod deploys from a bar. I do not run shell fixes when I am angry at a customer email. Human rules belong in SOUL.md. Technical limits belong in tools. Together they beat willpower.

When something goes wrong, widen logging, narrow writes, revert, update SOUL.md. Do not widen permissions because you are embarrassed about asking for help. That embarrassment is cheaper than a refund week.

Hermes tool configuration is not a one-time event. I re-run hermes tools after every incident, every new revenue tier, every time I add a payment feature. Permissions are a living document like SOUL.md. The agent does not remind you to tighten them. Your calendar should.

A practical example: my reminder tool added team invites as an experiment. Team invites touch auth visibility. Auth visibility went on the short leash list the same day. The skill for UI copy did not get auth write paths just because the feature was exciting. Excitement is not a permission model.

Read access deserves the same intentionality. Logs with customer emails are still customer data. Summarize themes, redact identifiers in recap, do not paste full inboxes into random threads. I learned that after forwarding a support dump to the agent in a public coffee shop mood. The agent was fine. My judgment was not.

My SOUL.md field guide: what I actually write

People ask for a template. Fine. Here is what my SOUL.md actually contains, simplified. Yours should differ where your product differs. Copy the structure, not every line.

Opening identity block

Two sentences max. Who I am as an operator. Non-coder. Micro-SaaS. Plain English always. Example shape: "You assist Imani, a solo founder who builds with AI tools. I do not read production code fluently. Explain changes like you are texting a tired friend."

Voice and copy rules

No hype words list: seamless, robust, innovative, leverage, game-changer. Error messages: direct, apologetic once, no jokes about failures. Support tone: short sentences, no corporate warmth. Onboarding copy: do not add steps unless message says add step.

Never-touch without explicit approval

Bullet list: Stripe live, auth config, production database writes, DNS, delete user data, deploy to production. Explicit means I typed yes in the same thread after recap. Not implied yes. Not "you seemed fine with it yesterday."

Default task behavior

Ask one clarifying question if task is vague, then stop. Prefer smallest change. Prefer existing patterns. If more than two files must change, stop and ask. Recap every write with: files touched, user-visible effect, tests I must run.

Environment tags

I start messages with PRODUCT, ENV, TASK when things get serious. SOUL.md tells the agent to request missing tags instead of guessing. ENV=staging is not optional for write tasks. Guessing staging versus prod is how non-coders learn bad words.

Changelog at the bottom

Date, rule, reason. Keeps me honest. Makes SOUL.md feel maintained, not abandoned. When the changelog stops growing, either I stopped making mistakes (unlikely) or I stopped paying attention (likely).

That is the whole field guide. No mysticism. If your SOUL.md reads like a novel, cut it. If it fits on one screen, you are probably close.

Pair SOUL.md with skills so the soul handles global rules and skills handle chore shape. Global plus local. Same pattern as good repo hygiene: eslint config plus per-script comments. You do not need to know that analogy deeply. You need to know the split.

Share SOUL.md with nobody by default. It is not a blog post. It contains your deploy fears and customer tone preferences. Treat it like a password manager entry: useful, private, updated when reality changes. I copy sections into skills when a rule is chore-specific, not when I want clout.

When a skill is earned vs when you are procrastinating

Not every repeat annoyance deserves a skill. Some repeats mean your product is unclear. Some mean you are avoiding outreach by tuning infrastructure. I have built beautiful skills on the same weekend I sent zero customer emails. The skills worked. My business did not.

Earned skill signals: chore happens weekly, inputs are stable, success is measurable, failure is bounded, review takes less than ten minutes. Procrastination signals: chore happened twice ever, task is "make it better," you are avoiding validation, you spent more time naming the skill than doing the chore once.

The three-run rule helps. Configuration cosplay feels productive because the terminal prints text. Customers do not care about your terminal.

Another trap: skills for thinking work. "Should I raise price?" is not a skill. "Summarize these five competitor pricing pages" might be. Thinking stays in chat or your notebook. Doing graduates to skills.

If you are pre-revenue with a landing page only, you might need zero skills. You might need one SOUL.md line: do not deploy anywhere. Honest.

I delete skills that have not run in sixty days. Dead skills lie to you. They suggest maturity you do not have. Keep the note of why you deleted it. Sometimes the chore died because the product changed. That is a win.

The procrastination test I use on Sundays: if I spent more than two hours on agent configuration and zero minutes on outreach or support, the agent is not the problem. I am hiding in infrastructure because infrastructure judges me less than humans. Skills setup can become the new "I need to reorganize Notion before I launch" trap. Same costume, different tab.

Earned skills feel almost disappointingly small when you write them. That is correct. A good first skill might be forty lines of instructions you already say out loud. If your first skill reads like a fantasy novel about autonomous business operations, delete it and go talk to a customer.

Wiring skills to real micro-SaaS workflows

Theory is cheap. Here is how skills sit on my actual weeks when a product has paying users and repeat chores.

Support Monday: run support-theme skill on pasted emails. Output themes and one smallest copy candidate. I decide. Separate message if I want code. Skill does not auto-code.

Staging Wednesday: ship a small UI change via agent with ENV=staging. Run deploy-recap skill. Test checklist on phone before I get cocky.

Research Friday: bounded competitor layout summary skill. No code. No roadmap decisions. Feeds my brain, not my repo.

Prod incident: no skill except error-plain first. Explain log in English. Smallest fix proposal. Human approves. Retest payments. Incident skills that auto-fix prod are how I almost became a cautionary tale.

Skills attach to calendar rhythms. That sounds rigid. It is relief. I do not wake up wondering how to talk to the agent today. I know what type of day it is.

Wire skills to human checkpoints. Agent proposes. Human approves. Especially for anything visible to users. The agent overview post calls this the review loop. Skills make the loop shorter. They do not remove it.

When a skill output looks too good, I get suspicious. Fast polish without me specifying criteria is a red flag. I ask what changed and why. Same habit as debugging: trust symptoms, verify fixes.

Cross-tool workflows are where skills shine. Bolt or v0 builds the first shape. Cursor explains a bug I reproduce twice. Hermes runs the weekly chore while I am on a call. The skill should reference which repo, which branch, which ENV. Ambiguous repo context is how you fix the wrong project and wonder why Telegram feels haunted.

I also keep skills boring on purpose. No skill should try to be clever across domains. support-theme does not also refactor auth. deploy-recap does not also rewrite marketing. Single responsibility sounds like engineer talk. It is also how non-coders stay sane when something breaks and we need to know which skill last touched prod.

The staging handshake I never skip

Staging is not a personality trait. It is a repeated message pattern. My handshake looks like this in practice.

I type ENV=staging in every write task. SOUL.md requires it. Skills assume it. If staging is broken, I fix staging before I touch prod. No heroics.

After every agent write, I run the same manual test script: sign up, sign in, pay in test mode, core feature, cancel or delete. Boring. The boredom is the point. Agents shorten paths to needing the list. They do not replace the list.

Recap must include hold prod unless I explicitly release hold in a second message. I treat accidental prod deploy like leaving the stove on. Maybe fine. Maybe not. I am not gambling.

Staging also means emotional staging. I do not review diffs when hungry. I do not approve deploys when angry at a support ticket. Calendar staging sounds silly until you ship a typo in the payment button because you were rushing to dinner.

If you do not have a staging environment, duplicate project, or preview deploy, build that before you widen write permissions. "I will be careful" is not a staging strategy. Non-coders need somewhere that is not customers to break things first.

Say your host gives preview URLs per branch. Great. Your skill should reference that URL in recap. "Preview: branch-123.host.app — run checklist there." Specificity beats hope.

The handshake also applies to model choice. I do not let a skill silently upgrade to a stronger model for write tasks unless the skill says so. Surprise intelligence is how you get surprise refactors. Predictable beats clever when you review like a user.

Finally, staging is a social contract with future-you. Future-you at 11 p.m. will approve anything to go back to bed. SOUL.md and skills exist partly to protect you from tired-you. That is not weakness. That is operations.

Debugging agent output when you cannot read the diff

Agents break prod too. When they do, skills and SOUL.md determine whether the failure is bounded. Wide tools plus vague tasks plus no recap equals weekend panic. Narrow tools plus stop rules plus plain recap equals Tuesday annoyance. I prefer Tuesday.

My debug loop is the same as debugging AI-generated code: reproduce twice, describe symptom not theory, ask for smallest change, test in staging, update SOUL.md with the mistake pattern.

Agent-specific addition: read the recap before you read the diff. If recap cannot explain user-visible impact, revert first and ask questions second. Non-coders do not owe anyone line-by-line review we cannot do. We owe users a working product and honest rollback when unsure.

When an agent touches twelve files for a tooltip change, that is not a model problem. That is permissions and SOUL.md failing. Revert. Add stop rule. Narrow write paths. Run again.

Keep a "agent incidents" note. Date, what happened, rule added. Same as SOUL changelog. Patterns emerge. Mine include: vague improve requests, late-night approvals, assuming staging when ENV missing.

If the same incident repeats after a rule, the skill is wrong or you are ignoring the skill. Both happen. Fix the system or fix your behavior. Sometimes it is both.

Debugging agent output is where SOUL.md and skills either pay off or fail publicly. A good recap lists files, user-visible changes, and tests. A bad recap says "improved error handling" like that means something to a person who pays twelve dollars a month for reminders. I reject bad recaps the same way I reject vague debug prompts: ask again with symptom language, or revert.

I also screenshot recaps when money is involved. Not because I distrust Hermes forever. Because my memory at 11 p.m. is worse than a PNG. Operator habits look paranoid until the first time they save you from approving a change you forgot by morning.

What changed after my worst agent week

Worst agent week was not a hack. It was death by helpfulness. Four onboarding steps became seven because I said "reduce friction" on a Thursday night. A settings toggle got "refactored" into something I could not explain. Support copy got cheerier while users were angry. Nothing technically exploded. Trust eroded. I spent a weekend reverting vibes.

What changed after:

I rewrote SOUL.md from scratch in one hour. Shorter. Meaner. More explicit.

I deleted two skills I had not earned.

I ran hermes tools and removed production deploy from default abilities.

I added the two-file stop rule globally.

I started typing HOLD PROD as its own message, not buried in paragraph three.

That week cost maybe twelve hours. Cheaper than losing paying users slowly.

Now when an agent week goes well, it looks boring. Two file changes. Clear recap. Tests pass. I go do outreach. That is the point. Agents are not the main character. The product is.

The worst week also changed how I talk to the agent in Telegram. I stopped writing paragraphs at midnight. I started sending structured tags even when I was tired: PRODUCT, ENV, TASK, STOP. SOUL.md reinforced that pattern. Skills inherited it. The thread reads like work orders now, not diary entries. Less poetic. More shippable.

I tell people the deep setup takes one focused afternoon plus two weeks of small edits. Not because the technology is hard. Because you need real chores to tune against. Install on Saturday, earn skills on the third Monday, tighten permissions after the first scare. That timeline is honest for solo founders with a live product. It is too fast if you have nothing to maintain yet.

Questions I get about skills and boundaries

The handbook beats the hero sprint

I still google things I should probably know by now. I still cannot read a production codebase the way an engineer can. What changed is Monday. I do not re-teach deploy rules to a blank thread. I invoke a skill. SOUL.md keeps the voice consistent. Tools keep the blast radius small.

Ai agent skills setup solo founder work is not glamorous. Nobody posts screenshots of a SOUL.md changelog for likes. That is fine. Likes do not pay hosting. Paying users do. And paying users notice when onboarding randomly grows extra steps, not when your Hermes config is elegant.

If you have an agent running wide open today, close one door tonight. Not all doors. One. Add one stop rule. Write one skill after the third repeat. Test in staging like you mean it. The handbook grows page by page. Hero sprints fade by Friday.

You already did the hard part if you have paying users and repeat chores. You proved strangers would pay. Now stop re-explaining yourself to software every Monday. Write the rules down. Let the agent read them. Go talk to a human instead.

Start tonight if you want a concrete first step. Open a blank doc. Write three never-touch lines you already believe about money and user data. Run one chore manually three times next week. Notice what you repeat. That is your first skill outline. Everything else in this article is commentary on those two actions.

That is the whole deep setup. Not magic. Memory with boundaries. The product still does not care who wrote the code. It cares whether someone pays. Skills and SOUL.md just help you ship without teaching the same lesson to a machine every week like it is new hire orientation day forever.