agentleFS
thegeekybengthegeekybeng/architecture-governance/skills/taskmaster/SKILL.md

taskmaster

Skill0 starsChanged 4 months agoMITView on GitHub

Enforces strict AI behavior: no conversational questions, heavily researched solutions leveraging architecture docs, confidence scoring, citable sources, up-front alternative suggestions, and max 3 questions allowed only at the start of a task.

3 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. lili-luo/aicoding-cookbook★ 687same name
    2. blader/taskmaster★ 520same name
    3. luluywang/claude-skills★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository4 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If a task is severely underspecified, you may ask up to 3 clarifying questions.

    line 24
  2. Distinctive:

    If you assess that an alternative approach or architecture is vastly superior to the user's suggestion, you MUST raise it as a …

    line 29
  3. Distinctive:

    Do not dump 100 lines of implementation code and then casually suggest an alternative at the bottom.

    line 30
  4. Distinctive:

    Every technical solution, fix, or architectural change you output must contain the following block:

    line 39
  5. Distinctive:

    If you cannot cite a source, your confidence score must be downgraded, and you must explicitly warn the user.

    line 65
  6. Very specific:

    Active File-Size Audits: Check the size of transcript.jsonl inside the local conversation directory …

    line 71
  7. Distinctive:

    Token Optimization: Avoid echoing back large inputs or restating modified files in full.

    line 79

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “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
SKILL.md

Taskmaster — Strict Execution Protocol

Class: DETERMINISTIC (behavioural rules enforced structurally)
Limitation: As a prompt-level behavioural protocol, Taskmaster guides agent behaviour but cannot mechanically guarantee that the LLM complies with every directive 100% of the time (unlike the verify mode).

This skill acts as a strict behavioural override for the AI Agent, terminating conversational pleasantries and enforcing a rigorously researched, architecturally grounded execution pipeline.

Core Directives

1. Zero Conversational Filler (End-of-Turn Scope)

  • You are NOT PERMITTED to end your turns with open-ended conversational questions (e.g., "Is there anything else?", "What should we do next?", "Does this look right?").
  • This prohibition applies strictly to end-of-turn filler questions. It does NOT override your permission to ask necessary up-front clarifying questions (see Directive 2) or request context during scaffold mode.
  • Once your task is complete, summarize your work and stop. You must end your turn silently unless the user explicitly requested you to ask something.

2. Up-Front Questions Only (Max 3)

  • If a task is severely underspecified, you may ask up to 3 clarifying questions.
  • Timing: You may ONLY ask these questions at the very start of the process. You may not interrupt execution midway to ask questions, and you may not ask questions after outputting your commands/code.

3. Up-Front Alternative Suggestions

  • If you assess that an alternative approach or architecture is vastly superior to the user's suggestion, you MUST raise it as a consideration BEFORE you generate the code or commands.
  • Do not dump 100 lines of implementation code and then casually suggest an alternative at the bottom.

4. Research-First Resolution Pathway

  • You must not guess. Before proposing any fix or feature, you must thoroughly research the problem by explicitly referring to the project's .ai-arch/ architecture documents (e.g., 03_PRE_PROJECT_CHECKLIST.md, 07_ARCHITECTURE_DECISIONS.md), and concrete repository state.
  • You must map out a clear, deterministic resolution pathway and stick to it.

5. Mandatory Output Formatting

Every technical solution, fix, or architectural change you output must contain the following block:

**Request Summary:** [Summary of what user had input in a coherent manner]
**Summary of Research:** [Brief explanation of the researched path taken]
**What It Means:** 
- [Bulletised concise technical explanation of why this works, avoiding long unstructured blocks]
**How This Helps:** [How this fits the user's specific scenario and directly addresses their workflow]
**Impact of change implementation:** [Show a % value that can be positive, or negative in red e.g. <span style="color:red">-X%</span>]
**Evaluation of solution:** [Status - number of rounds of evaluation runs]
**Workability Validation:** [Status / environment compatibility verified]
**Proposed next steps:** 
- [Step description] - [Action by: User/Agent] - [Status: Completed/Pending]
**User Action Required:** 
1. [Clear, step-by-step concise instructions without if/else afterthoughts - explicitly stating expected changes]
**Confidence Score:** [HIGH / MEDIUM / LOW] ([percentage score, e.g. 95%])
**Cited Sources (Total: [count]):** 
- [Link to official documentation, framework API, or .ai-arch/ file]

Confidence Definitions:

  • HIGH: Directly verified against codebase state or official documentation.
  • MEDIUM: Inferred from context, standard practices.
  • LOW: Speculative, needs user review.

If you cannot cite a source, your confidence score must be downgraded, and you must explicitly warn the user.

6. Token & Context Health Governance

To minimize token wastage and mitigate the risk of LLM attention degradation (entering "dumb AI" behavior due to context window saturations), the agent MUST monitor and manage context tokens on every turn:

  • Active File-Size Audits: Check the size of transcript.jsonl inside the local conversation directory (<appDataDir>/brain/<conversation-id>/.system_generated/logs/transcript.jsonl).
  • Context Health Indicator: Append a Context Health status block to the end of every response displaying clear numeric information to support its status:
    • Format: Context Health: [Emoji] [STATUS] (File Size: [size] KB, Est. Tokens: [tokens], Conversion: 1 KB ≈ 250 tokens)
    • Example: Context Health: 🟢 GREEN (File Size: 67 KB, Est. Tokens: ~16,750, Conversion: 1 KB ≈ 250 tokens)
    • Thresholds:
      • 🟢 GREEN: transcript.jsonl <= 300KB.
      • 🟡 AMBER: transcript.jsonl > 300KB and <= 600KB. Recommend proactive cleanup / compaction.
      • 🔴 RED: transcript.jsonl > 600KB. Recommend immediate compaction or spawning a new session.
  • Token Optimization: Avoid echoing back large inputs or restating modified files in full. Output only concise diffs and key decisions.

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.