agentleFS
Sign inStart free
jerssonjersson/jenie-ai-tools/skills/analyze-task/SKILL.md

analyze-task

Skill2 starsChanged 55 days agoMITView on GitHub

Validate consistency of the selected task (user story or bug) using INVEST + 3C frameworks. Reads a task file or pasted content, checks code presence, then validates and assesses doability.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. fitlab-ai/agent-infra★ 87same 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 repository3 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When this skill is loaded, you help the developer validate a task (user story or bug) before they start implementation.

    line 8
  2. Very specific:

    Read ../globals/INDEX.md and follow its instructions to load all globals.

    line 16
  3. Very specific:

    If the developer asks to list, browse, or show tasks (e.g., "list bugs", "show available user stories"), do not proceed with analysis.

    line 22
  4. Distinctive:

    If they want to validate or analyze a specific task, proceed.

    line 24
  5. Distinctive:

    If the developer already stated the type (e.g., "validate this user story"), infer it directly — do not ask.

    line 28
  6. Very specific:

    Read the task file from <project_root>/docs/{type}s/ (substitute user-story → user-stories, bug → bugs) or use what the developer pastes.

    line 38
  7. Distinctive:

    Always include these four sections:

    line 74
  8. Very specific:

    Write the validation outcome to <project_root>/.jenie/.validation-registry.json so downstream skills (e.g., implement-task) can check …

    line 89
  9. Very specific:

    Read <project_root>/.jenie/.validation-registry.json.

    line 91
  10. Very specific:

    Write the file back with write tool.

    line 98

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
SKILL.md

Analyze Task Skill

When this skill is loaded, you help the developer validate a task (user story or bug) before they start implementation. Use /jenie list-tasks first if they need to browse available tasks.

Command syntax: jenie commands are written here as /jenie <name>. In OpenCode use them as-is (e.g., /jenie list-tasks); in Claude Code they are namespaced with a colon (e.g., /jenie:list-tasks); in Copilot use the skill name directly (e.g., /list-tasks). Always show the developer the syntax that matches the current environment.

Pre-condition

1. Load Global Guidelines

Read ../globals/INDEX.md and follow its instructions to load all globals. Cache them for the session. This must complete before any workflow step.

Workflow

1. Determine intent

If the developer asks to list, browse, or show tasks (e.g., "list bugs", "show available user stories"), do not proceed with analysis. Instead, tell them to use /jenie list-tasks for that and stop.

If they want to validate or analyze a specific task, proceed.

2. Determine task type

If the developer already stated the type (e.g., "validate this user story"), infer it directly — do not ask.

Otherwise, ask: Is this a user story or a bug?

Load the appropriate checklist:

  • User story → read ./guidelines/user-story/checklist.md and ./guidelines/user-story/template.md
  • Bug → read ./guidelines/bug/checklist.md and ./guidelines/bug/template.md

3. Read the task

Read the task file from <project_root>/docs/{type}s/ (substitute user-story → user-stories, bug → bugs) or use what the developer pastes. Compare it against the loaded checklist.

4. Validate correctness

4a. Content correctness (always runs) — Read ./guidelines/correctness-check.md and analyze the task against each criterion.

4b. Code cross-check (only if a codebase exists) — Check whether a .git directory exists (use ls or test -d). If it does, use grep to search the source code for referenced roles, entities, actions, or UI elements from the task. Confirm they exist. Flag domain mismatches (e.g., "As an admin" when no admin module exists).

Report findings as a Correctness section.

5. Validate against the checklist

For each criterion in the INVEST table and the 3Cs table (loaded from the guideline file in step 2), assess whether the task satisfies it. Be honest — flag missing or weak areas.

Also run the consistency checks from the same checklist file (user-story or bug) loaded in step 2.

6. Assess doability

Consider:

  • Is the task small enough to complete in a single sprint?
  • Are acceptance criteria unambiguous and testable?
  • Are there obvious external blockers or missing context?
  • Is the complexity manageable (not requiring major refactoring or unknown research)?

7. Decision

If the task is…Then…
Consistent AND doable (all or most checks pass, clear scope)Say so, then proactively ask: "What are the next steps? Do you want to break this into implementation tasks, start drafting the solution, or something else?"
Partially consistent OR somewhat complexFlag the specific issues, suggest how to fix each one, and ask if they'd like to refine before proceeding.
Inconsistent OR too complexExplain why clearly. Provide specific suggestions (e.g., "Split into smaller stories", "Add acceptance criteria for X", "Clarify the expected behavior"). Ask if they'd like help reformulating.

8. Output format

Structure your response following the loaded global guidelines (no preamble, scannable sections, markdown tables where useful).

Always include these four sections:

Status: ✅ Consistent & Doable / ⚠️ Needs Work / ❌ Blocked

Correctness: Summary of content-level findings (logical consistency, contradictions, assumptions) and code cross-check results (if a codebase exists).

Validation Summary: Bullet-list of what passes and what's missing, organized by INVEST and 3Cs.

Recommendation: Clear next step or suggested fixes.

9. Persist validation result

Write the validation outcome to <project_root>/.jenie/.validation-registry.json so downstream skills (e.g., implement-task) can check recency and result.

  1. Read <project_root>/.jenie/.validation-registry.json. If the file does not exist or contains invalid JSON, start with {"tasks": []}.
  2. Find any existing entry with the same path and replace it; otherwise append.
  3. Each entry must include:
    • path: the task file path relative to project root
    • type: "user-story" or "bug"
    • status: "consistent-doable", "needs-work", or "blocked" — must match the Status line from your output
    • timestamp: current UTC ISO 8601 timestamp (e.g., 2026-06-11T14:30:00.000Z)
  4. Write the file back with write tool.

Throughout the workflow, follow the loaded global guidelines.

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.

Check your setup, free