101Hashes

Local-first, cloud-ready developer models for real engineering work

One shared identity across implementation, debugging, architecture, and security.

Overview

101Hashes is a developer model family built for actual software delivery, not generic chat demos. It gives teams one coherent engineering identity across four specialist roles:

• 101Hashes:forge for implementation and shipping
• 101Hashes:trace for debugging and root-cause isolation
• 101Hashes:blueprint for architecture and system design
• 101Hashes:shield for security review and practical remediation

The repo includes the full family Modelfiles, prompt examples, a weighted router, team profiles, tests, and CI. You can run it entirely on your own machine with Ollama today, and you can publish or mirror the same model family to a registry later without changing the workflow.

Model Family

101Hashes:forge

Forge builds. It is tuned for implementation, feature work, refactors, and direct copy-pasteable output. Ask it to write code, finish endpoints, ship CLI tools, tighten APIs, or produce the smallest practical deliverable that unblocks the team.

101Hashes:trace

Trace hunts. It is optimized for debugging, exact failure area detection, and the smallest correct fix first. Use it when logs are noisy, the stack is large, and the fastest path is isolating the real break instead of brainstorming.

101Hashes:blueprint

Blueprint designs. It handles architecture, service boundaries, interfaces, data flow, scaling, and observability. It favors one strong recommendation with clear tradeoffs instead of a pile of weak options.

101Hashes:shield

Shield defends. It focuses on auth, authz, tenant isolation, permissions, validation, secrets, attack surface, and concrete fixes. It is built for practical engineering security work, not abstract theory.

Comparison

Model	Brand line	Best for	Output style	Default stance
101Hashes:forge	Forge builds.	Features, code changes, refactors, practical implementation	Direct answer first, code-heavy, copy-pasteable	Ship the correct thing fast
101Hashes:trace	Trace hunts.	Debugging, flaky behavior, regressions, incident triage	Diagnosis-first, low-noise, verification-oriented	Find the exact break
101Hashes:blueprint	Blueprint designs.	Architecture, APIs, boundaries, migrations, platform design	Structured, tradeoff-aware, recommendation-led	Choose the strongest path
101Hashes:shield	Shield defends.	Security review, auth, threat reduction, data handling	Risk-first, concrete remediation, severity-aware	Reduce exploitable risk

Quick Start

1. Clone and set up

git clone https://github.com/blackx-create/101Hashes.git
cd 101Hashes
cp .env.example .env
./scripts/setup.sh

2. Build the full family

make build

3. Run a specialist directly

make run-forge PROMPT="Implement a paginated users endpoint with cursor pagination."
make run-trace PROMPT="The worker hangs after deploy when Redis reconnects. Find the likely failure area."
make run-blueprint PROMPT="Design a multi-tenant job processing system with retries and observability."
make run-shield PROMPT="Review this password reset flow for token leakage and privilege escalation risks."

4. Route automatically

make show-router-py PROMPT="Investigate why the checkout service times out only in production."
make run-router-py PROMPT="Add a dry-run mode to the deploy command and update tests."

When To Use Which Model

• Use forge when the answer should end in code, commands, or a finished implementation.
• Use trace when the main job is finding the exact failure area and proving the fix quickly.
• Use blueprint when you need boundaries, interfaces, migration plans, or systems thinking.
• Use shield when the prompt touches trust boundaries, secrets, auth, permissions, validation, or abuse risk.

If the work overlaps categories, the router scores the prompt and explains why it selected a model. Team profiles can bias toward security, platform, startup speed, or backend-heavy development without rewriting the base rules.

Example Prompts

Forge

Implement a transactional invoice finalization endpoint in FastAPI.
Return the updated schema, endpoint code, and the tests I should add.

Trace

Users intermittently receive duplicate webhook events after retries.
Identify the most likely failure area, the smallest safe fix, and how to verify it fast.

Blueprint

Design a service boundary between the billing API and the usage pipeline.
Recommend one architecture with interfaces, data flow, scaling concerns, and observability.

Shield

Review this S3 upload flow for tenant isolation, unsafe file handling, and secret leakage.
Rank the risks and give the smallest practical remediation plan.

More examples live in prompts/forge.examples.md, prompts/trace.examples.md, prompts/blueprint.examples.md, and prompts/shield.examples.md.

Repo Structure

101Hashes/
├── Modelfile.forge
├── Modelfile.trace
├── Modelfile.blueprint
├── Modelfile.shield
├── router.yaml
├── router.team.yaml
├── router.local.yaml.example
├── prompts/
├── scripts/
├── tests/
├── docs/
└── .github/workflows/

Local-First, Cloud-Ready

Local-first means the default workflow assumes your own machine, your own Ollama runtime, and deterministic files checked into the repo. You can inspect every system prompt, tune every keyword weight, and route prompts without sending them anywhere else.

Cloud-ready means the same family can be tagged, pushed, mirrored, or wrapped by deployment automation when the team needs shared registries, centralized environments, or reproducible distribution across machines. The repo separates local execution from publish-time metadata so you do not need to redesign the project to move from solo use to team rollout.

Routing

The router is intentionally simple:

• router.yaml defines the baseline family, keyword weights, and default behavior.
• router.team.yaml adds opinionated shared profiles like backend, security-review, and platform.
• router.local.yaml.example shows how an individual can tune model names, weights, and machine-specific defaults without committing personal overrides.

Read the full routing guide in docs/routing.md.

Publishing

Choose a namespace and build, tag, and push the whole family:

make build NAMESPACE=blackxgodx
make push-all NAMESPACE=blackxgodx

Or run the scripts directly:

./scripts/build-all.sh blackxgodx
./scripts/tag-all.sh blackxgodx
./scripts/push-all.sh blackxgodx

Tags

Recommended public tags:

• blackxgodx/101hashes:forge
• blackxgodx/101hashes:trace
• blackxgodx/101hashes:blueprint
• blackxgodx/101hashes:shield

Local default tags in this repo:

• 101Hashes:forge
• 101Hashes:trace
• 101Hashes:blueprint
• 101Hashes:shield

Vision

Most developer model repos stop at vague prompts and a few screenshots. 101Hashes is meant to be the opposite: a crisp, testable, shippable model family for engineering teams that need reliable role separation without fragmenting their workflow.

Forge builds. Trace hunts. Blueprint designs. Shield defends.

One family. One engineering identity. Real work.

Validation

This repo ships with router fixtures, a Python test runner, and CI coverage. Locally:

python3 -m py_compile scripts/router.py scripts/test-router.py
python3 scripts/test-router.py
python3 scripts/test-router.py --cases tests/routing_cases.team.json --team-config router.team.yaml