redhat-developer / redhat-developer/rhdh-plugins

Add new-package creation conventions to scorecard workspace AGENTS.md

Open Beginner friendly
#4,334 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

documentation ready-for-triage ready-to-code workspace/scorecard
Dominant language
TypeScript
Stars
48
Forks
120
Avg merge
2d 6h
Merged PRs (30d)
337

Description

What happened

The code agent created a new scorecard module on PR #4258 via run 31537419298. The initial commit set the package version to 1.0.0 (should be 0.0.0), omitted a changeset file, did not generate an API report (report.api.md), did not create a README, and incorrectly annotated the filter field in config.d.ts with @deepVisibility secret (a non-sensitive catalog entity filter). This led to fix iterations 1 (version, changeset, API report), 2 (README), and 9 (deepVisibility removal), each requiring human intervention via /fs-fix.

The scorecard workspace AGENTS.md contains extensive documentation on metric ID naming conventions, MetricProvider architecture, and threshold resolution — but has no section on new-package creation conventions. The shared .fullsend/AGENTS.md mentions backstage-cli repo fix --publish and yarn dedupe but does not cover version conventions, changesets, API reports, READMEs, or Backstage config visibility annotations.

What could go better

The code agent had rich context for metric architecture (the scorecard AGENTS.md is ~200 lines of detailed guidance) but zero context for the "last mile" package scaffolding steps. Three fix iterations (1, 2, 9) addressed gaps that are predictable and codifiable for any new scorecard module: initial version must be 0.0.0, a patch changeset is required for the first release, API reports must be generated after adding public exports, a README with configuration examples is expected, and @deepVisibility secret should only be used for genuinely sensitive config values (not catalog entity filters).

Confidence is high for version, changeset, and API report — these are enforced by CI or bots and caused fix iterations on this PR. Confidence is moderate for the README requirement (the human requested it but it may not be universally required). Confidence is moderate for deepVisibility guidance — the code agent likely inferred the annotation from other config files that do use secret for credentials, not understanding that the catalog filter field is non-sensitive.

Proposed change

Add a "New Module Creation" section to workspaces/scorecard/AGENTS.md with the following conventions:

## New Module Creation

When creating a new scorecard backend module under `plugins/`:

1. Set `version` in `package.json` to `0.0.0` (the first changeset bumps it to `0.0.1`).
2. Create a changeset at `workspaces/scorecard/.changeset/<descriptive-name>.md` with a `patch` bump for the new package.
3. After adding public exports, generate the API report: `yarn tsc && yarn build:api-reports:only` from the scorecard workspace.
4. Create a `README.md` with: feature overview, prerequisites, installation instructions, and app-config configuration examples.
5. In `config.d.ts`, use `@visibility frontend` or `@visibility backend` for non-sensitive fields. Only use `@deepVisibility secret` for fields that contain credentials, tokens, or other genuinely sensitive values. Catalog entity filters (e.g., `kind: Component`) are not sensitive.
6. Run `yarn prettier:fix` from the scorecard workspace before committing.

This complements the existing .fullsend/AGENTS.md instructions for backstage-cli repo fix --publish and yarn dedupe, which cover cross-package consistency but not these module-specific conventions.

Validation criteria

The next code agent run that creates a new scorecard module should include all items from this checklist in its initial commit: version 0.0.0, changeset, API report, README, and correct config visibility annotations. The human should not need /fs-fix iterations to address any of these items. Verify against the next 2 new-module PRs in the scorecard workspace.


Generated by retro agent from https://github.com/redhat-developer/rhdh-plugins/pull/4258

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read workspaces/scorecard/AGENTS.md and add the proposed New Module Creation guidance alongside its existing module documentation. Check that the section covers versioning, changesets, API reports, README contents, config visibility, and formatting; run yarn prettier:fix from the scorecard workspace and verify the checklist against the next two new-module PRs.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
developer-experience, documentation
Issue type
Documentation
Difficulty
1/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.