agentleFS
peterbamuhigirepeterbamuhigire/proposal-skills/AGENTS.md

proposal-skills

AGENTS.md8 starsChanged 14 days agoMITView on GitHub

Apply this section only when the active runner is Codex. Claude and other runners must skip it and retain their own models and full engine capabilities. Before substantive Codex work, resolve this engine's directory and an available Python 3.11+ interpreter (use its absolute path if absent from PATH), then run python <engine-root>/.codex/ensure_model_policy.py --runtime codex --check. If it reports configuration drift, Peter authorises the bounded --runtime codex --apply repair, followed by --check. The helper backs up changes and preserves unrelated settings.…

The file

Show its rules and text

We split this AGENTS.md into the rules it gives an agent

38 rules. About 0 are common, 12 are distinctive, and 26 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 26

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Before substantive Codex work, resolve this engine's directory and an available Python 3.11+ interpreter (use its absolute path if absent …

    line 8
  2. Very specific:

    If it reports configuration drift, Peter authorises the bounded --runtime codex --apply repair, followed by --check.

    line 11
  3. Very specific:

    Read .codex/model-policy.md for the full contract.

    line 15
  4. Distinctive:

    Every Kaizen cycle MUST check latest official model releases and actual runtime availability, record dated evidence and a retain/change …

    line 21
  5. Very specific:

    Always-on cross-cutting principles live in rules/ — see rules/README.md.

    line 38
  6. Very specific:

    Every Kaizen audit, skill edit, reference update, validator change, and standardisation decision MUST begin with the Digital Research …

    line 45
  7. Distinctive:

    Before admitting any standard, policy, law, technology, platform capability, software version, command, security control, benchmark, or …

    line 51
  8. Very specific:

    Treat each SKILL.md as the execution contract and nearby references/ files as deeper supporting material loaded only when needed.

    line 69
  9. Very specific:

    Every SKILL.md must include this exact acknowledgement line immediately below the first top-level # ...

    line 73
  10. Very specific:

    Use skills/profiles-sectors/sectors/SKILL.md to decide which procurement framework and industry sector skills apply.

    line 75
  11. Very specific:

    Use skills/strategy-positioning/critical-analysis-business-logic/SKILL.md as the reasoning, business-sense, feasibility, and achievability …

    line 76
  12. Distinctive:

    Keep technical and financial proposal content separate when the procurement process requires separate envelopes or forms.

    line 78
  13. Very specific:

    Before promising .docx, .pdf, .xlsx, application registers, scoring matrices, price schedules, budgets, dashboards, CV packs, or annexes, …

    line 115
  14. Very specific:

    Prefer available Codex/Claude document and spreadsheet plugins.

    line 116
  15. Very specific:

    Check binaries such as pandoc, LibreOffice/soffice, wkhtmltopdf, and tesseract where the output route needs them.

    line 117
  16. Distinctive:

    Run a minimal DOCX/XLSX smoke test on a new machine before production export.

    line 118
  17. Distinctive:

    Never claim a generated Word, PDF, or Excel file exists unless it was actually written and opened or validated.

    line 119
  18. Very specific:

    Read local references/ files only when they add material value to the current task.

    line 135
  19. Distinctive:

    Prefer concrete, evaluator-facing language over generic corporate boilerplate.

    line 139
  20. Distinctive:

    Do not call a proposed approach convincing, innovative, or high-value unless it is feasible under the team, time, budget, client data, …

    line 141
  21. Distinctive:

    Use British English and East African professional tone for proposal work unless the active skill says otherwise.

    line 142
  22. Distinctive:

    Keep outputs aligned across profile, methodology, work plan, staffing, and pricing.

    line 143
  23. Very specific:

    When a skill exposes Use When, Do Not Use When, Required Inputs, Workflow, Quality Standards, Anti-Patterns, and Outputs, follow those …

    line 144
  24. Very specific:

    Keep active skills under skills/ unless the repository architecture is explicitly changed.

    line 147
  25. Very specific:

    Do not duplicate logic into parallel Claude-only and Codex-only files when one SKILL.md can serve both.

    line 148
  26. Very specific:

    If you modify or add skills, keep frontmatter limited to name, description, and portable metadata as defined by …

    line 149
  27. Distinctive:

    Follow the local authoring standard and start new work from the skill template.

    line 154
  28. Very specific:

    Every active skill requires neighbour-aware positive and negative triggers, input/output/evidence contracts, capability and permission …

    line 155
  29. Very specific:

    Run python3 -X utf8 scripts/validate_skills.py --baseline quality-baseline.json and python3 -X utf8 scripts/routing_smoke_test.py before …

    line 157
  30. Very specific:

    Run python3 -X utf8 scripts/encoding_link_gate.py before release to reject invalid UTF-8, verified mojibake markers, broken local Markdown …

    line 158
  31. Distinctive:

    Run the canonical scanner and canonical quick validator for each changed skill directory, then the skill-safety and anti-slop gates.

    line 159
  32. Very specific:

    Run python3 -X utf8 scripts/source_ingestion_guardrail.py.

    line 160
  33. Very specific:

    Use python where python3 is not on the path (for example on Windows).

    line 161
  34. Distinctive:

    When the trigger fires:

    line 181
  35. Very specific:

    Read the relevant doctrine reference file in the finance engine (chwezi-accounting-doctrine (catalogue binding)).

    line 184
  36. Very specific:

    Read the corresponding finance skill SKILL.md in the finance engine (chwezi-accounting-doctrine (catalogue binding)).

    line 185
  37. Very specific:

    Check docs/source-registers/2026-10-currentness.json before reusing volatile procurement or AI claims.

    line 230
  38. Very specific:

    Every record there has a review date of 2026-11-30, and scripts/validate_skills.py fails from 2026-12-01 until each record is re-verified …

    line 232

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Proposal Skills Repository

Codex-only model setup and Kaizen review

Apply this section only when the active runner is Codex. Claude and other runners must skip it and retain their own models and full engine capabilities.

Before substantive Codex work, resolve this engine's directory and an available Python 3.11+ interpreter (use its absolute path if absent from PATH), then run python <engine-root>/.codex/ensure_model_policy.py --runtime codex --check. If it reports configuration drift, Peter authorises the bounded --runtime codex --apply repair, followed by --check. The helper backs up changes and preserves unrelated settings. If Python or configuration access is unavailable, report the limitation; do not replace the user's config wholesale. Read .codex/model-policy.md for the full contract. Use Luna (gpt-6-luna) with high reasoning by default for orchestration, research, audit, review, and implementation. Use Astra (gpt-6-astra) only when Peter explicitly selects it for the task; never select or fall back to GPT-5.6. Report unavailable required GPT-6 models. A running session may need restarting for root settings to apply.

Every Kaizen cycle MUST check latest official model releases and actual runtime availability, record dated evidence and a retain/change decision, and evaluate better candidates before recommending replacement. Preserve the pins until Peter authorises a verified change. Missing model-currentness evidence is NOT_ASSESSED. This Codex adapter must not change CLAUDE.md, Claude configuration, domain doctrine, permission settings or skill access.

Universal agent integration

See .skills-engine/engine-manifest.yaml for the declarative contract used by the optional universal coordination package. The router and domain SKILL.md files remain authoritative.

The package may read the router, discover skills, inspect Git, and run only declared checks. Missing evidence is NOT ASSESSED; writes, pulls, publication, submissions, ledger/filing changes, deployment, or control changes require explicit approval.

Project context: if the working project root holds a PROJECT.md with project_schema: 1, read it before planning. It points to this engine's own context sources and never replaces them.

Rules

Always-on cross-cutting principles live in rules/ — see rules/README.md. Load rules/common/core.md alongside the routed skill for any non-trivial task; it is short and does not replace the skill, only sets the baseline the skill operates within.

Mandatory Digital Research currentness gate for Kaizen

Every Kaizen audit, skill edit, reference update, validator change, and standardisation decision MUST begin with the Digital Research Engine at the catalogue binding digital-research-engine. Read its source-evaluation and source-verification skills and the currentness gate reference docs/continuous-improvement/kaizen-currentness-gate.md.

Before admitting any standard, policy, law, technology, platform capability, software version, command, security control, benchmark, or lifecycle claim, record source scope, publication/version date, access date, freshness class, review date, support status, and uncertainty. Use current authoritative primary sources; quarantine stale/ambiguous/unsupported claims and mark them NOT_ASSESSED. Books are durable concept inputs only.

Shared agent, command, hook, evidence, and handoff behavior is mapped for proposal work in docs/control-plane-adoption.md and governed centrally by chwezi-dev-engine/docs/engine-control-plane.md (resolve through the catalogue).

This repository is a dual-compatible skill system for consulting proposals, procurement responses, and related writing workflows. Active skills live under skills/; load the relevant skills/<skill-name>/SKILL.md file directly.

The canonical, model-neutral rules and routing remain in AGENTS.md, README.md, and skills/SKILL.md. CLAUDE.md is only the Claude Code discovery bridge that imports this file; keep it free of duplicated policy.

Baseline Rules

  • Kaizen is mandatory across the engine. Load skills/meta/kaizen-improvement-system/SKILL.md for engine/product audits and book-driven improvement; cap published audits at 65/100 and make every plan target 95/100 with evidence and re-audit dates.
  • Treat each SKILL.md as the execution contract and nearby references/ files as deeper supporting material loaded only when needed.
  • Book extractions and book summaries must never be stored in this repository, in any folder or under any name (owner rule, 2026-09-23; the former book-extractions/ folder was removed). Book knowledge lands only as task-oriented SKILL.md and references/ guidance with a short citation (author, year, title, publisher); see skills/writing-content/premium-commercial-writing/references/copyright-safe-source-use.md.
  • References must not be single-book digests. Organise every references/ file by this engine's task or workflow, synthesise across sources in the engine's own order and wording, and apply named frameworks with brief attribution. Do not reproduce a book's lists in its sequence with its item titles, its case studies, or near-verbatim text (owner rule, 2026-09-24).
  • Books and other copyrighted sources may inform independently written skills, but raw books, OCR output, chapter reconstructions, and long extracts must never be stored in this repository. Keep source files outside the repository, retain only the minimum facts or framework needed, attribute where appropriate, and run python -X utf8 scripts/source_ingestion_guardrail.py before accepting skill changes.
  • Every SKILL.md must include this exact acknowledgement line immediately below the first top-level # ... heading, not in frontmatter: Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
  • Load skills/profiles-sectors/profiles/SKILL.md before drafting any proposal text so voice, signatory, and proposer identity stay consistent.
  • Use skills/profiles-sectors/sectors/SKILL.md to decide which procurement framework and industry sector skills apply.
  • Use skills/strategy-positioning/critical-analysis-business-logic/SKILL.md as the reasoning, business-sense, feasibility, and achievability gate for high-stakes proposal content and final review.
  • Apply skills/meta/anti-ai-slop/SKILL.md as a real-time guardrail while writing every proposal section, then run skills/meta/ai-slop-audit/SKILL.md after each section or major iteration and as the final gate before submission; a grade of F (Blocked) blocks submission until the blocking findings are fixed.
  • Keep technical and financial proposal content separate when the procurement process requires separate envelopes or forms.

Task Routing

  • Full proposal orchestration or section drafting: start at skills/SKILL.md
  • Proposal identity and voice: skills/profiles-sectors/profiles/SKILL.md
  • Procurement and sector routing: skills/profiles-sectors/sectors/SKILL.md
  • Proposal sections: use the numbered section skills under skills/pipeline/01- through skills/pipeline/10-
  • Caps, weights and Data Sheets: when a solicitation caps pages, words or files, weights its criteria, or states its rules in a Bid Data Sheet or Data Sheet, read skills/pipeline/06-methodology/references/weighted-page-budget-and-compliance-matrix.md before drafting and check the allocation with python -X utf8 scripts/page_budget_check.py; the solicitation overrides the default section lengths
  • Supporting proposal domains: use unnumbered skills such as skills/domain-delivery/project-management/, skills/domain-delivery/monitoring-and-evaluation/, skills/domain-delivery/risk-management/, skills/domain-delivery/stakeholder-engagement/, and related folders when the ToR or methodology needs that domain
  • GIZ / EU / BMZ local procurement responses: use skills/domain-delivery/giz-eu-local-procurement-response/ when a tender includes GIZ AVB/local application requirements, two technical/financial zip folders, a GIZ assessment grid, self-declaration, price schedule, technical threshold, or GIZ clarification protocol.
  • EAC e-commerce BDS / digital trade programme design: use skills/domain-delivery/eac-ecommerce-bds-programme-design/ for donor-funded company selection, needs assessments, tailored technical assistance, expert-pool deployment, results-based monitoring, and lessons-learned/scaling methods.
  • Retail transformation and retail software proposals: use skills/domain-delivery/retail-transformation-proposal/ when the assignment includes retail, omnichannel, e-commerce operations, POS, merchandising, pricing, promotions, markdowns, loyalty, CRM, fulfilment, returns, store operations, shrink, vendor funding, private label, planogram, new-store opening, or retail KPI/WBR work.
  • Website design and development proposals: use skills/strategy-positioning/website-design-proposal-strategy/ whenever a proposal includes a website, SEO-ready site, landing page, ecommerce, portal, web app frontend, content hub, or website costing component
  • AI and technical transformation proposals: use skills/strategy-positioning/ai-transformation-proposal/ plus skills/profiles-sectors/references/technical-strategy-credibility-checklist.md for AI, SaaS, software, cloud, API, integration, data, or operations claims
  • Premium, executive, and high-ticket proposals: use skills/strategy-positioning/premium-client-proposal-strategy/ and skills/strategy-positioning/premium-pricing-and-value-defense/ when value, proof, pricing confidence, or premium-rate defence matters
  • Premium commercial writing: use skills/writing-content/premium-commercial-writing/ when proposals, cover letters, executive summaries, case studies, business documents, or blogs need stronger proof, evaluator-friendly structure, premium-fee-worthy language, or SEO/AI-search friendliness where relevant
  • Proposal language standard: before drafting any section, write the seven-paragraph power-paragraph sheet with skills/writing-content/premium-commercial-writing/references/proposal-power-paragraph-method.md, then draft from skills/writing-content/premium-commercial-writing/references/proposal-phrase-bank.md (section-by-section slot-templates, the client's own words, cost of doing nothing, price-first cost paragraphs, specific closes).
  • Key accounts: use skills/strategy-positioning/key-account-pursuit-and-account-plan/ for strategic-account selection, pragmatic strategy, GRASP stakeholder mapping, relationship targets, Account Cube expansion, value co-creation, executive sponsors, one-page account plans and strategic-account negotiation across several proposals.
  • Orals and presentations: use skills/strategy-positioning/tender-orals-and-proposal-presentation/ for tender orals, shortlist interviews, proposal walk-throughs and pitch meetings (strategy sheet, storyboard, rehearsal rubric, hard questions, room and equipment readiness); visual execution goes to chwezi-design-engine.
  • Marketing, digital-marketing and advertising service proposals: read skills/strategy-positioning/premium-client-proposal-strategy/references/marketing-and-digital-services-proposals.md; hand marketing-plan substance to business-plan-skills (marketing-plan orchestrator) and digital marketing, social and advertising substance to social-media-skills, keeping the proposal's win logic, offer, scope and commercial terms here.
  • Discovery and objections: use skills/strategy-positioning/sales-discovery-and-objection-handling/ when buyer assumptions, clarification questions, price objections, risk concerns, timeline objections, or follow-up logic matter
  • SaaS implementation and SaaS product-development proposals: use the skills/saas-* skill family (saas-discovery-and-qualification, saas-business-case-and-roi-modeling, saas-pricing-and-packaging-proposal, saas-implementation-methodology, saas-poc-and-pilot-scoping, saas-procurement-and-security-questionnaire, saas-customer-success-and-adoption-proposal, saas-mutual-action-planning-and-close-plans, saas-vertical-positioning, saas-objection-handling-and-competitive-displacement, saas-lifecycle-communications-as-deliverable, saas-trust-and-compliance-credentials-section, saas-multi-tenant-architecture-credibility-block, saas-pilot-to-rollout-change-management) for control plane / application plane methodology, tenant isolation, MEDDPICC qualification, MAP, business case, customer success, lifecycle communications, trust and compliance, and vertical positioning
  • AI-on-SaaS proposals (multi-tenant SaaS + AI features such as RAG, copilots, agents, AI analytics): use the skills/ai-on-saas-* skill family (ai-on-saas-combined-methodology, ai-on-saas-discovery-and-qualification, ai-on-saas-business-case-and-roi, ai-on-saas-pricing-and-packaging-proposal, ai-on-saas-poc-and-pilot-scoping, ai-on-saas-risk-and-responsible-ai, ai-on-saas-compliance-credentials, ai-on-saas-procurement-and-questionnaire, ai-on-saas-change-management-and-adoption, ai-on-saas-team-composition, ai-on-saas-vertical-positioning) for the three-plane methodology, eval discipline, hallucination SLO, Responsible-AI commitment, AI pricing patterns, AI procurement questionnaire pack, and AI vertical positioning. The headline skill is skills/ai-on-saas-proposals/ai-on-saas-combined-methodology/. Use skills/strategy-positioning/ai-transformation-proposal/ for generic AI strategy where there is no SaaS layer.
  • AI-agent / multi-agent product proposals (autonomous LLM systems that plan, call tools, decide, and act — as stand-alone products, multi-agent systems, or agentic layers inside SaaS): use the skills/ai-agent-* skill family (ai-agent-discovery-and-qualification, ai-agent-business-case-and-roi, ai-agent-pricing-and-packaging-proposal, ai-agent-poc-and-pilot-scoping, ai-agent-methodology, ai-agent-risk-and-responsible-ai, ai-agent-compliance-credentials, ai-agent-procurement-and-questionnaire, ai-agent-change-management-and-adoption, ai-agent-team-composition, ai-agent-vertical-positioning) for the eight-phase agentic methodology (Discover → Action-Catalogue → Architecture → Build → Shadow → Supervised → Agentic → Operate), autonomy-level discipline, action catalogue with reversibility classification, kill-switch architecture and drill, action audit log to regulator-grade, agent pricing patterns (per-resolution / per-outcome / per-step / per-agent / hybrid / success-based), Responsible-AI Agent Commitment with named Agent Safety Lead, agent procurement Q&A, trust staging, and agent vertical positioning. Headline skill is skills/ai-agent-proposals/ai-agent-methodology/. Load alongside the ai-on-saas-* family when the agent lives inside a multi-tenant SaaS product. Use skills/strategy-positioning/ai-transformation-proposal/ for generic AI strategy where there is no agentic deliverable.
  • AI-agent commercial, SLA, and contractual layer (agent SLA classes with credit schedules, refund and abort mechanics, MSA / SLA addendums, outcome-pricing structures, packaging shapes, procurement-objection responses on commercials, renewal mechanics): use the skills/ai-agent-commercial/ai-agent-sla-and-credit-schedule, skills/ai-agent-commercial/ai-agent-commercial-packaging, skills/ai-agent-commercial/ai-agent-contract-language-pack, skills/ai-agent-commercial/ai-agent-success-fee-and-outcome-pricing, skills/ai-agent-commercial/ai-agent-intervention-credit-and-abort-refund, skills/ai-agent-commercial/ai-agent-msa-and-sla-addendum-templates, skills/ai-agent-commercial/ai-agent-procurement-objections-on-commercials, and skills/ai-agent-commercial/ai-agent-renewal-and-true-up skills. Load alongside skills/ai-agent-proposals/ai-agent-pricing-and-packaging-proposal when the proposal moves from value narrative to contract-grade exhibits (Pricing Exhibit, SLA Exhibit, Credit and Refund Exhibit, MSA Addendum, Abandonment-and-Refund Policy, Dispute Resolution and Audit Rights, Vendor Cost Pass-Through, Renewal Clauses, Outcome-Pricing Clauses). Vertical SLA variants for financial services, public sector, and healthcare live under skills/profiles-sectors/references/ai-agent-sla-financial-services.md, ai-agent-sla-public-sector.md, and ai-agent-sla-healthcare.md.
  • Service design and support: use skills/strategy-positioning/service-design-proposal-strategy/ for journeys, blueprints, co-creation, and service implementation; use skills/strategy-positioning/customer-service-and-maintenance-proposals/ for SLAs, support, escalation, maintenance, and post-launch optimisation
  • Proposal narrative: use skills/strategy-positioning/proposal-storytelling-and-evaluator-journey/ when the proposal needs an evaluator journey, case-story spine, design rationale, or presentation/sign-off flow
  • Serious analysis and business logic: use skills/strategy-positioning/critical-analysis-business-logic/SKILL.md before methodology, work plan, financial, transformation, and final-review outputs
  • Language and tone: use skills/language/east-african-english/SKILL.md, skills/language/language-standards/SKILL.md, and skills/writing-content/premium-commercial-writing/ as cross-cutting review layers when commercial polish, proof, or premium value matters
  • Skill maintenance: use skills/meta/skill-writing/SKILL.md, skills/meta/skill-safety-audit/SKILL.md, and skills/meta/update-claude-documentation/SKILL.md
  • High-stakes bid red-teaming: use skills/meta/bid-red-team-dual-review/SKILL.md for adversarial two-independent-reviewer verification (both must PASS, max 3 iterations, fresh reviewers each round) with a compliance-sensitive rubric extension, when the stakes exceed what the routine ai-slop-audit gate tests. Use alongside kaizen-improvement-system step 6's red-team pass, not instead of it.
  • Submission proof for deadline/receipt-bearing tenders: use skills/meta/submission-proof-and-receipt-discipline/SKILL.md to fingerprint the exact submitted files and hold a durable receipt of what was sent, when, to whom, after the relevant submission checklist (e.g. giz-eu-local-procurement-response) has passed its mechanical checks.
  • Anti-slop quality gate: use skills/meta/anti-ai-slop/SKILL.md as a real-time guardrail on every section while writing, and skills/meta/ai-slop-audit/SKILL.md to grade each section or iteration (A/B/C/F) and as the final gate before submission; grade F blocks submission. These pair with skills/strategy-positioning/critical-analysis-business-logic/SKILL.md, which tests the reasoning
  • Blog workflows: use skills/writing-content/blog-idea-generator/ and skills/writing-content/blog-writer/ only for content publishing tasks, not for proposal work

Document and Spreadsheet Tooling

  • Before promising .docx, .pdf, .xlsx, application registers, scoring matrices, price schedules, budgets, dashboards, CV packs, or annexes, check whether document and spreadsheet tooling is available on the machine.
  • Prefer available Codex/Claude document and spreadsheet plugins. If unavailable, use local Python libraries such as openpyxl, XlsxWriter, pandas, python-docx, docxtpl, docxcompose, pypandoc, markdown, PyMuPDF, pypdf, pdfplumber, and reportlab.
  • Check binaries such as pandoc, LibreOffice/soffice, wkhtmltopdf, and tesseract where the output route needs them.
  • Run a minimal DOCX/XLSX smoke test on a new machine before production export.
  • Never claim a generated Word, PDF, or Excel file exists unless it was actually written and opened or validated.

Cross-Engine Handoffs

  • Proposal to SRS: when a bid is won or a proposal becomes delivery scope, hand off the ToR, final technical proposal, methodology, assumptions, exclusions, support promises, pricing options, evaluation criteria, and clarification responses to the SRS engine (chwezi-sdlc-documentation) for PRD/SRS, governance, acceptance criteria, evidence, and rollout planning.
  • Proposal to marketing plan (business-plan-skills): when a proposal sells a marketing plan, hand over the brief, objectives, budget ceiling, markets and evidence gaps; the plan structure and SMART objectives come back for the methodology.
  • Proposal to digital marketing and advertising (social-media-skills): hand over approved scope, audience, channels, measurement expectations and commercial boundaries; channel strategy, campaign method and reporting design come back. Never promise reach, engagement or conversion figures without data.
  • Proposal to website delivery: for website-only or website-led work, hand off approved scope, purpose statement, asset ownership register, care-plan commitments, discovery notes, sitemap/content/SEO assumptions, design rationale, launch commitments, acceptance criteria, support package, and commercial boundaries to the website engine (website-skills).
  • Proposal to implementation: route software, SaaS, AI, cloud, integration, API, security, data, and operations promises through the SRS engine first where formal requirements are needed, then to the engineering engine (chwezi-dev-engine) for production implementation.
  • Implementation to maintenance/support: ensure the proposal's support, SLA, escalation, warranty, maintenance, and optimisation language matches the final runbooks, release evidence, incident process, and retainer model.
  • Website launch to growth/retention: renewal, QBR, experimentation, observability, retention, and support findings can become proposal inputs for retainers, enhancements, and change requests.

Working Model

  1. Identify the user's actual deliverable.
  2. Load skills/SKILL.md when the deliverable spans multiple proposal sections or domains.
  3. Load only the directly relevant section, domain, sector, and framework skills.
  4. Read local references/ files only when they add material value to the current task.
  5. Draft or revise the output, then run a final pass for tone, consistency, and compliance.

Quality Expectations

  • Prefer concrete, evaluator-facing language over generic corporate boilerplate.
  • Make the logic visible: claim, evidence, warrant, assumption, countercase, and implication should be clear for load-bearing proposal claims.
  • Do not call a proposed approach convincing, innovative, or high-value unless it is feasible under the team, time, budget, client data, approvals, and country constraints.
  • Use British English and East African professional tone for proposal work unless the active skill says otherwise.
  • Keep outputs aligned across profile, methodology, work plan, staffing, and pricing.
  • When a skill exposes Use When, Do Not Use When, Required Inputs, Workflow, Quality Standards, Anti-Patterns, and Outputs, follow those sections as the default contract.

Change Safety

  • Keep active skills under skills/ unless the repository architecture is explicitly changed.
  • Do not duplicate logic into parallel Claude-only and Codex-only files when one SKILL.md can serve both.
  • If you modify or add skills, keep frontmatter limited to name, description, and portable metadata as defined by docs/skill-authoring-standard.md; keep the body execution-oriented and move heavy detail into directly linked references/.

July 2026 authoring and release gate

  • The active catalogue is every SKILL.md under skills/, including skills/SKILL.md; discover it from the filesystem and keep the documented count aligned with machine output.
  • Follow the local authoring standard and start new work from the skill template.
  • Every active skill requires neighbour-aware positive and negative triggers, input/output/evidence contracts, capability and permission boundaries, degraded mode, a decision table, stop and recovery workflow, observable quality standards, five corrected anti-patterns, and direct references.
  • Analysis, review, critique, planning, and audit procedures default to read-only. Mutation, publishing, submission, spending, destructive action, and certification claims require explicit authority.
  • Run python3 -X utf8 scripts/validate_skills.py --baseline quality-baseline.json and python3 -X utf8 scripts/routing_smoke_test.py before release. The baseline must stay at zero findings; it is not a waiver.
  • Run python3 -X utf8 scripts/encoding_link_gate.py before release to reject invalid UTF-8, verified mojibake markers, broken local Markdown links, machine-specific paths outside dated records, and stale device-specific sibling-engine routes.
  • Run the canonical scanner and canonical quick validator for each changed skill directory, then the skill-safety and anti-slop gates. Grade F blocks release.
  • Run python3 -X utf8 scripts/source_ingestion_guardrail.py; any finding blocks release. Do not bypass the gate by renaming, compressing, splitting, or moving source material.
  • Use python where python3 is not on the path (for example on Windows). The README validation table lists every check, what it needs and its expected result.

Finance & Accounting Trigger

For finance/accounting/IFRS/IAS work, use the finance engine at chwezi-accounting-doctrine (catalogue binding) whenever the user's request, the artefact being generated, or the code being edited touches any of:

  • Money flows: sales, purchases, payments, refunds, credit notes, expenses
  • Stock and inventory
  • Payroll
  • Tax (VAT, PAYE, WHT, NSSF, income tax, customs, excise, EFRIS, eTIMS)
  • Grants, donations, donor restrictions
  • Banking, mobile money, POS, card settlement, cash drawer
  • Fixed assets
  • Financial reports, management accounts, statutory returns
  • Chart of Accounts, journals, ledger, posting services, period state, audit trail
  • Reconciliation, close, migration, opening balances
  • Internal controls, audit, evidence packs
  • Any IFRS or IFRS for SMEs section

When the trigger fires:

  1. For finance/accounting/IFRS/IAS work, use the finance engine at chwezi-accounting-doctrine (catalogue binding).
  2. Read the relevant doctrine reference file in the finance engine (chwezi-accounting-doctrine (catalogue binding)).
  3. Read the corresponding finance skill SKILL.md in the finance engine (chwezi-accounting-doctrine (catalogue binding)).
  4. Apply the finance & accounting quality gate from the finance engine (chwezi-accounting-doctrine (catalogue binding)).
  5. Record the gate run in the artefact manifest.

The finance-module-audit skill (the corresponding skill in the finance engine, chwezi-accounting-doctrine (catalogue binding)) auto-runs whenever the user asks to analyse, review, audit, build, propose, or replace any software system with even a slight finance element.

<!-- chwezi-design-engine:trigger v4 -->

Design / typography / UI/UX (cross-cutting — consult IN ADDITION)

Any work touching how an artifact LOOKS — font/typeface choice, type scale, colour, layout/grid, visual identity, web/desktop/mobile UI screens, or the visual formatting of a DOCX/PPTX/PDF/XLSX — routes to the chwezi-design-engine engine, the single home for ALL design/UI/UX skills and the anti-AI-slop doctrine.

Resolve its location on THIS device from the active runner's global engine-routing table or AGENTS.md — never assume an absolute path; it varies per machine. Then read its README.md → doctrine/design-doctrine.md → glob skills/**/SKILL.md fresh and route by frontmatter (read SKILL.md directly, not via the Skill tool). Content and structure stay in THIS engine; presentation comes from chwezi-design-engine. Hard rule: never use a banned AI-slop font as primary type — hard ban: Inter, Geist, Roboto, Open Sans, Lato, Arial, Fraunces, IBM Plex (all faces); secondary ban: Space Grotesk, Instrument Serif, Instrument Sans, Poppins, Montserrat, Nunito, Nunito Sans, Newsreader, Cormorant (all cuts), Crimson Pro, Plus Jakarta Sans, DM Sans, Outfit, Playfair Display, Lora, Space Mono; Roboto Mono and IBM Plex Mono are banned as monospace choices; Source Sans 3 only as a paired body face; no bare system stacks alone. State the chosen typeface and reason before producing any artifact.

<!-- /chwezi-design-engine:trigger -->

Human-English editorial standard (2026-08 Kaizen)

Every proposal, bid, EOI, cover letter, executive summary, methodology, case study, and evaluator-facing message must load the human-English editorial standard and the proposal phrase bank alongside the profile, ToR, section skill, critical-analysis, and anti-slop gates. Apply its five passes and preserve evaluator-specific register, proof, compliance language, and honest delivery constraints.

The required result is readable British English with concrete verbs, accurate grammar and collocation, purposeful rhythm, visible judgement, and no copy-pasted prestige language. Do not simulate a human voice with errors, forced warmth, unsupported claims, or invented credentials. Record the buyer/purpose, claim-proof map, terms checked, revision/proof status, gaps, reviewer, and date.

DOMAIN PROMPT GENERATION CONTRACT

For a prompt handoff, read the local domain prompt contract. Generate a ready-to-paste prompt with buyer/decision, ToR, win or compliance objective, evidence, delivery proof, evaluator logic, commercial and language constraints, output, and red-team checks. Never invent credentials or proof. Ready-to-paste prompt: include assumptions, evidence/rights flags, and next action. Failure action: repair one unsupported section or regenerate the argument structure.

PORTFOLIO CRAFT CONTRACT

Load chwezi-engine-agents/docs/operations/portfolio-craft-standard-2026-09-04.md through the catalogue when available. Craft a proposal section by section: frame the decision-maker and win thesis, select one argument or compliance response, inspect the brief and evidence, draft the smallest persuasive unit, test it against the evaluation logic and counter-case, refine the language and layout, and record source, review, and acceptance evidence. Keep delivery proof, assumptions, risks, commercial logic, and next action visible. Do not produce a generic full proposal as an opaque batch. Apply Observe -> Baseline -> Select -> Experiment -> Check -> Standardise -> Teach -> Re-measure to kaizen itself. Missing source, compliance, financial, design, render, reviewer, or authority evidence is NOT ASSESSED, never a pass.

October Kaizen evidence is in docs/kaizen/2026-10-engine-kaizen/; pass 2 (31 October 2026) is in docs/kaizen/2026-10-engine-kaizen-pass-2/. The skill validator also scans every skill for retired World Bank form labels (scripts/check_form_labels.py), the link gate rejects machine-specific paths, and scripts/proposal_fixture_check.py --check-content scans a package's envelope files for cross-envelope leaks. Check docs/source-registers/2026-10-currentness.json before reusing volatile procurement or AI claims; scoped support never substitutes for the issued RFP. Every record there has a review date of 2026-11-30, and scripts/validate_skills.py fails from 2026-12-01 until each record is re-verified against its source. The skill validator also enforces marketplace parity, source review dates and the hard 5,000-entry limit for both package and complete checkout.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.