DEV Community

Taha
Taha

Posted on

Stop Building GitHub Outreach Scripts. Build a Signal Contribution Engine

#ai #automation #architecture #startup

A lot of developer-facing automation starts the same way.

You find GitHub issues that contain certain keywords.

You score them.

You generate a reply.

Maybe you mention your project.

Maybe someone clicks through.

It works well enough that the natural next step seems obvious:

Add more GitHub searches.

That is probably the wrong abstraction.

The reusable system is not a GitHub outreach pipeline.

It is a platform-agnostic Signal → Contribution Engine.

GitHub is just one adapter.

The same reasoning process should work across:

  • GitHub issues and discussions
  • Reddit posts
  • Hacker News threads
  • Discourse topics
  • Slack and Discord conversations
  • support forums
  • Linear or Jira issues
  • internal customer tickets
  • any other source where a concrete technical problem appears

The platform changes.

The intelligence should not.

The invariant pipeline

The core workflow looks like this:

TARGET
  ↓
INGEST
  ↓
NORMALIZE
  ↓
THREAD / ARTIFACT UNDERSTANDING
  ↓
SIGNAL EXTRACTION
  ↓
FIT SCORING
  ↓
CONTRIBUTION GAP
  ↓
REPO / PRODUCT MATCH
  ↓
DRAFT
  ↓
HUMAN GATE
  ↓
PUBLISH
  ↓
OBSERVE RESPONSE
  ↓
UPDATE TARGETING POLICY
Enter fullscreen mode Exit fullscreen mode

The important part is that almost none of this pipeline should know what a GitHub issue is.

Only ingestion and publishing need platform-specific behavior.

Everything between them should operate on a common representation.

Configuration, not hardcoded targeting

The platform, target, artifact, and objective should all be inputs.
For example:

platform:
  type: github
  target: "run-llama/llama_index"

objective:
  primary: qualified_repo_inspection
  secondary:
    - substantive_reply
    - maintainer_engagement
    - star
    - issue
    - pr

artifact:
  repo: leadingproblemsolver/living-context-engine
  claims_file: artifact_capabilities.yaml

target_policy:
  prefer:
    - active
    - low_comment_count
    - unresolved
    - technically_specific
    - buyer_or_maintainer_present
  reject:
    - solved
    - saturated
    - duplicate
    - promotional_thread
    - artifact_fit_is_incidental

publishing:
  auto_publish: false
  require_human_review: true
Enter fullscreen mode Exit fullscreen mode

The engine should not contain assumptions like:

if repo == "some-project":
    ...
Enter fullscreen mode Exit fullscreen mode

or:

if "memory" in issue.title:
    ...
Enter fullscreen mode Exit fullscreen mode

Instead, it should operate on:

Platform × Target × Artifact × Objective
Enter fullscreen mode Exit fullscreen mode

That makes the same engine reusable for very different jobs.

GitHub × agno-agi/agno × living-context-engine × repo_inspection
Enter fullscreen mode Exit fullscreen mode

could later become:

Reddit × r/devops × constraint-intelligence-engine × pain_validation
Enter fullscreen mode Exit fullscreen mode

or:

Hacker News × newest × operational-automation-service × buyer_discovery
Enter fullscreen mode Exit fullscreen mode

No core rewrite required.

Normalization is the real abstraction

This is the architectural layer that matters most.

Every platform object should be converted into one canonical signal schema.

A GitHub issue might become:

signal:
  platform: github
  container: run-llama/llama_index
  object_type: issue
  object_id: 22248

  title: ...
  body: ...
  replies: [...]
  participants: [...]
  timestamps: [...]
  labels: [...]

  state:
    open: true
    solved: false
    existing_fix: false
    saturation: low

  problem:
    symptom: "derived prompt is stale"
    authoritative_state: "ctx.store['state']"
    derived_projection: "LLM-facing state prompt"
    failure_mode: "projection not invalidated after state mutation"

  opportunity:
    missing_primitive: "revision-bound projection invalidation"
    confidence: 0.94
Enter fullscreen mode Exit fullscreen mode

Once this exists, the reasoning engine does not care whether the original object was a:

  • GitHub issue
  • Reddit thread
  • support ticket
  • Discord conversation
  • Stack Overflow question

It sees a technical signal with state, evidence, participants, a problem model, and an unresolved gap.

That is a much stronger boundary than building separate reasoning logic for every platform.

Platform adapters should be boring

The platform interface can stay intentionally small:

class PlatformAdapter:
    def discover(self, target, queries) -> list[RawObject]:
        ...

    def fetch(self, object_id) -> RawObject:
        ...

    def fetch_replies(self, object_id) -> list[RawReply]:
        ...

    def normalize(self, raw) -> SignalObject:
        ...

    def publish(self, object_id, text) -> PublishResult:
        ...

    def observe(self, object_id) -> EngagementState:
        ...
Enter fullscreen mode Exit fullscreen mode

Then implementations become:

GitHubAdapter
RedditAdapter
HNAdapter
DiscourseAdapter
SlackAdapter
DiscordAdapter
CustomRESTAdapter
Enter fullscreen mode Exit fullscreen mode

Adapters should answer questions like:

How do I fetch this conversation?

and:

How do I publish here?

They should not answer:

Is this problem interesting?

Is there a useful contribution gap?

Does our artifact genuinely solve part of it?

Those belong in the core engine.

The artifact needs a machine-readable truth boundary

There is another problem with contribution automation.

Once a system knows about your project, it becomes very easy for it to start stretching what the project actually does.

A thread mentions "memory."

Your project has something vaguely related to persistence.

Suddenly the generated reply makes it sound like your project is an autonomous memory system.

That is how useful participation turns into spam.

The fix is an explicit capability manifest.

For example:

artifact:
  name: Living Context Engine

implemented:
  - deterministic_file_ingestion
  - explicit_state_classification
  - sqlite_persistence
  - source_path_provenance
  - source_line_provenance
  - content_hash_provenance
  - timeline
  - source_linked_context_pack

not_implemented:
  - semantic_vector_retrieval
  - autonomous_memory
  - agent_orchestration
  - distributed_consensus
  - transactional_external_side_effects
Enter fullscreen mode Exit fullscreen mode

This becomes an evidence boundary.

Generated contributions may make claims supported by the implemented set.

They must not quietly cross into the non-implemented set.

That makes artifact matching significantly more trustworthy.

Contribution value and artifact fit are not the same score

This distinction turned out to be essential.

For every candidate, calculate at least two independent scores.

Contribution Value

Can we materially improve this discussion?

Artifact Fit

Does our actual artifact implement a useful primitive here?

Do not collapse these into a single "relevance score."

A discussion can be highly valuable even when your project has nothing useful to contribute.

That should produce:

Help, but do not link.

Likewise, your artifact might match a topic perfectly, but the thread may already be solved or hopelessly saturated.

That should produce:

Skip.

A simple policy table looks like this:

Contribution value Artifact fit Action
Low Any Skip
High Low Help, no link
High Medium Help; maybe mention the pattern, usually no link
High High Help first → contextual artifact link
Already solved High Skip
Saturated High Usually skip
Promotional environment High Skip

This one separation prevents a huge amount of bad behavior.

The goal is not:

Find every conversation where I can mention my repository.

It is:

Find conversations where I can make a useful contribution, then independently determine whether the artifact belongs in that contribution.

Keywords are useful for discovery, not understanding

Keyword search is a perfectly reasonable first-pass discovery mechanism.

It should not become the persistent mental model of the system.

Consider these five problem descriptions:

"state prompt doesn't update"

"history index hides sessions"

"handoff contains stale assumptions"

"busy rejection becomes permanent error"

"client transcript overwrites canonical message"
Enter fullscreen mode Exit fullscreen mode

At the string level, they look unrelated.

At the systems level, several can normalize into the same deeper structure:

AUTHORITATIVE STATE
        ↓
DERIVED PROJECTION
        ↓
PROJECTION BECOMES STALE OR WRONG
        ↓
NO INVALIDATION OR RECONCILIATION RULE
Enter fullscreen mode Exit fullscreen mode

That is much more useful.

Instead of learning:

Search for "state prompt."

the system can learn:

Look for derived state that can drift away from its authoritative source.

Now the knowledge transfers across repositories, frameworks, products, and even platforms.

The real reusable unit is an engineering pattern

Eventually, repeated high-quality contributions should become durable patterns.

For example:

pattern:
  id: stale-derived-projection

  invariant:
    authoritative_source: required
    derived_projection: allowed
    projection_version: required
    invalidation_on_source_change: required
    reconstruction: preferred

  prior_successes:
    - llama_index#22248
    - codex#19822
    - paseo#2889
    - mastra#20836
Enter fullscreen mode Exit fullscreen mode

This changes the nature of the system.

It is no longer building a database of:

Good GitHub issues we replied to.

It is building a library of:

Engineering invariants that have repeatedly helped diagnose real problems.

That is far more transferable.

A new signal can be matched against prior patterns based on its underlying failure mode rather than its vocabulary.

A cleaner architecture

The engine can be separated into eight modules:

1. adapters/
   github.py
   reddit.py
   discourse.py
   ...

2. normalization/
   canonical_signal.py

3. artifact/
   capability_manifest.py
   evidence_boundary.py

4. analysis/
   problem_extractor.py
   existing_solution_detector.py
   missing_primitive.py

5. scoring/
   signal_score.py
   contribution_score.py
   artifact_fit.py
   saturation.py
   spam_risk.py

6. generation/
   contribution.py
   contextual_reference.py

7. policy/
   human_gate.py
   skip_rules.py

8. feedback/
   replies.py
   reactions.py
   conversions.py
   policy_update.py
Enter fullscreen mode Exit fullscreen mode

This decomposition creates a useful separation of responsibilities.

Adapters understand platforms.

Normalization understands structure.

Analysis understands problems.

Artifact manifests understand truth.

Scoring understands opportunity.

Generation proposes contributions.

Policy decides whether publishing is appropriate.

Feedback updates future targeting.

The human gate should remain explicit

One design decision I would keep even as the system becomes more capable:

publishing:
  auto_publish: false
  require_human_review: true
Enter fullscreen mode Exit fullscreen mode

The highest-risk part of this system is not finding signals.

It is participating in someone else's community.

A scoring bug might produce a bad candidate.

A generation bug might produce an overstated claim.

A normalization bug might miss that the problem was already solved three replies ago.

Human review is cheap compared with damaging trust.

Automation can do the expensive part:

  • discovery
  • reading
  • normalization
  • comparison
  • scoring
  • drafting
  • evidence checking

The final publication decision can remain human.

Feedback should improve targeting, not just copywriting

Once a contribution is published, the engine should observe what happens.

Did someone reply?

Did a maintainer engage?

Did the conversation continue technically?

Did someone inspect the repository?

Did the candidate generate an issue, star, or PR?

More importantly:

Which problem patterns repeatedly produce meaningful engagement?

That feedback should update the targeting policy.

Not:

"Comments containing this phrase perform well."
Enter fullscreen mode Exit fullscreen mode

But:

"Unresolved authoritative-state / derived-projection failures in
low-saturation maintainer-visible discussions have historically
produced useful technical engagement."
Enter fullscreen mode Exit fullscreen mode

That is a much healthier optimization target.

From outreach automation to contribution intelligence

The architectural shift is small in wording but large in consequence.

Do not model the system as:

GitHub Search
→ Issue Filter
→ Comment Generator
→ Repo Link
Enter fullscreen mode Exit fullscreen mode

Model it as:

Signal
→ Normalized Problem
→ Engineering Invariant
→ Contribution Gap
→ Artifact Correspondence
→ Human-Reviewed Contribution
→ Feedback
Enter fullscreen mode Exit fullscreen mode

Then make the source replaceable.

platform = adapter

repo / community = target configuration

project = capability manifest

objective = policy

intelligence = platform-independent
Enter fullscreen mode Exit fullscreen mode

At that point, the system is no longer a GitHub outreach script.

It becomes a Contribution Intelligence Engine: a reusable system for finding unresolved technical signals, understanding the underlying engineering problem, determining whether there is something genuinely useful to add, and only then deciding whether an artifact belongs in the conversation.

That is a much more interesting system to build.

Top comments (0)