jlong

A context repository is a git repo of Markdown files where you store the documents your AI needs to operate with real understanding. Product vision, PRDs, feature specs, customer profiles, glossary — all versioned and reviewable, where both humans and agents can find it.

Why Markdown in git instead of Notion? Local files are instant (no MCP latency). Markdown is token-efficient — no rich-text metadata, just content. And git gives you versioning, branching, and reviewable PRs for free. When you update five documents as part of a product pivot, that's one PR you can roll back.

Then you add an AGENTS.md to the root of your project that links to the important documents. Think of it as a table of contents for your AI. When an agent picks up a task, it reads AGENTS.md first, then follows the links as needed.

Most AGENTS.md files try to do too much. Treat yours as a table of contents — link to essential docs, let your LLM know where to look, and keep the file itself short and scannable.

There are some activities that make everything else more productive. I call these sweeping activities. The idea is that these activities straighten out the work, make the goals concrete, and make it easier to get everything done.

I'm actually looking for something that allows me to teach my own courses.

Thanks! It's pure CSS3 rounded corners and gradients.

The core product hasn't really changed in years. Most of the time when I get an upgrade it's only so I can feel more current. I could be content with Fireworks 4 if necessary.

And what are you using? I have observed the world and my observations about web designers are completely different.

I have asked before for references or articles supporting your point of view and you have not posted anything. @charlesr posted some excellent links below. Where is the evidence that supports your perspective?

It sounds like we have both had very different experiences with other designers.

I don't seem to be making any headway with you on this, so this will probably be my last reply on this thread. But I'm speaking as a professional web designer that has a programming background. I see a lot of correlation between the two.

If we were talking strictly design (as in art) your point would hold a little more weight with me, but we are talking about web design. The skills that are required here are not that different from the skills that are required by a programmer. One is very visual it is true, but both require strong troubleshooting skills.

I'm not sure about the whole left/right brain thing. I'm speaking from my experience of what it takes to be a good web designer.

Is programming strictly a right brain activity? I hear a lot of talk about beauty and design in programming circles today. Clearly it is not all cold crisp logic. You aspire towards beauty and function just as much as designers do.

All I can say is try it for a while. A month or two at least. I don't think the issues that you are anticipating are as great as you think they are.

Um, you are missing my point completely.

CSS is not a programming language.

However, when you are dealing with CSS related bugs in browsers a high level of determination and problem solving ability is required to get to the bottom of each bug. The same kind of determination is required to debug Ruby or Java or any other programming language.

So the jump from competent web designer to programmer is not as far as you might think. They actually require a similar skillset.

Web designers? Again, to be good at web design you have to develop many of the same skills as programmers. Debugging CSS/HTML is about the same as debugging code.

I'm not sure what enjoyment has to do with it.

In my opinion Web design requires a very similar skill set. Debugging CSS/HTML takes a programmer's mindset. It is not that difficult for most designers to make that jump. Many of them have picked up Javascript just fine.

This is exactly my point.

Designers don't like programming? Most web designers I know want to know more about programming and jump at the opportunity to learn. Can you provide references or articles to back up your assertion?

Um, tools like Compass, Serve, and the Rails plugin totally remove any awkwardness.

"What's next for CSS? Probably CSS Current_Version+1, designed by committee [...]"

But this is the beautiful thing about popularizing the concept of compiling to CSS. Once you are liberated from the Browser's implementation a whole new world opens up. Experimentation can be conducted in languages that compile to CSS.

Right now the reason why we need a committee to decide what goes into CSS is that we all suffer the consequences if they get it wrong. With languages that compile to CSS, bad ideas only hurt that language.

Freedom for experimentation can only be good for CSS in the long run.

For development I like to use Serve: http://github.com/jlong/serve

I prefer to call it a designer's programming language. BTW, Sass does have simple control statements (if and while). I didn't cover all of the things that Sass can do. To get that see: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html

Possibly. Perhaps it correlates better with the gap between C and C++.

To be fair this isn't my technology. I didn't invent Sass. But having used it for over two years now I can say it is a huge improvement over CSS. And yes hopefully the features found in Sass will eventually make it into CSS, but if it replaces CSS or is incorporated into CSS isn't that the same thing?

Yup, the possibilities are endless. It should be built in.

Exellent point. Web apps are not the only use case.

Well for one, RSS is pull. This is push. RSS also requires that you subscribe. This wouldn't necessarily require that.