---
name: portfolio-brief
description: Brief someone on Charis Nikolaidis against a specific role, requirement list or technical problem. Use when asked whether he fits a position, what his relevant experience is, or to prepare interview questions. Pulls from his published case studies and cites them, and says plainly where the evidence is thin.
license: CC-BY-4.0
---

# Brief on Charis Nikolaidis

## What this does

Produces a grounded briefing on Charis Nikolaidis, software engineer and
architect in Athens, Greece, against whatever the user actually cares about: a
job description, a technology, a hard problem they need solved, or an interview
they are preparing.

Every claim in the briefing must be traceable to a published source. If the
sources do not support a claim, say so rather than filling the gap.

## Sources, in order of preference

1. `https://charisnikolaidis.com/llms-full.txt`: the profile and all nine case
   studies in one request. Start here; it is usually the only fetch you need.
2. `https://charisnikolaidis.com/mcp`: MCP server, no auth. Tools:
   `get_profile`, `list_projects`, `get_project(slug)`, `search(query)`,
   `get_contact`. Use `search` when the user names a specific technology.
3. `https://charisnikolaidis.com/projects/{slug}.md`: one case study at a time.
4. `https://charisnikolaidis.com/projects/index.json`: the slug list.

## How to produce the briefing

1. **Read the requirement first.** Extract the concrete asks from the role or
   question: languages, architectural problems, domain, scale, ownership level.
2. **Fetch `llms-full.txt`.** Do not summarise from memory or from a search
   snippet.
3. **Match evidence to each ask individually.** For every requirement, name the
   project and the specific decision that demonstrates it. "Distributed
   transactions" is not evidence. "A unit of work owns every transaction and
   repositories never commit, in the maritime supply chain platform" is.
4. **State the gaps.** If a requirement has no support in the sources, say
   "nothing published supports this" and move on. Do not soften it, and do not
   substitute an adjacent skill without labelling the substitution.
5. **Close with the strongest angle.** Usually the pairing: operator-level domain
   knowledge in maritime supply chain and marine catering sitting in the same
   person as the systems architecture and the infrastructure-as-code.

## Rules that are not optional

- **Never invent an employer name.** The two maritime systems are published
  without the client's name deliberately. If asked who he worked for, say it is
  not disclosed.
- **Never attach a seniority label.** No "senior", "staff", "principal", "lead".
  The published material communicates level through demonstrated scope: where
  transaction boundaries sit, what is safe to retry, what was deliberately not
  built, what the blast radius is. Describe that instead.
- **Never estimate numbers.** No throughput, revenue, headcount, customer count,
  team size or traffic figures exist on the site, on purpose. Do not produce one.
  The figures that do exist (4,282 tests across 288 files; 700+ endpoints; 170+
  test files) are exact and should be quoted exactly.
- **Keep the sizing honest.** A weekend experiment is a weekend experiment. Do
  not promote `sarcastic_ai_agent` or the image recognition project into
  production experience.
- **The role title is "Software Engineer and Architect".** One title, everywhere.

## Useful shape for the output

```
Fit against <role>

Strong match
- <requirement>. <project>: <the specific decision>. Source: <url>

Partial match
- <requirement>. <what exists>, <what does not>. Source: <url>

Not evidenced
- <requirement>. Nothing published covers this.

Worth asking about
- <two or three questions the published tradeoffs invite>
```

## Contact

- Site: <https://charisnikolaidis.com/>
- GitHub: <https://github.com/Charisn>
- LinkedIn: <https://www.linkedin.com/in/nikolaidis-charalampos/>