What is existing-app-discovery-change?

A development skill for changing how an existing application is examined, classified, and prepared for later work.

Use it when changing existing-app discovery, adoption decisions, preload checks, module breakdowns, or storage, connector, login, and security detection.

It helps keep changes to brownfield software—an existing application being adapted—consistent across discovery, routing, and saved project information.

How BlocUnited-LLC/mozaiks configures Claude Code

Reuse

Borrowing it

Nothing to install: this file belongs to BlocUnited-LLC/mozaiks. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file

curl -O https://raw.githubusercontent.com/BlocUnited-LLC/mozaiks/main/.agents/skills/existing-app-discovery-change/SKILL.md

Clone the repo

git clone --depth 1 https://github.com/BlocUnited-LLC/mozaiks

Made for: Claude Code.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/skills/blocunited-llc/mozaiks/existing-app-discovery-change/github.svg)](https://agentmods.dev/skills/blocunited-llc/mozaiks/existing-app-discovery-change)

Your own site

<a href="https://agentmods.dev/skills/blocunited-llc/mozaiks/existing-app-discovery-change"><img src="https://agentmods.dev/badge/skills/blocunited-llc/mozaiks/existing-app-discovery-change/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/skills/blocunited-llc/mozaiks/existing-app-discovery-change"><img src="https://agentmods.dev/badge/skills/blocunited-llc/mozaiks/existing-app-discovery-change.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 39 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.

When invoked 1,726 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe. Third-party audits

NVIDIA SkillSpector pass 7 Sept 2026

How audits are shown

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00039	$0.01726
Opus 5.5	$0.00016	$0.00690
Sonnet 5.5	$0.00008	$0.00345
Haiku 4.5	$0.00004	$0.00173

Measured 26d ago against content hash 36a5b4599107, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

existing-app-discovery-change scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 26d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.agents/skills/existing-app-discovery-change/SKILL.md · 145 lines

How it starts

The opening of the file, as written. The whole thing — 145 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Before starting: git fetch origin && gh pr list --state open && git log origin/main --oneline -3 — if another agent has an open PR touching the same files you need, wait for it to merge, then branch from fresh origin/main.

Use this skill when a change touches the brownfield or existing-app discovery flow.

Typical triggers:

factory_app/workflows/ExistingAppDiscovery/**
brownfield_app_adoption in factory_app/workflows/extended_orchestration/extension_registry.json
existing app preload or discovery tools
adoption levels or adoption rationale
embed, bridge, ecosystem, or gradual_modernization decisions
module decomposition outputs for brownfield adoption
storage, connector, auth, or security detection
brownfield artifact saving or downstream discovery artifact consumption
ExistingAppDiscovery workflow-local handoffs or brownfield routing into later factory workflow contracts

Inspect first:

factory_app/workflows/extended_orchestration/extension_registry.json
docs/architecture/workflows/workflow-routing-transitions.md
docs/architecture/orchestration-and-decomposition.md
factory_app/workflows/ExistingAppDiscovery/agents.yaml
factory_app/workflows/ExistingAppDiscovery/structured_outputs.yaml
factory_app/workflows/ExistingAppDiscovery/transition_graph.yaml
factory_app/workflows/ExistingAppDiscovery/context_variables.yaml
factory_app/workflows/ExistingAppDiscovery/tools/preload_discovery_context.py
factory_app/workflows/ExistingAppDiscovery/tools/save_existing_app_artifacts.py
tests/test_existing_app_discovery_contracts.py
the narrowest matching brownfield routing tests before editing:
- tests/test_existing_app_discovery_gradual_modernization.py
- tests/test_session_router.py
- tests/test_session_launcher.py
- tests/test_pack_schema_models.py

Core truth:

ExistingAppDiscovery belongs to the brownfield or existing-app adoption flow.
It is not the default greenfield build path.
It is not AppGenerator.
It should analyze an existing app and produce structured adoption, discovery, and decomposition artifacts.
It must not copy existing-app code directly into generated apps without a conscious adoption strategy.
Separate docs and stated intent from code truth when evaluating an external app.
Code truth wins over docs, screenshots, or product summaries when they conflict.
embed, bridge, ecosystem, and gradual_modernization are current workflow-local adoption labels. They are discovery evidence, not canonical AppContext artifact kinds.
brownfield_app_adoption currently routes into ExistingAppDiscovery; it does not continue through the default greenfield build sequence unless the authored sequence contract changes.
Downstream factory workflow consumption should happen through saved artifacts and explicit contracts, not by pretending discovery is already AppGenerator.

AppContext target direction: ExistingAppDiscovery currently emits workflow-local outputs including ExistingProductSpec, CapabilitySpec[], AgentAugmentationPlan, and optionally module_decomposition_plan. These are retired evidence outputs — they are not canonical AppContextVersion artifact kinds and must not become control-plane source of truth. The target canonical substrate for both greenfield and brownfield apps is AppContextVersion. See docs/architecture/foundations/app-context-and-brownfield-adoption.md.

Boundary rules:

Do not make ExistingAppDiscovery the greenfield build path.
Do not make AppGenerator responsible for brownfield discovery, preload scanning, or adoption classification.
Do not treat docs as the source of truth when analyzing an external app.
Code truth wins.
Do not copy provider-specific or proprietary implementation into OSS fixtures, examples, or tests.
Use neutral fixture apps in tests.
Do not copy existing-app code directly into generated apps as an implicit migration strategy.
When old in-flight outputs use native_migration adoption level, treat that as retired historical discovery evidence feeding the AdoptionPlan / AppContextVersion contracts — not as a canonical artifact kind to preserve or extend.
Keep workflow_sequence, transition routing, and workflow-local transition_graph.yaml distinct.
Do not assume later factory workflows are part of the brownfield path unless extension_registry.json and the saved artifact contracts explicitly say so.

Read the full file on GitHub · 145 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

26d ago Changed 36a5b4599107
2mo ago First seen · 145 lines · 39 tokens per session scan A 601b2972019c

Subscribe to this mod's changes

existing-app-discovery-change is a skill published in the GitHub repository BlocUnited-LLC/mozaiks (24 stars, last pushed yesterday), licensed MIT. It adds 39 tokens to every session and 1,726 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Backend and APIs LLM Planning agent-framework agentic-ai ai ai-agents genai

existing-app-discovery-change next to 6 skills from other repositories
Mod	Type	Stars	Last push	Licence	Scan	Tokens	Works with
existing-app-discovery-changeBlocUnited-LLC/mozaiks	Skill	24	yesterday	MIT	A	39	Claude Code
agentfieldAgent-Field/agentfield	Skill	2.6k	yesterday	Apache-2.0	A	127	Claude Code, Codex
building-pydantic-ai-agentspydantic/pydantic-ai	Skill	21k	yesterday	MIT	A	92	Claude Code, Codex
pydantic-ai-harnesspydantic/pydantic-ai	Skill	21k	yesterday	MIT	A	197	Claude Code, Codex
migrating-langchain-to-pydantic-aipydantic/pydantic-ai	Skill	21k	yesterday	MIT	A	100	Codex
migrating-vercel-ai-sdk-and-eve-to-pydantic-aipydantic/pydantic-ai	Skill	21k	yesterday	MIT	A	107	Codex
migrating-claude-agent-sdk-to-pydantic-aipydantic/pydantic-ai	Skill	21k	yesterday	MIT	A	90	Codex

mozaiks: Skill for Claude Code