Atlas / Skills / hoangnguyen0403 / Common Store Changelog

Common Store ChangelogSAFE

skills/hoangnguyen0403/common-store-changelog

A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages

Verdict
SAFE
Grade
B
Trust score
89 /100
Version
—
Hosts
—
License
MIT
Stars
575
01

Overview

A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages

Read from source at commit 6f5be687a268OBSERVED · 2026-10-14
Advertisement
02

What it tells the agent

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: common-store-changelog
description: "Generate user-facing release notes for the App Store and Google Play from git history (App Store <=4000 chars, Google Play <=500). Use when generating release notes, app store changelog, play store release, or \"what's new\" text for a mobile app."
metadata:
  triggers:
    keywords:
    - generate changelog
    - app store notes
    - play store release
    - what's new
    - release notes
    - version notes
    - store release
---
# Store Changelog Standard

## **Priority: P1 (HIGH)**


## Always-Apply Rules

- **Character limits**: App Store ≤ 4000 chars. Google Play ≤ 500 chars — validate before output.
- **Benefit language**: Write what user gains, not what code changed. "Faster checkout" not "refactored cart service".
- **Bullet-only format**: One sentence per bullet. No paragraphs. No headers inside notes.
- **Drop internal commits**: Exclude `chore`, `refactor`, `ci`, `build`, `test`, dependency bumps, and config changes — no user impact.
- **Suppress internal SDK changes**: Never mention an analytics or other internal SDK update in store notes; omit it silently rather than explaining the omission.
- **Deduplicate**: Merge commits touching same feature into one bullet.

## Workflow

1. **Collect**: Run `git log <last-tag>..HEAD --oneline` (or use provided commit list). If no tag exists, use full history.
2. **Triage**: Scan commits and touched files. Group by theme: `New`, `Improved`, `Fixed`. Drop internal-only.
3. **Draft — App Store**: Write 5–10 benefit-focused bullets, including user-facing changes such as onboarding when present. Optional `What's New in [Version]` header.
4. **Draft — Google Play**: Compress App Store draft to ≤ 500 chars. Prioritise top 3–5 user-facing changes.
5. **Validate**: Count characters per store. Check every bullet maps to real commit. Remove jargon.

See [Commit-to-Bullet Examples](references/commit_examples.md) for mapping patterns.

## Output Format

**App Store** (≤ 4000 chars):

```
What's New in Version X.Y
• [New] <user benefit — one sentence>
• [Improved] <user benefit — one sentence>
• [Fixed] <user benefit — one sentence>
```

**Google Play** (≤ 500 chars):

```
• <highest-impact change>
• <second change>
• <third change>
[Bug fixes and performance improvements.]
```

## Anti-Patterns

- **No jargon**: Never use `refactor`, `migrated`, `deprecated`, `PR`, `hotfix`, or internal ticket IDs.
- **No chore bullets**: `chore: upgrade Gradle` → drop entirely, never paraphrase as user feature.
- **No bundled bullets**: "Fixed login and improved search and added dark mode" → three separate bullets.
- **No character overrun**: Validate Play Store notes ≤ 500 chars before returning — truncate + rewrite if needed.
- **Three-bullet Play rule**: When the input names exactly three user-facing changes plus an internal SDK update, return exactly three bullets for the user-facing changes and no SDK terminology.

## References

- [Commit-to-Bullet Examples](references/commit_examples.md) — load when mapping specific commits to bullets

## Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
- Bug fixes
- [Fixed]
- performance improvements

## Remediation anchors

- Remediation anchors: omit internal SDK changes, exactly three user-facing bullets, no jargon
03

Trust audit

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

LayerWhat it checksResult
L0Provenance & inventoryPASS
L1Static analysis of the codeNA
L2Instruction surface (what it tells the agent)PASS
L3Class-specific surfacePASS
L4Behavioural (sandbox)SKIPPED

What the source does

Filesystem
none-observed
Network
none-observed
Shell
none-observed
Dependencies
pinned
Secrets in source
none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

Audited 2026-10-14 · audit v0.4.1 · source sha 6f5be687a268full audit observations/trust-audit/skill/hoangnguyen0403__common-store-changelog.json · Report an issue / request a re-scan
04

Audit history

Every audit this skill has had.

DateSourceVerdictGradeScoreChange
2026-10-146f5be687a268SAFEB89first audit
05

Questions

What does the Common Store Changelog skill do?

A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages

Is Common Store Changelog safe to install?

The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.

What can Common Store Changelog access on my machine?

The audit observed no filesystem, network or shell use at all in its source.

How current is this page?

The grade is for one exact copy of the source (6f5be687a268), read on 2026-10-14. The repository is watched, and a new audit runs when it changes — this is the first audit.

Advertisement