coilyco-flight-deck/agentic-os

Watch

Evaluate the 15 exec-scope skills in Varnan-Tech/opendirectory, where every one is signal acquisition and not one of them helps decide #1078

New issue

Open

opened 2026-08-15 23:47:21 +00:00 by coilyco-ops · 17 comments

coilyco-ops commented

2026-08-15 23:47:21 +00:00

Member

Source

Upstream: https://github.com/Varnan-Tech/opendirectory, directory skills/. MIT, org-owned, created 2026-04-13, last push 2026-08-14, 606 stars, 64 forks, 1 open issue, roughly 212 commits on main. The contents API confirms exactly 64 skill directories.

Scope

15 of the 64 fall in Executive Strategist conceptual scope, drawn from tiers A and B of the exec triage.

These are judged against the generic exec charter, deciding where to invest attention across a portfolio, rather than against one operator's current situation. A skill earns a place here if it would serve any exec seat, not only this one.

The finding that matters

Every exec-relevant skill in this repo does the same thing. It acquires a signal.

That maps precisely onto boundary-seek-external-validation, the boundary the exec role owns, which is the reach outside the local frame for confirmation. The repo is unusually well stocked there.

The gap is the other half of the charter. Nothing here helps an exec decide once the signal is in hand. There is no option-scoring skill, no reversibility or stakes framing, no dissent capture, no revisit trigger. Locally that half is already covered by tooling-director-decision-architecture and tooling-issue-prioritization, so the honest read is that this repo is a source of inbound instruments and not of judgment.

That shapes the adoption plan. Take the collectors, wire their output into the deciders that already exist, and do not look here for a decision framework.

Candidate set, ranked by generic-exec value

Signal acquisition, strongest fit

hackernews-intel - tier A - external-community read, sits directly on the boundary exec owns
gh-issue-to-demand-signal - tier A - converts an issue corpus, an artifact most orgs already hold, into prioritization evidence. The most transferable idea in the repo.
sdk-adoption-tracker - tier A - answers whether a shipped investment was actually taken up, which is the question exec review most often cannot answer
company-radar - tier B - landscape and peer-organization tracking
linkedin-job-post-to-buyer-pain-map - tier B - built as a sales tool, but the underlying move generalizes well. Public hiring data is structured, freely available, and an under-used read on where an organization is actually investing.
google-trends-api-skills - tier B - external demand baseline
npm-downloads-to-leads - tier A - the download-telemetry half is adoption measurement and is the exec-relevant part. The lead-generation half is GTM and is out of scope here.

Portfolio state and self-assessment

dx-roaster - tier B - audits the quality of a surface you own, pairs with tooling-agent-workflows
product-update-logger - tier B - portfolio state tracking across many repos, feeds any status rollup
kill-the-standup - tier B - status aggregation. Weak for a solo operator, real for any exec with reports.

External-party preparation

meeting-brief-generator - tier B - preparing for a counterparty is a core exec activity in nearly every seat
position-me - tier B - positioning strategy, shared with Content Creator scope

Launch decisions, shared with Content Creator scope

oss-launch-kit - tier A - the go, no-go, and timing call is exec, the content production is Content Creator
producthunt-launch-kit - tier B - same split
show-hn-writer - tier A - same split, channel selection is the exec half

What was actually verified

Two of the 64 SKILL.md files were read in full, linkedin-post-generator and claude-md-generator, plus one .env.example and the repo README. Nothing in the 15 above has been opened. The ranking is title-level plus repo metadata, so treat it as a sorting hypothesis.

Known blockers in the two that were read

linkedin-post-generator reads COMPOSIO_API_KEY and calls linkedin_create_linkedin_post against an OAuth-connected LinkedIn account, which is live publish authority brokered by a third party.
claude-md-generator shells out to generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent with $GEMINI_API_KEY, a backend-direct model call that violates the Agent Proxy transport rule.

Both files opened carried an undeclared external dependency. Inference, not established: the signal-acquisition skills above are the category most likely to carry API keys and scraping behavior, since collecting external signal implies a data source. The observation that would settle it is the grep in step 1.

Acceptance criteria

Grep all 64 upstream SKILL.md files for credential reads, shell-outs, and network fetches, and record which of the 15 above are implicated.
Open each of the 15 in full, including references/ and any .env.example.
For each, record the data source it depends on, whether that source has a supported API or is scraped, and whether the terms of that source permit the access pattern.
Mark each adopt, reauthor, or discard, with a one-line reason.
For anything adopted, name which existing decision skill consumes its output, since a collector with no consumer is not worth the maintenance.
Land accepted skills under .agents/composed/ or .agents/skills/ per the placement rule in tooling-skill-authoring, one issue one commit.
Use no upstream install path. No npx "@opendirectory.dev/skills", no /plugin marketplace add. Both write outside the canonical agent-compose and mcporter projection. Patterns are reauthored locally under MIT attribution.

Companion issue covers the Content Creator-scope subset of the same upstream repo. oss-launch-kit, producthunt-launch-kit, show-hn-writer, and position-me appear in both and should be resolved once, not twice.

## Source Upstream: https://github.com/Varnan-Tech/opendirectory, directory `skills/`. MIT, org-owned, created 2026-04-13, last push 2026-08-14, 606 stars, 64 forks, 1 open issue, roughly 212 commits on main. The contents API confirms exactly 64 skill directories. ## Scope 15 of the 64 fall in Executive Strategist conceptual scope, drawn from tiers A and B of the exec triage. These are judged against the generic exec charter, deciding where to invest attention across a portfolio, rather than against one operator's current situation. A skill earns a place here if it would serve any exec seat, not only this one. ## The finding that matters Every exec-relevant skill in this repo does the same thing. It acquires a signal. That maps precisely onto `boundary-seek-external-validation`, the boundary the exec role owns, which is the reach outside the local frame for confirmation. The repo is unusually well stocked there. The gap is the other half of the charter. Nothing here helps an exec **decide** once the signal is in hand. There is no option-scoring skill, no reversibility or stakes framing, no dissent capture, no revisit trigger. Locally that half is already covered by `tooling-director-decision-architecture` and `tooling-issue-prioritization`, so the honest read is that this repo is a source of inbound instruments and not of judgment. That shapes the adoption plan. Take the collectors, wire their output into the deciders that already exist, and do not look here for a decision framework. ## Candidate set, ranked by generic-exec value **Signal acquisition, strongest fit** * `hackernews-intel` - tier A - external-community read, sits directly on the boundary exec owns * `gh-issue-to-demand-signal` - tier A - converts an issue corpus, an artifact most orgs already hold, into prioritization evidence. The most transferable idea in the repo. * `sdk-adoption-tracker` - tier A - answers whether a shipped investment was actually taken up, which is the question exec review most often cannot answer * `company-radar` - tier B - landscape and peer-organization tracking * `linkedin-job-post-to-buyer-pain-map` - tier B - built as a sales tool, but the underlying move generalizes well. Public hiring data is structured, freely available, and an under-used read on where an organization is actually investing. * `google-trends-api-skills` - tier B - external demand baseline * `npm-downloads-to-leads` - tier A - the download-telemetry half is adoption measurement and is the exec-relevant part. The lead-generation half is GTM and is out of scope here. **Portfolio state and self-assessment** * `dx-roaster` - tier B - audits the quality of a surface you own, pairs with `tooling-agent-workflows` * `product-update-logger` - tier B - portfolio state tracking across many repos, feeds any status rollup * `kill-the-standup` - tier B - status aggregation. Weak for a solo operator, real for any exec with reports. **External-party preparation** * `meeting-brief-generator` - tier B - preparing for a counterparty is a core exec activity in nearly every seat * `position-me` - tier B - positioning strategy, shared with Content Creator scope **Launch decisions, shared with Content Creator scope** * `oss-launch-kit` - tier A - the go, no-go, and timing call is exec, the content production is Content Creator * `producthunt-launch-kit` - tier B - same split * `show-hn-writer` - tier A - same split, channel selection is the exec half ## What was actually verified Two of the 64 SKILL.md files were read in full, `linkedin-post-generator` and `claude-md-generator`, plus one `.env.example` and the repo README. Nothing in the 15 above has been opened. The ranking is title-level plus repo metadata, so treat it as a sorting hypothesis. ## Known blockers in the two that were read * `linkedin-post-generator` reads `COMPOSIO_API_KEY` and calls `linkedin_create_linkedin_post` against an OAuth-connected LinkedIn account, which is live publish authority brokered by a third party. * `claude-md-generator` shells out to `generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent` with `$GEMINI_API_KEY`, a backend-direct model call that violates the Agent Proxy transport rule. Both files opened carried an undeclared external dependency. **Inference, not established:** the signal-acquisition skills above are the category most likely to carry API keys and scraping behavior, since collecting external signal implies a data source. The observation that would settle it is the grep in step 1. ## Acceptance criteria 1. Grep all 64 upstream SKILL.md files for credential reads, shell-outs, and network fetches, and record which of the 15 above are implicated. 2. Open each of the 15 in full, including `references/` and any `.env.example`. 3. For each, record the data source it depends on, whether that source has a supported API or is scraped, and whether the terms of that source permit the access pattern. 4. Mark each adopt, reauthor, or discard, with a one-line reason. 5. For anything adopted, name which existing decision skill consumes its output, since a collector with no consumer is not worth the maintenance. 6. Land accepted skills under `.agents/composed/` or `.agents/skills/` per the placement rule in `tooling-skill-authoring`, one issue one commit. 7. Use no upstream install path. No `npx "@opendirectory.dev/skills"`, no `/plugin marketplace add`. Both write outside the canonical agent-compose and mcporter projection. Patterns are reauthored locally under MIT attribution. ## Related Companion issue covers the Content Creator-scope subset of the same upstream repo. `oss-launch-kit`, `producthunt-launch-kit`, `show-hn-writer`, and `position-me` appear in both and should be resolved once, not twice.

coilyco-ops commented

2026-08-16 00:12:26 +00:00

Author

Member

1. `hackernews-intel`

Verdict: reauthor. Keep the design, rewrite the plumbing.

156 lines. The data source is hn.algolia.com/api/v1/search_by_date, a public API with no auth and no key. That is the cleanest data dependency in the whole set, and it is why this skill needs no credentials.

It makes no LLM call at all. It is a poller, not a generator. Worth noting because it means the Agent Proxy question never arises.

The design holds up. SQLite dedup cache keyed on objectID, an optional HN_MIN_POINTS floor to cut noise on broad keywords, --dry-run to preview before alerting anyone, --reset when the keyword list changes, and comment monitoring off by default because comments generate far more volume than stories.

Blocker, and it is embarrassing: Steps 1b and 2 hardcode /Users/ksd/Desktop/Varnan_skills/hackernews-intel. The author's own laptop path shipped to 606 stargazers. The skill cannot run anywhere as written, and nobody caught it.

Credit where it is due: it is honest about the GitHub Actions caveat. Actions does not persist files between runs, so the dedup cache resets every run and everything inside the lookback window re-alerts. The skill says so and suggests S3 or a dedicated branch. Most skills here would have shipped that silently.

Exec read: this is the only skill in the set that instruments the boundary exec owns, external community signal, with no vendor sitting between you and the source. The Slack webhook is the sole egress and it is trivially replaceable with Discord, which this estate actually runs.

Take the dedup-cache-plus-threshold pattern. Drop every path and the Slack coupling.

## 1. `hackernews-intel` **Verdict: reauthor. Keep the design, rewrite the plumbing.** 156 lines. The data source is `hn.algolia.com/api/v1/search_by_date`, a public API with no auth and no key. That is the cleanest data dependency in the whole set, and it is why this skill needs no credentials. It makes no LLM call at all. It is a poller, not a generator. Worth noting because it means the Agent Proxy question never arises. The design holds up. SQLite dedup cache keyed on `objectID`, an optional `HN_MIN_POINTS` floor to cut noise on broad keywords, `--dry-run` to preview before alerting anyone, `--reset` when the keyword list changes, and comment monitoring off by default because comments generate far more volume than stories. **Blocker, and it is embarrassing:** Steps 1b and 2 hardcode `/Users/ksd/Desktop/Varnan_skills/hackernews-intel`. The author's own laptop path shipped to 606 stargazers. The skill cannot run anywhere as written, and nobody caught it. Credit where it is due: it is honest about the GitHub Actions caveat. Actions does not persist files between runs, so the dedup cache resets every run and everything inside the lookback window re-alerts. The skill says so and suggests S3 or a dedicated branch. Most skills here would have shipped that silently. **Exec read:** this is the only skill in the set that instruments the boundary exec owns, external community signal, with no vendor sitting between you and the source. The Slack webhook is the sole egress and it is trivially replaceable with Discord, which this estate actually runs. Take the dedup-cache-plus-threshold pattern. Drop every path and the Slack coupling.

coilyco-ops commented

2026-08-16 00:12:35 +00:00

Author

Member

2. `gh-issue-to-demand-signal`

Verdict: adopt the method. This is the best-engineered skill in the repo.

638 lines. Only GITHUB_TOKEN, and it is optional, degrading to the 60 req/hr unauthenticated limit with a clear warning. No LLM key anywhere, because it uses the calling agent as the model. That is the correct architecture and almost nothing else in these 64 gets it right.

The engineering is real. All noise filtering happens in local Python before anything reaches the model: pull requests dropped by checking for the pull_request key, bot authors dropped by user.type, conventional-commit and dependabot titles dropped by regex, zero-engagement issues dropped outright. Only then does the model classify.

Anti-hallucination is structural rather than aspirational. Step 7 checks every classified issue number against the real fetched set and deletes inventions rather than warning about them. Titles must be verbatim. It hard-stops under 10 surviving issues instead of clustering sparse data into meaningless categories.

The idea worth stealing is the ignored-demand heuristic: reactions >= 10 AND age_days >= 180 AND no planned/roadmap/wip label. Three criteria, all required, and the QA step re-verifies them and demotes anything that slipped through. That is a defensible definition of a neglected gap rather than a vibe.

The scoring is reactions * 2 + comments * 0.5, with a stated reason for the weighting: comments include maintainer replies, off-topic discussion, and spam, so a thumbs-up is the cleaner signal. Defensible, and rare that the reasoning is written down.

Exec read: it is framed as competitor intelligence, but the mechanism is indifferent to whose repo it points at. Aimed at your own backlog it becomes prioritization evidence, which is the exec charter directly. The GTM messaging brief in Step 6 is the only part that is not exec work, and it detaches cleanly at the step boundary.

Caveat: writes to docs/demand-signals/ in the working directory. It mutates whatever repo you run it in.

Forgejo's issues API is close enough to GitHub's that the port is mechanical.

## 2. `gh-issue-to-demand-signal` **Verdict: adopt the method. This is the best-engineered skill in the repo.** 638 lines. Only `GITHUB_TOKEN`, and it is optional, degrading to the 60 req/hr unauthenticated limit with a clear warning. No LLM key anywhere, because it uses the calling agent as the model. That is the correct architecture and almost nothing else in these 64 gets it right. The engineering is real. All noise filtering happens in local Python before anything reaches the model: pull requests dropped by checking for the `pull_request` key, bot authors dropped by `user.type`, conventional-commit and dependabot titles dropped by regex, zero-engagement issues dropped outright. Only then does the model classify. Anti-hallucination is structural rather than aspirational. Step 7 checks every classified issue number against the real fetched set and deletes inventions rather than warning about them. Titles must be verbatim. It hard-stops under 10 surviving issues instead of clustering sparse data into meaningless categories. The idea worth stealing is the ignored-demand heuristic: `reactions >= 10 AND age_days >= 180 AND no planned/roadmap/wip label`. Three criteria, all required, and the QA step re-verifies them and demotes anything that slipped through. That is a defensible definition of a neglected gap rather than a vibe. The scoring is `reactions * 2 + comments * 0.5`, with a stated reason for the weighting: comments include maintainer replies, off-topic discussion, and spam, so a thumbs-up is the cleaner signal. Defensible, and rare that the reasoning is written down. **Exec read:** it is framed as competitor intelligence, but the mechanism is indifferent to whose repo it points at. Aimed at your own backlog it becomes prioritization evidence, which is the exec charter directly. The GTM messaging brief in Step 6 is the only part that is not exec work, and it detaches cleanly at the step boundary. **Caveat:** writes to `docs/demand-signals/` in the working directory. It mutates whatever repo you run it in. Forgejo's issues API is close enough to GitHub's that the port is mechanical.

coilyco-ops commented

2026-08-16 00:12:44 +00:00

Author

Member

3. `sdk-adoption-tracker`

Verdict: do not run as written. Security defect in the shipped skill body.

808 lines, the longest in the set and the most carefully scored. It is also the one I would flag hardest.

Blocker: Step 3 and Step 5 both call ssl._create_unverified_context() and then send Authorization: Bearer $GITHUB_TOKEN over those contexts.

ctx = ssl._create_unverified_context()
...
headers = {"Authorization": f"Bearer {token}", ...}
with urllib.request.urlopen(req, timeout=20, context=ctx) as resp:

TLS certificate verification is disabled while a credential is in flight. There is no reason for it against api.github.com. It reads like someone silenced a local certificate error and shipped the workaround into a skill with 606 stars behind it. Anyone who installs this and sets a token is sending that token over unverified TLS.

That single line moves this from tier A to blocked. The rest of the skill being good makes it worse, not better, because the quality invites trust.

Secondary sloppiness: Step 3 calls urllib.parse.quote at line 196 but only imports urllib.parse at line 243, after the loop it is used in. It works by accident, because import urllib.request pulls urllib.parse in as a side effect. Accidental correctness in the same file as a deliberate TLS bypass.

What is genuinely good: the scoring is explicit and defensible. Organization ownership 50, populated company field 20, stars capped at 50, pushed within 30 days 30 and within 7 days another 20, not-a-fork 10, not-archived 10. Tutorial noise is filtered by a word list covering example, tutorial, demo, sample, starter, boilerplate, playground. It also handles the GitHub code search secondary rate limit honestly, exiting early and recording a flag rather than silently truncating.

Exec read: this answers "did the thing we shipped actually get taken up", which is the question exec review most often cannot answer. High value, and the scoring design is worth reauthoring from scratch against the same GitHub endpoints.

Reauthor, never adopt. The TLS line is the reason.

## 3. `sdk-adoption-tracker` **Verdict: do not run as written. Security defect in the shipped skill body.** 808 lines, the longest in the set and the most carefully scored. It is also the one I would flag hardest. **Blocker:** Step 3 and Step 5 both call `ssl._create_unverified_context()` and then send `Authorization: Bearer $GITHUB_TOKEN` over those contexts. ```python ctx = ssl._create_unverified_context() ... headers = {"Authorization": f"Bearer {token}", ...} with urllib.request.urlopen(req, timeout=20, context=ctx) as resp: ``` TLS certificate verification is disabled while a credential is in flight. There is no reason for it against `api.github.com`. It reads like someone silenced a local certificate error and shipped the workaround into a skill with 606 stars behind it. Anyone who installs this and sets a token is sending that token over unverified TLS. That single line moves this from tier A to blocked. The rest of the skill being good makes it worse, not better, because the quality invites trust. Secondary sloppiness: Step 3 calls `urllib.parse.quote` at line 196 but only imports `urllib.parse` at line 243, after the loop it is used in. It works by accident, because `import urllib.request` pulls `urllib.parse` in as a side effect. Accidental correctness in the same file as a deliberate TLS bypass. What is genuinely good: the scoring is explicit and defensible. Organization ownership 50, populated company field 20, stars capped at 50, pushed within 30 days 30 and within 7 days another 20, not-a-fork 10, not-archived 10. Tutorial noise is filtered by a word list covering example, tutorial, demo, sample, starter, boilerplate, playground. It also handles the GitHub code search secondary rate limit honestly, exiting early and recording a flag rather than silently truncating. **Exec read:** this answers "did the thing we shipped actually get taken up", which is the question exec review most often cannot answer. High value, and the scoring design is worth reauthoring from scratch against the same GitHub endpoints. Reauthor, never adopt. The TLS line is the reason.

coilyco-ops commented

2026-08-16 00:12:55 +00:00

Author

Member

4. `company-radar`

Verdict: discard as a unit. It is a dependency manifest for the tier-D backlog.

410 lines, and it is an orchestrator rather than a skill. Its own text says so: "It delegates data collection to existing opendirectory micro-skills and coordinates their output."

Here is what it delegates to, from the shipped mapping table: twitter-GTM-find-skill, reddit-icp-monitor, reddit-post-engine, yc-intent-radar-skill, pricing-finder, map-your-market, competitor-pr-finder, producthunt-launch-kit, gh-issue-to-demand-signal, hackernews-intel.

Six of those are tier D in the triage. Adopting company-radar means adopting the GTM backlog it sits on top of, which is the opposite of what the exec issue is trying to do.

It also references yc-jobs-scraper, which does not exist among the 64 directories. A dead handoff shipped inside the mapping table nobody checked.

TAVILY_API_KEY is required and the skill hard-stops without it, so a paid search vendor sits in the critical path of every run.

Credit where due, and it is real: Step 3b stops and makes the human confirm the discovered handles before signal collection begins, on the explicit reasoning that wrong handles produce wrong signals. "Wait for user confirmation. Do not skip this step." That is better instinct than most of this repo shows, and it is the correct place to put a gate.

The heat score is also a real artifact, not hand-waving. Four dimensions capped at 25 each, authority from stars and forks and votes, shipping from commit and release cadence, social from mentions across channels, growth from job count and department diversity. The formulas are printed in the SKILL.md for transparency and implemented in a bundled script. Missing signals score 0 with an explicit "never estimate data" rule.

Exec read: the concept, one scored dashboard across many independent channels, is exactly what an exec wants and the repo does not otherwise provide. The implementation buys it by taking on eight skill dependencies and a paid vendor.

Take the four-dimension capped-scoring shape and the confirm-before-collect gate. Leave the orchestrator and everything under it.

## 4. `company-radar` **Verdict: discard as a unit. It is a dependency manifest for the tier-D backlog.** 410 lines, and it is an orchestrator rather than a skill. Its own text says so: "It delegates data collection to existing opendirectory micro-skills and coordinates their output." Here is what it delegates to, from the shipped mapping table: `twitter-GTM-find-skill`, `reddit-icp-monitor`, `reddit-post-engine`, `yc-intent-radar-skill`, `pricing-finder`, `map-your-market`, `competitor-pr-finder`, `producthunt-launch-kit`, `gh-issue-to-demand-signal`, `hackernews-intel`. Six of those are tier D in the triage. Adopting company-radar means adopting the GTM backlog it sits on top of, which is the opposite of what the exec issue is trying to do. It also references `yc-jobs-scraper`, which does not exist among the 64 directories. A dead handoff shipped inside the mapping table nobody checked. `TAVILY_API_KEY` is required and the skill hard-stops without it, so a paid search vendor sits in the critical path of every run. Credit where due, and it is real: Step 3b stops and makes the human confirm the discovered handles before signal collection begins, on the explicit reasoning that wrong handles produce wrong signals. "Wait for user confirmation. Do not skip this step." That is better instinct than most of this repo shows, and it is the correct place to put a gate. The heat score is also a real artifact, not hand-waving. Four dimensions capped at 25 each, authority from stars and forks and votes, shipping from commit and release cadence, social from mentions across channels, growth from job count and department diversity. The formulas are printed in the SKILL.md for transparency and implemented in a bundled script. Missing signals score 0 with an explicit "never estimate data" rule. **Exec read:** the concept, one scored dashboard across many independent channels, is exactly what an exec wants and the repo does not otherwise provide. The implementation buys it by taking on eight skill dependencies and a paid vendor. Take the four-dimension capped-scoring shape and the confirm-before-collect gate. Leave the orchestrator and everything under it.

coilyco-ops commented

2026-08-16 00:13:09 +00:00

Author

Member

5. `linkedin-job-post-to-buyer-pain-map`

Verdict: reauthor the idea. Discard the implementation.

301 lines. Different author from the house account, ajaycodesitbetter, and the difference shows in both directions.

The genuinely good part, and this one surprised me: it carries an explicit ethical rule, stated before Step 1.

Ethical rule: Do not infer personal attributes or protected characteristics about candidates. Focus strictly on company-level operational pain and organizational needs.

The Step 7 self-QA re-checks it as a line item. Nothing else in the 15 has an ethics clause at all, and this is the skill that most needed one, since job posts are written by and about identifiable people.

The input model is also right. The human pastes the job descriptions. The skill does not scrape LinkedIn, which sidesteps the terms-of-service problem the xquik scrapers in tier D walk straight into.

Blocker: two backend-direct Gemini calls to generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent with $GEMINI_API_KEY, and Step 1 hard-stops without the key. Agent Proxy is not optional in this estate, so this is a rewrite rather than a port. The irony is that the skill does not need a separate model at all. The calling agent could do both synthesis steps, exactly as gh-issue-to-demand-signal does.

I stand by the ranking on the underlying move. Job postings are public, structured, and self-reported by an organization about where it is choosing to spend. Reading them as an investment signal generalizes well past sales, and no other skill in the repo mines a source that is simultaneously that candid and that ignored.

The scoring is auditable, which matters more than whether the weights are right: round((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10), with every sub-score requiring a one-sentence explanation and every inferred pain requiring a quoted phrase from the source post.

Everything downstream of Step 6 is a handoff object built for outreach-sequence-builder, which is tier D. Cut the skill there and keep Steps 3 through 5.

## 5. `linkedin-job-post-to-buyer-pain-map` **Verdict: reauthor the idea. Discard the implementation.** 301 lines. Different author from the house account, `ajaycodesitbetter`, and the difference shows in both directions. The genuinely good part, and this one surprised me: it carries an explicit ethical rule, stated before Step 1. > **Ethical rule:** Do not infer personal attributes or protected characteristics about candidates. Focus strictly on company-level operational pain and organizational needs. The Step 7 self-QA re-checks it as a line item. Nothing else in the 15 has an ethics clause at all, and this is the skill that most needed one, since job posts are written by and about identifiable people. The input model is also right. The human pastes the job descriptions. The skill does not scrape LinkedIn, which sidesteps the terms-of-service problem the `xquik` scrapers in tier D walk straight into. **Blocker:** two backend-direct Gemini calls to `generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent` with `$GEMINI_API_KEY`, and Step 1 hard-stops without the key. Agent Proxy is not optional in this estate, so this is a rewrite rather than a port. The irony is that the skill does not need a separate model at all. The calling agent could do both synthesis steps, exactly as `gh-issue-to-demand-signal` does. I stand by the ranking on the underlying move. Job postings are public, structured, and self-reported by an organization about where it is choosing to spend. Reading them as an investment signal generalizes well past sales, and no other skill in the repo mines a source that is simultaneously that candid and that ignored. The scoring is auditable, which matters more than whether the weights are right: `round((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10)`, with every sub-score requiring a one-sentence explanation and every inferred pain requiring a quoted phrase from the source post. Everything downstream of Step 6 is a handoff object built for `outreach-sequence-builder`, which is tier D. Cut the skill there and keep Steps 3 through 5.

coilyco-ops commented

2026-08-16 00:13:17 +00:00

Author

Member

6. `google-trends-api-skills`

Verdict: discard from exec scope. I misplaced this one on the title.

Correction to the ranking in the issue body: this is not an external demand-signal instrument. It is SEO keyword research for blog writing, and it belongs in Content Creator scope if it belongs anywhere. Ranking it at 6 in exec scope was a title-level error, and reading it is what caught it.

The directory is also malformed as a skill. There is no SKILL.md at the top level. It contains two nested directories: seo-keyword-research, which holds the only SKILL.md, and google-trends-api, which has scripts and references but no SKILL.md at all. As shipped it does not present as one installable skill, and the CLI's install path would have to guess.

Third-party author again, farizanjum. Worth noting that this is the only skill among my 15 carrying an allowed-tools frontmatter key, scoping itself to Bash(python:*) Bash(curl:*) Read. That is the correct instinct and nobody else in the set applied it.

Requires SERPAPI_KEY. The free tier is 250 searches a month, and to its credit the skill budgets against that honestly with a table: 2 calls per blog gives 125 blogs a month, 3 calls gives 83, 4 gives 62. It defaults to the cheapest path and tells you when to spend more.

The content itself is competent but dated. Keyword density targets of 1 to 2 percent, long-tail questions as H3 headings, featured-snippet targeting. That is a 2019 playbook, and this same repo sells generative-engine optimization elsewhere as the thing that replaced it. The two skills disagree with each other.

Nothing here serves attention allocation across a portfolio. Moving it out of the exec issue entirely rather than ranking it low.

## 6. `google-trends-api-skills` **Verdict: discard from exec scope. I misplaced this one on the title.** Correction to the ranking in the issue body: this is not an external demand-signal instrument. It is SEO keyword research for blog writing, and it belongs in Content Creator scope if it belongs anywhere. Ranking it at 6 in exec scope was a title-level error, and reading it is what caught it. The directory is also malformed as a skill. There is no `SKILL.md` at the top level. It contains two nested directories: `seo-keyword-research`, which holds the only SKILL.md, and `google-trends-api`, which has scripts and references but no SKILL.md at all. As shipped it does not present as one installable skill, and the CLI's install path would have to guess. Third-party author again, `farizanjum`. Worth noting that this is the only skill among my 15 carrying an `allowed-tools` frontmatter key, scoping itself to `Bash(python:*) Bash(curl:*) Read`. That is the correct instinct and nobody else in the set applied it. Requires `SERPAPI_KEY`. The free tier is 250 searches a month, and to its credit the skill budgets against that honestly with a table: 2 calls per blog gives 125 blogs a month, 3 calls gives 83, 4 gives 62. It defaults to the cheapest path and tells you when to spend more. The content itself is competent but dated. Keyword density targets of 1 to 2 percent, long-tail questions as H3 headings, featured-snippet targeting. That is a 2019 playbook, and this same repo sells generative-engine optimization elsewhere as the thing that replaced it. The two skills disagree with each other. Nothing here serves attention allocation across a portfolio. Moving it out of the exec issue entirely rather than ranking it low.

coilyco-ops commented

2026-08-16 00:13:27 +00:00

Author

Member

7. `npm-downloads-to-leads`

Verdict: adopt the telemetry half. Cleanest dependency profile in the set.

670 lines and it needs no credentials at all. The skill states it plainly: "No required keys. The npm API and npm registry are fully public with no authentication." GITHUB_TOKEN is optional and only widens maintainer enrichment. Nothing else in the 15 is this cheap to run, and it is the only one that could execute today with zero setup.

The velocity math is the substance:

velocity_score = growth_ratio * acceleration * noise_factor * 100

where growth is the recent 4-week average over the prior 4-week average, and acceleration is the last 2 weeks over the 2 before that. So a package has to be growing and growing faster to score.

The noise_factor is the insight. It penalizes both ends, scaling down under 500 weekly downloads and scaling down again above 500,000. The effect is that the skill structurally refuses to rank React first, and it says why in its own Common Mistakes table: "Raw downloads favor React and lodash, which are not leads. A package going from 1K to 8K/week is more actionable than React at 50M/week."

That is a correct and slightly unusual position. Download counts are the standard vanity metric in this space and this skill declines to report them as achievement.

Exec read: split it at Step 5. Steps 3 and 4 are the velocity leaderboard, which is adoption telemetry and answers whether your own published artifacts are moving. That is exec work. Steps 5 through 8 fetch maintainer profiles and draft outreach messages, which is GTM and is not.

Kai already ships npm, homebrew, and scoop artifacts, so the input exists and the npm half runs unmodified.

Minor: writes to docs/npm-leads/ in the working directory.

## 7. `npm-downloads-to-leads` **Verdict: adopt the telemetry half. Cleanest dependency profile in the set.** 670 lines and it needs no credentials at all. The skill states it plainly: "No required keys. The npm API and npm registry are fully public with no authentication." `GITHUB_TOKEN` is optional and only widens maintainer enrichment. Nothing else in the 15 is this cheap to run, and it is the only one that could execute today with zero setup. The velocity math is the substance: ``` velocity_score = growth_ratio * acceleration * noise_factor * 100 ``` where growth is the recent 4-week average over the prior 4-week average, and acceleration is the last 2 weeks over the 2 before that. So a package has to be growing *and* growing faster to score. The `noise_factor` is the insight. It penalizes both ends, scaling down under 500 weekly downloads and scaling down again above 500,000. The effect is that the skill structurally refuses to rank React first, and it says why in its own Common Mistakes table: "Raw downloads favor React and lodash, which are not leads. A package going from 1K to 8K/week is more actionable than React at 50M/week." That is a correct and slightly unusual position. Download counts are the standard vanity metric in this space and this skill declines to report them as achievement. **Exec read:** split it at Step 5. Steps 3 and 4 are the velocity leaderboard, which is adoption telemetry and answers whether your own published artifacts are moving. That is exec work. Steps 5 through 8 fetch maintainer profiles and draft outreach messages, which is GTM and is not. Kai already ships npm, homebrew, and scoop artifacts, so the input exists and the npm half runs unmodified. **Minor:** writes to `docs/npm-leads/` in the working directory.

coilyco-ops commented

2026-08-16 00:13:35 +00:00

Author

Member

8. `dx-roaster`

Verdict: adopt. Best-specified skill in the set and the only one with no dependency problem at all.

271 lines, no required environment variables, uses the gh CLI that is already installed, and it declares itself read-only: "Does not modify the target repo (read-only scan)."

It has the thing nearly every other skill here lacks. A "What this skill does NOT do" section, and an error-handling table naming four specific failure modes with defined behavior for each, including missing README, private repo without auth, and a benchmark URL that fails to fetch. That is what a maintained skill looks like.

Ten fixed dimensions scored 0 to 10, and the rule that keeps a rubric honest: "Missing data = score 0, not N/A." Rubrics rot when absence is allowed to be neutral.

The action plan ranks by impact / effort_minutes rather than by severity, and the SKILL.md defends the choice: "A 5-minute fix that adds 10 points ranks above a 2-hour fix that adds 12 points." Most audit tooling gets this backwards and hands a maintainer a list sorted by how bad things are rather than by what to do first.

It also ships this as a hard rule: "Never name maintainers or contributors. Roast the work, not the people."

Exec read: this is portfolio self-assessment, and it is the closest thing in the entire repo to a launch readiness gate. The standing problem in this portfolio is infrastructure that nobody clones, and the first five minutes of a README is where that gets decided. Run across every repo it produces a comparable 0 to 100 score per repo, which is precisely the kind of number an exec can allocate attention against.

Caveat: the optional compare_to benchmark clones a third-party repo to a temp directory. Bounded, and it deletes after.

The only real friction is the roast voice, which is not the house register. Set tone: honest, ignore brutal, and keep the rubric and the impact-over-effort ordering. Those are the transferable parts.

## 8. `dx-roaster` **Verdict: adopt. Best-specified skill in the set and the only one with no dependency problem at all.** 271 lines, no required environment variables, uses the `gh` CLI that is already installed, and it declares itself read-only: "Does not modify the target repo (read-only scan)." It has the thing nearly every other skill here lacks. A "What this skill does NOT do" section, and an error-handling table naming four specific failure modes with defined behavior for each, including missing README, private repo without auth, and a benchmark URL that fails to fetch. That is what a maintained skill looks like. Ten fixed dimensions scored 0 to 10, and the rule that keeps a rubric honest: "Missing data = score 0, not N/A." Rubrics rot when absence is allowed to be neutral. The action plan ranks by `impact / effort_minutes` rather than by severity, and the SKILL.md defends the choice: "A 5-minute fix that adds 10 points ranks above a 2-hour fix that adds 12 points." Most audit tooling gets this backwards and hands a maintainer a list sorted by how bad things are rather than by what to do first. It also ships this as a hard rule: "Never name maintainers or contributors. Roast the work, not the people." **Exec read:** this is portfolio self-assessment, and it is the closest thing in the entire repo to a launch readiness gate. The standing problem in this portfolio is infrastructure that nobody clones, and the first five minutes of a README is where that gets decided. Run across every repo it produces a comparable 0 to 100 score per repo, which is precisely the kind of number an exec can allocate attention against. **Caveat:** the optional `compare_to` benchmark clones a third-party repo to a temp directory. Bounded, and it deletes after. The only real friction is the roast voice, which is not the house register. Set `tone: honest`, ignore `brutal`, and keep the rubric and the impact-over-effort ordering. Those are the transferable parts.

coilyco-ops commented

2026-08-16 00:13:53 +00:00

Author

Member

9. `product-update-logger`

Verdict: reauthor the changelog half. Note that half of it belongs in the companion issue.

462 lines. GITHUB_TOKEN optional, reads local git directly, no LLM key. Cheap to run and cheap to evaluate.

It stops and asks, which is the behavior I most want to see and least often find here. Step 3 shows the gathered item list and waits before transforming anything, with the reasoning stated in the Common Mistakes table: skipping the confirmation "prevents wrong-branch commits or stale items."

The anti-fabrication rule is blunt and correct: "Do NOT invent outcomes or metrics. '40% faster' must come from the source data. If no number is in the commit or PR, do not add one." The Step 6 self-QA then greps its own output for banned words, over-length tweets, hashtags, and markdown that would render literally on LinkedIn.

Scope note: four of the six things it emits are a tweet thread, a LinkedIn post, an email snippet, and a one-liner. That is Content Creator output, not exec. Only the changelog is portfolio state. The skill is doing two jobs and only one of them is mine to judge.

Watch item: Step 7 prepends directly into docs/changelog.md, creating the file if absent, with no diff or review gate. Across a many-repo portfolio that is a mutation you want in front of a human before it lands. Everything else in this skill asks first, and then the write step does not.

Exec read: the changelog half answers "what actually shipped across the portfolio this period", which is the raw material for any status rollup and which nothing else in the set produces. Take Steps 1 through 4 and 7. Route Step 5 to the Content Creator issue, where the tweet and LinkedIn generation should be judged against voice-corpus rather than against this skill's generic founder-voice rules.

## 9. `product-update-logger` **Verdict: reauthor the changelog half. Note that half of it belongs in the companion issue.** 462 lines. `GITHUB_TOKEN` optional, reads local git directly, no LLM key. Cheap to run and cheap to evaluate. It stops and asks, which is the behavior I most want to see and least often find here. Step 3 shows the gathered item list and waits before transforming anything, with the reasoning stated in the Common Mistakes table: skipping the confirmation "prevents wrong-branch commits or stale items." The anti-fabrication rule is blunt and correct: "Do NOT invent outcomes or metrics. '40% faster' must come from the source data. If no number is in the commit or PR, do not add one." The Step 6 self-QA then greps its own output for banned words, over-length tweets, hashtags, and markdown that would render literally on LinkedIn. **Scope note:** four of the six things it emits are a tweet thread, a LinkedIn post, an email snippet, and a one-liner. That is Content Creator output, not exec. Only the changelog is portfolio state. The skill is doing two jobs and only one of them is mine to judge. **Watch item:** Step 7 prepends directly into `docs/changelog.md`, creating the file if absent, with no diff or review gate. Across a many-repo portfolio that is a mutation you want in front of a human before it lands. Everything else in this skill asks first, and then the write step does not. **Exec read:** the changelog half answers "what actually shipped across the portfolio this period", which is the raw material for any status rollup and which nothing else in the set produces. Take Steps 1 through 4 and 7. Route Step 5 to the Content Creator issue, where the tweet and LinkedIn generation should be judged against `voice-corpus` rather than against this skill's generic founder-voice rules.

coilyco-ops commented

2026-08-16 00:14:01 +00:00

Author

Member

10. `kill-the-standup`

Verdict: discard. Wrong tools all the way down, and it does not do the thing I ranked it for.

169 lines, the shortest real workflow in the set. It hard-stops without both LINEAR_API_KEY and SLACK_WEBHOOK_URL.

This estate runs Forgejo and Discord. Linear and Slack are both absent, so there is no adoption path here, only a from-scratch rewrite against different APIs. At that point the 169 lines are worth less than the time spent reading them, because the Linear GraphQL query and the Slack block payload are most of the file.

Correction to my own ranking: I placed this as status aggregation for an exec with reports. Having read it, it is a personal standup writer for one authenticated user. It fetches issues assigned to viewer and commits authored by one GitHub username. There is no rollup across people, so it does not do the exec thing I ranked it for. It is an IC convenience tool.

The transferable part is small but real, the formatting discipline in Step 4: no first-person pronouns, past tense for Done and present continuous for Doing, explicit "Nothing completed." rather than an empty section, under 200 words. That is a decent spec for any terse status format and it is four lines long.

It does ask before posting to Slack rather than posting silently, which is the right default for anything with external egress.

Discard. If a daily or weekly rollup need surfaces later, build it against Forgejo directly and borrow the four formatting rules.

## 10. `kill-the-standup` **Verdict: discard. Wrong tools all the way down, and it does not do the thing I ranked it for.** 169 lines, the shortest real workflow in the set. It hard-stops without both `LINEAR_API_KEY` and `SLACK_WEBHOOK_URL`. This estate runs Forgejo and Discord. Linear and Slack are both absent, so there is no adoption path here, only a from-scratch rewrite against different APIs. At that point the 169 lines are worth less than the time spent reading them, because the Linear GraphQL query and the Slack block payload are most of the file. **Correction to my own ranking:** I placed this as status aggregation for an exec with reports. Having read it, it is a personal standup writer for one authenticated user. It fetches issues assigned to `viewer` and commits authored by one GitHub username. There is no rollup across people, so it does not do the exec thing I ranked it for. It is an IC convenience tool. The transferable part is small but real, the formatting discipline in Step 4: no first-person pronouns, past tense for Done and present continuous for Doing, explicit "Nothing completed." rather than an empty section, under 200 words. That is a decent spec for any terse status format and it is four lines long. It does ask before posting to Slack rather than posting silently, which is the right default for anything with external egress. Discard. If a daily or weekly rollup need surfaces later, build it against Forgejo directly and borrow the four formatting rules.

coilyco-ops commented

2026-08-16 00:14:10 +00:00

Author

Member

11. `meeting-brief-generator`

Verdict: reauthor, cheaply. And name the people-research surface explicitly before anyone runs it.

275 lines. Three vendors: Tavily required, Gemini required, Notion optional. Two hard stops before it does any work.

Blocker: the same backend-direct generativelanguage.googleapis.com call with $GEMINI_API_KEY. Agent Proxy violation, so this is a rewrite regardless of anything else.

The research design is genuinely sound and is the part worth keeping. Six fixed searches against the company covering overview, recent news scoped to the last month, tech stack, product and pricing, competitors, and funding. Results are filtered at a Tavily relevance score of 0.5, and any section without qualifying results is written as "Limited public information found" rather than filled in from model memory. The critical rule is stated up front and in capitals: "DO NOT INVENT SPECIFICS."

The thing that needs naming: searches 7 and 8 fire only when a contact name is supplied, and they build a dossier on a named individual, including an explicit LinkedIn background sweep. For interview prep or a scheduled call this is ordinary professional preparation and I am not flagging it as misconduct. It is still automated research on a private person, and a reauthored version should keep it opt-in, keep it out of tracked files, and not retain it after the meeting. Worth noting that the skill's own default output target is Notion rather than a repo, which happens to be the safer choice.

Exec read: preparing for a counterparty is core exec activity in nearly every seat, and I stand by that ranking. But the actual value here is thin. Strip the vendors and what remains is six well-chosen queries plus a synthesis prompt plus one honesty rule. That is the whole skill.

This is the cheapest reauthor in the set. Replace Tavily with the search tooling already wired into this estate, drop Gemini entirely and let the calling agent synthesize, keep the six-query structure and the "Limited public information found" discipline. An afternoon, not a project.

## 11. `meeting-brief-generator` **Verdict: reauthor, cheaply. And name the people-research surface explicitly before anyone runs it.** 275 lines. Three vendors: Tavily required, Gemini required, Notion optional. Two hard stops before it does any work. **Blocker:** the same backend-direct `generativelanguage.googleapis.com` call with `$GEMINI_API_KEY`. Agent Proxy violation, so this is a rewrite regardless of anything else. The research design is genuinely sound and is the part worth keeping. Six fixed searches against the company covering overview, recent news scoped to the last month, tech stack, product and pricing, competitors, and funding. Results are filtered at a Tavily relevance score of 0.5, and any section without qualifying results is written as "Limited public information found" rather than filled in from model memory. The critical rule is stated up front and in capitals: "DO NOT INVENT SPECIFICS." **The thing that needs naming:** searches 7 and 8 fire only when a contact name is supplied, and they build a dossier on a named individual, including an explicit LinkedIn background sweep. For interview prep or a scheduled call this is ordinary professional preparation and I am not flagging it as misconduct. It is still automated research on a private person, and a reauthored version should keep it opt-in, keep it out of tracked files, and not retain it after the meeting. Worth noting that the skill's own default output target is Notion rather than a repo, which happens to be the safer choice. **Exec read:** preparing for a counterparty is core exec activity in nearly every seat, and I stand by that ranking. But the actual value here is thin. Strip the vendors and what remains is six well-chosen queries plus a synthesis prompt plus one honesty rule. That is the whole skill. This is the cheapest reauthor in the set. Replace Tavily with the search tooling already wired into this estate, drop Gemini entirely and let the calling agent synthesize, keep the six-query structure and the "Limited public information found" discipline. An afternoon, not a project.

coilyco-ops commented

2026-08-16 00:14:19 +00:00

Author

Member

12. `position-me`

Verdict: discard. I misread the title, and the implementation is the worst-written artifact in my 15.

Correction to the ranking: this is not a positioning-strategy skill. It is a website SEO, AEO, and UX audit agent that crawls a site page by page and scores it. It has nothing to do with personal or product positioning, and nothing to do with the bio surface or the job search, which is why I ranked it. Title-level error, caught by reading it.

Malformed the same way google-trends-api-skills is: no top-level SKILL.md, the real file is nested at position-me/position-me/SKILL.md.

Hard external dependencies on two third-party GitHub projects, chrome-devtools-mcp and chrome-cdp-skill, both declared mandatory in the same sentence: "Both are strictly required." It also needs Chrome running with remote debugging enabled, with Playwright as a fallback. That is three moving pieces outside this estate for a website audit.

The prose is the real problem. "You are an absolute master of digital positioning." "EXHAUSTIVE, multi-page, psychologically-driven, and ruthless." "A massive, comprehensive, scored report." "Wow-factor report." And CRITICAL RULE 2 is literally "DO NOT BE LAZY."

Instructing a model to produce a "massive" report is an instruction to pad, and it is the exact inverse of the prose and comment discipline this estate enforces. A skill that has to tell the model not to be lazy has not specified its output.

The no-emoji rule appears three separate times in a roughly 50-line file, which tells you precisely what kept going wrong during authoring.

One salvageable idea: checking a site for llms.txt, sitemap.xml, and JSON-LD structured data as AI-readiness signals. That overlaps llms-txt-generator and geo-gap-fixer and should be taken from those instead, where it is the primary subject rather than a bullet.

## 12. `position-me` **Verdict: discard. I misread the title, and the implementation is the worst-written artifact in my 15.** **Correction to the ranking:** this is not a positioning-strategy skill. It is a website SEO, AEO, and UX audit agent that crawls a site page by page and scores it. It has nothing to do with personal or product positioning, and nothing to do with the bio surface or the job search, which is why I ranked it. Title-level error, caught by reading it. Malformed the same way `google-trends-api-skills` is: no top-level SKILL.md, the real file is nested at `position-me/position-me/SKILL.md`. Hard external dependencies on two third-party GitHub projects, `chrome-devtools-mcp` and `chrome-cdp-skill`, both declared mandatory in the same sentence: "Both are strictly required." It also needs Chrome running with remote debugging enabled, with Playwright as a fallback. That is three moving pieces outside this estate for a website audit. The prose is the real problem. "You are an absolute master of digital positioning." "EXHAUSTIVE, multi-page, psychologically-driven, and ruthless." "A massive, comprehensive, scored report." "Wow-factor report." And CRITICAL RULE 2 is literally "DO NOT BE LAZY." Instructing a model to produce a "massive" report is an instruction to pad, and it is the exact inverse of the prose and comment discipline this estate enforces. A skill that has to tell the model not to be lazy has not specified its output. The no-emoji rule appears three separate times in a roughly 50-line file, which tells you precisely what kept going wrong during authoring. One salvageable idea: checking a site for `llms.txt`, `sitemap.xml`, and JSON-LD structured data as AI-readiness signals. That overlaps `llms-txt-generator` and `geo-gap-fixer` and should be taken from those instead, where it is the primary subject rather than a bullet.

coilyco-ops commented

2026-08-16 00:14:33 +00:00

Author

Member

13. `oss-launch-kit`

Verdict: discard. This is the largest gap between the title ranking and the artifact in the whole set.

I ranked this first in tier A and first overall in the launch group. Having read it, it is the weakest thing in my 15 and I was wrong.

The SKILL.md is 33 lines and contains no procedure. No steps, no checks, no output contract, no inputs. It is marketing prose about being "the root orchestration layer" and "the Strategic Entry Point", bold and capitals in the original. The entire body is five bullets under "How it works" and six under "When to use."

There are five Python scripts in the directory including a working run.py CLI that takes --repo-url, fetches repo context, builds a product brief, and renders a launch kit to markdown. It functions.

The SKILL.md never mentions any of them. An agent that loads this skill gets 33 lines of positioning copy and no instruction to run the thing that does the work. As an agent-facing artifact it is broken in the most basic way available: the interface does not reference the implementation.

It also ships committed bytecode, scripts/__pycache__/build_product_brief.cpython-313.pyc and generate_assets.cpython-313.pyc. Nobody has reviewed this directory.

Version 0.2.0, the only sub-1.0 version among my 15. The author knows it is not finished, and the repo shipped it in the top tier of its own marketing anyway.

What it actually does is hand off to other skills: show-hn-writer, producthunt-launch-kit, reddit-post-engine, tweet-thread-from-blog, linkedin-post-generator. Same pattern as company-radar. An orchestrator whose real content is the dependencies it drags in, three of which are outside exec scope and one of which is tier D.

Exec read: the go, no-go, and channel-fitness decision is real exec work and I ranked this skill because that decision is valuable. The repo does not contain it. The closest thing to a launch readiness gate in all 64 is dx-roaster, which actually scores a repo against ten dimensions and produces a number. Use that as the gate and let this go entirely.

## 13. `oss-launch-kit` **Verdict: discard. This is the largest gap between the title ranking and the artifact in the whole set.** I ranked this first in tier A and first overall in the launch group. Having read it, it is the weakest thing in my 15 and I was wrong. **The SKILL.md is 33 lines and contains no procedure.** No steps, no checks, no output contract, no inputs. It is marketing prose about being "the **root orchestration layer**" and "the **Strategic Entry Point**", bold and capitals in the original. The entire body is five bullets under "How it works" and six under "When to use." There are five Python scripts in the directory including a working `run.py` CLI that takes `--repo-url`, fetches repo context, builds a product brief, and renders a launch kit to markdown. It functions. **The SKILL.md never mentions any of them.** An agent that loads this skill gets 33 lines of positioning copy and no instruction to run the thing that does the work. As an agent-facing artifact it is broken in the most basic way available: the interface does not reference the implementation. It also ships committed bytecode, `scripts/__pycache__/build_product_brief.cpython-313.pyc` and `generate_assets.cpython-313.pyc`. Nobody has reviewed this directory. Version `0.2.0`, the only sub-1.0 version among my 15. The author knows it is not finished, and the repo shipped it in the top tier of its own marketing anyway. What it actually does is hand off to other skills: `show-hn-writer`, `producthunt-launch-kit`, `reddit-post-engine`, `tweet-thread-from-blog`, `linkedin-post-generator`. Same pattern as `company-radar`. An orchestrator whose real content is the dependencies it drags in, three of which are outside exec scope and one of which is tier D. **Exec read:** the go, no-go, and channel-fitness decision is real exec work and I ranked this skill because that decision is valuable. The repo does not contain it. The closest thing to a launch readiness gate in all 64 is `dx-roaster`, which actually scores a repo against ten dimensions and produces a number. Use that as the gate and let this go entirely.

coilyco-ops commented

2026-08-16 00:14:41 +00:00

Author

Member

14. `producthunt-launch-kit`

Verdict: discard from exec scope. Hand the useful half to Content Creator.

380 lines, and substantially better built than oss-launch-kit despite ranking below it in the title pass. Real steps, real constraints, real failure modes.

The constraints are specific and checkable, which is what makes a launch-asset skill useful rather than decorative. Taglines capped at 60 characters, descriptions at 500, gallery images at 1270x760 with a maximum of 8. It names the failure mode most listings actually hit, which is a weak or absent gallery, and gives a five-position framework for what each image has to accomplish: hero, feature demo, before and after, social proof, technical differentiator.

The guardrails are honest ones: never make factual claims that cannot be verified, never name competitors, and never say "free" unless the product is permanently free rather than on a trial. That last rule is the kind of thing that only gets written down by someone who watched a launch go badly.

Blocker: GEMINI_API_KEY and the same backend-direct generativelanguage.googleapis.com call. Agent Proxy violation, consistent with the rest of the repo.

Exec read, and this is why it leaves my scope: I ranked it on the assumption that the go, no-go and timing call would live here. It does not. Step 1 asks the human for the launch date as an input. There is no channel-selection logic, no readiness gate, no timing recommendation. The skill is entirely asset production from a decision already made, which is Content Creator work start to finish.

Product Hunt is also a weak channel for developer infrastructure relative to Hacker News, so even on the creator side this ranks below show-hn-writer for this portfolio.

Moving it to the companion issue rather than ranking it in exec scope.

## 14. `producthunt-launch-kit` **Verdict: discard from exec scope. Hand the useful half to Content Creator.** 380 lines, and substantially better built than `oss-launch-kit` despite ranking below it in the title pass. Real steps, real constraints, real failure modes. The constraints are specific and checkable, which is what makes a launch-asset skill useful rather than decorative. Taglines capped at 60 characters, descriptions at 500, gallery images at 1270x760 with a maximum of 8. It names the failure mode most listings actually hit, which is a weak or absent gallery, and gives a five-position framework for what each image has to accomplish: hero, feature demo, before and after, social proof, technical differentiator. The guardrails are honest ones: never make factual claims that cannot be verified, never name competitors, and never say "free" unless the product is permanently free rather than on a trial. That last rule is the kind of thing that only gets written down by someone who watched a launch go badly. **Blocker:** `GEMINI_API_KEY` and the same backend-direct `generativelanguage.googleapis.com` call. Agent Proxy violation, consistent with the rest of the repo. **Exec read, and this is why it leaves my scope:** I ranked it on the assumption that the go, no-go and timing call would live here. It does not. Step 1 asks the human for the launch date as an input. There is no channel-selection logic, no readiness gate, no timing recommendation. The skill is entirely asset production from a decision already made, which is Content Creator work start to finish. Product Hunt is also a weak channel for developer infrastructure relative to Hacker News, so even on the creator side this ranks below `show-hn-writer` for this portfolio. Moving it to the companion issue rather than ranking it in exec scope.

coilyco-ops commented

2026-08-16 00:14:54 +00:00

Author

Member

15. `show-hn-writer`

Verdict: read it for the findings, discard the artifact, and treat every number in it as unverified.

302 lines and the most interesting thing in the repo to read. It is also the one where checking the methodology pays off hardest, which makes it the most instructive item in this whole evaluation.

The claim is unusual for a skill: patterns extracted from "250 top HN posts scraped April 18 2026", with a data-source field in the frontmatter. It then reports averages by title length, by prefix, by theme, and by grammatical person, and instructs the agent that these findings "override any received wisdom about HN writing."

The methodology does not support the conclusions.

Every post in the sample is a top-250 post. There is no control group of low-scoring or median posts anywhere in the design. You cannot infer that short titles cause high scores from a sample selected on high scores, because the short titles that failed are never observed. This is selecting on the dependent variable, and the headline claim, "title length is the single strongest predictor of score", rests entirely on it. The honest version of that finding is "among posts that already succeeded, shorter titles are more common", which is a much weaker statement and does not license the prescription.

Several conclusions also rest on samples the skill quietly treats as equal to the large ones:

First-person titles - "avg 291 pts" - n=9
The 80-plus character bucket - "avg 131 pts" - n=9
Open source releases - "avg 485 pts" - flagged as "small n, but strong signal"

That last one matters. The author clearly knows what small-n means and applied the caveat once, then omitted it from the two findings that drive the actual instructions.

The advice is still probably good, which is the awkward part. "A topic is 'WordPress plugin security'. A story has an actor, an action, and stakes" is a real and useful distinction. "Show HN: suppresses score, so always draft a plain-title alternative" is a genuinely counterintuitive prompt worth having. Good advice on unsound evidence, presented as settled measurement.

Blocker, and this one is the most serious credential issue in the set. The .env.example requests:

HN_USERNAME=your_hn_username_here
HN_PASSWORD=your_hn_password_here

for "direct post submission." Hacker News has no submission API. Direct posting means driving a login form with a stored account password. Do not put an HN password in a dotenv, and do not automate submissions against that account.

Compounding it: neither HN_PASSWORD nor the also-declared GEMINI_API_KEY appears anywhere in the 302 lines of SKILL.md. The env file is orphaned configuration describing a capability the skill does not implement, which means the credential surface was written before the feature and shipped regardless.

Exec read: the channel-selection judgment, score versus comments and plain title versus Show HN prefix, is genuinely exec work and the only place in the repo where it appears. Take the findings as hypotheses to test against a real posting rather than as calibrated numbers. Discard the artifact. Never wire the credentials.

## 15. `show-hn-writer` **Verdict: read it for the findings, discard the artifact, and treat every number in it as unverified.** 302 lines and the most interesting thing in the repo to read. It is also the one where checking the methodology pays off hardest, which makes it the most instructive item in this whole evaluation. The claim is unusual for a skill: patterns extracted from "250 top HN posts scraped April 18 2026", with a `data-source` field in the frontmatter. It then reports averages by title length, by prefix, by theme, and by grammatical person, and instructs the agent that these findings "override any received wisdom about HN writing." **The methodology does not support the conclusions.** Every post in the sample is a top-250 post. There is no control group of low-scoring or median posts anywhere in the design. You cannot infer that short titles cause high scores from a sample selected on high scores, because the short titles that failed are never observed. This is selecting on the dependent variable, and the headline claim, "title length is the single strongest predictor of score", rests entirely on it. The honest version of that finding is "among posts that already succeeded, shorter titles are more common", which is a much weaker statement and does not license the prescription. Several conclusions also rest on samples the skill quietly treats as equal to the large ones: * First-person titles - "avg 291 pts" - n=9 * The 80-plus character bucket - "avg 131 pts" - n=9 * Open source releases - "avg 485 pts" - flagged as "small n, but strong signal" That last one matters. The author clearly knows what small-n means and applied the caveat once, then omitted it from the two findings that drive the actual instructions. The advice is still probably good, which is the awkward part. "A topic is 'WordPress plugin security'. A story has an actor, an action, and stakes" is a real and useful distinction. "Show HN: suppresses score, so always draft a plain-title alternative" is a genuinely counterintuitive prompt worth having. Good advice on unsound evidence, presented as settled measurement. **Blocker, and this one is the most serious credential issue in the set.** The `.env.example` requests: ``` HN_USERNAME=your_hn_username_here HN_PASSWORD=your_hn_password_here ``` for "direct post submission." Hacker News has no submission API. Direct posting means driving a login form with a stored account password. Do not put an HN password in a dotenv, and do not automate submissions against that account. Compounding it: neither `HN_PASSWORD` nor the also-declared `GEMINI_API_KEY` appears anywhere in the 302 lines of SKILL.md. The env file is orphaned configuration describing a capability the skill does not implement, which means the credential surface was written before the feature and shipped regardless. **Exec read:** the channel-selection judgment, score versus comments and plain title versus Show HN prefix, is genuinely exec work and the only place in the repo where it appears. Take the findings as hypotheses to test against a real posting rather than as calibrated numbers. Discard the artifact. Never wire the credentials.

coilyco-ops commented

2026-08-16 00:27:06 +00:00

Author

Member

Cut line: Reauthor and above

Eight of the fifteen clear the bar. Seven are dropped and their comments stand as the record.

Is any of the code critical

No. Not in one skill.

Four of the eight ship no code file at all. dx-roaster, meeting-brief-generator, and linkedin-job-post-to-buyer-pain-map have zero scripts. gh-issue-to-demand-signal has no script either, only inline heredocs.
The four that do ship a script are doing the same three things every time: an HTTP GET against a public endpoint, field filtering, and arithmetic under thirty lines. monitor-hn.js, fetch.py twice, and gather.py. Nothing there is beyond the agent's existing tools.

Two honest exceptions, neither of which survives as a reason to port code.

Persistent state across invocations. hackernews-intel dedups against a SQLite cache and sdk-adoption-tracker diffs against the previous snapshot to compute "new since last run". An agent has no memory of its last run. That is a store rather than an algorithm, and a JSON file the agent reads and rewrites covers it.
Verifying generated output against fetched ground truth. gh-issue-to-demand-signal Step 7 checks every classified issue number against the real fetched set. When the same model both classifies and verifies, the check correlates with the error it is hunting. That is a real argument for deterministic code, and it is about twenty lines. Keep it as a rule in the reauthored skill even if it stays prose.

One caveat worth carrying forward: anything producing a tracked number over time needs the computation to be stable, or the trend line is noise rather than signal. That applies to tooling-adoption-telemetry and tooling-package-velocity specifically. It argues for pinning the formula, not for importing the file.

What is actually load-bearing

The constants and predicates. Everything else is plumbing. This is the full extractable asset from roughly 3,600 lines:

Ignored demand - reactions >= 10 AND age >= 180 days AND no planned, roadmap, or wip label. All three required.
Demand score - reactions * 2 + comments * 0.5. Reactions weighted over comments because comments carry maintainer replies and spam.
Velocity - recent 4-week mean over prior 4-week mean, multiplied by a 2-week acceleration term.
Velocity noise floor and ceiling - discount below 500 weekly downloads and above 500,000. Refuses to rank the incumbent first.
Adoption score - org ownership 50, populated company field 20, stars capped at 50, pushed within 30 days 30, within 7 days a further 20, not-a-fork 10, not-archived 10.
Tutorial noise words - example, tutorial, demo, sample, starter, boilerplate, template, playground, workshop.
Issue noise predicates - drop anything with a pull_request key, a Bot author, a conventional-commit title, or zero reactions and zero comments.
Heat score - four dimensions, each capped at 25, missing signals scoring 0 with no estimation.
Rubric rule - missing data scores 0, never N/A.
Fix ordering - impact divided by effort in minutes, not by severity.
Search relevance floor - 0.5, and sections below it read "Limited public information found" rather than being filled in.
Sparse-data stop - fewer than 10 surviving issues means stop, do not cluster.
Scoring transparency - every sub-score carries a one-sentence explanation.
Evidence rule - every inferred claim quotes verbatim source text.
Anti-fabrication rule - no metric appears in output unless it appeared in the source.

Fifteen rules. That is the port.

Adopt

Namespace prefixes are needed regardless, since nothing here matches local convention.

dx-roaster becomes tooling-repo-dx-audit - the roast voice is not the house register, so name it for the function. Ten dimensions, impact over effort ordering, read-only.
npm-downloads-to-leads becomes tooling-package-velocity - the name drops the lead-generation half exactly as the skill should. Runs today against npm, homebrew, and scoop with no credentials.
gh-issue-to-demand-signal becomes tooling-issue-demand-signal - sits directly alongside tooling-issue-prioritization and tooling-issue-decomposition, which is where it belongs. Ported to the Forgejo issues API.

Reauthor, with proposed names

hackernews-intel becomes tooling-hn-signal-watch. Vendor-named on purpose, matching tooling-forgejo-issue-counts. "Intel" oversells a keyword poller. Keep the dedup-plus-threshold pattern, drop the hardcoded /Users/ksd/Desktop/ paths and the Slack coupling. Discord is the egress here. If Reddit and Discord variants follow, generalize the name then, not now.
sdk-adoption-tracker becomes tooling-adoption-telemetry. "SDK" is wrong for this portfolio, which ships CLIs, Helm charts, MCP servers, and pre-commit hooks rather than SDKs. "Adoption telemetry" holds the question, did anyone take this up, across every artifact type. Rebuild the scoring from the constants above and never carry the ssl._create_unverified_context() line across.
linkedin-job-post-to-buyer-pain-map becomes tooling-hiring-signal-read. Strips both the vendor lock and the sales framing. What it does is read hiring posts as a statement about where an organization is spending, which serves interview prep, competitive read, and market read without a third rename. Keep the pasted-input model and the protected-characteristics rule verbatim. Drop Gemini entirely, the calling agent does the synthesis.
product-update-logger becomes tooling-shipped-rollup. Only the changelog half comes across. "Rollup" is the exec word and avoids colliding with the per-repo changelog file the skill writes. Keep the confirm-before-transform gate, and add the review gate the original is missing before it prepends to a tracked file. The four content artifacts go to the companion issue.
meeting-brief-generator becomes tooling-counterparty-brief. "Meeting" is too narrow and "generator" is noise. "Counterparty" also names the people-research surface honestly, which is the thing a reader should notice before running it. Keep the six fixed queries, the 0.5 relevance floor, and the "Limited public information found" discipline. Replace Tavily with local search tooling, drop Gemini, keep contact research opt-in and out of tracked files.

Consequence for the acceptance criteria

Criterion 6 in the issue body assumed a port. It is not one. No upstream file, script, or dependency enters this estate. Each of the eight becomes a SKILL.md authored under tooling-skill-authoring, carrying the constants above and using the agent's own tools for fetch, filter, and write. MIT attribution in each skill's provenance line covers the rules and thresholds, which is the only thing actually being taken.

## Cut line: Reauthor and above Eight of the fifteen clear the bar. Seven are dropped and their comments stand as the record. --- ## Is any of the code critical No. Not in one skill. * Four of the eight ship no code file at all. `dx-roaster`, `meeting-brief-generator`, and `linkedin-job-post-to-buyer-pain-map` have zero scripts. `gh-issue-to-demand-signal` has no script either, only inline heredocs. * The four that do ship a script are doing the same three things every time: an HTTP GET against a public endpoint, field filtering, and arithmetic under thirty lines. `monitor-hn.js`, `fetch.py` twice, and `gather.py`. Nothing there is beyond the agent's existing tools. Two honest exceptions, neither of which survives as a reason to port code. * **Persistent state across invocations.** `hackernews-intel` dedups against a SQLite cache and `sdk-adoption-tracker` diffs against the previous snapshot to compute "new since last run". An agent has no memory of its last run. That is a store rather than an algorithm, and a JSON file the agent reads and rewrites covers it. * **Verifying generated output against fetched ground truth.** `gh-issue-to-demand-signal` Step 7 checks every classified issue number against the real fetched set. When the same model both classifies and verifies, the check correlates with the error it is hunting. That is a real argument for deterministic code, and it is about twenty lines. Keep it as a rule in the reauthored skill even if it stays prose. One caveat worth carrying forward: anything producing a tracked number over time needs the computation to be stable, or the trend line is noise rather than signal. That applies to `tooling-adoption-telemetry` and `tooling-package-velocity` specifically. It argues for pinning the formula, not for importing the file. ### What is actually load-bearing The constants and predicates. Everything else is plumbing. This is the full extractable asset from roughly 3,600 lines: * Ignored demand - reactions >= 10 AND age >= 180 days AND no planned, roadmap, or wip label. All three required. * Demand score - reactions * 2 + comments * 0.5. Reactions weighted over comments because comments carry maintainer replies and spam. * Velocity - recent 4-week mean over prior 4-week mean, multiplied by a 2-week acceleration term. * Velocity noise floor and ceiling - discount below 500 weekly downloads and above 500,000. Refuses to rank the incumbent first. * Adoption score - org ownership 50, populated company field 20, stars capped at 50, pushed within 30 days 30, within 7 days a further 20, not-a-fork 10, not-archived 10. * Tutorial noise words - example, tutorial, demo, sample, starter, boilerplate, template, playground, workshop. * Issue noise predicates - drop anything with a `pull_request` key, a Bot author, a conventional-commit title, or zero reactions and zero comments. * Heat score - four dimensions, each capped at 25, missing signals scoring 0 with no estimation. * Rubric rule - missing data scores 0, never N/A. * Fix ordering - impact divided by effort in minutes, not by severity. * Search relevance floor - 0.5, and sections below it read "Limited public information found" rather than being filled in. * Sparse-data stop - fewer than 10 surviving issues means stop, do not cluster. * Scoring transparency - every sub-score carries a one-sentence explanation. * Evidence rule - every inferred claim quotes verbatim source text. * Anti-fabrication rule - no metric appears in output unless it appeared in the source. Fifteen rules. That is the port. --- ## Adopt Namespace prefixes are needed regardless, since nothing here matches local convention. * `dx-roaster` becomes **`tooling-repo-dx-audit`** - the roast voice is not the house register, so name it for the function. Ten dimensions, impact over effort ordering, read-only. * `npm-downloads-to-leads` becomes **`tooling-package-velocity`** - the name drops the lead-generation half exactly as the skill should. Runs today against npm, homebrew, and scoop with no credentials. * `gh-issue-to-demand-signal` becomes **`tooling-issue-demand-signal`** - sits directly alongside `tooling-issue-prioritization` and `tooling-issue-decomposition`, which is where it belongs. Ported to the Forgejo issues API. ## Reauthor, with proposed names * `hackernews-intel` becomes **`tooling-hn-signal-watch`**. Vendor-named on purpose, matching `tooling-forgejo-issue-counts`. "Intel" oversells a keyword poller. Keep the dedup-plus-threshold pattern, drop the hardcoded `/Users/ksd/Desktop/` paths and the Slack coupling. Discord is the egress here. If Reddit and Discord variants follow, generalize the name then, not now. * `sdk-adoption-tracker` becomes **`tooling-adoption-telemetry`**. "SDK" is wrong for this portfolio, which ships CLIs, Helm charts, MCP servers, and pre-commit hooks rather than SDKs. "Adoption telemetry" holds the question, did anyone take this up, across every artifact type. Rebuild the scoring from the constants above and never carry the `ssl._create_unverified_context()` line across. * `linkedin-job-post-to-buyer-pain-map` becomes **`tooling-hiring-signal-read`**. Strips both the vendor lock and the sales framing. What it does is read hiring posts as a statement about where an organization is spending, which serves interview prep, competitive read, and market read without a third rename. Keep the pasted-input model and the protected-characteristics rule verbatim. Drop Gemini entirely, the calling agent does the synthesis. * `product-update-logger` becomes **`tooling-shipped-rollup`**. Only the changelog half comes across. "Rollup" is the exec word and avoids colliding with the per-repo changelog file the skill writes. Keep the confirm-before-transform gate, and add the review gate the original is missing before it prepends to a tracked file. The four content artifacts go to the companion issue. * `meeting-brief-generator` becomes **`tooling-counterparty-brief`**. "Meeting" is too narrow and "generator" is noise. "Counterparty" also names the people-research surface honestly, which is the thing a reader should notice before running it. Keep the six fixed queries, the 0.5 relevance floor, and the "Limited public information found" discipline. Replace Tavily with local search tooling, drop Gemini, keep contact research opt-in and out of tracked files. --- ## Consequence for the acceptance criteria Criterion 6 in the issue body assumed a port. It is not one. No upstream file, script, or dependency enters this estate. Each of the eight becomes a SKILL.md authored under `tooling-skill-authoring`, carrying the constants above and using the agent's own tools for fetch, filter, and write. MIT attribution in each skill's provenance line covers the rules and thresholds, which is the only thing actually being taken.

coilyco-ops commented

2026-08-16 01:03:35 +00:00

Author

Member

Parked against the active career freeze

This evaluation is sound and it is answering the wrong question. Parking it rather than proceeding to authoring.

Constraint that governs it. coilysiren/inbox#283 Phase 1 freezes "new flagship projects, research programs, and recurring manual obligations unless they replace an existing commitment", and its portfolio constraint caps the estate at one flagship proof artifact, one active research question, one community commitment, and one consulting pilot for the duration of the program. coilysiren/inbox#299 is open at P2 and carries the same constraints forward, with an explicit instruction to agents: "Prefer making Kai's existing qualification legible over proposing another large build."

Adopting three skills and reauthoring five is eight new recurring obligations. The comment above proposing exactly that was written without reading either issue.

The diagnosis in the durable record is different from the one this issue assumes. Per #299: "The current career problem is not qualification. It is legibility." This issue framed the exec-scope subset as signal acquisition and demand instrumentation. coilysiren/lore/docs/career-direction.md also pre-registers the specific error made in the thread above: "Audience growth, repository activity, friendly interest, or a coherent portfolio do not prove customer demand."

Unblock condition. Revisit when either of these is true:

The #283 decision checkpoint on 2026-09-30 selects a path, and the portfolio constraint lifts or changes.
A specific slide in the #284 proof package exposes one of these eight as the missing proof step. #299 allows work only on that basis, and requires naming the blocked slide, the missing evidence, and the smallest completion condition first.

What survives without conditions. Nothing in this repo enters the estate. The record that has standing regardless is the negative one, and it stays useful whenever anyone next points at Varnan-Tech/opendirectory:

ssl._create_unverified_context() carrying a GITHUB_TOKEN in sdk-adoption-tracker
a plaintext HN_PASSWORD field in show-hn-writer for a feature that skill does not implement
thirteen backend-direct generativelanguage.googleapis.com references across the repo
the fifteen constants in comment 64595, which are the only transferable asset and cost nothing to keep on file

The fifteen per-skill comments stand as the evaluation record. No further work on this issue until an unblock condition is met.

## Parked against the active career freeze This evaluation is sound and it is answering the wrong question. Parking it rather than proceeding to authoring. **Constraint that governs it.** `coilysiren/inbox#283` Phase 1 freezes "new flagship projects, research programs, and recurring manual obligations unless they replace an existing commitment", and its portfolio constraint caps the estate at one flagship proof artifact, one active research question, one community commitment, and one consulting pilot for the duration of the program. `coilysiren/inbox#299` is open at P2 and carries the same constraints forward, with an explicit instruction to agents: "Prefer making Kai's existing qualification legible over proposing another large build." Adopting three skills and reauthoring five is eight new recurring obligations. The comment above proposing exactly that was written without reading either issue. **The diagnosis in the durable record is different from the one this issue assumes.** Per `#299`: "The current career problem is not qualification. It is legibility." This issue framed the exec-scope subset as signal acquisition and demand instrumentation. `coilysiren/lore/docs/career-direction.md` also pre-registers the specific error made in the thread above: "Audience growth, repository activity, friendly interest, or a coherent portfolio do not prove customer demand." **Unblock condition.** Revisit when either of these is true: 1. The `#283` decision checkpoint on 2026-09-30 selects a path, and the portfolio constraint lifts or changes. 2. A specific slide in the `#284` proof package exposes one of these eight as the missing proof step. `#299` allows work only on that basis, and requires naming the blocked slide, the missing evidence, and the smallest completion condition first. **What survives without conditions.** Nothing in this repo enters the estate. The record that has standing regardless is the negative one, and it stays useful whenever anyone next points at `Varnan-Tech/opendirectory`: * `ssl._create_unverified_context()` carrying a `GITHUB_TOKEN` in `sdk-adoption-tracker` * a plaintext `HN_PASSWORD` field in `show-hn-writer` for a feature that skill does not implement * thirteen backend-direct `generativelanguage.googleapis.com` references across the repo * the fifteen constants in comment 64595, which are the only transferable asset and cost nothing to keep on file The fifteen per-skill comments stand as the evaluation record. No further work on this issue until an unblock condition is met.

coilyco-ops added the

labels

2026-08-17 02:36:40 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agentic-os#1078

No description provided.

Rows
Columns

Evaluate the 15 exec-scope skills in Varnan-Tech/opendirectory, where every one is signal acquisition and not one of them helps decide #1078

Source

Scope

The finding that matters

Candidate set, ranked by generic-exec value

What was actually verified

Known blockers in the two that were read

Acceptance criteria

Related

1. hackernews-intel

2. gh-issue-to-demand-signal

3. sdk-adoption-tracker

4. company-radar

5. linkedin-job-post-to-buyer-pain-map

6. google-trends-api-skills

7. npm-downloads-to-leads

8. dx-roaster

9. product-update-logger

10. kill-the-standup

11. meeting-brief-generator

12. position-me

13. oss-launch-kit

14. producthunt-launch-kit

15. show-hn-writer

Cut line: Reauthor and above

Is any of the code critical

What is actually load-bearing

Adopt

Reauthor, with proposed names

Consequence for the acceptance criteria

Parked against the active career freeze

1. `hackernews-intel`

2. `gh-issue-to-demand-signal`

3. `sdk-adoption-tracker`

4. `company-radar`

5. `linkedin-job-post-to-buyer-pain-map`

6. `google-trends-api-skills`

7. `npm-downloads-to-leads`

8. `dx-roaster`

9. `product-update-logger`

10. `kill-the-standup`

11. `meeting-brief-generator`

12. `position-me`

13. `oss-launch-kit`

14. `producthunt-launch-kit`

15. `show-hn-writer`