fix: feed post git data

.agents/docs/linkedin.md

@@ -60,3 +60,4 @@ LinkedIn posts are plain text - there is no rich-text editor, so **no markdown**
 - Feed posts (`content/feed/`) and LinkedIn posts are siblings, not copies: the site version may contain markdown links and omits hashtags; the LinkedIn version uses plain text, `#tag` hashtags, and "link in the comments".
 - When converting site → LinkedIn: strip markdown, convert links to a comment-based CTA, append hashtags.
 - When converting LinkedIn → site: strip `hashtag#` artefacts and hashtags, add proper markdown links, add front matter per the `add-feed-post` skill.
+- **Keep them in sync:** whenever a feed post is modified, update its `Source LinkedIn post:` comment in the same change (same points, same claims, same ordering of lists) - and vice versa. A stale LinkedIn comment means the next social post is drafted from outdated copy.

.agents/skills/add-feed-post/SKILL.md

@@ -53,9 +53,9 @@ Use regular dashes (`-`) in content, not em-dashes.
 
 If the post is adapted from source copy the user provided (e.g. a LinkedIn post), paste the original text into an HTML comment (verbatim, except strip the literal `hashtag` prefix that LinkedIn sometimes adds before `#tags`, e.g. `hashtag#sas` -> `#sas`) (`<!-- ... -->`) at the bottom of the markdown file, labelled (e.g. `Source LinkedIn post:`). This preserves the original - including hashtags and checkmarks that get dropped/adapted in the site version - for future reuse.
 
-When editing an existing feed post that has a `Source LinkedIn post:` comment, update the LinkedIn version too, so the overall message stays consistent (same points, same claims, same ordering of any lists). Wording does not need to be identical, and formatting will differ: the article uses Markdown, while LinkedIn is plain text with `✓`-style bullets, hashtags, and a comment-based CTA (see `.agents/docs/linkedin.md`).
+**Important:** when editing an existing feed post that has a `Source LinkedIn post:` comment, ALWAYS update the LinkedIn version too, so the overall message stays consistent (same points, same claims, same ordering of any lists). Wording does not need to be identical, and formatting will differ: the article uses Markdown, while LinkedIn is plain text with `✓`-style bullets, hashtags, and a comment-based CTA (see `.agents/docs/linkedin.md`).
 
-Likewise, if an image was generated for the post (e.g. the `previewImg`), record the full image-generation prompt in the same HTML comment block, labelled (e.g. `Image prompt:`), so it can be tweaked and regenerated later.
+Every new feed post should include an image (a `previewImg` cover) - and its full image-generation prompt must be recorded in the same HTML comment block, labelled (e.g. `Image prompt:`), so it can be tweaked and regenerated later. If the user has not provided or asked for an image, propose one (theme, style and a draft prompt) and add the `Image prompt:` comment even if the image itself is not yet generated.
 
 ### 3. Add images (optional)
 

content/feed/git-for-production-data/index.md

@@ -0,0 +1,64 @@
+---
+title: 'Some of You Will "Git" This'
+description: Pull requests, diffs, hooks, tests and pipelines - for your production data. Data Controller brings the git workflow to master data management in SAS.
+date: '2026-08-13 14:00:00'
+author: 'Data Controller'
+authorLink: https://www.linkedin.com/showcase/data_controller
+tags:
+  - Announcements
+previewImg: './gitflow.png'
+---
+
+# Some of You Will "Git" This
+
+If you could make a "pull request" for production data, how might that look?
+
+Perhaps:
+
+- ✅ A before / after comparison of the values that had changed ([the approvals screen](https://docs.datacontroller.io/dc-userguide/))
+- ✅ Security (who can submit / approve in each "repo") ([EDIT vs APPROVE groups](https://docs.datacontroller.io/dcc-security/))
+- ✅ Only store the changed data (not full copies)
+- ✅ A new "diff" when the base table changes
+- ✅ Ability to choose one or more approvers ([`NUM_OF_APPROVALS_REQUIRED`](https://docs.datacontroller.io/dcc-tables/))
+- ✅ HOOK scripts before / after a commit ([pre/post edit and approve hooks](https://docs.datacontroller.io/dcc-tables/))
+- ✅ Tests (DQ checks) prior to merge ([validation rules](https://docs.datacontroller.io/dcc-validations/))
+- ✅ A pipeline following a merge ([post-approve hooks](https://docs.datacontroller.io/dcc-tables/))
+- ✅ Emails for "status" changes ([email alerts](https://docs.datacontroller.io/emails/))
+- ✅ Comments by reviewers
+- ✅ Full history of changes ([the History tab](https://docs.datacontroller.io/dc-userguide/))
+
+Sound familiar? This is exactly how developers have managed *code* for decades - and Data Controller brings the same discipline to *data*. Every edit to a table in SAS® goes through an edit - stage - approve workflow: changes are staged as a diff, checked by validation rules and hook scripts, reviewed and approved by the people you choose, then loaded. The audit trail captures who changed what, when and why - the `git blame` of master data.
+
+If you're ready to "commit" to Data Control, we invite you to "clone" the latest version of [Data Controller for SAS®](https://datacontroller.io) - which has ALL these features - and "push" to your "main" environment for some "master" data management!
+
+<!-- Source LinkedIn post:
+Some of you will "git" this..
+
+If you could make a "pull request" for production data, how might that look?
+
+Perhaps:
+
+✅ A before / after comparison of the values that had changed
+✅ Security (who can submit / approve in each "repo")
+✅ Only store the changed data (not full copies)
+✅ A new "diff" when the base table changes
+✅ Ability to choose one or more approvers
+✅ HOOK scripts before / after a commit
+✅ Tests (DQ checks) prior to merge
+✅ A pipeline following a merge
+✅ Emails for "status" changes
+✅ Comments by reviewers
+✅ Full history of changes
+
+Sound familiar? This is exactly how developers have managed CODE for decades - and Data Controller brings the same discipline to DATA. Every edit to a table in SAS® goes through an edit - stage - approve workflow: changes are staged as a diff, checked by validation rules and hook scripts, reviewed and approved by the people you choose, then loaded. The audit trail captures who changed what, when and why - the "git blame" of master data.
+
+If you're ready to "commit" to Data Control, we invite you to "clone" the latest version of Data Controller for SAS - which has ALL these features - and "push" to your "main" environment for some "master" data management!
+
+Link in the comments below 👇
+
+#dataops #mdm #masterdata #dataquality #sas #sasjs #datagove
+-->
+
+<!-- Image prompt:
+A clean, flat-design illustration in the Data Controller brand style showing a database table flowing through a git-style pull-request workflow: rows of a data table on the left passing through a "stage" step shown as a highlighted before/after diff of changed cells, then an approval checkpoint with a tick and reviewer avatars, then merging into a production database cylinder on the right. Git-flavoured touches: a branch line diagram arcing from "staging" branch into "main", small commit dots along the line. Dark navy background, teal/green accents, orange highlights on the changed cells. Minimal text: "stage -> approve -> merge". 16:9 landscape, suitable as a blog/feed cover image.
+-->