i lesser considered parameter for workplaces: Barselsvilkår

[jakob1379]

Momkind (the brand) has build a public database around this topic - for some people this might be worth more than salary and other benefits, but is seldom discussed or negotiated at interviews.

https://airtable.com/apphCAMeWgwQEv6BT/shrVodlXqS6TBEN6D

Having this as an additional parameter to search for would be great, though keep it optional as it is not a universal criteria

[MadsLorentzen]

Good observation - benefits like parental leave are real decision factors that rarely get negotiated, and I like that you flagged it as optional up front.

Two halves to this: the criterion is already supported - deal-breakers and preferences in the profile are free-form, and the evaluation rubric scores against whatever you put there, so "strong parental-leave terms" can carry real weight in /rank and fit evaluations today, and /interview can prompt you to actually ask about it.

The data source is where I would hold back upstream: the Momkind database is Denmark-specific, and the template stays market-agnostic - same reasoning as with portal skills. For a Danish fork/adaptation it would be a great enrichment though, and I would happily see it shared in #78.

[jakob1379]

I am not sure if this has already been discussed too; Have you thought about adding an extension system making it easier for people to build modules that can easily be added and extended, similar in nature to https://github.com/facelessuser/pymdown-extensions ?

[MadsLorentzen]

That's a genuinely good question, and my answer is going to be a reframe rather than a yes or no: the extension system you're describing mostly already exists - what's missing from it is missing on purpose.

The repo has three extension points today. Portal skills are the strongest: /add-portal generates a self-contained folder with a documented contract and an enabled flag, /scrape auto-discovers any installed *-search skill, and the portal table in #78 is the catalog - open the fork, read the code, copy the one folder in. That's pymdown's model, with one deliberate difference: the install step is manual. Templates are the second (/add-template registers any engine since #238). Evaluation criteria are the third, and it's the one your Barselsvilkår idea lives in: deal-breakers and preferences are free-form, so a criterion is one profile line - no module needed. What has no vehicle is market-specific data sources (the Momkind DB, award-rate tables), and that's a policy line rather than a gap: those belong in market forks, shared via #78.

The two pieces a "real" extension system would add are the ones I'd decline:

• An installer. This template ships pre-approved execution - fork users' settings allowlist running the portal CLIs. Tooling that pulls third-party folders into that pre-approved zone punches a hole through exactly the supply-chain wall the CI guards were built around (ci: add supply-chain guards — permission allowlist, gitignore rules, manifest checks, pinned actions #84). "Copy the folder and read the code first" isn't missing convenience, it's the security model.
• A stable module API. pymdown works because Python-Markdown's extension API is versioned, stable code. Here the equivalent surface is prompt-file conventions, and those evolve constantly (the evaluation framework changed twice this month). Freezing them into a compatibility contract for third-party modules would turn every framework improvement into a breaking-change negotiation. That cost lands on every future contributor, not just me.

Where your instinct does point at something real: none of this is documented as an extension model. It's folklore spread across #78, /add-portal, and closed PRs. So here's what I'll take from this: a docs section - "Extending the framework: portals, templates, criteria, and borrowing from other forks" - that spells out the three extension points, the copy-a-folder pattern, and the read-before-you-run rule. That makes #78 formally the catalog it already informally is, and gives module-shaped contributions a described home without new infrastructure.

And if criteria-pack demand genuinely materializes (several markets wanting rubric add-ons), there's a lightweight convention I'd consider long before an installer: criteria modules as plain markdown files referenced from the profile. Not now - two requests in a week is contributors having good ideas, not users hitting a wall - but the door isn't ideological.

[MadsLorentzen]

The docs section from my last reply is live: 7a753f3 - README now has "Extending the framework: portals, templates, criteria - and borrowing from other forks" under Customization. Thanks for the nudge that turned folklore into documentation.