Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add hmj1026/dhpk --skill project-briefgit clone --depth 1 https://github.com/hmj1026/dhpkWrote 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.
[](https://agentmods.dev/skills/hmj1026/dhpk/project-brief)<a href="https://agentmods.dev/skills/hmj1026/dhpk/project-brief"><img src="https://agentmods.dev/badge/skills/hmj1026/dhpk/project-brief/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.
<a href="https://agentmods.dev/skills/hmj1026/dhpk/project-brief"><img src="https://agentmods.dev/badge/skills/hmj1026/dhpk/project-brief.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00042 | $0.01052 |
| Opus 5.5 | $0.00017 | $0.00421 |
| Sonnet 5.5 | $0.00008 | $0.00210 |
| Haiku 4.5 | $0.00004 | $0.00105 |
Grade A, and why
project-brief 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 yesterday.
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.
How it starts
The opening of the file, as written. The whole thing — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Project brief
Convert one technical specification into a PM/CTO-readable executive summary.
The input path in $ARGUMENTS is read-only. Parse an optional --output <path>
without changing any other argument; when omitted, save beside the source with
the -brief suffix. Stop with BLOCKED when the source is missing or
unreadable, or when the requested output cannot be written.
$PROJECT_DIR denotes the consumer project root in path examples. It is
notation for that root, not a required ambient environment variable. The source
and any --output path are consumer project files; preserve the explicit output
path or the default beside-source path described above.
When NOT to Use
- The source technical specification needs correction: edit it through its owning workflow first.
- The audience needs implementation-level detail, code analysis, or module names: return the technical specification instead.
- More than one source document or a broad documentation refresh is in scope: use a bounded documentation workflow.
Workflow
- Read the source. Resolve the path from
$ARGUMENTS, record the source path, and read it completely. Extract the core value proposition. Preserve unresolved decisions instead of silently resolving them. - Extract the business view. Capture one sentence covering what, why, and value; compare current state with target; retain solution pros/cons and the recommendation; keep milestones, risks, dependencies, timeline, and resources.
- Simplify deliberately. Remove code snippets, internal module names, and implementation detail. Keep a plain-language architecture overview with no more than three layers. Turn immediate actions into PM/CTO decision points.
- Write the brief. Save to the explicit
--outputpath or to the source directory using<stem>-brief<extension>. Do not modify the source file.
The conversion map is:
| Technical section | Executive treatment |
|---|---|
| Trust boundary diagram | Simplify to at most three architecture layers |
| Code analysis; reusable modules | Remove |
| System architecture; implementation roadmap | Keep in simplified form |
| Key design decisions | Remove implementation detail |
| Alternative comparison; risks and mitigations; timeline | Keep |
| Immediate actions | Simplify to decision points |
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday Changed · +2 lines 839da188e00a
- 23d ago First seen · 126 lines · 42 tokens per session scan A 3ab63e35f4eb
project-brief is a skill published in the GitHub repository hmj1026/dhpk (2 stars, last pushed today), licensed MIT. It adds 42 tokens to every session and 1,052 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-09-24.
Other skills, from other repositories
promote-idea
Converts an album idea from IDEAS.md into an actual album project in one step. Use when the user says "promote [idea title]", "turn idea into album", or "start working on [idea]".
customer-onboarding-and-implementation
Takes a new customer from signature to working — setting a definition of live that both sides agreed before the contract was signed, planning and staffing the implementation, running data migration and integration realistically, training the people who will actually use it, and handing over to the ongoing…
recap-doc
Post-development recap document generator. Use when: AI/Codex has implemented a feature and the user needs a guided walkthrough of what changed and why, with blind-spot detection and anticipated questions. Not for: Q&A follow-up (use /recap-ask), technical share-out for teammates (use /tech-brief), or generic code…
runbook
Generate and update feature release runbooks from existing docs and codebase. Use when: creating operational runbook, release handbook, deployment checklist, pre-release preparation. Not for: incident response (v2), code review (use codex-code-review), architecture design (use architecture).
show-me-your-work
For autonomous multi-phase or unattended work, a reviewer needing an evidence trail, or an explicit decision-log/show-your-work request, keep an append-only decision log with why, evidence, and result. Record decisions and corrections, not hidden reasoning transcripts.
ccc-onboard
Contributor first-hour plan for the current repository: reads CLAUDE.md, BIBLE.md and package.json, checks required tools, asks the contributor's role, and returns a five-step checklist plus five real starter resources. Use when someone new joins a repo or types $ccc-onboard.