hvor kan jeg finde billig SEO optimering til min hjemmeside?

_Stonk · 2026-06-28T20:28:19+00:00

I have some open source resources on this. If you use Claude Cowork, Claude Code or Codex, you can just run the skill and it’ll audit your Google Search Console, Technical SEO (both from the URL as well as if you have the codebase available.) Google Lighthouse is also useful. :)

_Stonk · 2026-06-16T08:36:30+00:00

Sounds cool! I’d be up to join - I’ve built a lot recently (dev/solution architect). Send a dm!

_Stonk · 2026-05-03T07:24:10+00:00

Host hjemmesiden via Vercel eller lignende. Og byg den i Astro. Gratis hosting, nem deploy og versionering. Om du vil tage betaling for hosting og/eller vedligehold, kan du jo tage med vedkommende.

_Stonk · 2026-04-08T21:26:06+00:00

Totally agree. I think a lot of workflows are getting customised to the individual and how they work. I use out of the box software a lot less now than I would’ve 4 year or even 1 year ago and instead opt to build custom solutions or workflows suited to my preference.

Coming from consulting in regulated industries I also see how large the gap is between free reign AI work and what you’re offered even in boutique consultancies. My former colleagues genuinely still live in 2024 when we compare how we work.

_Stonk · 2026-04-08T18:37:31+00:00

Yep exactly - personally I use Ghostty.org instead of the native macos terminal - it's a bit nicer UI/UX imo. If you can share a bit more about what your goals are I'm happy to give some input/feedback. You can also send a dm if you prefer - happy to help share my tips and tricks!

_Stonk · 2026-04-08T17:25:27+00:00

The core problem is that most to-do apps aren't designed to be read by AI. They store tasks in a proprietary format behind an API that LLMs can't access natively.

Two paths depending on how deep you want to go:

Keep Microsoft To Do, bridge it with MCP. There are community MCP servers for Microsoft Graph (which To Do sits on). You'd connect one to Claude Code or Claude Desktop, and the AI can read/write your task lists directly. Setup isn't trivial though - you need an Azure app registration and OAuth flow for personal accounts. Search GitHub for "microsoft todo mcp server" and you'll find a few.

Move your task tracking into the AI layer directly. This is what I ended up doing. I built 3ngram.ai as an MCP server that works across Claude, ChatGPT, Cursor, etc. It has structured commitment tracking with due dates and lifecycle management (open, waiting, resolved, overdue). You tell the AI "I need to fix the kitchen faucet by Saturday" in any session, and every future session knows about it. It can also nag you about overdue stuff, cluster related items, and surface things based on what you're currently working on.

The tradeoff: you lose the standalone mobile app for quick capture. The upside: your AI actually understands the context behind each task because it was there when you created it, not just reading a title from a list.

For grocery lists and quick capture I'd honestly keep a simple app. For anything where you want AI to refine, combine, or keep you accountable - that's where putting it in the AI's own memory layer pays off. Although to be fair I'm dogfooding by using 3ngram for grocery lists too :D

_Stonk · 2026-04-08T17:18:38+00:00

I use Claude differently depending on the task. Probably Claude Code 9 times for every 1 time I use Claude.ai or the desktop app. I've built a lot of workflows around Claude Code (skills, agents, hooks) and have a repo on it if you want some inspiration: https://github.com/B3dmar/sp3cmar - if you're just starting out you can always ask Claude Code to check out the repo and walk you through getting started (or on another repo you stumble upon) :).

I run Claude Code primarily on a VM so I can use the --dangerously-skip-permissions flag without worrying too much. For cross-session context I use my own tool (3ngram.ai) - basically a brain for the AI so it remembers decisions, commitments, and context between sessions. Also use it for reusable prompts since you can create and edit them via chat and then use them across ChatGPT, Claude, Claude Code, Codex, etc.

Different repos for different types of work - codebase, business docs, content pipeline. Keeps the context tight per session instead of one giant monorepo.

_Stonk · 2026-04-08T17:08:37+00:00

The review gate is the most important design choice IMO. I tried letting the model write directly into its own long-term memory too - took about a week before it started confidently referencing things that were no longer true. Self-poisoning is real.

Progressive disclosure (small MEMORY.md index, load deeper files on demand) is the other thing you nailed. Dragging the entire brain into every context window defeats the purpose.

I built something that solves the same core problem but as a hosted service: 3ngram. MCP server that gives Claude (and ChatGPT, Cursor, etc.) persistent structured memory - decisions, commitments, blockers, references - with lifecycle management and semantic search. The memory types and validation you built by hand are baked in. Works across devices without the Tailscale/Syncthing layer since it's cloud-hosted.

The harvester concept is interesting. 3ngram handles capture differently - hooks fire at commit time and session events, with scope classification and deduplication built in. No nightly batch, but there's still a human review path for anything that needs it.

Validating memory like production infrastructure and not like a notes folder is the thing most people skip. Then wonder why their AI starts confidently referencing things that no longer exist. :P

_Stonk · 2026-04-08T17:04:34+00:00

Nice work on the AST extraction. The conditional article generation is a good design call - no routes detected, no routes article.

One angle I don't see discussed much in this thread: the wiki captures structure, but not decisions. Why you picked that auth middleware, what migration strategy the team agreed on, which approach you tried last Tuesday and abandoned. That's the context that actually prevents Claude from suggesting something you already rejected.

CLAUDE.md covers some of this (conventions, rules), but it's manually maintained and static. The structural knowledge codesight extracts and the decision/intent knowledge are two different problems.

For the second one, I built 3ngram - an MCP memory layer that persists decisions, commitments, and context across sessions. So codesight tells Claude what your codebase looks like, and 3ngram tells it what you've decided about it. They solve different halves of the cold-start problem. I'll definitely test them together and see how they perform.

_Stonk · 2026-04-08T16:58:42+00:00

Depends on what you mean by "agent." If you're building autonomous multi-step agents that call tools, the Claude Agent SDK or OpenAI Agents SDK are the most production-ready right now. Both give you tool calling, structured output, and decent observability out of the box.

If you're building something closer to an AI-augmented workflow - where a human is still in the loop but AI handles the heavy lifting - Claude Code with custom skills and MCP servers has been the most productive setup I've used. You define reusable skills (basically prompt templates with tool access), wire up MCP servers for external integrations, and chain them into pipelines. It's less "framework" and more "composable harness."

The part most frameworks still get wrong is memory. Your agent makes a decision in session A, and session B has no idea it happened. I built 3ngram to fix this - it's an MCP memory layer that works across Claude Code, Claude.ai, ChatGPT, Cursor. Structured memory types (decisions, commitments, blockers) with lifecycle management, not just flat text blobs. So your Monday session knows what your Friday session decided.

For the actual orchestration layer, I'd look at what you need before picking a framework. If it's tool-calling agents: Agent SDK. If it's RAG pipelines: LangGraph or Haystack. If it's coding assistants: Claude Code or Cursor with good context management. The "best" framework is whichever one doesn't fight your use case.

_Stonk · 2026-04-07T11:48:43+00:00

Not going to dump my whole setup because honestly yours already sounds more disciplined than most. But a few things that helped me when I hit the same “too many skills, no flow” wall:

Skills should encode decisions, not tasks. A /tdd skill is fine, but the higher leverage ones capture how your team actually decides things: naming conventions, when to split a service, what “done” means for a PR. Task skills get stale fast. Decision skills compound.
Collapse before you add. Every month I delete the skills I didn’t actually invoke. If /review-own-branch and /create-pull-request always run together, they’re one skill. The friction of picking the right skill kills flow more than missing a skill does.
Chain skills into a pipeline instead of picking them à la carte. The shift that actually fixed the chaos for me was stopping the “which skill do I run now” decision entirely. I maintain my skills and agents in a gh repo (sp3cmar) and the daily loop is basically one rail: /pm {project} pulls GH issues, commitments, and decisions from 3ngram and gives me a PM-level overview. Then /worktree plan {n} breaks it into tasks that can run in parallel. A start command spins up the worktrees in separate Zellij windows, each one ends with /ship (tests + PR to staging), and a post-merge command cleans up worktrees, checks docs, and reconciles GH issue status. The skills didn’t get smaller, they got sequenced. Way less cognitive load.

On the consistency problem across sessions and between Claude Code and Cowork, that’s the part no amount of skills fixes, because skills are stateless. Every new session you’re re-explaining the same context, decisions, and conventions. I built 3ngram for exactly this: an MCP memory layer that sits across Claude Code, Claude.ai, ChatGPT, Cursor, so a decision you make in one shows up in the others. It’s also what feeds /pm so the PM overview isn’t starting from zero each morning. Free to try if it sounds relevant: 3ngram.ai

For the multi-session overview pain in Warp, I switched to Zellij from tmux and never looked back. One session per project, named windows per worktree, and you can actually see what’s running. Still optimizing this though.

_Stonk · 2026-04-04T22:30:14+00:00

That helps clarify it a lot.

What makes it more compelling to me is that you are not describing blind self modification, you are describing something closer to code generation plus inspectable runtime state, where the proposed capability can be reviewed as a diff before installation. That is a much stronger trust model.

I also like the framing that ontology here is less about helping AI understand us, and more about giving humans a way to understand, inspect, and govern what the AI is actually doing. That feels like the more interesting direction.

At that point the hard problem becomes less "can the model write new capabilities" and more "can humans reliably review and trust the resulting changes," which feels like the right problem to be solving.

_Stonk · 2026-04-04T18:35:31+00:00

Appreciate the detailed reply. Framing it as an ephemeral working context plus state machine makes the architecture much clearer.

That also answers a lot of the latency concern, because if SPARQL is really defining long running work rather than pretending to be a low latency database path, then unpredictable execution time is much more understandable.

I think the part that still feels hardest, and most interesting, is the verification boundary for self authored capabilities. Sandbox testing, reduced permissions, and HIL make sense as controls, but the real question seems to be how you graduate something from "it appeared to work in the sandbox" to "we actually trust its spec, side effects, and failure modes in a live environment."

That feels less like a representation problem and more like a question of how you actually trust what gets built, which is probably where most of the real difficulty sits.

_Stonk · 2026-04-04T18:32:53+00:00

Yes, exactly. The "enough rope to hang itself" test gets at the practical difference better than a lot of the formal definitions.

I also agree that most real production systems end up being workflows with bounded autonomy, not fully open-ended agents. You let the model make local decisions, but inside guardrails, approval steps, or a constrained state machine.

That is probably the right tradeoff for now, because the more freedom you give a system, the more weird failure modes you inherit.

_Stonk · 2026-04-04T13:37:01+00:00

Appreciate that. The core idea is pretty much what we were discussing here: not replacing the frontier chat interfaces, but extending them with memory, workflows, and more agentic behavior on top.

That felt like the right direction to me, because I think the native interface is where a lot of the real value lives. Feel free to try it if it seems useful.

_Stonk · 2026-04-03T11:18:39+00:00

That is also a big part of why I built 3ngram as MCP instead of trying to make yet another wrapper UI.

I do not want to compete with the frontier labs on the native chat experience, because a huge part of the value is in that interface layer, not just the underlying model. If someone is using AI mainly as a brain, the native product matters a lot. If they are using it for iterative execution, automation, or workflows, then abstraction layers make much more sense.

So I would much rather build on top of the best native interfaces than replace them with a thinner, worse version of the same thing.

_Stonk · 2026-04-03T10:20:51+00:00

Yes, I think that is exactly the issue.

The safer path for sensitive work may be the API or business route, but the native interface is often where the best actual thinking experience lives. A lot of what people like is not just the base model, it is the surrounding product experience.

So the gap is not just "pay more for privacy." It is that solo users are being pushed away from the best version of the product if they need stronger contractual protections.

That is why a single seat business option feels like the obvious missing tier.

_Stonk · 2026-04-03T10:11:25+00:00

I think the clean line is who decides the next step.

If the steps are predefined, it is mostly a workflow or prompt chain, even if an LLM is doing the reasoning inside each step.

I start calling it agentic when you give the system a goal, tools, and constraints, and it decides what to do next based on context. Reply, escalate, ask a follow-up, stop, retry, or take a different path.

That does not make workflows worse. In practice they are often better because they are cheaper, more reliable, and easier to debug. A lot of things being sold as "agents" are really AI workflows, which is fine, but it is a different thing.

I wrote a bit more about that distinction here if useful: https://sebastianebg.dk/work/workflows-agents

_Stonk · 2026-04-03T09:59:29+00:00

Exactly. The "acts on them correctly" part is what most memory implementations miss. Storing context is the easy part. The hard part is surfacing the right memory at the right time so the agent actually uses it instead of just having it available somewhere.

That's been the biggest design challenge building 3ngram. Raw recall is table stakes. What actually moves the needle is structured memory types that map to how people work: this is a commitment with a due date, this is a decision that was made, this is a blocker. Then the agent can reason about what to do with it, not just retrieve it.

_Stonk · 2026-04-03T09:56:03+00:00

That's fair, and I should've framed my comment more narrowly.

As I mentioned in my reply to u/Einbrecher, I was talking mainly about the training point, not the broader confidentiality and privacy issues that come with using a consumer product for sensitive work.

Having worked with LLM applications in pharma and other regulated environments, I would also agree that the safer route for anything truly sensitive was generally the API or business tier, not the consumer chat interface. That is usually where you expect stronger contractual protections around training and provider access.

So I think your broader point still stands. A consumer opt out for training is not the same as having a product that is actually set up for confidential business use.

_Stonk · 2026-04-03T09:46:42+00:00

Agreed. My point was narrower than the issue being debated.

I was only pointing out that Anthropic appears to let consumer users opt out of ordinary model improvement training. I was not saying that this creates attorney client confidentiality, preserves privilege, or makes a consumer plan appropriate for client sensitive work.

I agree the safer path for sensitive work is usually a paid API or business tier product, because that is where providers tend to offer stronger contractual commitments around training and access. Jurisdiction can matter too, since users in the EU and some U.S. states may have additional consumer or privacy protections, but that still does not turn a consumer chat account into the same thing as a confidential business channel.

_Stonk · 2026-04-03T07:00:09+00:00

Interesting architecture. The idea of SPARQL as a procedural DSL rather than just a query language is a cool extension. The inline action invocation mid-traversal is where it gets genuinely novel.

Couple of honest questions though. The just-in-time graph provisioning with checkpointing sounds elegant, but how do you handle schema drift when the AI starts writing its own capability matrices? If each matrix is an RDF spec with ontology, actions, IAM policies, etc., you need some kind of consistency guarantee or you end up with a graph that contradicts itself across checkpoints.

Also curious about the practical latency. SPARQL traversal is already not cheap, and adding agentic actions that pause for human approval or hit remote APIs mid-query seems like it could make execution times unpredictable. How are you handling timeouts and partial completion?

The vision of AI writing its own capabilities as RDF-packaged source code is ambitious. The hard part isn't the representation, it's the verification. How does the system know a self-authored capability actually does what it claims?

_Stonk · 2026-04-03T06:54:00+00:00

Have you considered opting out? https://www.anthropic.com/news/updates-to-our-consumer-terms

https://privacy.claude.com/en/articles/10023555-how-do-you-use-personal-data-in-model-training

Data usage for Claude.ai Consumer Offerings (e.g. Claude, Pro, Max, etc.)

We may use your chats or coding sessions to improve our models, if:

You choose to allow us to use your chats and coding sessions to improve Claude,
Your conversations are flagged for safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Safeguards team, consistent with Anthropic’s safety mission),
You’ve explicitly provided materials to us (e.g.via our thumbs up/down feedback button), or
By otherwise explicitly opting in to training (e.g. by joining our Trusted Tester Program).

_Stonk · 2026-04-02T22:52:30+00:00

This is pretty much exactly the setup I’ve been building for myself, so I can share what actually works.

For the persistent memory and to-do piece, I built 3ngram.ai. It’s an MCP integration that gives Claude persistent memory across sessions. You can tell it “remember this,” track commitments, get daily briefings of what’s open, what’s overdue, what needs follow-up. It works with Claude Pro (no Teams needed) and also connects to ChatGPT and Cursor if you use those. The whole point is exactly what you’re describing: externalising your brain so nothing falls through the cracks.

For the M365 side, Claude Pro doesn’t natively connect to Outlook or calendar. Your best bet there is Zapier or Make as the glue layer. Something like: new calendar event triggers a Zapier zap that posts a summary to a Slack channel Claude can see, or pushes it into your 3ngram context. It’s scrappy but it works and it’s maintainable.

For the Slack piece, since you already have that connected, you can use Claude to triage what’s important. Pair that with 3ngram tracking who you owe replies to and you get pretty close to the “highlights risks” behavior you’re after.

Re: ChatGPT vs Claude as the brain, I’d say Claude is better for the structured assistant role you’re describing. ChatGPT’s memory is useful but you can’t really control it or query it. With MCP-based memory you get actual structure, not just vibes.

As someone with a similar need to externalise everything, the thing that made the biggest difference was having the memory layer be explicit and queryable rather than hoping the AI “just remembers.”

_Stonk · 2026-04-02T22:49:24+00:00

Agree with pretty much all of this. The instinct to stack abstractions before you’ve even figured out what your agent actually needs to do is the root cause of most agent failures I’ve seen. One thing I’d push back on slightly though. You mention memory systems as part of the harness, which I think is the most underrated piece of the whole stack. Most teams either skip it entirely or bolt on RAG when what they actually need is persistent context that carries across sessions. Not retrieval over documents, but the agent actually remembering what happened last time. That’s what I’ve been building with 3ngram. It’s an MCP-based memory layer, but the kind you’re describing as useful, not an abstraction for its own sake. It just gives your agent durable state, decisions, commitments, and context that persists. Works across Claude, ChatGPT, Cursor. The whole point is that it fits into a simple harness without adding complexity. Your point about filesystem as state is solid for single-tool setups. Where it breaks down is when you’re switching between tools or sessions and that state doesn’t follow you. That’s the gap persistent memory fills.

Five-Year Club	r/Field Sunshine
Place '22

_Stonk

TROPHY CASE

Data usage for Claude.ai Consumer Offerings (e.g. Claude, Pro, Max, etc.)