diff --git a/.agents/docs/linkedin.md b/.agents/docs/linkedin.md index e67c070..25b247c 100644 --- a/.agents/docs/linkedin.md +++ b/.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. diff --git a/.agents/skills/add-feed-post/SKILL.md b/.agents/skills/add-feed-post/SKILL.md index a31a5bc..1a473d1 100644 --- a/.agents/skills/add-feed-post/SKILL.md +++ b/.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) diff --git a/content/feed/git-for-production-data/gitflow.png b/content/feed/git-for-production-data/gitflow.png new file mode 100644 index 0000000..1fbb416 Binary files /dev/null and b/content/feed/git-for-production-data/gitflow.png differ diff --git a/content/feed/git-for-production-data/index.md b/content/feed/git-for-production-data/index.md new file mode 100644 index 0000000..2cf3227 --- /dev/null +++ b/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! + + + +