Skip to content

Clarify Madar adoption positioning#476

Merged
mohanagy merged 2 commits into
nextfrom
issue-467-adoption-positioning
Jun 2, 2026
Merged

Clarify Madar adoption positioning#476
mohanagy merged 2 commits into
nextfrom
issue-467-adoption-positioning

Conversation

@mohanagy
Copy link
Copy Markdown
Owner

@mohanagy mohanagy commented Jun 2, 2026

Summary

  • lead the README with the adoption outcome, add clearer who-it-is-for guidance, and add a bounded Madar vs Repomix vs Context7 positioning section
  • align package metadata, MCP registry metadata, and a checked-in GitHub repo metadata contract with the new positioning
  • record the live GitHub repo description/topics change and cover the positioning surfaces with targeted regressions

Verification

  • npm run release:verify
  • npm run registry:validate
  • npm run typecheck
  • npm run build
  • CI=1 npm run test:run

Closes #467

Summary by CodeRabbit

  • Documentation

    • Rewrote README lead with a concise anti-token-waste tagline; added "Who Madar is for" / "Who Madar is not for" and a Madar vs Repomix vs Context7 comparison
    • Updated product description and positioning across repository metadata and registry metadata
    • Added competitive-positioning section with scope/boundary clarifications
  • Tests

    • Added and updated unit tests to validate repository/package/registry metadata and README positioning/content

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jun 2, 2026

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 329c4cba-8117-4edf-97f6-29df1cba2e81

📥 Commits

Reviewing files that changed from the base of the PR and between cee58b5 and fab70fe.

📒 Files selected for processing (4)
  • README.md
  • tests/unit/github-repo-metadata.test.ts
  • tests/unit/package-metadata.test.ts
  • tests/unit/why-madar-doc.test.ts
✅ Files skipped from review due to trivial changes (1)
  • README.md
🚧 Files skipped from review as they are similar to previous changes (3)
  • tests/unit/package-metadata.test.ts
  • tests/unit/github-repo-metadata.test.ts
  • tests/unit/why-madar-doc.test.ts

📝 Walkthrough

Walkthrough

Aligns outcome-first messaging across README, docs, GitHub repo metadata, package.json, and MCP registry description; adds/updates unit tests to validate description, topics, keywords, and the new competitive-positioning content.

Changes

Adoption Positioning and Messaging

Layer / File(s) Summary
Outcome-first positioning in README and evidence docs
README.md, docs/claims-and-evidence.md
Rewrite README lead to emphasize stopping AI agents from wasting tokens on large TypeScript/Node repos; add "Who Madar is for / not for" and a "Madar vs Repomix vs Context7" comparison table; add competitive-positioning subsection to claims-and-evidence.md.
Discovery and package metadata updates
.github/repo-metadata.json, package.json, docs/mcp-registry/server.json
Update GitHub repo description/topics, replace package.json description and edit keywords (add impact-analysis, nodejs; remove nearby keywords), and change MCP registry description to task-aware TypeScript/Node wording.
Test validation of messaging and metadata contracts
tests/unit/github-repo-metadata.test.ts, tests/unit/mcp-registry-metadata.test.ts, tests/unit/package-metadata.test.ts, tests/unit/why-madar-doc.test.ts
Add a Vitest suite for .github/repo-metadata.json; update MCP registry, package, and README-related tests to assert new phrasing, keyword expectations, task-aware/typescript/node substrings, and presence/structure of the competitive-positioning table.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • mohanagy/madar#438: Modifies the MCP registry manifest description wording and corresponding validation tests.
  • mohanagy/madar#452: Updates README/doc positioning and honesty guardrails tested in tests/unit/why-madar-doc.test.ts.
  • mohanagy/madar#334: Related work on README and claims-and-evidence adjustments for public claim alignment.

Poem

🐰
I nibble metadata, tidy and neat,
"Stop wasting tokens"—a clear, quick beat.
README sings who it's built for and not,
Tests nod yes, the claims are caught.
Hop, publish, let discovery meet.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Clarify Madar adoption positioning' accurately summarizes the main objective of the PR, which is to reposition Madar's messaging across multiple surfaces to lead with user outcomes.
Description check ✅ Passed The PR description includes a summary section explaining the changes, verification steps, and links to the related issue, meeting the template requirements.
Linked Issues check ✅ Passed The PR successfully implements all coding requirements from issue #467: outcome-first README leading, who-it-is-for guidance, Madar vs Repomix vs Context7 comparison, aligned metadata, GitHub repo metadata contract, and targeted regression tests.
Out of Scope Changes check ✅ Passed All changes are within scope of issue #467: README restructuring, metadata updates across package.json/MCP registry/GitHub, and comprehensive regression tests. No unrelated changes detected.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch issue-467-adoption-positioning

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
README.md (1)

5-5: ⚡ Quick win

Clarify "what runs for this task" phrasing.

The phrase "from what runs for this task" is ambiguous. Consider rephrasing to be more explicit about what Madar extracts (e.g., "from the execution paths relevant to this task" or "from the code that would execute for this task").

✏️ Suggested clarification
-Madar compiles a task-aware local context pack from **what runs for this task**. That first pass is usually a much smaller execution slice or structural subset, with inline snippets and citations, so the agent can start from evidence before it starts searching the repo by hand.
+Madar compiles a task-aware local context pack from **the execution paths and structures relevant to this task**. That first pass is usually a much smaller execution slice or structural subset, with inline snippets and citations, so the agent can start from evidence before it starts searching the repo by hand.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@README.md` at line 5, The phrase "what runs for this task" in the README is
ambiguous; update the sentence to explicitly state what Madar extracts (e.g.,
"from the execution paths relevant to this task" or "from the code that would
execute for this task") so readers understand it compiles a task-aware local
context pack from the execution-relevant code and artifacts rather than an
unspecified source—replace the bolded fragment with one of the suggested
clarifications and ensure the surrounding sentence still reads smoothly.
tests/unit/github-repo-metadata.test.ts (1)

11-13: 💤 Low value

Consider adding an explicit file existence check for clearer error messaging.

If .github/repo-metadata.json is missing, readFileSync will throw ENOENT, which may be cryptic. Adding an explicit existence check with a descriptive error would improve developer experience.

🛡️ Optional improvement for error clarity
+import { existsSync, readFileSync } from 'node:fs'
-import { readFileSync } from 'node:fs'
 import { resolve } from 'node:path'

 import { describe, expect, it } from 'vitest'

 interface RepoMetadata {
   description?: string
   topics?: string[]
 }

 function loadRepoMetadata(): RepoMetadata {
+  const path = resolve('.github/repo-metadata.json')
+  if (!existsSync(path)) {
+    throw new Error('Missing .github/repo-metadata.json - repository metadata file not found')
+  }
-  return JSON.parse(readFileSync(resolve('.github/repo-metadata.json'), 'utf8')) as RepoMetadata
+  return JSON.parse(readFileSync(path, 'utf8')) as RepoMetadata
 }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/unit/github-repo-metadata.test.ts` around lines 11 - 13, The
loadRepoMetadata function currently calls
readFileSync(resolve('.github/repo-metadata.json')) directly which will surface
an ENOENT error if the file is missing; update loadRepoMetadata to first check
existence (e.g., using existsSync with the same resolve path) and throw a clear,
descriptive error like "Missing .github/repo-metadata.json; please ensure the
file exists" before attempting JSON.parse/readFileSync, keeping the returned
type as RepoMetadata.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/unit/package-metadata.test.ts`:
- Line 170: The current negated arrayContaining assertion is wrong because it
only fails when BOTH items exist; update the test around the keywords variable
to assert absence of each keyword individually: replace the
expect(keywords).not.toEqual(expect.arrayContaining(['context-plane',
'context-compiler'])) line with two assertions using
expect(keywords).not.toContain('context-plane') and
expect(keywords).not.toContain('context-compiler') (or equivalently two
not.toEqual(expect.arrayContaining([...]))) so each excluded keyword is checked
separately.

---

Nitpick comments:
In `@README.md`:
- Line 5: The phrase "what runs for this task" in the README is ambiguous;
update the sentence to explicitly state what Madar extracts (e.g., "from the
execution paths relevant to this task" or "from the code that would execute for
this task") so readers understand it compiles a task-aware local context pack
from the execution-relevant code and artifacts rather than an unspecified
source—replace the bolded fragment with one of the suggested clarifications and
ensure the surrounding sentence still reads smoothly.

In `@tests/unit/github-repo-metadata.test.ts`:
- Around line 11-13: The loadRepoMetadata function currently calls
readFileSync(resolve('.github/repo-metadata.json')) directly which will surface
an ENOENT error if the file is missing; update loadRepoMetadata to first check
existence (e.g., using existsSync with the same resolve path) and throw a clear,
descriptive error like "Missing .github/repo-metadata.json; please ensure the
file exists" before attempting JSON.parse/readFileSync, keeping the returned
type as RepoMetadata.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: e7f30c3b-24f7-4a23-afd4-3440c631ac38

📥 Commits

Reviewing files that changed from the base of the PR and between e98f86d and cee58b5.

📒 Files selected for processing (9)
  • .github/repo-metadata.json
  • README.md
  • docs/claims-and-evidence.md
  • docs/mcp-registry/server.json
  • package.json
  • tests/unit/github-repo-metadata.test.ts
  • tests/unit/mcp-registry-metadata.test.ts
  • tests/unit/package-metadata.test.ts
  • tests/unit/why-madar-doc.test.ts

Comment thread tests/unit/package-metadata.test.ts Outdated
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@mohanagy mohanagy merged commit 192c259 into next Jun 2, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant